The Future Of The Application Stack

If you have built and deployed an application in production over the last few years, odds are that you have deployed your code in containers. You might have created and deployed individual containers (Docker, Linux LXC, etc.) directly in the beginning, but quickly switched over to a container orchestration technology like Kubernetes (K8s) or Swarm when you needed to coordinate multi-node deployments and high availability (HA). In this container-driven world, what will the future of the application stack look like? Let’s start with what we need from this “future” application stack.

What Do We Need From This Future Application Stack?

1. Cloud Agnostic

   We want to be cloud agnostic with the ability to deploy to any cloud of our choice. Ideally, we can even mix in various providers in a single deployment.

2. On-Premise

   We need to be able to run our application stack on-premise with our own custom hardware, private cloud, and internally managed datacenters.

3. Language Agnostic

   It almost goes with saying, but I’ll add it in for completeness. The future open stack needs to support all of the popular programming languages.

The Future Application Stack

The future application stack will be composed of a triad of technologies – K8s, Platform-as-a-Service (PaaS), and Database-as-a-Service (DBaaS):

K8s

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, and you can deploy your applications directly to K8s containers. For customers with existing applications, it makes perfect sense to package and deploy your existing applications to K8s directly.

All of the public cloud vendors provide strong native support for K8s, and you can run your own K8s cluster on-premise as well. Docker has also now jumped on the K8s bandwagon – so you have full flexibility. There’s no doubt that K8s is king of the hill today. In a few years, it might get beat out by another solution, but container orchestration technology is here to stay.

PaaS Solutions

If you’re creating a new application from scratch, Platform-as-a-Service solutions like Cloud Foundry and OpenShift offer compelling advantages that you can leverage to speed up your application development lifecycle. Is a PaaS a must? Definitely not, but I think it’s worth considering if you’re creating a new application.

In some cases, the PaaS solutions might run on K8s or sit beside it – from an application perspective, it doesn’t matter. If your IT organization is deploying the PaaS solution, they might like it if it just runs on their existing K8s clusters. The PaaS solutions mentioned above are also available on all the public clouds. So again, you have the full flexibility you need from your platform.

DBaaS Solutions

Running and managing a production database system is not for the faint of heart. If you think you’re going to install your production database on three containers and it’s going to run happily ever after, you have another thing coming. By using a Database-as-a-Service solution, they will handle all the operational aspects of your database management so you’re prepared for any and all of the unexpected.

Your DBaaS may or may not run on K8s. Maybe some portions of the DBaaS run on K8s, but the odds are that it doesn’t. Why is that?

1. Outside of the popular public clouds, there isn’t a great solution for storage/volumes that are up to EC2 Elastic Block Storage (EBS) quality. Vendors like PortWorx and OpenEBS are working on it, but it’s not there yet. Without a good storage solution, it’s practically impossible to put data into your containers.
2. If you’re running a large, several TB production database server, it doesn’t make sense to run it in containers – you are going to have large dedicated machines with fancy SSD’s.
3. Too much dynamism – yes, you can have too much of a good thing. Sometimes, when things fail, you want them to stay failed so you can take a look and see what is going on. StatefulSets in Kubernetes are a great step in the right direction to solve this problem.

At ScaleGrid, our vision is to deliver on the DBaaS part of this future application stack. We are multi-cloud today, and can also run on-premise or in your own private datacenter. Additionally, our platform is a polyglot system that supports multiple databases, including MongoDB, Redis, MySQL, and PostgreSQL.

For the sake of simplicity, I have excluded some other parts of the application stacks like object storage, file system storage, etc. In principle, I expect these components will be similar to the DBaaS component. This blog post was inspired by a Silicon Valley PostgreSQL meetup I attended a few weeks ago, and shout out to Dave Nielsen (@davenielsen) from RedisLabs for starting the discussion on this topic.