Thought Leadership
Service Catalogs Are Just The Start
Naphat Sanguansin
The software development landscape has witnessed a surge in the popularity of service catalogs, such as Backstage, Cortex.io, OpsLevel, and Port. These service catalogs have revolutionized how development teams collaborate and organize their development flows. They provide basic self-service, increase accountability through scorecard mechanisms, and give lightweight scaffolding through templates.
However, they have a significant drawback: they lack a complement for abstracting away and orchestrating software in production.
Addressing Production Challenges
Service catalogs have proven invaluable in standardizing and streamlining development workflows; they fall short when managing production environments.
Questions arise concerning who is accountable for production pieces, where to encode global and customer-specific business rules separate from services, and how production deployments meet business requirements.
To solve this problem, most platform teams start assembling pieces bottom up. This is due to competing priorities of developer experience and production metrics, such as reliability and infrastructure COGS.
For example, platform teams bring technology like Argo Rollouts, giving fine-grained rollout control without consideration to the larger workflow. This means Argo Rollouts and just about every other solution deployed is one of many point solutions used to uplevel reliability and reduce costs. These tools can include both off-the-shelf and homegrown tools. They can be broadly categorized into “Infrastructure as Code, “Deployment Tools”, and “One off Management Tools”.
When you combine needing to learn about Argo Rollouts with the rest of the collection of point solutions, it's clear that no workflow is being built to give the developer a fantastic experience.
Ultimately these competing priorities require the developer to understand the “full stack.”
The architecture looks similar to this:
In this example, the developer's journey uses the service catalog to understand what systems, libraries, and capabilities are out there. The catalog may also scaffold basic configurations that work in the base case ignoring business rules and other specifics in production. Using this basic information, the developer can start building and developing.
After developing the service, the Developer will need to work with an SRE, DevOps, or team that understands production to learn the underlying processes and procedures that are required to be production. In our example above, this would be learning how to configure and set up Argo Rollouts and the related tooling in the diagram.
This creates an incredible amount of overhead and switches the developer out of self-service mode and into working with a service organization team.
Adding Prodvana: A Production Orchestration System
Alternatively, Prodvana provides a clear interlock between development and production, acting as the production orchestration system.
To do this, Prodvana starts with a zero migration workflow. Prodvana combines disparate flows across your production toolchain by bringing together modern tools such as Kubernetes, Argo Rollouts, Pulumi, and Terraform, connecting legacy flows through Prodvana’s Runtime Extensions, and then enforcing your constraints via Prodvana’s Protections.
To bring Prodvana into an existing environment, you create two files; the first indicates your environment and the rules of the environment, and the second lets Prodvana know what services are in those environments.
This configuration file outlines two environments: staging and production. The two production environments have three rules:
Staging is stable.
It has been approved.
No alerts are firing before and after a deployment.
Any service that Prodvana knows about must obey these rules to be shipped to production environments.
To bring the service in, put the following in the same directory as your Kubernetes config files. This will ensure that configurations such as Argo Rollouts are managed within the Prodvana workflow.
With 42 configuration lines, we have created a very simple and elegant interface for developers to manage production systems.
The Happy Medium: Prodvana and Service Catalog Integration
While Prodvana and service catalogs target different challenges, they work seamlessly together to create an optimal development and production environment. Here's how they complement each other:
Prodvana Service Templates via Service Catalogs: Service catalog users can define service templates in Prodvana, allowing developers to leverage predefined configurations, reducing errors, and maintaining consistency.
CI System Integration: Continuous Integration (CI) systems can integrate with the service catalog and initiate Prodvana deployments automatically after successful builds. This ensures that new features and code changes flow smoothly from development to production.
Prodvana Safeguards Production: Prodvana, with its environment-aware approach, safeguards production environments, ensuring that business requirements are met during each deployment. This minimizes the risk of potential issues and downtime in live systems.
Conclusion
As the software development landscape continues to evolve, service catalogs and Prodvana represent next-generation workflows. Service catalogs excel at streamlining developer workflows and promoting accountability, while Prodvana focuses on orchestrating production environments in line with business requirements.
By integrating these two solutions, development teams can enjoy the benefits of both worlds, creating a symbiotic and efficient workflow that ensures both development ease and robust production environments.
