Parse: 3 Lessons Learned

Last night the backend-as-a-service provider, Parse, which was acquired by Facebook in 2013, announced they were shutting down. They are offering a graceful migration over the course of the year. Whether you’ve tried the service or not, their aim was to make building software easier, and I think there are important lessons to learn from their work.


Building Applications Should Be Easier

Every time I go to build an application today, I’m frustrated by the state of the programming and the hosting ecosystem. I feel the pain of writing software — it shouldn’t be this hard, this is annoying, and this is annoying, and this is annoying. I know it could be much, much better. We need to bring more design-thinking to our programming tools. The problem is multi-faceted. It will get better. It already has.

Storing and interacting with your data is a core component of building software, and I believe backend-as-a-service providers have the right mindset in suggesting that storing and accessing data should be a lot easier than it is. We will build software using higher and higher levels of abstractions, and worry less and less about what’s happening under the hood. From assembly language, to programming languages, from managing our own physical servers, to colos, to AWS, from setting up our own databases, to leveraging hosted datastores like Parse and Firebase.

I’ve spent the past few years thinking about how to build a better hosted data store and application service than Parse, Firebase, App Engine and the other solutions that are out there, trying to understand what the core issues are. Recently, I got my Greencard on a National Interest Waiver for Entrepreneurship based on a business plan that I wrote to the US government which described what a future version of a backend-as-service might look like. Parse was one of the major inspirations.

My co-founder Kareem Amin and I are exploring what building this data store of the future looks like.

Parse’s announcement last night that they’re winding down the service gracefully seems like a good moment to thank them for their hard work, and also consider what lessons can be learned from Parse, and the current generation of hosting and Backend-as-a-Service (BaaS) providers.

Thank You

When you build a platform that takes care of an always-on, mission-critical aspect of customers’ businesses, you also inherently take on a lot of pressure. You’ve theoretically made things easier for your customers, but now, they’re also counting on you. To make things truly easier, you need to focus on delivering a ‘whole-product’ solution.

I commend people who take this on their shoulders, and I think we should all be appreciative of the work and commitment of the Parse team, and the teams behind any of these types of services. When there are issues, and there are are always issues, they’re the ones who get the calls and need to fix things straightaway. Stand the servers back up, fix the bugs. They’re the ones who are on ‘pager’ duty. That’s what you’re paying for: their shouldering the responsibility of managing your database, and making it much easier for you to just build. I am thankful to not have to shoulder the responsibility of managing my own physical servers, my own DB. I am thankful for at least getting to program in a programming language rather than assembly. I am thankful for getting to think and work in higher levels of abstraction, while also having access to understand how the lower levels work. All of this makes creating software feel lighter, more powerful, and more enjoyable. I can only imagine how much lighter creating software will feel in the future, as we move to even higher levels of abstraction.

Facebook and Parse have handled their migration gracefully by providing a long window for winding down, and open sourcing their tools. Thanks for supporting your community in that way.

Problems With Backend Services

I’ve tried to build apps using the various backend as a service companies, to learn what their strengths and weaknesses are. My experience resonates a lot of the concerns that the Hacker News comments exemplify, platforms such as Parse still raise many issues and concerns:

  • Lack of future-proofing. Fear that your ‘hosted’ backend would one day shut down, and leave you having to figure out a painful migration off the system.
  • Performance and reliability problems. Whether these turn out to be real issues or not, you at least have this fear of: “What do I do if their service goes down, or misses some data, or is just slow?”
  • Poor documentation and customer support. This applies more to App Engine and other services than Parse — they did pretty well on this front. Still, unless you are really confident that the service will reliably do what you want to do, and understand how the system works fully, there are often moments where you want to be able chat with someone who runs the service. Despite these services generally making things easier, one small issue you don’t understand can block you for days.
  • Inability to see and get under the hood, to understand how the system is actually working. Rap Genius built their system on Heroku, and then hit major performance and scaling issues as Heroku changed how they were doing things under the hood. This put them between a rock and a hard place as they had to either get Heroku to fix things, or make the expensive move to another platform. http://genius.com/James-somers-herokus-ugly-secret-annotated
  • Will it Scale? There is a common sentiment amongst many programmers, that if you’re building on one of these application hosting or backend-as-a-service providers, you’re not building it ‘for real’. You’re building a prototype, it’ll get you so far, but if things actually work out then the expectation is that you will outgrow the system you’re building on. You’ll eventually move to your own backend, and the narrative in people’s minds is often: well, if I’m going to have to migrate eventually anyways, why not just build it for real from the start, even if it takes a bit more time. Almost always, building it ‘for real’ from the start takes way more time. But there is an important question of why many people don’t consider these services as able to ‘scale them all the way’.

Lessons Learned

Identifying these problems has led us to summarize the 3 lessons learned. These are principles for how we think about services we’re building.

  1. Assistive not Restrictive. The platform you use should let you still be able to get under the hood if needed. It should be a layer that assists you in doing the things you’re looking to do, but doesn’t necessarily stop you from doing things differently, or tweaking things. It should be like training wheels on a bike, take them off whenever you want. Rails Generators are a good example of this approach.
  2. Future-Proof Your Customers. The platform should strive to scale with your service as it grows, and be able to be that whole-product offering that does the things you need. If that means giving you easy ways to migrate to other services eventually when the stack no longer supports your use cases, then that migration should be automagical.
  3. Documentation & Customer Service. You should not feel restricted by the platform because you didn’t ‘build it yourself’. Documentation should be deep and explain the things you need to know in detail, suggest different approaches based on different use cases. The customer service should also be unparalleled, so that you can get unblocked as quickly as possible, and be able to handle any questions that the documentation doesn’t already explain. The service should also ‘just work’. It should strive to be as intuitive as possible, so that less and less documentation is needed.

These were some of the lessons learned from Parse. Would love to hear if they resonate with your experiences, and what you’re looking for.

Thanks again Parse Team for all of your hard work!

If you’re working on migrating your Parse application, or have other experiences and thoughts on what building and hosting applications and data should look like, please hit me up on Twitter!


Follow me on Twitter @nicolaerusan for more thoughts on product design, product management, entrepreneurship & futurism.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.