In this blog post, we want to discuss the pros and cons of the different deployment options
Deployment options
When introducing an Internal Developer Platform (IDP), companies have basically two option: building it in-house or acquiring a complete package from an external service provider. For in-house development, the responsibility lies with the operations team or a designated „Platform Team“ within the company. This team’s primary functions include creating, further developing, and maintaining the IDP. They closely interact with other organizational members to identify issues at the team and company levels, set basic configurations for applications, and manage permissions. Additional tasks involve ensuring „Standardization by Design,“ managing infrastructure, Service Level Agreements, optimizing workflows, and configuring the IDP to automate recurring processes.
Contrastingly, the Platform-as-a-Service (PaaS) approach involves an external provider offering the platform, taking on these responsibilities. Companies with specific IDP requirements and an in-house Platform Team generally prefer self-development. Instead of starting from scratch, the team can utilize various tools and services to assemble the platform. These tools and services, categorized into platform orchestrators, portals, service catalogs, Kubernetes Control Planes, and Infrastructure Control Planes like Terraform and GitLab CI, each handle specific functionalities of an IDP. Existing tools and technologies like PostgreSQL, Kubernetes, and GitLab CI can be integrated into the IDP.
Backstage Tech Stack
A potential tech stack for an IDP might include Backstage, serving as an internal developer portal with features like a software catalog and tools for monitoring and technical documentation management. Backstage can be extended through plugins for new functionalities. ArgoCD, a GitOps tool, would handle dynamic application deployment in Kubernetes clusters, while Terraform allows developers to provision the desired infrastructure. In addition, companies like Soeldner Consult offer ready to use GitOps plug-ins for the self-service of infrastructure deployments.
Cost considerations
Tool selection often considers cost structures, with distinctions mainly in usage-based or ongoing expenses. While open-source tools like Backstage, ArgoCD, and PostgreSQL are available for free, commercial tools like the Internal Developer Portals „Roadie“ or „configure8“ have usage fees. Despite being open-source, some tools may incur costs for underlying infrastructure operation or developer effort for setup and maintenance.
Along with the complex cost structure, differences in integration concepts, scope, and hosting models must be considered when selecting tools. The self-development of IDPs presents challenges like increased effort and a steep learning curve for tool implementation, necessitating a capable platform team with the necessary knowledge and resources. While complex configurations may prolong the IDP’s readiness, self-development offers design freedom, allowing the platform team to tailor the platform to specific requirements.
IdP for Startups
For startups, small companies, or organizations lacking the necessary resources and knowledge to independently develop and operate an Internal Developer Platform (IDP), leveraging pre-built solutions from third-party providers might be a practical choice. This route bypasses the complex tasks of setup, maintenance, and further development, as they are primarily executed by the third-party vendor. Similar to custom development, both open-source and closed-source ready-made solutions are available. Typically, these solutions are offered as „Platform-as-a-Service“ (PaaS) products, encompassing a wide array of toolsets. „Mia-Platform“ and „Coherence“ are examples of such platforms. Many providers also allow for the integration of services from external providers, like GitHub repositories or Kubernetes tools, and often feature their own developed tools designed to be integrated into the IDP.
Most providers offer official support, a benefit not always guaranteed with self-developed IDPs. The focus on the IDP concept varies by provider, with some covering the entire software development process as an „End2End“ development process, while others, particularly open-source solutions, may offer only parts of the IDP’s task spectrum. Currently, a comprehensive IDP that is distributed as open-source but also covers most features of a closed-source software does not seem to exist. Closed-source products are generally offered for a monthly fee, with costs dependent on factors like team size, the number of builds completed per month, or the underlying infrastructure used. Due to the predominantly closed-source approach, there is an expectation of reduced design flexibility in the setup and operation of the platform, as well as an increased dependency on the third-party provider.
