This post is one of a series of posts previewing KubeCon + CloudNativeCon Europe 2023, April 18-21, Amsterdam. Join us there, to learn more about the transformative nature of cloud native applications and open source software.
The notion of internal developer platforms (IDPs) is very popular at the present time. Software engineering teams of all types have it at the top of their wishlist. Teams within large organizations are able to devote resources exclusively for the development and maintenance of IDPs, but the demand is ubiquitous.
Based on observations at the KubeCon + CloudNativeCon NA 2022 floor, several leading surveys, and general feedback — we concluded that the Kubernetes community can greatly benefit from platforms that simplify its adoption and day-to-day usage.
Kubernetes Is Powerful but Complex
Since the nature of the problem solved by Kubernetes is a complex one, Kubernetes itself can be difficult to manage. The technology handles many important tasks involved in running an application such as persistent volumes, load balancing, secrets and authentication, service discovery, auto-scaling and others. All have the intent of liberating application developers. Instead, we find that application developers end up being tasked with knowing Kubernetes primitives, which can be a significant cognitive overhead. Over time, so many new features have been built into Kubernetes that it has started to work in myriad ways, which is demonstrated in this excellent talk by Viktor Farcic.
In the past, we have written about how DevOps practices shape over time. Our observation is that ― many small factors add up to bigger outcomes. The use of platforms for software engineering teams is no different. Small, yet significant outcomes for engineers bubble up as important results for product teams. In turn, this leads to meaningful development for the business units, culminating in success for the company as a whole. For those in the business of delivering software products to their customers, this paradigm can be illustrated using the pyramid below.
What Should Teams Shoot for?
Individual software teams need to be equipped with the right kind of tools and processes in order to be able to deliver the desired results. Both velocity and accuracy are paramount in order to release functionally. Defining the right kind of Sservice Level Objectives (SLOs) is critical in meeting availability and reliability requirements. SLOs can take many forms. It can be defined in terms of a percentage for uptime, in units of seconds or milliseconds when defining (un)acceptable latency or by volume when defined for throughput. In the event that SLOs are not met, engineers should have sufficient knowledge and transparency to be able to investigate and ascertain the root cause. Teams should be able to collaborate with each other and work together to inspect problematic areas, especially those that are cross-functional.
Upon such a foundation of sound engineering practices, value addition can happen downstream. High-quality software can be engineered and delivered by teams designed to be dynamic and agile. Teams should be able to remove opacity in all areas of malformed operations, including application errors, security misconfiguration and vulnerabilities — in addition to latency and reliability issues on production.
Armed with these capabilities, engineering teams can promise faster development cycles. By consuming environments and frameworks that are standardized.
Platforms Are Everywhere
Platforms are not limited to cloud computing. They can be used to improve the workflow of developers involved in all kinds of stacks. For example, Blockchain developers have options such as Avalanche. Avalanche provides primitives that allow developers to then build decentralized apps utilizing exchanges, platforms or contracts as needed. Similarly, Fermyon is positioned as a platform for WASM (WebAssembly). With just a few commands, a developer can spin up a WASM application and deploy it. Their combination of CLI and web UI allow developers and operators to work together on the platform to manage applications. Another example of a platform for WASM is Cosmonic.
Overall, a platform is intended to help organizations to build better software faster, with improved collaboration, quality and scalability.
A Platform for Kubernetes
Kubernetes is an emerging technology that can greatly benefit from having a paved path to production associated with it. Using a platform, application developers can simplify the application deployment process by being able to deploy to any remote instance without having to engage in manual configuration for various clusters.
A platform consumed as a PaaS tool is also of great value when services have to be integrated with applications, especially when working with Kubernetes. Built-in support for databases, messaging and monitoring saves enormous amounts of time and liberate developers from significant toil. It also improves the production parity of applications by making the same grade of services available on all remote instances. This increased level of automation is useful in accurate deployments and can help scale applications on demand.
Conclusion
We believe that the Kubernetes community can greatly benefit from having platforms built to abstract away some inherent complexity. A definitive set of tools, processes, and services that surround Kubernetes clusters in order to establish developer self-service is key in helping improve the adoption of Kubernetes. With this, software engineering teams will be able to build, test and deploy their applications with efficiency and effectiveness.
The Cloud Foundry Foundation will be sponsoring KubeCon + CloudNativeCon Europe 2023 this April in Amsterdam. We’ll be hosting a booth with our contributors present to discuss platforming on Kubernetes. We invite you to please stop by for a chat and check out Korifi — The Cloud Native Platform For Cloud Foundry.
Group Created with Sketch.