The primary focus of the 2020 State of DevOps report is the emergence of a self-service developer platform that top performing DevOps teams are adopting. The reason for adopting this model is to enable a self-service experience for application development teams.

The internal platform model

There are many ways to refer to this platform - Internal developer platform, Kubernetes platform, GitOps platform (see GigaOm’s latest key criteria report on GitOps Platforms). Those are some of the more common phrases used. Whichever name it goes by, the key characteristic of an internal platform is that it enables separation of concerns for Dev and Ops teams.

It starts with a dedicated Platform team that is solely responsible for the creation, and maintenance of the platform. We recently interviewed Mae Large from the State Farm Platform team who shared the best practices they use to deliver a self-service experience for developers. The platform team defines a list of pre-vetted resources such as container registries, source code repositories, access controls, and monitoring tools.

As workloads move from being VM’s and bare metal to Kubernetes, the goal of the platform is to make it easy for developers to interact with Kubernetes. This allows developers who are unfamiliar with Kubernetes to use the platform while being abstracted away from the detail.

What does 'self-service' actually mean?

Traditionally ticket-based Ops has involved a great deal of delay and friction for development teams. With API and cloud-based platforms we’ve seen the ability of creating and configuring resources move into the hands of developers. With a self-service platform a software team can create the environments and resources that they need - the result is less friction in the development process ensuring they can deliver customer value faster.

The key to a great self-service platform is having a Platform team who invests ahead of time in creating the most frequently needed resources and configuration that the development teams will need. This also means that Platform teams can create services using best practices.

This model is indispensable in large organizations with numerous development teams. For example, the DoD needs to support a massive workforce of nearly 200,000 developers both internally and externally. It is a tall order for the Ops team to individually service each developer and team. The DoD is a big believer in the platform model, and their Chief Software Officer, Nicolas Chaillan recently shared about the platforms they use to deliver a self-service experience for all their developers.

Another interesting use case was discussed by Axel Springer SE, one of the largest publishers in Europe, who was able to set up a Kubernetes platform that allows developers to create test environments on demand.

Developer benefits from a self-service platform

Give developers autonomy over the tech stack

Large organizations need to give their teams the autonomy to choose which public cloud vendor they'd like to run their applications on, which repository management service they'd like to use, which testing and monitoring tools they'd like to leverage. Forcing a cookie-cutter approach on developers is bound to backfire. The platform model allows different development teams to make choices for their applications without interfering with other teams, and in a way that is perfectly acceptable to the Platform and Ops teams.

Free developers from infrastructure tinkering

Developers would much rather focus on their core role of writing code and building new apps and features than worrying about how to run the code they write. They do not specialize in ensuring high availability, security, and high performance. They would be happy to have ready-made templatized options available for them to choose and deploy their code on. This greatly improves developer productivity.

Ops benefits of a self-service platform

Allow Ops to move from tasks to strategy

By separating out a Platform team from the wider ops team, the ops team can become more strategic. They need not spend time managing tickets, or duplicating work. They can instead focus on optimizing system performance across the board, improving resource utilization

Improve security and compliance

The Platform team can enforce requirements on resources and actions across the pipeline. For example, they can have a list of approved container images or a container registry, or require certain security checks to be performed on every commit before it can be deployed into production. These capabilities provide security guard rails and compliance in a way that is not possible manually.

Speed up time from commit to deploy

Automating the most common tasks before a deployment and enabling self-service convenience for developers greatly reduces the time for each release. As release frequency increases, the organization can release features faster and gain a competitive edge.

The DevOps movement is about removing silos between dev and ops teams; however, there wasn't a clear solution to how dev and ops teams can stop being an obstacle to each other until now. The platform model meets Dev and Ops teams right where they are, enabling them to do what they do better. As organizations look to move faster, deploy more frequently, and become more innovative the platform model is set to become the norm. Large organizations like State Farm, and the DoD are trailblazers and front-runners. It is now time for mainstream organizations to follow in their footsteps and reap the benefits of a self-service developer platform. The GitOps model is certainly one approach for successfully deploying and maintaining a Kubernetes platform that benefits both developer and ops teams.

To understand how to get the most out of GitOps at the right scale for your organization watch an on-demand webinar about the GitOps Maturity Model.