Why You Can’t Go from Zero to Platform Engineering
Much of the conversation around platform engineering has suggested that it is a golden bullet for maximizing the developer experience while speeding application development. While it can provide significant benefits in these areas, this is only part of the story.
To achieve centralized control over infrastructure while reaping these benefits, infrastructure governance must be frictionless and consistent, which necessitates a significant level of automation maturity. So, what is automation maturity and why is automation required for a successful platform engineering strategy?
Why Automation Maturity Is Crucial for Platform Engineering
Most large organizations deliver automated infrastructure at multiple levels of maturity. The objective is for all infrastructure to be delivered and managed consistently, removing disparity and reducing the diversity of infrastructure types. For our purposes, we will consider three levels of maturity for infrastructure automation: ad-hoc, automated (some automation) and frictionless.
Organizations considered to have an ad hoc level of maturity employ a mix of manual, scripted and niche infrastructure methods. This level is people-intensive and error-prone. Maturing requires consistent, simple, measurable and secure infrastructure automation. It should be frictionless, enabling infrastructure to be created, administrated and supported without needing increasing numbers of experts who are in high demand and short supply.
Automation must be easy, providing native support for entire infrastructure stacks, which vary in size and complexity and reside in multiple locations. An effective automation solution removes all manual work, reduces complexity and fragmentation, ensuring the infrastructure is governed, secure and accountable to the business.
Most enterprises have multiple types and levels of infrastructure automation. Some visible and others buried as code. So, while enterprises may use a mix of Infrastructure as Code (IaC), cloud services, virtualization, containers and configuration tools, it does not mean things are under control or providing a measurable value. The use of automation is mandatory; however too much disparate and fragmented automation creates more issues than it solves. This includes difficulties in administration, inconsistent policies, unknown risks, increasing skill requirements, and difficulties debugging and supporting the automation.
Having many automation tools creates islands of automation where each method of provisioning infrastructure stands alone. Since modern application architectures use a mix of infrastructure resources, it’s common to see automation procedures trigger other automation procedures to deliver all the things needed at any point in an application software-delivery life cycle. Though this second level of automation maturity is where many businesses can begin to think about a platform engineering approach, many still have work to do to deliver the associated business value.
Finally, the move from automated to frictionless requires the infrastructure to stop being an abstraction and become an integral part of the activities for which it is used. For developers using an IDP, infrastructure is a seamless integrated function. The activity defines what infrastructure is needed at any point in time.
What makes frictionless automation possible is the notion of environments. An environment is an easy-to-understand model that includes all the things necessary to support an activity — the middleware, data, tools, infrastructure, etc. As environments are derived from an activity or task, they contextualize the purpose for those environments, allowing organizations to understand the reason, the criticality and the value of each environment. Then multiple environments can be associated so organizations understand how environments are used, why they are used and by whom, no matter the cloud provider, the infrastructure types or the complexity of the infrastructure layers. This gives businesses the ability to plan, prioritize and budget based on the value each activity delivers.
Plot a Path to Automation Maturity
While smaller teams typically have less complexity, larger teams and organizations are much more complex, requiring a greater level of automation. This means that the requisite level of automation to successfully employ a platform engineering strategy will vary from company to company or even between disparate teams.
Platform engineering for organizations with little to no infrastructure automation is a non-starter. Instead, these organizations should start by focusing on their desired outcomes and implement the necessary tools and processes to achieve them. For example, is the objective developer experience, speeding application development, managing costs, enforcing governance or something else? Based on that, organizations can then determine which tools and processes make sense to automate based on the associated business value.
Organizations with a medium level of automation maturity are in a good position to explore implementing platform engineering. The goals should be to standardize all infrastructure, understand all components that make up the complete environments used, enforce security and compliance, associate cloud costs with those environments and the business value they provide and, finally, make infrastructure readily available on demand via self-service when developers need it. On top of that, there should be a high level of ongoing visibility into every environment instance throughout its life cycle to maintain governance and manage costs.
Achieve More from Platform Engineering
Platform engineering, while still an emerging methodology, promises many operational benefits. While speeding application development and keeping your developers happy provide significant value for businesses, they should strive to realize the most value possible. By outlining the desired outcomes and implementing the requisite automated processes, the pursuit of platform engineering will yield better results more quickly for organizations, justifying the cost and effort of technological and organizational investments.
