How We Build, Deploy and Scale Apps in the Future

Background

During the past couple of years, Docker has become an incredibly popular way of building, shipping, and running applications in the cloud. Long gone are the days when we had to worry about server configuration and differences between environments. Just build the application once and run it anywhere! This is the era of containers.

Although containers are a giant leap forward in how we build and ship applications they are still difficult to manage at large scales. Back in 2014 Google created Kubernetes to solve the problems they had when running thousands of containerized workloads all over the world. Since then, Kubernetes has become the de facto standard for deploying and operating containerized applications.

Even though Kubernetes is a great tool, it still requires quite a bit of effort to set up properly. With Kubernetes, you still have to manage your own infrastructure. If you are a small startup, have limited resources, or time to market really matters — Kubernetes might not be the best alternative for you.

In addition, building a high-quality backend with all the bells and whistles needed for modern application development can be very costly.

Generalizing the backend

If you’ve been working as a developer for some years, maybe with different employers or at least different products, you’ve probably seen a pattern — A lot of the code you’ve written is really the same across different services. The data models are different, but the rest have at minimum a lot of similarities. Most of the code you’ve written can probably be generalized. In fact, it’s been generalized already.

The thing is that most backends for apps on the web and mobile require a very similar set of features. Apps need a way to handle user authentication and authorization. Your apps need a way of validating user input to ensure that users provide the correct information. Then there must be some storage to store whatever the information, typically a relational database or document store. Often, you’d also like to dispatch events once records are saved, updated or deleted to handle side effects. Then finally there must be a way to query whatever data is stored by the application, typically using a RESTful APIs or GraphQL.

A general solution to this, is what’s called Backend-as-a-Service, or BaaS for short. BaaS is not another no code approach, it’s more like a less code approach. You only write the code that separates your apps from all other apps, not the general stuff.

With BaaS you typically configure your data models and maybe how they relate to each other. You configure which OAuth providers you’d like to enable or even just email/password. You can write some code to attach your own claims to users' authorization tokens. In addition, you must specify a set of rules that will be used to allow/disallow users to request different resources.

In return, you get a scalable backend able to handle thousands of requests per second with an SLA above 99.9%. A backend with features such as live notifications, GraphQL and RESTful APIs — a billion-dollar worth of backend.

Google Firebase and MongoDB Realm are examples of such BaaS providers. Both offer a very rich set of features as well as developer-friendly tools for setting up data models and configuring your backend.

Both these providers are relatively cheap, especially when compared to running your own k8s cluster and the cost of having your own DevOps team. You typically only pay for what you use on a per-request basis and there’s usually a generous free quota.

One question still remains though, how do you implement business logic in a BaaS environment?

Serverless

Implementing business logic in a BaaS environment is typically done serverless. With serverless, you will be able to handle business logic and computations in a flexible and scalable way without having to worry about managing infrastructure and servers.

Serverless doesn’t mean «no-servers», it means «no servers for you to manage».

Serverless is great for breaking up monoliths while also providing a better separation of concerns. Clean and reusable code. A typical serverless function only solves a single well-defined problem. Serverless functions are stateless, a black box that takes an input and yields some output.

Running serverless functions are usually cheap. You only pay for what you use. However, it can be more expensive than running your own services if you have a continuously high load and limited peak load.

Conclusion

If you are in the market for a scalable and feature-rich backend that fits these criteria don’t create your own unless you think you can do better than the likes of MongoDB and Google. Have a look at BaaS instead.

The only real reason not to is the vendor lock-in. Once you decide on a vendor there is no turning back. All vendors have specific implementations and there are no simple ways of migrating solutions between different vendors.

Though Kubernetes is great, it’s not necessarily something all businesses need. At least not something you need to manage yourselves. Most BaaS vendors run Kubernetes behind the scenes anyway.

I’ve made a small app with MongoDB Realm, please check it out if you are interested in learning more about Backend-as-a-Service and how you can build, scale and deploy your apps with ease.