Kubernetes and the Next Generation of PaaS – InApps 2022

2022 is here. Web3, Metaverse, NFT are all the rage, but tons of developers still struggle deploying their applications to the cloud like it’s 2015.

Why is this happening? Is it unavoidable? Let’s try to answer those questions.

The Issue

You may argue that not all developers have trouble deploying their applications, and you would be right. Google and Netflix are smoothly shipping code at an infernal rate. With his brand-new startup, your friend is deploying his Jamstack app on Vercel seamlessly. So what are we talking about?

I’m talking about those tens of thousands of medium-sized companies with applications too big to fit in a Platform as a Service (PaaS), but not enough to hire an army of DevOps and site reliability engineers (SREs).

The Heroku Days

A startup wants to get its minimum viable product (MVP) to market as fast as possible at an early stage. Most companies will turn to a PaaS like Heroku, Vercel or any of the countless solutions on the market. This decision totally makes sense for the following reasons:

• It’s cheap: There is usually a free plan with the ability to run an application for a few dollars per month.
• It’s easy to use: The last thing early-stage startups want is to spend time setting up their infrastructure. A few clicks on a Web UI, a push on git and the app is live.

AWS Calling

The fairytale can potentially go on forever, but the less fortunate will someday find themselves in front of a complex reality: They are outgrowing their PaaS. Or at least it doesn’t fit their needs anymore. This can be for various reasons.

• Their codebase grows and managing dozens of services becomes difficult on their platform.
• It was cheap in the beginning but is now way too expensive.
• They need to deploy on a specific cloud provider for some reason.
• The PaaS doesn’t support a particular region they need to deploy to.
• They don’t want vendor lock-in.
• Their application has specific needs that are incompatible with the PaaS.
• The list goes on …

At this moment, those companies turn to one of the major cloud providers — AWS, most of the time. It looks very promising at first. Every API or service they could ever think of is already present. They can tailor their infrastructure to their exact needs with a nearly infinite number of EC2 instance types. Managed databases? Yes! CDN? Of course! You can even throw some lambdas into the mix to add “serverless” to your stack.

It must be a perfect dream, right?

Kubernetes, the Wolf in Sheep’s Clothing

Except upon waking up from the dream, the reality is less appealing. Amazon Web Services is a complex beast and getting started is less obvious than it seemed in the first place. Services like Elastic Beanstalk have the same drawbacks as the other PaaS, and building a delivery pipeline from scratch on top of the provided building blocks is no easy feat. And what if you also want to deploy to GCP or Azure? Each cloud provider has its own specificities and APIs. There is no obvious way to go multicloud.

As an answer to these issues, many companies turned to Kubernetes. This platform quickly became mainstream and the de-facto choice for every team to be “cloud native.”

Problem solved, right? Wrong! Many people made the mistake of thinking Kubernetes is a platform for developers. It might seem simple initially, but as the complexity grows, people find themselves going down the rabbit hole to the point of insanity until they finally realize that Kubernetes is not meant to be used by developers.

Tweet by Kelsey Hightower.

Companies then build whole DevOps and SRE teams to create their own developers’ platform on top of Kubernetes. Some succeed, but most fail.

The Next Generation of PaaS

So on one hand, we have the Heroku-style PaaS, easy to use but limited. On the other hand, Kubernetes, with endless possibilities but great complexity. What if we could get the best of both worlds?

• Easy as PaaS for developers
• No vendor lock-in
• Full Kubernetes power

Both Worlds

That’s what Qovery aims to achieve.

What those teams that get to the point of using their own AWS (or GCP or Azure) account need is not an all-in-one hosting platform. They need a way to reduce their DevOps effort to the bare minimum.

Qovery is a DevOps engineer as a service. It keeps you in full control of your infrastructure while doing the maintenance and the heavy lifting for you.

All the Terraform and Helm configurations we generate live in your own cloud account.

If for some reason you decide to stop using Qovery, your app keeps running on your own Kubernetes cluster the way it was before. You just lose features like:

• Automatic CD pipeline
• Automatic upgrades of your cluster
• Developer-friendly tools (UI, CLI and API)
• Preview environments

Conclusion

Heroku has been the standard cloud deployment solution for years. However, there are many downsides, including quickly increasing pricing and a lack of granular control.

Modern solutions have emerged to address these issues, like AWS Fargate, Google Cloud Run and Qovery.

Instead of spending months setting up your infrastructure or directly dealing with the complexity of AWS, you could consider Qovery. You can connect your git repository and start deploying your application in about 15 minutes while retaining the power of your cloud provider.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Hightower.

Feature image via Pixabay