By Ram Iyengar, Chief Evangelist, Cloud Foundry Foundation
Platform engineering is a dynamic area of chaotic – yet constructive – discussion right now. It is not a new area of work, but a noteworthy and increasingly relevant one. Especially in the Kubernetes era, the complexity and novelty of Kubernetes has resulted in the demand for a platform substrate. The success of Kubernetes and the overwhelming reception from the community further fuels the platforms gold rush. Everyone responsible for managing infrastructure to support large teams is in search of the lucrative “Heroku Over My Kubernetes Clusters” developer experience. This article will focus on the cloud native ecosystem and platforms intended to abstract Kubernetes.
Why Do We Need Platforms?
Efficiency gains are essential for software engineering teams. As teams start to grow or products start to take off, engineering teams that support them find themselves taking on additional responsibilities. Between the time a product grows from 10 users to 10,000 users, different growth phases will have the engineering team work on different priorities for stabilizing the product and scaling workloads. Non-linear growth implies non-linear assignment of responsibilities.
Another interesting trend currently in vogue is “Shift Left”. There is an increasing tendency to adopt a developer-led mindset for any of the reliability, security, or observability needs of web applications. This places a burden on the application developer that grows over time, distracting developers from their core development work.
Collectively, these distractions must be subsumed by platforms. When these tasks emerge at the horizon as unknown unknowns, it is acceptable that engineering effort is devoted to resolving them. As they become repeatable patterns, the right thing to do is to fold them into the platform. As an example, if observability needs to shift left, it is fair that it is bundled as an element into the build process. Every build can then be configured with the additional components as they roll out immutable artifacts for deployment.
Speed and agility are required for all software development teams. Achieving the right velocity is essential for managing high quality engineering teams. Suppressing the additional asks and tasks of engineering teams is a good way to make gains in speed and agility, and the adoption of platforms can go a long way in ensuring this.
Efficiency gains come from automation. It emerges from self-service enabled over infrastructure used by engineering teams. It comes from eliminating toil that can come from repeated effort and engaging in boiler plate ahead of bootstrapping any project.
Kubernetes by itself is capable of providing an orchestration layer for applications deployed as containers. In order to make these deployments useful, many more services are required to operate at its perimeter. The choices for tools that provide these services have exploded in the past few years, resulting in a vast, complicated CNCF landscape. Cloud native platforms emerged to meet the need to simplify the complexity in the landscape surrounding Kubernetes.
Current State of Platform Engineering
A Cambrian explosion of platform tools has occurred in the wake of the rising CNCF tide. A Gartner prediction adds plausibility to this reaction caused by free market forces. Currently, there are numerous platform products out there competing for viability. Most software engineering managers I meet are working with a platform, typically built by them. Kelsey Hightower said it best when he said “I’m convinced the majority of people managing infrastructure just want a PaaS. The only requirement: it has to be built by them.“. Most platforms are meant for internal consumption by engineering teams and the efforts to standardize around Internal Developer Platforms.
Platforms are typically composed of two types of capabilities, the first being the automation and simplification of the provisioning of infrastructure. These aspects of a platform typically abstract layers of infrastructure and allow downstream teams to consume them through simple self-serve mechanisms. The second type of capability begins with the application deployment experience and is tuned to make remote deployments sophisticated. A platform tool may optimize for either of these capabilities or choose to tackle both.
Within the cloud native ecosystem, platforms are aimed at minimizing the complexity of Kubernetes felt by application development teams. Creating consistent application deployment experiences is the foremost focus of platform engineering for these tools. While this has been true for years, it has never been more important in the Kubernetes era. Incompatible images, pod scheduling failures, and network misconfiguration are some of the errors that a developer may encounter when deploying to Kubernetes. These can be rather difficult issues to debug and resolve, especially when the developers are, for example, data scientists working on statistical optimization in R.
Peering Into The Crystal Ball
In the future, platform engineering in the cloud native space will continue to push user experience and automation. It will provide an expanded substrate, abstracting several areas and aspects of software engineering. It will enable application development teams to build with greater focus and operations teams to reinforce the technical stacks better.
Specific areas in which we can expect progress include: :
- Further automation: Fueled by the need for developer velocity and the arrival of new tools, platform tools will become more automated, making it easier for users to deploy, manage, and scale applications in the cloud native space.
- Interoperability: Platform tools will become more integrated with other cloud-native technologies, such as service meshes and APM tools. This will make it easier for users to get a holistic view of their Kubernetes applications and infrastructure.
- Enhanced security: Platform tools will transform into security-first paradigms, folding in aspects such as provenance, signed builds, and hermetic deployments.
Orthogonal to these technical areas, platforms will help improve their ability to communicate business outcomes in future iterations. The contributions of platforms to value streams will become clearer and their benefits more evident.
What Does Open Source Have To Do With This?
Most teams will either look to build their own internal platforms, which is a drain on resources, or buy turnkey solutions which can be a drain on money.
Building platforms can be a great way to supplement engineering efforts, however it is only warranted for those organizations which have sufficient resources to commit, and specific needs for bespoke platforms. Most engineering organizations should not have to assume the additional overhead of having to build their own platforms. As an example, the Media Cloud Engineering team at Netflix has built (and rebuilt) a platform for helping process incoming videos to be served on all kinds of devices – which is a niche problem.
Buying a platform product saves time and resources, and comes with multitudes of business benefits. A well known case study is Mercedes’ usage of Tanzu. That being said, buying into a product comes with inherent risks. Product development for general-purpose tools follows a lifecycle that comprises a large number of sweeping and broad requirements, without necessarily addressing specific requirements required for any vertical. This can turn into a long tail of compatibility issues, especially because software products are known for being opinionated.
Open source efforts to help push the platform engineering agenda forward should be encouraged and supported. A large number of platform tools have been emerging over the years, especially focused on the developer experience, embracing the open source ethos. Notably, the Kubernetes community has supported a CNCF TAG App Delivery which works with contributors focused on projects and initiatives related to delivering cloud-native applications, including building, packaging, deploying, managing, and operating them – which in a nutshell is Platform Engineering. The TAG has working groups dedicated to Platforms, Operators, Artifacts and other areas which are relevant for developing developer platforms.
However, for many organizations facing the dilemma of build vs buy, a third option might be the solution: a robust open source platform. Solving complex computer science problems with open source tooling is a familiar paradigm. Open source software has already commoditized computing, threw the gates open for web application development, and helped scale technology into the massive force it is today.
Using an open source tool for bootstrapping app modernization efforts can help save resources and allow avoid problems of technical fit through customization. Several organizations have demonstrated success in using open source to enable large scale teams to work with their software stacks.
++
Join us at KubeCon + CloudNativeCon North America this November 6 – 9 in Chicago for more on Kubernetes and the cloud native ecosystem.
##
ABOUT THE AUTHOR
Ram Iyengar
Ram Iyengar is an engineer by practice and an educator at heart. He was (cf) pushed into technology evangelism along his journey as a developer and hasn’t looked back since! He enjoys helping engineering teams around the world discover new and creative ways to work. He is a proponent of community-first product development.
Images courtesy Freepik.com.
