*article updated on September 28, 2024
How to build success into your internal developer platform
Platform engineering is an emerging approach to internal infrastructure whose end goal is accelerating product delivery to external customers. It means a top-down commitment to streamline and scale software development and delivery across the entire organization. Even for experienced DevOps engineers, it means adopting an additional set of best practices.
The end goal for platform engineering teams is an optimized developer experience. You need to give developers (including platform teams) the ability to orchestrate any tool. Replace toolchain complexity with fast, secure, scalable workflows. Allow developers to choose the best tools for the job. Design wisely to embed best practices, standards, and governance as built-in foundations rather than after-the-fact requirements.
These best practices will streamline the development and delivery of new features and products across the company. They’ll let software teams deliver robust value to customers much faster. And often, adhering to them will do the same for you.
1. Keep the focus developer-centric
Treat your internal developers as if they were paying customers with plenty of other options should you fall short of their expectations. It’s true enough. Give them a platform between their work and the services they rely on to do it so they can focus on their code and configs rather than that of the infrastructure they build with.
They’re tough customers: they want autonomy and self-service but don’t want it from a mandatory toolkit. Build a platform that lets them choose the best tools for the job and makes it easy to configure their toolchains.
2. Promote productivity by removing overhead
Developers shouldn’t need to become experts in assembling ever more complicated services. Instead, reduce their mental burdens by standardizing self-service automations, actions, CI/CD workflows, and golden paths. Encourage fast onboarding and collaboration through familiar and extensible domain-specific languages.
Configurations should be composable, reusable across projects, and easy to maintain and update. Define policies, access controls, properties, secrets, etc., at an organization-wide level so new pipelines can inherit them.
3. Keep it cloud-native, open, and extensible
Build for the next ten years rather than extending the last ten. Create an open and integrated architecture around popular open standards and de facto technologies that are both open-source and cloud-native, such as Kubernetes, Tekton, OAuth, OpenSearch, OpenFeature, and Keycloak. Embrace the DevOps ecosystem as a foundation, starting with Jenkins.
The flexibility to orchestrate diverse toolsets will let developers continue to use their preferred technologies by simply plugging them into the platform.
4. Lock in security and compliance checks
Build in platform-wide checks for source code, binaries, cloud environments, data, and the entire infrastructure. Design for inheritance and use out-of-the-box actions to inherit properties set across the organization. For example, set organization-wide security requirements in Snyk at the platform level. New pipelines will automatically inherit the correct actions.
5. Champion continuous improvement
Build in and use feedback loops that collect data from the entire software development lifecycle to get contextual and correlated flow, DORA, and value stream management metrics. Just as developers are moving from periodic updates to daily releases with testing in production, so should platform teams plan, design, and maintain internal developer platforms (IDP) that can be updated or modified at a moment’s notice to remove impediments immediately.
You have non-technical work to do, too
Implementing an IDP isn’t only a technical endeavor. It also requires a cultural shift within the organization. Developers and other stakeholders need to understand the benefits of using the IDP and be willing to adopt it as part of their development processes. Organizations need to allocate skilled engineers, project managers, and budgets to ensure the successful implementation and ongoing maintenance of the platform.
Our best practices will guide you in building the best IDP for your organization. But you also need to do some non-technical work to ensure it is brought to fruition and provides maximum benefits:
Secure executive buy-in. The biggest hurdle to success is often the need for dedicated resources to create, maintain, and support an internal platform. Top-down support of the IDP is crucial to getting the resources, approval, and prioritization you need to deliver what you’re technically capable of.
Communicate benefits. Reach out to various groups, including developers — they can resist change as much as anyone — to present how the platform can streamline development processes, improve collaboration, enhance productivity, and accelerate the business. Take their questions and objections to heart.
Provide training and support. Offer multiple ways to help developers effectively utilize the IDP. Meet them where they are: Different developers will respond to different forms and formats of skill enhancement. Be clear that you’re there both to teach and to learn.
Facilitate the sharing and retention of knowledge. Developers prefer tools that come with a community that shares and preserves their experience, ideas, and even complaints. Your IDP should be one of them.
Everybody wins — including customers
The end goal of a better developer experience is to accelerate the rollout of new and better products to market. By giving your internal developer customers the autonomy and efficiency they crave in ways that scale going forward for everyone, you’ll empower the whole company to succeed.
Learn how the CloudBees cloud native DevSecOps platform can effectively tackle your platform engineering challenges and serve as the hub for implementing best practices across your teams. Try it today!