Update: The RSS feed causing the problem with the plug-in installer has been restored as of September 28, 2017.
If you read this blog regularly, you know we love our plug-ins — the programs that run within the application that extend its usefulness in so many ways. Plug-ins have been part of both Sibelius and Finale for many years, becoming so essential to my workflow that it’s hard to imagine using either product without them. Indeed, both Sibelius and Finale ship with dozens of plug-ins, some of which are so embedded into the application that the average user may not know (or care) if a task is being done by a plug-in or by code in the core application.
In Finale, any plug-ins that don’t ship directly with the application are found on third-party sites. On the Sibelius side, however, the vast majority of extra Sibelius plug-ins — more than 500 at this time — are made available directly from Avid, free of charge.
Starting with Sibelius 7, users have been able to browse and install plug-ins directly in Sibelius from File > Plug-ins > Install Plug-ins. This was a big improvement from Sibelius 6 and earlier, when plug-ins had to be downloaded from the Sibelius web site, unzipped, manually installed into the correct folder, all without Sibelius running.
What makes the installer possible is an RSS feed that sends out the news of new and updated plug-ins to Sibelius. (At NYC Music Services, we also rely on it to display the latest plug-in updates on our Resources page.) When this works — which, up until now, has been nearly all the time — it’s a great service; it adds real value to Sibelius by making powerful tools easily discoverable.
However, since September 9, the RSS feed serving the plug-in updates has been broken, leading all users of Sibelius 7 and higher to see an empty screen where a big, bountiful list of plug-ins should be:
To be clear, you can still find the plug-ins and download them manually (the old-fashioned way), and, once installed, the outage does not impede how the plug-ins function.
So, what’s the big deal, you say? Well, the plug-in installer was really the first Sibelius feature (other than activation) that relied on an internet connection in order to function. Now, consider the new Cloud Sharing service that Avid announced last week that will be part of Sibelius 8.7. As described, it has the potential to be really cool — you share your scores online and embed them in all sorts of ways, such as blogs, social media, educational resources, and more.
There’s just one catch: It all relies entirely on your scores being processed and delivered online by Avid.
Now, to be fair, Avid says that the Sibelius | Cloud Sharing scores will be hosted on Avid’s MediaCentral Platform (running on Microsoft Azure) which delivers critical, time-sensitive assets to many large customers. A two week outage on MediaCentral — or even a two-minute outage — would be intolerable.
But the hosting platform is only one concern. Unlike with Scorch, you can’t just post your file on another site if your web site goes down — because the whole Cloud Sharing system is integrated, with the score’s assets being processed behind the scenes. It’s a strength but also a potential weakness. If someone builds a whole site or resource relying on displaying scores via Cloud Sharing, all the eggs are in that basket. So rock-solid confidence is needed.
What if there’s a bug in the Sibelius processor — the “headless” version of Sibelius that renders the score — that suddenly makes all of the scores unviewable, or prevents you from making important updates to existing scores? What if there’s a software or hardware update up or down the line that throws an unexpected wrench into the works — taking your scores offline?
I reached out to Sibelius senior product manager Sam Butler to address these concerns. “The maintenance and upkeep of Sibelius.com is completely different to our new MediaCentral Platform,” Sam said. “Sibelius.com is on old infrastructure and it’s doing quite well considering. You will have noticed more and more go from Sibelius.com onto an equivalent place on Avid.com (support pages, knowledge base etc.), and we’ll see more of this in due course. Avid.com runs on much more modern systems, including third-party infrastructure provided by SalesForce and CloudCraze, which both assure us maximum uptime. The industry standard is 99.9% uptime in any given year and we strive to achieve that on the Platform too.”
In reply to my questions, Sam said, “The Cloud Publishing Engine doesn’t talk to the Platform but simply takes scores in and renders various different assets. It can’t make other scores unviewable, much like opening one score on your computer can’t corrupt all your other files on that computer or even another server running on the network. The hardware this runs on is all on Microsoft’s side, although we manage the software what we put up there. Our staging environment is essentially a clone of what we have in production. We only promote things up to staging that our own QA have vetted on our separate development instance. Once in staging, we give it another more real-world test to make sure each of the four main Cloud Publishing components are working well. Only once it goes through that scrutiny, and our platform team are happy with it, we then push to production.
“The MediaCentral platform, on which Cloud Sharing, Cloud Publishing, Pro Tools Collaboration and a host of other great services run, couldn’t be more different from how Sibelius.com is managed,” Sam continued. It’s staffed round-the-clock to respond to any scenario. We have development and staging instances of the Platform that we can test new features and improvements on before they hit production, allowing us to ensure everything works as it should and doesn’t affect anything else that’s running on the platform. We have a huge amount of logging that goes on, allowing us to see exactly how every micro-service is running, with warning alarms and load balancers that go off when anything gets overloaded. Sibelius.com in comparison is completely different.”
The explanation provides a measure of reassurance for the upcoming sharing service, but the delay in fixing the current problem is still a source of frustration to users and developers alike. Let’s hope that the relatively obscure RSS feed for plug-ins is back online soon and that this episode is ultimately a blip in the larger scheme of things. But it’s also a reminder of the vulnerability of features that rely on a cloud service in order to work properly — especially one that processes and stores in cloud all of the assets needed for it to function, without those assets being available to the user.
Thanks for this – I went to install plugins last week and wondered if something was wrong with my install.
Thanks, Phil, for this informative post.
David, Tom: I’m glad you found this helpful. Thanks for reading.
“The industry standard is 99.9% uptime in any given year and we strive to achieve that on the Platform too”
Note that 99.9% uptime means that they can have over 8 hours 45 minutes outages in a year and still be able to boast that they’ve hit 99.9% uptime.
‘Uptime’ is also a slippery phrase and could mean lots of different things – so just because something is ‘up’ doesn’t mean that it’s actually available to the end-user (which is what the common-sense understanding of the phrase might be)
There is also the question whether planned outages count towards that total. Again common-sense says that they shouldn’t, but often you get boasts such as ‘we have 100% availability – apart from the 6 hour weekly back-up slots…’ which make a mockery of 99.9% uptime targets.
And what do the targets apply to? Does the two week outage to the plug-in installer count? that’s blown even 99% availability, which allows for 3 days, 15 hours and nearly 40 minutes of downtime per year.
For comparison, in Banking, for critical applications such as electronic funds transfer, the Holy Grail is true 99.999% availability (also know as the five nines) with good availability being close to 99.99% true availability. Probably overkill for Sibelius (or Avid) cloud availability, but…