Companies implement internal developer platforms to streamline developers’ efforts around app management and deployment. But these platforms are challenging for developers to use. Ravi Lachhman, field CTO, Shipa.io, discusses how platform engineers can reimagine these platforms to make developers happier.
Enabling developers to focus on their applications and rapidly bring new bells and whistles to market is a — if not the — crucial competitive differentiator for many businesses. To streamline developers’ efforts around application management and deployment, organizations are directing their platform engineering teams to create secure and scalable internal developer platforms (IDPs). Infrastructure complexity can be abstracted away with these platforms, and application rollouts can be accelerated.
Err, at least that is what the hope is.Â
In reality, rollouts of these internal platforms are often fraught. They become hampered by ballooning budgets and developer frustration. Along the faultline of this tension: platform engineers and developers each have their own perspectives and goals that are not necessarily congruent. Platform engineers are tasked with building a self-serve application platform that standardizes operations across tools and teams, advances infrastructure with no impact on developers and, importantly, can offer something that developers do not mind using. Developers want to focus solely on application code and quick deployment while ignoring infrastructure, be able to visualize application architecture, dependencies, and communications, and support applications directly without DevOps or platform team involvement.
The issue for platform engineering teams is that modern organizations must adopt containers, Kubernetes, infrastructure-as-code (IaC) tooling, continuous delivery pipelines, and the list goes on. Delivering these technologies effectively turns the platform engineering team into the organization’s own internal cloud provider. And providing these technologies at a high level is an immense challenge. A poor-quality IDP — or even one that simply does not win development teams over — runs the risk of wasting months of expensive time and effort, failing to meet management goals, and failing even to get developers to use it.
Such failures are not uncommon, as this recent Reddit post by a platform team facing a developer mutinyOpens a new window demonstrates. Adding to the complexity of delivering viable IDPs is that even within organizations, different teams will have different notions about what specific options around pipelines, IaC, and more will serve them best, and correctly so.Â
To meet these challenges, platform development teams should look to the practices of the actual major cloud providers. In particular, cloud providers leverage a standard API consumption model to render the complexities of their technology stacks invisible to users. Emulating this approach can enable development teams and critical tools to benefit from advanced infrastructure without being aware of it. Get this right, and you are maximizing the odds of winning crucial developer goodwill and support.
See More: How to Unlock Key Requirements for Enterprise-Grade Kubernetes Opens a new window
How an API Consumption Model Can Help
Here is a typical internal developer platform and the headaches it produces for platform engineers and developers alike:
(Note the Hell Helm templates… either term applies)
Source: Shipa.io
Platform engineers will invest months creating abstractions to connect specific pipelines, IaC tools, cluster versions, ingress controllers, and so on. Then they will repeat large portions of that work all over again whenever new variants of those solutions arrive. Because developers lack the expertise to operate services, ingress, and other requirements of application onboarding, it falls to the platform team to handle the endless, unpleasant job of creating and managing needed Helm charts and templates.Â
The internal developer platform also turns microservices support into a black box, meaning developers must lean on the platform team to troubleshoot issues. Post-deployment support reads like the same story, with platform engineers investing significant time into sorting out service ownership, changes, impacts on other services, and how to prepare developers to fix issues. Sweetening the deal, this job is entirely thankless. Developers primarily view the platform team that performs all that work as the bottleneck holding up their productivity. Developers face their own pressures to achieve rapid application delivery and deployment, which they cannot accomplish when facing the complexity at hand. Developers, therefore, often avoid using the IDP altogether, condemning these projects to failure.
To avoid this fate, platform engineers should instead safeguard the developer experience and enable self-service by borrowing a cloud provider strategy and leveraging a standardized application management API layer to detach applications from infrastructure.
(The API model from a developer perspective)
Source: Shipa.io
For developers, this approach hides Kubernetes complexity and the headaches of Helm charts and YAML files while allowing them to define application details directly. Developers can onboard applications themselves as they prefer while sparing platform engineers from that work. Developers can also utilize any tools they like to accelerate application delivery since every IaC and pipeline application calls the same application API.Â
(The API model from the platform team’s perspective)
Source: Shipa.io
Platform teams similarly make their lives far easier by putting a standardized application API in place. Teams can avoid the complexity of Rego policies or Kubernetes cluster API level definitions while simply and directly creating and managing RBAC, networking, registry control, node selection, and other policies. Platform engineers can also easily experiment and identify the optimal IaC tools and pipelines for each project, using the same policy definition for each. With a standardized format and workflow for defining policies, specific underlying details such as the ingress controller or cluster version no longer present any obstacles. Platform teams can freely shift or upgrade clusters, components, or providers while those changes remain utterly invisible to developers. Platform engineers can also utilize isolation and multi-tenancy by applying namespace level policies.Â
Make Developers Happy
The bottom line is that introducing a standardized application API is a win-win for platform teams, which become truly effective internal cloud service providers, and for the developers they serve. Developers gain a self-service model they actually control, will enjoy — yes, enjoy — using, and that helps them achieve their goals. At the same time, platform teams eliminate tedious and painful Helm chart and YAML file duties, as well as tension with development teams while maintaining and evolving scalable and secure infrastructure.
Do you use an internal developer platform? How do you ensure your developers are happy using it? Let us know on FacebookOpens a new window , TwitterOpens a new window , and LinkedInOpens a new window .