Table of Contents
As your organization grows, deploying your software and maintaining all related systems can become more complex. This complexity, along with the desire to own the infrastructure stack without needing workarounds for off-the-shelf tools, drives many teams to implement an internal developer platform (IDP). An IDP allows software developers to complete tasks previously handled by the operations team, despite having little to no operations experience. These tasks might include anything from spinning up new test environments to deploying code to production.
This article will look at some of the factors that teams should consider before building an IDP. It will also explain how to get started if you decide that having an IDP would be beneficial to your team.
Benefits of an Internal Developer Platform
With off-the-shelf tooling, the learning curve for getting started to deploy your code is much less steep. However, over time, you may find that you’re constantly creating exceptions and workarounds in these tools to get them to match your deployment process. It might make sense in this case to develop your own internal platform. As long as you have buy-in from inside your organization as well as a team dedicated to supporting an IDP, you can achieve a number of benefits by building your own platform.
Faster Engineering
If the operations team is consistently overwhelmed by requests from the engineering team, an IDP can automate some of these tasks and enable the engineers to do the work themselves, freeing the operations team up to perform the more complex tasks. This prevents bottlenecks and allows the engineering team to accomplish their work more quickly, without waiting for the operations team. In addition, an automated platform ensures that the operations tasks are performed to the same standards that the ops team would have used because best practices are built into the platform.
Automation
Especially if your company is just starting out, it can be challenging to automate your deployment and operations processes because your product and company are still evolving. However, as your organization grows and matures, many of the tasks related to deployment become more standardized and repetitive. Once that’s the case, these tasks can be automated. Using an automated system keeps human error out of the deployment process and frees up developers and operations staff to work on the more intensive or one-off tasks while ensuring that the automated work doesn’t affect the day-to-day ability of the team to ship code.
Better Visibility and Access for Engineers
When the development and operations teams are separated and only communicating via Jira tickets or internal chat, it can be difficult for the development team to understand everything that needs to happen for their code to get deployed. In addition, if the operations team has a large backlog, the development team may not know when their code is getting deployed or when it might be ready for testing and verification.
With a self-service internal developer platform, developers know exactly what’s going on with their deployments because they’re initiating those deployments. Most IDPs also provide details, including what stage of a deployment the platform is on or whether any errors need to be corrected.
Brings Dev and Ops Together
The entire foundation of the DevOps movement was the idea that developers and operations staff shouldn’t be two separate entities and are most effective when they are working together. This means writing and deploying code in tandem, sharing knowledge, and most of all, communicating clearly about how each team can make the other’s job easier.
Collaborating on an IDP can be one of the best ways to do this. The development team doesn’t suffer any ambiguity about what the operations team needs because the operations team designed the platform to fit the organization’s deployment and operations needs. And the operations team doesn’t have to work with individual developers to get them what they need because they can build it into the system and make it available to the entire team. This helps all members of an organization work more effectively and in closer collaboration.
Standardized Workflow
Because changes to the IDP are rolled out to the entire team and the IDP can be modified to suit the needs of the organization, building a platform like this ensures that the deployment workflow is standardized. This means it’s more easily documented than a web of workarounds and shortcuts. The documentation and standardization makes it easier to fix bugs in the deployment process. Additionally, new team members can get up to speed quickly even without the years of institutional knowledge possessed by more experienced team members.
What to Consider in an IDP
If building an IDP is right for you and your organization, there are a few things you should keep in mind as you start building and testing it with your team. At its core, an IDP is usually managed by the operations team, but developers are often needed to help with the implementation as well. Usually, the platform will run on an organization’s already-existing cloud infrastructure, although an on-premises solution is an option.
There are a few other factors to consider.
Developer Experience
Building an IDP is by no means a trivial task. It requires working with tools and processes that can be quite complicated. Because of this, at least one or two experienced developers may be required to help build it. If your entire team is relatively junior, you may want to consider using a pre-built solution. If you’re still set on building your own IDP, it might make sense to bring in a consulting team to guide your team through the process.
Policies
Building an IDP also requires that you know which users and groups of users should have which permissions. If you’ve used any cloud infrastructure system, you know that in-depth permissioning sets need a lot of attention to detail. This can be one of the most time-consuming parts of the IDP to build, because of how granular the permission set has to be and how these various permissions need to interact.
Cost Optimization
Because your IDP is also giving more people a layer through which to interact with your cloud infrastructure, you need to keep cost optimization in mind. If a developer spins up a new test environment, it uses cloud resources that your organization is paying for. If these resources aren’t frequently audited or if broad permissions are granted as to who can undertake more intensive operations, these costs could start to spiral out of control.
Conclusion
As your organization scales up and your platform gets more complex, you may want a tool that you can control to help you and your team with deployments. This is where an internal developer platform comes in handy. The biggest downside to IDPs is that they can require a lot more headcount and expertise than off-the shelf solutions. It’s important to balance those things when choosing the best path for your organization.
Photo by Martin Reisch on Unsplash
