Introduction
DevOps teams continue to look for ways to make the development and releases of enterprise software run as efficiently as possible. Although the software development life cycle has changed how applications are produced, DevOps teams must maintain the momentum of utilizing this modern practice. This would require looking for innovative ways to maximize the development team’s productivity so that they can work in optimal conditions with the resources provided by the enterprise. One of these solutions is the implementation of self-service through an Internal Developer Platform. Internal Developer Platforms are being adopted into more enterprises due to the various benefits and challenges of using this technology.
IDP/Self Service Overview
An Internal Developer Platform, or IDP for short, is a layer of technical components that allows developers to interact independently with their organization’s existing technology. It provides developers with the resources they need to run their applications. This can include but is not limited to container images, databases, logs, virtual machines, or pipeline deployments.
The operations or DevOps team are normally the ones that manage a company’s IDP. They make the baseline templates for configuration and prevent unstructured scripting that could cause additional maintenance. This ensures that the development team has a reliable platform to integrate into their existing workflows in producing software. In addition to managing the platform, the operations/DevOps teams architect the platform, create the APIs to the required infrastructure, and establish entry and compliance guardrails. These components are essential to having a fully functioning IDP, as the APIs allow developers to programmatically access the platform. The guardrails ensure that they are not using tools outside the enterprise’s scope and minimize the number of infrastructure problems that could arise during development.
It is common for IDPs to use an orchestration tool as the foundation of their platform. Modern-day IDPs are built on top of Kubernetes clusters with containers as workloads. This is due to Kubernetes’ ability to provision resources declaratively using YAML files known as manifests. They would need to write up the manifest of the resource they need to deploy and apply it to the cluster. Furthermore, the granularity of Kubernetes’ customization options allows DevOps teams to configure the tool to fit their enterprise’s resource and security needs. Additionally, they can restrict developers from accessing certain components on Kubernetes, permit access to resources within a particular namespace, or test out their application code in a deployment to see how it performs at scale. Kubernetes having this much development potential makes it a competent tool to create an IDP platform.
IDP vs. Paas
IDPs provide a platform for developers to build and test their code, making it easy to confuse it for a Platform as a Service solution. Platform as a Service, or PaaS for short, is a service where an entire platform or development environment is made ready-to-use in the cloud or a third-party service. It allows developers to build applications without worrying too much about the underlying infrastructure, similar to an IDP. However, PaaS and IDPs do have their differences. One major difference is that PaaS solutions normally require a partnership or subscription to a third-party vendor. While there is room for some customizability within a PaaS, most of the time, subscribers are only limited to the configuration options that the vendor has given to the platform environment. This could make it difficult for enterprises that need their applications to integrate with their existing technical resources since the PaaS solutions could lack the necessary features for their software to run proficiently.
With an IDP, the enterprise can put in the tools and resources that are specific to their company. Despite the customizability that IDPs offer, the drawback is that they have to be manually built while PaaS solutions are already configured and managed by a third party. However, IDPs are built on the tools and processes developer teams are already familiar with, whereas a PaaS would require teams to learn about the platform before effectively utilizing it. This could lead to delays in releasing updated software as the learning curve that comes with using a PaaS solution can vary depending on the service, especially when it comes to troubleshooting or debugging application code.
Benefits
Using IDPs comes with various benefits to the enterprises that use them. Here are some of the notable advantages that IDPs have to offer.
Promoting self-service
IDPs allow development teams to serve themselves according to their project needs. The self-service aspect of IDPs reduces the operations load on DevOps teams since the developers can serve themselves. That way, DevOps teams can have more time to focus on critical issues and efficiently maintain their enterprise’s technical resources. In addition, IDPs set a standard baseline that can be utilized by developers across the board. They can select the workloads that they need to run their application, apply changes to the baseline configurations, and initiate a deployment. They will know the available default configurations and expand from them if needed. If the edited configurations do not work for the developers, they can revert to the default settings with little to no issues. The promotion of self-service practices that IDPs offer to developers reduces wait time to deploy new features, shorten feedback loops, align tooling, and increase labour capacity. Therefore, development teams can continuously deploy applications without having to rely on or communicate with other teams. This leads to NoOps delivery, where no intervention from operations is needed to manage the infrastructure that will run the application code.
DevOps teams achieve their goals.
DevOps teams often become a bottleneck, but with IDPs and self-service, they can achieve their goals more efficiently.
As we all know, the concept of DevOps is to improve the efficiency of developing and maintaining applications, infrastructure, and services produced by the business. Fortunately, IDPs make that goal easier to achieve for the team. They lead to faster and easier delivery of software that is better quality and more secure. The platform comes with the tools needed to support the application, which has already been approved for use by the DevOps team. In addition, since application developers do not need to wait on an operations team to provision environments or cloud resources for them, they can just focus on their code and the repositories that version control their work. Any developer would agree that this will give them a huge break from getting their tasks done sooner and staying ahead of work deadlines.
Governance and Compliance
IDPs also benefit enterprises in terms of governance and compliance. An effective platform enables efficient IT governance while empowering application teams to deliver quickly. This is because IDPs render enterprises fully aware of their resources, so they can effectively align their technology strategies with their business strategies. Compliance is also made easier with IDPs. Taking a platform approach prevents compliance teams from being spread throughout the organization. They can all collaborate from one central source of truth, the IDP, where they can ensure that the resources provisioned on the platform comply with their enterprise’s business and security needs. One could only imagine how many compliance teams that IDPs have saved from excess stress and management of various technical resources within the company.
More focus on the business
Maintaining the business is very crucial in the field of IT. Undoubtedly, technical teams are one of the main backbones of a business that keep it running. For businesses to continue to thrive, they need to be able to efficiently manage their resources, which can become challenging over time. This is where IDPs can help resolve this issue. They ease the common complexities of modern application software systems and lower operational burdens. Relieving these complexities allows enterprises to run their applications and systems at optimal conditions while directing more energy into implementing business strategies that will maximize their profits and success in the industry.
In addition, IDPs allow companies to experiment with new configurations and updates that could help them continue to thrive. Providing ready-to-use environments offer more opportunities for experimentation within different business models. This could include testing a new VM configuration or a different server architecture for an application. As a result, companies can determine what models are effective while minimizing the technical risk that could come with experimentation. It is hard to disagree that implementing experimental changes could potentially bring down important resources and make it more challenging to roll back these changes without crippling the business as a whole. Thus, IDPs provide a safety net for enterprises to fall back on if needed by rolling back changes to their default configurations.
Challenges
While IDPs offer many great benefits to businesses, they do come with their own set of challenges. One of these challenges involves defining a tech stack to use with the platform. A tech stack is the combination of tools, programming languages, and frameworks used to build or manage software applications. They are the foundation of the services that a company has built, and an IDP needs to incorporate their tech stack to be effective. Unfortunately, tech stacks are not uniform across all companies, even within different teams. They can vary from group to group relying on their stack, tradition, codebase, and power set—which makes discovering an agreed-upon definition considerably tough when making an IDP.
Another challenge is building the IDP itself. Building an IDP requires having a platform engineering team. They will be responsible for building and managing the platform. Normally the platform team includes the existing operations or DevOps teams, but they would need to ensure that they incorporate everything that the developers would need into the IDP. If the platform is missing several components, it can make it difficult for this technology to be reliable for the business. In addition, an internal development platform must also be prepared to integrate with new development tools and leverage new infrastructure. However, reducing bottlenecks might become a double-edged sword for an IDP. If the dev team relies on an IDP that requires high maintenance by DevOps, they can face problems with accessing resources like internal VMs or databases that are constantly configured by the DevOps teams. As a result, the development team could be limited on what internal resources are readily available to use with their projects.
Enterprise Adoption
Despite the challenges that come with constructing an IDP, companies are already adopting this modern practice into their technical strategies. According to Puppet Lab’s 2020 State of DevOps Report, from a survey that included over 2,400 participants around the world who work in the tech industry, about 63% of participants agree that they use internal developer platforms. Statistics like this make sense as companies continue to expand their DevOps practices for producing software. In fact, the researchers featured in a ZDNet article on IDPs have noted that the evolution of DevOps correlates strongly with the high use of internal platforms. These platforms offer the automation and efficiency that DevOps teams are looking to provide for their companies, which is one of the principal reasons why IDPs are becoming widely adopted.
Various enterprises like GitHub, HelloFresh, TwoSigma, and Twitter have their reasons for adopting IDPs. Jason Warner, the CTO of GitHub, has stated that one reason for needing an IDP is because of the fact that the enterprise “cannot scale an efficient engineering organization on bash-scripts…”. Scripting tools like Bash are limited to the person or service that executes them and the code within the script itself. Thus, any new tools and services would require consistently refactoring the scripts to cover those resources. With GitHub’s adoption of this practice, they decided to base their IDP on Kubernetes as an orchestrator called Moda that abstracts away everything related to K8s so that application developers have zero touchpoints with it. As a result, their teams can customize and deploy their enterprise resources as efficiently as possible. No wonder Kubernetes continues to be the go-to container orchestration tool!
Samantha Coffman, the senior product manager at HelloFresh, states that the company adopting an IDP has helped solve the problem where the complexity of their software grew as their engineering team continued to expand. They decided to take advantage of an IDPs ability to allocate resources for a project easily, which is essential for a company that specializes in delivering groceries to its end users. At Two Sigma, their IDP consists of a Git environment for building, testing, and reviewing code and an internal execution environment for packaging that code in a container, along with all of the underlying operational, monitoring, and compliance considerations abstracted away from the developers. Incorporating version control into the platform can help roll back changes if needed, which has been noted as an essential component for an IDP to be reliable.
Twitter has a unique way of viewing its IDP platform. They view their IDP as providing a set of paved paths for developers to follow. These paths remove the confusion and decision fatigue that development teams can come across with developing new or updating application code. They would not need to schedule some time to make some excessive discovery on what tools and technologies would support their application, as the discovery has already been taken care of by the DevOps team who built the platform.
IDP tools
Normally there are a set of different tools that DevOps teams could use when it comes to new technology or practice, but that is not the case with IDPs. The tooling behind Internal Development Platforms are tailored specifically to the enterprise that is building them. In GitHub, their IDP is an internal catalog that manages services that are hooked together with Service-level objectives. The catalog of services that GitHub configured for their workflows would not apply to another company like Twitter or TwoSigma. If that was the case, then it would be more of a PaaS solution instead of an IDP. In addition, IDP tooling normally consists of APIs that can only be accessed within the scope of the enterprise. APIs integrate technologies and tools that are used by the enterprise teams to minimize maintenance and security risks across the board.
Although IDPs are designed specifically for the company that is using them, there are third-party cloud providers that offer utilities that help companies to build their own IDPs. Amazon has a tool known as AWS Service Catalog, which allows organizations to create and manage catalogs of IT services that are approved for use on AWS. Although this applies to tools and services within AWS, it allows DevOps teams to configure the AWS resources that the company needs for their applications and make them a part of their IDP. For example, a company can use the Service Catalog to provision Amazon EC2 instances, the virtual machines that AWS provides, or Amazon RDS databases that are configured to meet their specific needs. When a developer needs to use an AWS service for their application, they could go to the catalog and use one of the approved services that are readily available to support their new or existing software projects.
Conclusion
Internal Developer Platforms have proven to be a useful component to have in an enterprise. From having internal infrastructure and services ready to use to reduce the complexity of enterprise resources, IDPs are making the software development life cycle easier to manage for many technical teams. Developers can access the resources that they need, while operations can save themselves the headache of having to process additional resource requests from the development teams. Overall, it looks like IDPs are here to stay and will continue to be adopted across more enterprises to support their software.
