 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
The primary focus of the 2020 State of DevOps report was the emergence of a self-service developer platform model that top-performing DevOps teams are adopting. The reason for adopting this model is to enable a self-service experience for application development teams.
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 VMs 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.
Traditionally, ticket-based ops has involved a great deal of delay and friction for development teams. With API- and cloud-based platforms, the ability to create and configure resources has moved 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 that they can deliver customer value faster.
The key to a great self-service platform is having a platform team that 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 Department of Defense (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 its chief software officer, Nicolas Chaillan, recently shared 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, which was able to set up a Kubernetes platform that allows developers to create test environments on-demand.
Large organizations need to give 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 as well as which testing and monitoring tools. 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.
Developers would much rather focus on their core role of writing code to build 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 to them so they can choose the best one on which to deploy their code. This greatly improves developer productivity.
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.
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 is deployed into production. These capabilities provide security guard rails and compliance in a way that is not possible manually.
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. It is time for mainstream organizations to follow in their footsteps and reap the benefits of a self-service developer platform. The GitOps model is 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, view our on-demand webinar about the GitOps Maturity Model.
