We see an increase in the number of companies building internal platform engineering teams. With this increase, we have seen some successful and some not-so-successful approaches. The goal of this article is to go through some of the practices we see out there.
What is Platform Engineering?
Before we start, let’s try to define what Platform Engineering is.
Companies are now trying to innovate to gain a competitive advantage. One of the key ways to achieve that competitive advantage is to have an efficient process for deploying and operating applications, which enables their teams to provide features to their customers faster.
Based on the assumption above, we can then assume that:
Platform Engineering is the process of building and maintaining a common platform as a product or service for internal teams. The goal is to reduce time to market and complexity by providing self-service deployments for applications and ease of operating and supporting applications in production. The team building and operating that platform need to innovate to keep the statement above accurate constantly.
A successful result enables development teams to build, deploy, and manage their applications in a self-service manner and using a simple process.
The Platform Engineering Team
That’s the team that builds and manages the platform mentioned above. If we were to pitch our team why we need a Platform Engineering Team, we could do it using the below:
For: Application development, security and compliance, and infrastructure teams (A.k.a your customers!)
Who needs to: Deploy and manage applications (your customer goals)
We provide: A scalable, secure, and self-service platform (your solution)
That is: extensible, declarative, and that can fit into the existing stack (your differentiator)
And as a result: You get a competitive advantage by reducing time to market and complexity (your value proposition)
Enabling evolution without compromise
One of the Platform Engineering team’s key responsibilities is to innovate how applications are deployed and managed constantly. That’s what gives your internal customers that competitive advantage and will make them consume the platform you provide.
The picture below is a general example of a platform in many organizations:
For your team to continue driving innovation, you need to experiment with new technologies and tools constantly. You need to work closely with your internal customers to implement the required tools and provide new features and improvements to the platform.
When trying to deliver on the above, we see the Platform Engineering team facing the following challenges:
1 – Every time you bring a new tool, especially around infrastructure provisioning or pipeline, it fundamentally changes how your users will consume your platform
2 – Many teams spend months or years building a platform focused on the current stack or infrastructure they utilize. When it’s time to adopt a new tool, a good chunk of the work done is no longer usable, causing stress and reinvestment on rebuilding.
The case for a declarative and standard application layer
The issues mentioned above are driven mainly by the interfaces you are giving your users to deploy and manage their applications are tied to the underlying infrastructure you chose, your pipeline, or the infrastructure-as-code (IaC) platform your team decided on.
While Terraform is a great tool, I’ve seen teams spending endless hours trying to now move to GitOps or Pulumi. That requires them to recreate pipelines, templates, and more.
There is no standard application layer to be leveraged by these tools that allow you to move between such different tools and approaches without requiring you to change things drastically and, as a result, impact your internal customers and remove that competitive advantage.
In addition to the above, as you scale infrastructure, experiment with new approaches and tools, you have several items to consider and address, such as RBAC, policies, monitoring, and more.
If not well performed, all of the above can cause friction between Development teams, Platform Engineering, Security, and others. That’s where an application layer can help.
Why should you implement it?
Using an application layer, you can implement a declarative and standard definition that your users can leverage to deploy, manage, and secure their applications. This approach enables you to detach the application from the underlying infrastructure, pipeline, or IaC provider.
Implementing a standard application definition lets you plug your platform into different IaC providers and move from Terraform to Pulumi or GitOps without introducing changes to how your users consume your platform. At the same time, it frees you up to experiment with new tools and approaches.
Implementing an application layer empowers your users to connect their deployed applications to different monitoring platforms. Your Security team has detailed visibility into changes, application ownership, service dependencies, and more. Finally, it enables developers to manage their applications successfully.
Conclusion
If you want your Platform Engineering team to deliver constant value, be able to explore new technologies and keep the competitive advantage that enables your developers to deliver the applications that move your business, then you should explore adopting an application as code approach.
In the next blog, we will show you how a declarative application layer, or application-as-code, can help you experiment with different technologies and enable teams to use different tools while keeping the developer experience consistent and your Platform Engineering team moving fast.
