The ground shook for a 600,000 strong developer community when Facebook ‘axed’ Parse.
The announcement met with disbelief, anger and anguish from Parse users. This was three months ago. Now disgruntled parse users are looking for a new Mobile Backend-as-a-Service, (MBaaS) and trying to navigate a tricky migration. Judging by the reactions, Facebook seems to have alienated a sizeable section of the developer family with this move.
Was it a Foolish Move?
Not if economics were Facebook’s priority!
To comprehend Facebook’s move, we need to go back to 2013 and understand why FB bought Parse in the first place.
Parse is a Mobile Backend-as-Service (MBaaS). It is essentially a set of tools for developers who are well-versed with front-end design but have little or no expertise in building a backend for their app. Parse was quickly lapped up by developers who welcomed the opportunity to focus on optimising their UI design. When Facebook acquired Parse, it did not have the booming mobile advertising business that it does now. It was still looking at different lines of business that could generate revenue. Exploring a cloud-as-service business was one of the many options it considered on route to profitability. Today, FB’s mobile advertising business is thriving and has led to a waning of interest in renting out its infrastructure. To truly compete with cloud providers like AWS and GCP, Facebook would have to make significant investments and add features to Parse. Even then it would be a standalone service while competitors would be offering a host of cloud computing services in addition to MBaaS. All of these challenges must have dissuaded FB from the cloud computing space and led to the decision to shut down Parse.
But, Facebook doesn’t seem completely oblivious to the ire parse shutdown would attract from the developer community. It has softened the blow by releasing migration support tools and by open sourcing the Parse Server, besides offering a year-long sunset period.
Facebook Has Good Reasons; Do You Have a Good Alternative?
Parse isn’t dead, by open-sourcing the Parse server Facebook has released it to the wider community which can now study how Parse’s API was built and add feature improvements. In the future, we may even see an alternative hosted service built by the open source community.
Alternatives: Firebase (bought by Google and integrates with Google App Engine sdk and Cloud Endpoints), Kinvey, Baasbox, Azure and Backendless are some of the promising ones you can explore.
Fool me once, shame on you; fool me twice, shame on me
CTO: Sir we found the right alternative to Parse, let’s use ‘……….’
CEO: What if this shuts down too? Should we not build and host our own backend?
This is the question on every parse victim’s mind. What if whichever service they choose goes the Parse way? This is a misplaced fear, and we will give you two simple tips to guide your choice:
- Use a competitively priced service over a free one. And select a small business that cares about customers and will grow with you.
- If you are tech product shopping, there is no safety in choosing a startup (Parse) or an internet giant (Facebook). You need to be prepared for a future when your business goals are not aligned and you will need to look for a new service.
Does this mean it can happen on App Engine or AWS too?
Never say, never!
While no one can guarantee that a service will continue to run forever. Companies which own the underlying infrastructure are far less likely to shut down services abruptly. For example, Microsoft Azure, AWS, and GCP have massive investments in the cloud business and are in it for the long haul.
What Google Cloud offers Mobile app developers?
Google provides end-end mobile app development services through products like Firebase, Cloud Endpoints and Google App Engine.
Firebase: Google acquired Firebase around the same time that Facebook acquired Parse. Firebase is a Back-end-as-service (BaaS) provider which supports real-time synchronization to help developers build real-time apps. The service will now run on Google infrastructure, providing better performance and scalability.
Cloud Endpoints: Developers can use Endpoints create an API backend for their App Engine applications easily.
Google Cloud Messaging (GCM): Is a separate service that lets you send messages and notifications (Push notifications) to users and receive messages on the same connection.
Google Cloud Platform allows you to choose a design that supports your needs.
The various design configurations that can be used to build a solid backend using Google services: The design patterns transition from fully managed (Firebase) to unmanaged platforms like Google Compute Engine.
Google has detailed the differences between these design patterns in a neat table:
|Feature||Firebase||Firebase & App Engine||Firebase & Managed VMs||App Engine &
|Compute Engine & REST/gRPC|
|Automatic capacity scaling||✔||✔||✔||✔||If you configure an autoscaler.|
|Automatic real-time data synchronization||✔||✔||✔|
|Automatic server maintenance||✔||✔||✔||✔|
|Call native binaries, write to the file system, or make other system calls.||✔||✔|
|Data storage||✔||✔||✔||If you add other Cloud Platform services||If you add other Cloud Platform services|
|Easy user authentication||✔||✔||✔||OAuth 2.0|
|Language support for backend service logic||N/A||Java, Python, Go, PHP||Any||Java, Python, Go (Cloud Endpoints for Go.)||Any|
|Messages and notifications, such as push notifications||✔with Cloud Messaging||✔with Cloud Messaging||✔with Cloud Messaging||✔with Cloud Messaging|
|Platform support||iOS, Android, Web||iOS, Android, Web||iOS, Android, Web||iOS, Android, Web||iOS, Android, Web|
|Requires code to run within asandbox.||✔||✔|
Google Cloud Platform maybe the right cloud to build your MBaaS on. It’s a complete platform that offers end-to-end mobile app development and limitless scalability at industry leading prices.