True DevOps - “you build it, you run it” - has been the guiding methodology behind many development teams for years. However, the harsh reality is that most developers don’t like dealing with infrastructure. It isn’t just a source of significant cognitive load, but it also takes time away from their core job of writing, debugging, and running applications.
This is where Internal Developer Platforms (IDPs) present a significant advantage. By employing platform engineers to abstract this complexity away from developers, organizations can move away from the outdated DevOps model to a solution that’s more suited to their business.
Chris Stephenson, CTO at Humanitec, recently joined Sid Palas from DevOps Directive to discuss how IDPs and platform engineering are the future of software delivery.
Platform engineering is the future
While some companies may have some basic aspects of an IDP already in place (semi-standardized Helm charts and scripts, basic GitOps workflows, etc.), they need platform engineering to give that internal platform purpose and direction. Undirected growth often leads to unmaintained scripts that are barely connected, and that often cause more of a problem than they solve. This is particularly the case when new technologies evolve and prevent organizations from using these standardized practices.
Compared to this, platform engineering takes a more general approach.
According to Luca Galante, “platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an Internal Developer Platform covering the operational necessities of the entire lifecycle of an application.”
Instead of looking at tooling to solve a particular problem, organizations need to look to the future and foresee where they are going to be. It requires significant investment into a platform engineering team who can manage that vision, but it ensures that organizations can continually evolve and maintain a cohesive tech stack.
Solving organizational problems with an IDP
The first step is to take a step back and look at the problems the IDP needs to solve. This is something that often gets overlooked in the excitement to build an IDP, but in these cases, organizations fail to consider that their IDP is a product. Chris says:
“You need to think of it as any other kind of product, whether that’s B2C or B2B. Your IDP has users, so it has customers. You need to talk to your developers and find out how you can improve their developer experience. You need to talk to operations to see what challenges they’re experiencing. And you need to talk to engineering management to discuss whatever metrics are important to your organization.”
While customer feedback is vital to the success of an IDP, there will always be some broad themes that present themselves during platform development. Developer self-service is a key part of any IDP, as this allows developers to get their code running with minimal dependencies on other people. Not only this, but it gives operations and platform teams a way to provide tools while maintaining security standards and other best practices.
Self-service doesn’t just benefit engineers, either. As it reduces the time it takes to perform basic actions, IDPs can save organizations money in the long run. This is both by improving engineering efficiency by reducing cognitive load and using standardization to ensure that code adheres to internal standards.
Internal platforms are constantly evolving as technology evolves, which means that organizations will always need new ways to standardize the development process. Platform engineers play a vital role not only in building a platform, but also in ensuring that the platform meets stakeholder expectations.
With developer self-service playing a significant role in any IDP, this stakeholder engagement is vital. This ensures that the platform engineering team knows which tasks need to be standardized and find the correct level of abstraction. Chris explains:
“An IDP needs to satisfy the self-service needs of your developers and the control needs of the platform team without forcing any engineers to escape from the abstractions we’ve designed. It’s a way of structuring the development process rather than building a heavy system that’s churning a load of wheels.”
When should organizations build an IDP?
Typically, a Platform as a Service (PaaS) offers a lot of benefits to organizations when they start to grow their engineering teams. However, these benefits don’t last. For example, a lot of companies start building on Heroku because it provides the functionality their teams need to launch and manage software. Very few organizations can successfully scale Heroku and continue using PaaS as they get bigger, so this isn’t a realistic option for all organizations.
As organizations grow, they often need specific scalability, software integrations, or just more control than these PaaS tools offer. The first thing a lot of organizations do is turn to Kubernetes. However, what they fail to consider is that their developers - who are used to the ease of PaaS tools - now have to manage a lot more infrastructure themselves. Developers are thrown into a large learning curve where they have to now understand namespace management, manifests, and tooling just to do their jobs.
This presents a significant issue in both the short and long-term. Not only are current developers facing a significant rise in cognitive load, but it makes the onboarding process for new developers overly complex. Chris says:
“By the time you’re employing developer 101, this person probably can’t understand everything that’s going on because they get lost in a big sea of complexity. At this point, it makes sense to build an IDP because you want new developers to become productive quickly. You don’t want to have them spending time figuring out the intricate details of how your development pipeline works.”
At this stage, companies might also start to find that a lot of a developer’s workload is taken up by performing the same tasks repeatedly. This might be things like requesting infrastructure, finding the tools they need, and running their applications at scale for testing. It’s a pattern that’s repeated across various companies, particularly when organizations need to deploy code and run it at scale.
This is where internal platforms come in. The fundamental thing IDPs should do is, according to Chris:
“An IDP is a bridge between the developers and the platform teams so that developers can do their job without being blocked by operations. On the other side, operations can then ensure standards are applied and things are scalable without having to put that on the developer’s shoulders.”
Even though every IDP should share this core goal, no two IDPs should be identical. Large and small organizations face different problems, and internal platforms should evolve as technology changes and companies grow. Chris elaborates, “doing self-service for 2,500 developers is very different from 25 developers.”
At the end, building an IDP is less about when you build it, and more about what benefit it will bring developers. Chris says:
“At a large company, you might have thousands of developers all building small parts of a huge application with lots of micro services to manage. It has very different challenges to, for example, a startup with five to ten engineers who all have a greater understanding of how the system fits together.”
Similarly, there’s no qualifying metric that states when an organization needs to build an IDP, as this will depend on the organization and its needs. Organizations should consider building an IDP when they start to outgrow third-party platforms or are not able to provide a great developer experience to their engineers and need solutions that better fit their problems.
Thanks to Sid Palas at DevOps Directive for hosting this engaging and informative talk with Chris. Make sure to watch the whole talk on YouTube to get the full story from Sid and Chris, or read Sid’s summary thread on Twitter and join the conversation.
