Choosing a technology is a challenging step for businesses when building any application.
These days, there are plug-ins and modules to do pretty much everything from front end frameworks to complete back end solutions. Heck, there are plug-ins to install your plug-ins. So how do you choose which technologies are the best for your business?
They say “nobody ever got fired for buying IBM.” That’s an old saying that in the enterprise space is still true today. IBM is a safe, stable choice. How do you know which software solutions will be supported in a year from now? Six months? My original answer would have been to do your research on the developer(s)/author(s) and try to pick products that appear stable and well-maintained. History however, has shown me that this is a terrible answer. The monolith of Google has 30+ projects that have been cancelled after launching with a large amount of hype and press. So even the stability that comes with being a part of a large conglomerate like Alphabet doesn’t mean a product is safe from being discontinued.
The question is: what can you do to ensure continuity of service when the software you rely on goes belly-up?
The date is December 8th 2010. Later today, with the second launch of the SpaceX Dragon, SpaceX will become the first privately held company to successfully launch, orbit, and recover a spacecraft. The number one billboard topper is “Hey, Soul Sister.” Our hypothetical protagonist is Trevor, the CTO for a new radiology clinic in central Florida. His current assignment is to deliver a solution for secure document storage for all the company’s HIPAA sensitive documents, including healthcare records and imaging results.
After some exhaustive research, he chooses Google Health. He found that the project was introduced in 2008 after 2 years of development and multiple pilot tests with reputable contributors in the world of healthcare. Moreover, a few months earlier the entire Google Health interface had been completely revamped with a new look and feel, which of course, was accompanied by another round of press.
This is Google, what could possibly go wrong? Confident in his selection, the board is easily persuaded that this is the best choice. Six months after implementing Google Health, on June 24, 2011, Google announces it will be retiring Google Health on January 1, 2012, with data being available for download through January 1, 2013.
Not only will the organization have to decide on a new document storage solution, they will now have the challenge of migrating all the documents and data from one data structure/architecture to another. For even a small clinic this amounts to roughly 20TB of data, all of it which must be handled in ways that meet HIPAA standards.
This is no minor feat. Trevor's clinic now has a massive, expensive snag on its hands. And really? It's not even Trevor's fault. He chose a reputable product from a massive company- and wound up in serious trouble as a result.
This is not a one-off scenario, nor is it a strictly hypothetical one. Even huge, supposedly stable services leave the playing field, and it happens all the time. Seriously, I'm not joking. There are millions of software products out there, and most won’t be around for even five years.
Partner Case Study: Migrating from Parse
Now that you're good and scared, let's talk about a real-world company that ran into a discontinuation.
Facebook’s Parse is a back-end tool that lets developers store data in the cloud, manage identity log-ins, handle push notifications and run custom code in the cloud. It was a core component of the tech stack for one of our partners, a local startup which allows you to view bar and restaurant capacities from the convenience of an app.
Parse was founded in 2011 and sold to Facebook in 2013 for $85M. In 2014, Parse was reported to power more than a half million apps and was quickly becoming an industry standard. Yet on January 28, 2016, Facebook announced that it would close down Parse, with services effectively shutting down on January 28, 2017. I told you - this happens all the time.
Our partner came to us after Facebook announced it was closing its Parse developer platform, as their mobile application relied on Parse for log in, data storage and push notifications.
First, I want to give credit to Facebook for creating a self-hosted solution for the discontinuation of their product. However, this now puts the onus on an app’s tech team to ensure that their migrated instance of Parse is easy to maintain and has the ability to scale.
Migration is never a trivial task and things can go wrong, especially when you are a part of the “first wave” of migrations. During this “first wave” (usually during months 1-4) documentation is often hard to find and in most cases is very inconsistent. During my research in early April 2016, there were only a handful of articles to assist with migration and none of them proposed the same solution. Often one solution would contradict the other. Here are some of the basic questions I had, approaching the migration of Parse data:
Q: Which Mongo Db providers have datacenters in matching AWS availability zones?
A: Both mLab and ObjectRocket – This is important as latency between your self-hosted instance of Parse and Mongo cannot exceed 20ms.
Q: What size database do I need?
A: Due to data being compressed in the hosted Parse database, make sure to size your Mongo at least 3X the current amount of data storage you are using (you can find this information in your hosted Parse app's Analytics overview page). This is extremely important as your organization may find that they are now writing a check for what was once a free service.
Generally speaking, once the “first wave” of migration has ended, the documentation has been formalized and accounts for most everything you will encounter during migration including funky little edge cases. Such is the case with Parse. On April 29, 2016, four days after we successfully migrated our partner to their own hosted instance of Parse, Facebook released an updated migration guide which you can view here.
With very well-done diagrams included
After reviewing the new migration guide, I was pleased to find that it includes a general overview and timeline. Easy to understand, step-by-step instructions with references to the dependent technologies linked directly within the guide. The new migration guide accounts for all of the pain points encountered during our migration, including the questions I had previously had to find answers to through trial and error.
Partner Case Study: Losing an API
One thing that I do want to emphasize about discontinuations is that they often come from unexpected sources. Sure, small, niche services shut down, but so do large, well-maintained and financed ones.
The latest shutdown we've had to deal with was that of Echo Nest's web API. Echo Nest is a music data platform, and their now discontinued API was an important piece of an app we had built for one of our partners, a music-based social media platform. Without it, users were no longer able to see the artist news and reviews that Echo Nest's API had once surfaced.
Why did the discontinuation happen in the first place? It certainly wasn't because of poor service or technological shortcomings. No, the end of Echo Nest's API was spelled when the company was acquired by Spotify for an undisclosed amount of money after its wild success as a startup. Two years after the acquisition, Echo Nest gave its one-month notice, and was replaced by Spotify's web API.
Which takes us back to our partner's predicament. They were in the unfortunate spot of having a service that powered some of their app's features just vanish overnight. Fortunately, as with the Parse scenario, they weren't left entirely high and dry. Rerouting traffic from the Echo Nest API to Spotify's API replaced some of the functionality; however, news and reviews were more difficult to maintain. We commented out some code, and then had a decision to make.
Eventually, we opted to work on placing a short survey in the vacant section, opening the question of what to put there to the app's community. It's far from perfect, but it was within budget, gave our partner some definite value, and minimized the effects of the discontinuation - all things we aim for even in ideal development scenarios.
Discontinuations and You
At the risk of sounding alarmist, discontinuations are a consistent, unpredictable risk for any tech product. However, that's not to say that losing a service is cause for panic. Yes, it's a problem, and yes, it likely will take some fixing, but it's more of a roadblock than a dead end. A large, widely-used platform facing discontinuation will rarely disappear without warning. Instead, users will generally have a grace period, even if it's not a particularly long grace period, to find an alternative. And there is nearly always an alternative, often one provided by the same company or community that's facing the discontinuation.
Even with the brightest and most informed tech teams, maintenance is an unavoidable part of owning a tech product. As long as you have patience and funds set aside for it, you will be just fine.
Dealing with some unplanned obsolescence of your own? Mike and the rest of the LookFar development crew can help. Shoot us a question on our Codeology page, and we'll get back to you with a free video answer researched and recorded by a LookFarian expert.