The 2020 State of DevOps report talks about the “platform model” as the biggest development in the cloud-native space right now. As opposed to creating and maintaining separate clusters for developer teams associated with individual products or services, the internal platform model is gaining popularity for its “self-service” approach and its scalability when dealing with multiple products. While product teams are an essential aspect of DevOps evolution, they pretty much reach their limit when you start scaling up and have hundreds of products and services, each one with its own team and technology stack.
Scaling-up with internal platforms
In addition to plenty of “reinventing the wheel,” since all teams are essentially working on solving similar problems, the amount of time and effort that goes into infrastructure management and getting everything integrated and working together is time away from working on products. Another problem when you have multiple products and applications, all running on different infrastructure stacks, is that managing cost and compliance can be a whole different nightmare of its own.
This is where internal platforms step in and provide uniformity across an organization while also providing developers with an easy way to navigate around the complexities of infrastructure management. An internal platform is essentially a standardized technology stack or set of tools that can be used across all products in an organization. Internal platforms are typically run and managed by a separate platform team dedicated to infrastructure maintenance, allowing developers the freedom to work on their applications.
Why an internal Kubernetes platform?
While most organizations move to a cloud-based Kubernetes environment because, at some point, their applications just got too complex for their on-premises datacenter, they often underestimate the learning curve associated with Kubernetes. Again, this is where the internal platform model makes everyone’s life easier as you have one team dedicated to Kubernetes, while everyone else can continue to do what they do best. Additionally, with most applications running on top of Kubernetes, it only makes sense to use Kubernetes to build an internal platform.
As a result, the need for more than a generalized, monolithic solution is fueling the rise of the platform model. This means building a single, integrated solution that brings together all the disparate components of a company’s internal software and external vendor solutions.
A Kubernetes platform is different from traditional architectures
Platforms are a fundamental part of any distributed systems architecture. However, the way the platform is implemented keeps changing and evolving. The platform model is quite different from the enterprise-class application architecture of the previous generation. In the past, technologies like an enterprise service bus (ESB) were used to create a hub-and-spoke model where resources were shared between multiple teams. This model was not built to scale, and inevitably enterprises ran into problems of scale. Kubernetes, with its distributed approach to infrastructure management, is the answer to these challenges. More specifically, the platform model powered by Kubernetes is the replacement for outdated enterprise architectures.
Security in the platform model
With the varied demands of developer teams, a lot of security and scalability issues arise. The platform model helps enforce security by default and relieves developers of having to follow security protocols every time they initiate a deployment. Security configuration is already hardcoded into the environments and resources that are provided for developers.
Self-service developer experience
Developers have access to ready-made resources that they can spin up immediately without having to wait on Ops. This cuts short the time it takes to move from code to deployment. It empowers developers and gives them a self-service experience. This is one of the key drivers of the platform model.
One platform for a multicloud world
The platform model also enables multicloud. You can use the same platform to create development environments in a datacenter or on any cloud provider such as AWS or Azure. Kubernetes makes it easy to move workloads across cloud platforms or scale up and down based on demand. It also manages resource allocation across multiple distributed hosts, making it scalable and resilient.
Rather than each product or service needing to have its own cluster, you create a network of services or resources that can share information between each other through a means of a network and a control plane. You might also use this approach to create “sub-clusters” that enable different components of the infrastructure to be deployed, scaling up and down independently.
Benefits to the QA team
The platform approach is a boon to QA testing as well. Typically, testing involves the rapid creation and destruction of testing environments. As test automation advances, QA teams require lightweight, fast creation of test environments. These environments need to be pristine and not contain residual data from past tests. This was not possible when running tests on virtual machines. Today, in a world of containers, it is possible but not easy to create and destroy test environments en masse. Now, QA teams can easily provision test environments as soon as they’re needed and destroy them after running the required tests. The short lifespan of these environments helps save on cloud computing costs.
Challenges with the platform model
There are challenges with the platform model. For one, any new paradigm, no matter how powerful, will face resistance in the face of the tried-and-tested practices. The biggest challenge is related to changing culture and existing habits. For example, Ops teams are now comfortable having developers raise a ticket requesting resources they need and the Ops team reverting in a day or two. This gives them buffer time to perform the manual tasks it involves. Now, with the platform model, they’re forced to take a hands-off approach and allow developers to provision resources on their own without requiring manual approval each time. Going from the manual to automated approach can be hard to get your head around if you’ve been doing it the manual way for years.
A path to adopting the platform model
For the platform model to succeed, it takes a dedicated effort on the part of the organization to separate a platform team from the larger Ops team. It takes a lot to manage Kubernetes at scale. Further, building a system that is scalable, flexible to meet diverse teams’ needs, and highly fault-tolerant is no mean task. Organizations need to build Kubernetes expertise internally, and this expertise should be concentrated in the platform team.
The key focus of the platform team should be to enable a seamless developer experience. They should accordingly track metrics that reflect how fast developers can move through their workflows. How frequently code is committed, deployed, how many tests are run, how long it takes for a change to make it to production. A key priority for the platform team should be to evangelize the platform internally and drive adoption. This would take training, support, documentation, and events that celebrate milestones along the way.
The end of traditional Ops-heavy methods?
The adoption of platform-based architectures has created an environment where traditional methods that are Ops-heavy are not enough anymore. The big tech early adopters have already jumped ship to the platform model. We’ll now see mainstream enterprises get on board in the next few years. Kubernetes makes the technology possible, but the bigger and more interesting change will be the change of culture this enforces.
Featured image: Shutterstock