As Kim explains, Platform engineering is the practice of allowing the application development team to really purely focus on the development and reliable operation of their application without having to concern themselves with the complexity and the implementation details of the platform. The platform engineering team’s responsibility is to build and run and provide that platform as a service.
The old DevOps model: The Dev team was responsible for writing the application. They would go in and package that build to a deployable artifact and hand it over to the Ops team. The Ops team would take that deployable artifact, place it on a server that they operate, and they would run it, i.e., they would carry the pagers for if there was anything that was problematic from that application. Problem: The developers’ domain of concern and the operators’ domain of concern had nothing to do with each other. The operators didn’t really understand the development point of view, the application-specific characteristics, like the memory utilization and the failure modes. The application development team didn’t have an appreciation of what it meant to operate the server, what reliability meant, and what they needed to do. The DevOps mentality was born to try to understand one another’s cadences and try to coordinate that a little better.
The platform engineering model has an application team who’s responsible for the application from development to operations. And then you have the platform team who’s responsible for the development and the operation of the platform.
What is driving this model change is the need to take advantage of the new architectures that are available today. In a cloud infrastructure, there are APIs to manage the resources and their lifecycle. There is a platform, which allows you to go in and manage contracts of how applications move through the application lifecycle, through development, and release and operations. And then you have the application, which has contracts to the end users.
The biggest challenge in transitioning to this new model is mostly an organizational/cultural one because roles and responsibilities have to change. The platform engineering team develops the platform for its customers (i.e., the app dev teams). It has its own release process, and it has its own operations with SLAs. The app dev teams will have to give up control of the platform, but if they follow along the conditions, cadence, and SLA of the platform, they are then free to simply focus on application philosophy and service reliability. The platform engineering team will provide all the tools that the app dev teams need to successfully run and meet their objectives.
- Application developers can focus on writing applications and service reliability. They can be agile because their development cadence is not bogged down by platform complexities.
- Platform engineers can develop excellence over time and allow them to develop tools that are impactful to the organization.
The ideal developer experience is having clear separation of concerns: software developers/ engineers write their code and submit it. The platform engineering team takes care of everything else. There is often no human interaction between developers and platform engineers.
Qarik focuses on two core areas:
- Platform modernization, i.e., building an organization that allows infrastructure to have more options. For example, modernizing the platform from VMs to container-based, or from data center over to the cloud, for motivations of cost and resource elasticity.
- Developer productivity.
This summary was written by Camille Gregory.