On Monday we announced that one of our largest enterprise IT customers is now using Kinvey as the backend for its mobile apps. What we didn’t talk about in that post is why they switched to Kinvey – the apps previously ran on FeedHenry, another “BaaS” provider (more on why BaaS is in quotes later) – and how they managed the migration. So let’s take a look at the Why and the How:
Managed service via vCloud Air
Kinvey is available as a managed service on vCloud Air, while our client’s FeedHenry instance was provided as an unmanaged configuration. As a result, they had significant costs related to monitoring and operations of the FeedHenry platform and the custom code running on it. Using the new model, they are able to fully realize the benefits of a true cloud based BaaS offering. This is why I’m putting FeedHenry’s “BaaS” designation in quotes – for our client, FeedHenry was more like an application platform as a service, with no real client library support, ease of updating discrete components, or code reuse capabilities. And why use a “BaaS” if you still have to manage it?
For our customer’s flagship app, the FeedHenry client libraries were not able to fully support their chosen development platform (Appcelerator Titanium), forcing them to write 100% custom code for the front end development. This custom development increased the initial development costs, resulted in code duplication, and has left an expensive code base to maintain. They are looking to simplify maintenance and feature development by leveraging Kinvey’s client libraries that support all of the development platforms that they use, including Titanium, PhoneGap, and other hybrid/native frameworks.
Ease of updating discrete components
Two of our client’s internal applications broke several months prior to the migration due to a change in a schema within a backend system. As a consequence of having node modules tightly coupled to the application, every time a node module changed (which was often), the app had to be re-compiled. Or, in business terms, that means that each of these changes led to an awful lot of downtime for tens of thousands of users. Development on Kinvey, on the other hand, allows for individual components to be upgraded as schemas change, allowing the front-end to be kept current and running without needing to go through a complete development cycle.
Since our customer was required to write all backend code for the application running on FeedHenry, they could only take advantage of code reuse at the source code level. If all three apps are integrating with the same backend system they must share a library to keep access the same, but due to the specific needs of each application the integration source code mutates in incompatible ways between each application. The Kinvey platform allows all backend access to use unified connectors and be customized by unique business logic associated with each application. This reuses as much code as possible and allows for very agile development of customizations.
This is my favorite part – the migration could hardly have been easier. We built a FeedHenry wrapper component to handle the server-side code our customer had used to support their apps, which effectively turns that code into a Datalink Connector for Kinvey. Then it was just a matter of updating the application code to point to that connector instead of to FeedHenry. Our client also upgraded their authorization flow to use OAuth (a best practice) instead of a custom auth solution they had developed for FeedHenry. In all, the migration took less than 30 days for development and testing.