Abstraction Propels Innovation
Let's begin by setting the definition of Platform. In the CNCF Platforms White Paper, they say, āA platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platformās users. It is a cross-cutting layer that ensures a consistent experience for acquiring and integrating typical capabilities and services for a broad set of applications and use cases.ā They then go on to state what a good platform is ..ā A good platform provides consistent user experiences for using and managing its capabilities and services, such as Web portals, project templates, and self-service APIs.ā This sounds like abstraction to me.
Many large companies abstract the platform from their software developers. This was the reason for containers in the beginning, so we no longer have to worry about what our code runs on. By abstracting the platform from non-platform engineers, it allows developers to focus on what they do bestā¦ code.
This year at Platform Engineering Day 2024 they had a talk titled: Platform Adoption Strategies: Critical Roles When Investing in Platforms. In this talk they talked about critical things to consider when investing in a platform. During their talk, one theme that came up repeatedly was the stress or tension once faced between developer teams and operations before the concept of 'DevOps' and now a tension between app teams and Platform Teams. Platform teams often focus on building robust, scalable, and technically advanced platforms. This often clashes with the needs of a developer that are simple and tailored to their immediate needs. Complex platforms may feel like a barrier to developers rather than an enabler. This presents the need to make things simpler for the developer.
At KubeCon 2024 North America, two senior engineers presented a session titled: Yahooās Kubernetes Journey from on-Prem to Multi-Cloud at Scale. In this talk Yahoo discusses the key decisions they made when moving to Kubernetes. One theme you see throughout the beginning of their talk is abstraction. Yahoo understood two things 1. that they wanted to move to Kubernetes and 2. the stress that it would put on the employees who do not know how to use Kubernetes. This motivated them to create a platform they coined with the name the Omega Platform to provide a layer of abstraction to preexisting complexities of Kubernetes. Omega is composed of a lightweight set of tools and templates to make it straightforward to deploy k8s workloads. The Yahoo team had created a YAML template for its developers to use to abstract them away from the code and allow them to focus on developing. They called this omega templates, from the talk it sounds like the omega templates would then be used to create container images for the applications and generate YAML manifests to deploy the Kubernetes application on their Kubernetes infrastructure. The template would also take care of common use cases such as identity, routing, security, observability, and networking ...etc. In the talk, Nandhakumar Venkatachalam, a senior principal engineer at Yahoo, states, 'We believe that abstraction helps eliminate the complexity...' and 'In 2016, we didnāt want to let thousands of developers figure out how to deploy onto Kubernetes. It was pretty new at that time.' Yahoo decided they wanted to move to Kubernetes, but wanted to make the learning curve as low as possible so their software developers could do what they do best and it would allow them to continue to innovate and deliver value to the customer at the normal pace.
As explained above, many companies build elaborate and complex tools that allow their software teams to deploy onto their platform without any knowledge of how the platform is runningāwhether itās a single cluster, multi-cluster, single cloud, multi-cloud, etc. They donāt need to know where or how they are running; they are simply given the options to choose what their app needs to work and the tools dynamically set up everything required to run effectively in the cluster, including complex network configurations and more.
Someone like me might think this is a lot of work to build an application or tool that does things I already understand. The problem with this assumption is Iām thinking as a platform engineer. Iām not a master software engineer, and it wouldnāt make sense for a company to expect me to do things Iām not an expert in. Abstraction allows for increased efficiency between teams in the company. When employees are allowed to focus on what they do best, it allows the company to be its best, and deliver value which is the ultimate goal at the end of the day.
K8s even abstracts the underlying workings away from a platform engineer. In order to use Kubernetes and use it effectively we are not expected to be familiar with the code base that allows it to do the things that it needs to do. Abstraction not only encourages efficient work and thought processes among employees but also limits what can go wrong. By enforcing access controls, we are not only limiting what people can see and touch but what they can break as well. Regarding controlling the disbursement of information, you often hear the phrase āneed to knowā If you want to know something and arenāt cleared to access it then ... you donāt need to know it. This made me think of the phrase āneed to touchā When you are a parent and have kids you have to establish boundaries ... if they donāt have a need to touch the stove they canāt .. in a similar fashion of how you donāt want your kids to burn your house down it would probably make sense to not want your employees to burn down your platform... So if no need to touch ā¦ No Touchy!!
How are you abstracting unnecessary tasks from people in your organization to propel innovation?