What is The ‘Single Source of Truth’?
Microservice Versions and Container Content
Microservice Versions are deployed via containers. Versioning container content is a new approach specific to Kubernetes. Have you thought about what your future looks like when you’re managing hundreds of containers and microservices that make up a single version of your software solution? Let’s just say, you’re going to need more than an Excel spreadsheet. Containers and microservices are game changers in terms of how we develop and deliver software. In the past, we have relied on a monolithic approach, with everything moving at the same time in an orchestrated dance that was never guaranteed to work just right. With microservices, we are deconstructing that dance into individual steps, allowing for its unique parts to be independently deployed. While solving many problems, this approach also creates its own set of issues. The primary problem is how to visualize what those individual Services create overtime in terms of the whole base application and subsequent application versions. This is the purpose of versioning container content.
What is a Microservice?
Let’s start from the top. What is a microservice and how do we decompose a monolithic application into Services? I like how Chris Richardson of CloudFoundry fame defines a Service:
- A service should implement a small set of strongly related functions;
- Services that change together should be packaged together;
- The Service can be changed without affecting clients;
- And, each team that owns one or more services must be autonomous. A team must be able to develop and deploy their services with minimal collaboration with other teams.
With microservices, we let go of the concept of a monolithic software application or linear pipeline. We instead have a non-linear configuration of different points of Services that represents the application. It’s still there, but just represented by many parts. For managing deployment configurations, we need to understand what is in the ‘microservices soup’ in terms of usage and configurations in order to wee the whole picture, or what we can call the ‘monolithic equivalent.’ This is the purpose of versioning container content.
Microservice Versions and a ‘Single Source of Truth’
For these and other reasons, there’s a conversation happening about tracking and versioning container content, or often called ‘configuration as code.’ Most of the focus is on using version control to manage the scripts defining a Kubernetes Pod or Cluster. Another discussion is needed about how to do versioning around the content of the containers, tracking history, and updates over time. Knowing where a Service is, who is calling it, as well as the version and relationships is critical. In other words, we need a ‘single source of truth.’
A Single Source of Truth
DeployHub is a hosted microservice management platform that simplifies the use of microservices. It was developed to be the ‘single source of truth’ for microservice usage and deployment configurations, particularly around the Kubernetes architecture with the added benefit of versioning container content. DeployHub’s versioning reports on what microservice is in a container, who is using it, and the microservices relationship to other services.
DeployHub versions and deploys database updates, environment variables, Kubernetes configurations, infrastructure components, application artifacts, and other critical parts of your software release. By versioning these individual parts, it can iteratively update, rollback, roll forward or jump versions to any state. It was designed with microservices in mind but can also support agile teams working in legacy architectures with safe, iterative releases.
Critical Features for Versioning Container Content
When we created DeployHub, we knew we needed to address the new microservices architecture. What we saw as critical for Kubernetes deployments was the ability to:
- Group ‘like’ Services together as a package;
- Support Domain Driven Design (DDD) with sub-domains;
- Services are organized based on a ‘business’ or ‘problem’ space;
- Encourage re-use and collaboration of Services;
- Perform continuous deployments without agents for frictionless implementation;
- Track a Service version to an application version, providing a single source of truth.
To provide the framework for managing services in their containers, DeployHub uses the concepts of Domain, Environment, Application, and Component. Some of these terms we’ve seen before, like Environment and Application, but Domains and Components are new concepts which relate to how your Services are organized. Just to make sure we are all on the same page, an Environment is a collection of endpoints where your Application is going to be deployed. Most traditional Application Release Automation solutions use these terms and concepts for doing software deployments.
To support microservices, DeployHub uses the concept of Components and uses Domains to organize them. DeployHub defines an Application as a collection of Components. Your microservices map directly to Components. Your Application could have any combination of Component types, such as application Services and database Services. A Domain is both an object unique to DeployHub and a concept used to organize microservices based on lines of business or ‘problems’. This is often referred to as Domain Driven Design (DDD). DeployHub Team (open source) provides you with two levels of Domains – a Global Domain and a Project Domain. DeployHub Pro supports a third level called the ‘Divisional’ Domain. Components are organized under the Domain structure. This organization is critical to versioning container content.
Collaborating for Success
As Developers, we know from our experience around Object-Oriented Programming that sharing and collaborating around the use of services will become critical for their success. We know we’re failing when each team begins to ‘copy’ and ‘rename’ their own versions of services. This would be bad. DeployHub provides a collaboration framework so that your service can be published and shared across teams. This allows them to choose a service from a Component list. Providing a central repository of the available Components also reduces the temptation of taking an older version of a service and making it ‘our own.’
Microservices are changing the way we develop, build, and deploy software. While solving many problems, microservices are also creating new challenges around tracking and versioning the use of services in large Kubernetes clusters. New methods of managing microservice and versioning container content track is needed to manage the ‘Microservice soup.’ DeployHub is one such solution. Its microservice management design creates a single source of truth of all your microservice configurations. It includes a back-end version control engine that tracks the changes and history of all service configuration. It also has features specific to organizing and sharing microservices across diverse team.
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Blogs on Kubernetes Microservices
- Microservice Configuration Management Blogs
- What is Configuration Management?
- How to Navigate the Deathstar
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- Versioning Lambda Functions
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Agentless Deployments with DeployHub’s Engine
- Version Jumps and Tracking
- How are Microservices and Applications Related?
- Migrate to Microservices with a Domain Driven Design
- Docker ‘Run’ May Not Work as You Expect