By Richard Lander, CTO | April 19, 2024
As the name suggests, platform engineering is the engineering of application platforms. Application platforms are used by development teams to deliver software to their end users. Not all organizations need an application platform, and not all organizations need to build one. This leads to the first question: Does my organization need platform engineering?
For organizations managing relatively simple systems, engineering an app platform could be overkill. In these cases, a set of tools that are well understood and used by a small team may be perfectly adequate. If this is your situation, don't overthink it. Stick with simplicity until the conditions that demand a more advanced system exist.
In other cases, a platform-as-a-service (PaaS) can provide what you need. Heroku, Vercel and Google Cloud Run are good examples of this. They offer a fast path from completed application code to running in a live environment and available to your users. The cost of this proposition will almost certainly be less than hiring full time platform engineers to build a custom implementation for your organization.
The problem in most cases with a PaaS solution is the limitations imposed by the platform. They may work perfectly well when you start out, but as requirements accrue, you can quickly find you need to build solutions that don't fit well into the PaaS framework. PaaS offerings generally have a finite set of use cases they support and if you outgrow those supported use cases, you have a tough choice to make: Abandon the features that aren't supported on the PaaS, or re-platform your application?
Re-platforming can be treacherous. If you re-platform onto another PaaS that does support your new immediate requirements, you run the risk of the same situation repeating later. And if you build your own in-house platform, you take on significant new engineering overhead internally. And in either case, you have the toil and potential mishaps of the re-platforming itself - the moving of the application from one environment to another.
For this reason, if you have an opportunity to develop your own platform that can grow as your requirements grow, you can bypass the potential dead ends of using a PaaS. The hard reality for many teams is that building a custom platform is in direct conflict with the need to get their software delivered quickly and with relatively low cost.
You will find a common theme in this post that revolves around the trade offs between the capabilities of your platform and complexity in building and/or using it. Simple solutions are generally faster to get up and running, getting your application in the hands of users faster. However, the simpler the solution, the more risk you run of painting yourself into a corner. You may find your platform unable to support features you need to deliver and a costly re-platforming effort ensues.
In many cases, the expected outcome of re-platforming is an acceptable technical debt to take on. Getting applications in the hands of users early is valuable and can give you the opportunity to afford the re-platforming at a later date. As with financial debt, it's not all bad. Very often, it is entirely necessary to achieve the desired outcome.
If you're in the position of developing your own app platform, read on. There are some important decisions to navigate.
Containers are the obvious place to start. Containers allow you to package up all of your application's OS and library dependencies. And it is pretty low-friction endeavor for your team to write some Dockerfiles and get some container images built. For more information about Docker and containers, see our blog post: What is Docker?
Next you will need a container orchestrator. Container orchestration allows you to declare the configuration of your containers in their runtime environment. If simplicity is your highest priority, consider Docker Swarm. If you need a more capable system with autoscaling, high availability and self-healing features, Kubernetes is your likely choice. Kubernetes is a complex system which brings us back to the capabilities vs complexity trade off. However, there are many managed service offerings that can help ease the complexity... for a price.
DevOps is a popular approach to app platform development. DevOps is generally thought of as a distinct discipline to platform engineering. For a deeper dive into DevOps, check out our blog post: What is DevOps?. The TL;DR is this: DevOps focuses on using open source tools and integrating them together into a coherent system. In contrast, platform engineering is a software engineering practice. It involves building software that provides useful abstractions to the users of the platform.
Because DevOps teams use feature-rich tools already available in the ecosystem, useful functionality can be implemented pretty quickly. However, due to the lack of interoperability and the level of detail exposed to users of the platform, the long term pay off from DevOps efforts will not be as high. And you risk encountering diminishing returns over time as complexity inexorably increases.
It is important to note that DevOps and platform engineering are not mutually exclusive. There is a happy marriage that can be had here (see below).
One of the biggest challenges in deploying workloads to Kubernetes is in the configuration of the Kubernetes resources that represent your application. As your systems develop, it is common for an application to consist of dozens of different Kubernetes resources with thousands of lines of YAML to define them all. Furthermore, those resources need to be configured for different environments such as testing, development, staging and production. This can prove to be a pretty enormous source of toil for your team.
This is where it can be extremely beneficial to leverage the Kubernetes operator pattern. If using open source components such as Prometheus for metrics or Postgres for the database as a part of your application stack, there are community supported Kubernetes operators that you can leverage.
Furthermore, you can build your own Kubernetes operators to ease the delivery of the applications you build in-house. This is one of the most under-used options available to Kubernetes users. The value here is in providing a custom Kubernetes abstraction to define your entire app stack. Now, a user only needs to manage a single object in the Kubernetes API. In response, the operator creates, updates and deletes all the other Kubernetes resources needed to run the application. Reducing the configuration overhead for the Kubernetes resources makes using DevOps tools to manage the deployment and management of your application much more feasible. This is where the marriage between DevOps and platform engineering can pay dividends.
The following diagram illustrates how this works. A Kubernetes user (or delivery system) submits an "AppStack" resource that represents a running instance of the application. To be useful, it should have relatively few configuration fields that abstract much of the implementation detail. The logic for the implementation details lives in the App Stack Controller. That controller consumes the App Stack custom resource, then deploys and manages all the different Kubernetes resources that comprise the app.
In the past, this has been a challenging endeavor for many organizations. Finding seasoned platform engineers that can do this kind of work is not easy or cheap. However, with the modern SDKs available, you can achieve your goals with one of the following:
Go is the language of choice for Kubernetes operators. Kubernetes is an API driven system, so any language that can integrate with an API over HTTP can suffice, however the libraries and SDKs available in the ecosystem make Go the right choice.
Kubebuilder is a very popular SDK for building Kubernetes operators. Operator SDK also provides similar features for building Golang operators. Operator Builder is a Kubebuilder plugin that allows you to rapidly develop operators based on existing Helm charts or Kubernetes manifests that you have used in the past.
One of the things that app platforms invariably have to consider is the integrations with systems outside Kubernetes. If your application stack includes managed services like managed databases, you have to consider that integration. You can use projects like ACK to help with these integrations but you often still find manual toil or custom code is necessary to tie all your app components together elegantly.
This is where Threeport can be very useful. It is an application orchestrator that is designed to manage Kubernetes itself, your app running on K8s as well as all those dependencies that exist beyond Kubernetes, such as managed databases. One of the core value propositions of Threeport is in avoiding re-platforming altogether. It makes it easy to get up and running on Kubernetes with simple use cases and allows your platform to grow with the requirements of your software. It supports common DevOps tools to help get up and running, but is infinitely extensible so that you will never be cornered into moving your application to a new platform. It integrates seamlessly with the Kubernetes operator pattern so that, if you find that approach helpful, you will be well served.
Platform engineers can think of Threeport as a baseline for application platforms. It includes the primitives for managing cloud native apps and their dependencies. But, most importantly, it has an SDK for extending it to meet the custom requirements your organization needs. It is a framework for building reliable, self-service app platforms that your developers will love.
Qleet is a managed Threeport service that hosts and manages your Threeport control plane for you so you can stay focused on building and delivering the software that your users and customers find valuable.