Platform Engineering teams are the developer’s cloud provider

TL;DR

• Platform engineering teams are the internal cloud providers.
• Pressure is on for both sides to maintain security and scalability while delivering applications faster than ever.
• Many platform engineering teams struggle to get developers to consume what they spent months building.
• Detaching applications from the infrastructure enable platform teams to continue building while quickly providing developers with self-service and a developer platform they can use.

The Pressure is On

Organizations rely more than ever on their engineering teams to get in front of their customers. Quickly delivering the latest functionalities to end-users in a reliable way can make or break a company these days.

This need raises the pressure on engineering to deliver a scalable platform, rollout application updates faster, and manage applications efficiently once in production.

To achieve this, Platform Engineering teams are building internal platforms to hide infrastructure complexities so developers can focus on deploying and managing applications, and this is a tall order.

I say it’s a tall order because we have to realize we are dealing with two desired outcomes here:

Platform Engineers:

Developers:

The above may seem obvious, but let’s be honest: As you adopt technologies such as containers, Kubernetes, different IaC tools, pipelines, and more, delivering this IS a real challenge.

If not delivered well, developers won’t use it, management won’t be happy, and months of effort will be wasted.

Here is a recent thread on Reddit that you can take as a reference: https://www.reddit.com/r/sre/comments/stuekd/weve_spent_months_building_this_platform_devs/.

Becoming a Service Provider

Platform teams are the internal cloud provider. They now have to build internal developer platforms so developers can focus on what matters most.

But every organization is different, and different teams inside a single organization will have preferences around pipelines, IaC, and more. See the complexity increasing?

Cloud providers are great because they hide the complexity of their tech stack choices behind a (drumroll please) standard API consumption model.

So, the question is: How can you repeat this model, hide the complexity of infrastructure choices and provide a standard way for developers and tools to consume it, turning your development teams into happy consumers?

Challenges with Internal Platforms

Here is what most teams are dealing with:

The picture above presents problems for both personas:

Platform Engineers:

• Spend months building abstractions between a specific pipeline, IaC tool, underlying cluster version, ingress controller, and more. As soon as a new variant is introduced, most of their work will need to be recreated, adjusted, or duplicated.
• Most developers don’t have a deep knowledge of services, ingress, and more, so onboarding new applications become a Platform team’s responsibility to create and manage endless Hell Helm charts and templates. 
• Because of the above, developers see Platform teams as a bottleneck. 
• Developers can’t support their applications post-deployment. The Platform team has to spend an enormous amount of time identifying who owns each service, changes made, impacts on other services, and how to help the developer fix it. 
• Developers refuse to use the internal built platform

This is far from an ideal scenario.

Developers:

• Can’t onboard their applications and place the burden on the Platform team to create boilerplate templates.
• Supporting microservices becomes a black box, so when challenges arise, developers depend once again on the Platform team to help them identify issues.
• Developers are under pressure to deliver more often and faster, but given the level of abstraction and complexity given, they can’t achieve it.
• They are getting inundated with YAML and infrastructure-level definitions that mean nothing to them and add no value to their task.

Tough on both sides, right?

Builders Are Gonna Build. Users Are Gonna Use.

What can we do to untangle that complex scenario? How can you get developers to use what you build? And, how can you continue building and evolving the platform without impacting your user’s experience? 

By repeating a very successful model that we have seen multiple times before, implementing a standard interface (API) layer that detaches the application from the underlying infrastructure.

How do you do that?

For developers:

Let’s follow the cloud provider model. By standardizing the application management API, you:

• Hide Kubernetes away from the developers. They focus on defining the details of the application without dealing with Helm charts, kustomize, or whatever combination of 493193814 of YAML lines you have to create to deploy a container.
• Enable developers to onboard applications independently, reducing the platform team’s burden.
• Reduce the amount of toil and repetitive work you would have to manage with solutions like Helm and Kustomize.
• Because all IaC and pipelines call the same application API, developers can choose the tools they prefer to deliver applications.

For Platform Teams:

By implementing the standardized application API approach, Platform teams:

• Can build policies across RBAC, networking, registry control, node selection, and more without dealing with complex Rego policies or Kubernetes cluster API level definitions.
• Use the exact policy definition across different IaC tools and pipelines, allowing you to experiment and implement different tools for different projects.
• Implement a workflow and standardized format to define policies, regardless of the underlying ingress controller, cluster version, provider, and more. 
• Are free to upgrade clusters, swap components, move providers, and more. All without impacting developers
• Apply policies at the namespace level, enabling platform teams to build isolation and multi-tenancy.

Overall, by implementing an application-level API, you quickly enable a self-service model for developers and build a scalable and secure model. All while you are the cloud service provider within your organization, continuing to build and evolve your infrastructure.

Getting Started

In conclusion, you can implement an application API by using Shipa.

Shipa’s control plane is available both as a SaaS and a self-hosted solution:

• SaaS: https://apps.shipa.cloud
• Self-Hosted: Installing Self-Managed Shipa

Because Shipa’s control plane allows you to connect its application API to your existing Kubernetes infrastructure and target specific namespaces, you can continue running your existing applications and Shipa side-by-side.

As you connect policy frameworks to specific namespaces in your cluster, every application deployed using that policy framework as the reference will automatically use the particular namespace associated with Shipa’s policy framework API.

Resources

Shipa Cloud: https://apps.shipa.cloud

Documentation: https://learn.shipa.io/docs

Quickstarts: https://learn.shipa.io/docs/quickstart