Companies that are built upon or are building software typically want to move fast and not break things. But how can growing teams allow developers to keep building new features and fixing bugs without operations teams slowing them down with complex and arduous processes?
How can operations teams allow developers to self-serve the environments and infrastructure while setting in place guardrails, precautions, and limitations to prevent downtime, security concerns, and service-level agreement (SLA) violations?
Consider building an internal developer platform (IDP). Here are key steps to take, and technical considerations to review, when setting up your IDP.
Don't rush or needlessly reinvent
Yes, this first point is an obvious one. Getting to a self-serve setup is a multi-stage process, and you should implement each stage as you are ready and evaluate its suitability and effectiveness as you go.
As you progress through these steps, you will build and add to your internal platform. Always be sure to assess existing commercial and open-source tools to help you do this before creating your solutions. These are plentiful and mature, from standards such as version control and Kubernetes to specialized open-source and commercial tools.
First, you benefit from the ecosystem itself and from the experiences of users of these tools. Second, you are not dependent on individual team members to maintain custom tools and potentially lose that knowledge.
Treat creating this internal developer platform as a product itself.
As David Sudia said in his KubeCon 2020 keynote:
"You have to treat internal developer tools and platforms as a product. Product management, developing personas, and providing support are super important for success."
Identify your pain points
It's hard to know what will solve problems if you don't truly understand those problems in the first place. Speak with team members, or regularly watch how they work. Where do they experience frustration and blockages or repeatedly waste time?
Are these problems related to tools such as brittle custom scripts that fail quickly, poor secrets management, or slow testing environments? Or are they related to people and processes such as lengthy and tedious approval processes, information silos, or team fiefdoms that are hard for outsiders to access?
Tools issues are relatively easy to identify and fix, but a fix or change is meaningless if you leave the people and process issues unresolved. People are often reluctant to change what they do and how they do it.
Instead of telling people they need to change, ensure that the new processes and tools you propose address their concerns and needs. For example, maybe an operations team enforces slow and strict approval processes due to a fear of a security breach.
If you can find a more automated tool that addresses those concerns, they are more likely to be on board.
Define boundaries
You are likely looking at implementing an internal developer platform when you have one or more development teams working on different aspects of one or more interconnected applications. This means that different development teams should be able to work on their own components without affecting the work of others and that operations and environments should support this ideal.
The shift to microservices-based applications has helped create tools and practices suited to this workflow. You can use different repositories to manage different application components that come with their own permissions and workflows.
Kubernetes namespaces help you define virtual clusters per team or component with their own policies and resource allocations.
These restrictions help ensure that while development teams can create and manage their environments, they can't overtake machine resources or impinge upon the work of others.
Automate trust
With guardrails and restrictions in progress, how do you ensure that the code running in environments meets requirements? The answer is something you probably have in place already: continuous integration and continuous delivery (CI/CD) pipelines.
One of the essential stages in the self-serve journey is ensuring you trust these pipelines to be reliable and give meaningful feedback. Many development teams have unreliable and inconsistent CI/CD pipelines with flaky tests and stages they continually override or ignore. If you have any doubts about the thoroughness or efficacy of your continuous processes, fix those before progressing any further.
As you go deeper into this process, spend time shoring up your external dependencies and analyzing their impact on your applications from a security and productivity perspective.
If one were to develop a problem, what impact would that have on your pipelines and deployments?
Fully provision environments on demand
There are a handful of components that teams often forget about switching to infrastructure as code (IaC). Among these are longer-running external services that your application relies upon but, for various reasons, are problematic to define as code. This could include DNS routing, object storage, or persistent data stores.
If you want to relieve environment provisioning responsibilities from ops teams fully, spend time figuring out how to allow developers to provision instances of these services or, at worst, connect to them without needing to speak to an ops team. This may be harder with brittle legacy services and applications.
There are ways to make these tools fit into an IaC setup, such as with the open-source Terraform coding tool, but development teams need to understand how to use them properly.
Some commercial services provide APIs or command-line interfaces to create resources worth investigating to achieve a middle ground.
Create new responsibilities
Often operations teams are opposed to setting up self-serve environments because they fear it will threaten their jobs. This common argument against automating repetitive tasks is generally false.
It pays to turn this thinking on its head. What do customers care about, as opposed to what internal teams care about? Customers care about performance, uptime, stability, security, and new working features. They don't care about how internal delivery workflows and pipelines function.
Suppose operations teams can spend more time on satisfying these demands and meeting SLAs instead of fielding requests from development teams. In that case, this improves not only developer experience but also customer experience.
To quote Evan Bottcher, an early proponent of IDPs:
"Application teams build, deploy, monitor, and are on call for the application components and application infrastructure that they provision and deploy on the platform. Platform teams build, deploy, monitor, and are on call for the platform components and underlying platform infrastructure."
Towards a good developer experience
If a team structure that allows its members to focus on tasks important and relevant to them sounds appealing to you, try to aim for an internal self-serve setup. In the long run, this will also help you work toward self-serving accounts and environments to external users, too, if applicable, including customers. This is a key principle of good developer experience.
Taking your internal processes seriously, and seeing the benefits of doing so, brings a broader rethinking of how to treat all interactions a developer might have with your product, which can only be a good thing.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
