Critical for Managing Microservices at Scale
DeployHub simplifies cloud-native architecture by governing your microservice supply chain in one place. With microservices at scale, Developers, DevOps, and Security teams struggle to understand dependencies, SBOMS, vulnerabilities, impact, and ownership. They grapple with microservice versions drifting across clusters or the sprawl of redundant services. DeployHub’s microservice catalog tool centralizes this level of information, making what’s hard about microservices easy.
With DeployHub, you get a microservice catalog tool that…
Provides the clarity needed to govern microservices at scale.
Follows your microservice supply chain across organizational siloes with versioning.
Tracks your microservice ‘logical’ application dependencies, giving you uncompromised visibility with SBOMS.
Features of Our Microservice Catalog Tool
DeployHub’s unique microservice catalog tool features include:
DeployHub is a microservice catalog that provides governance around the software supply chain. It centralizes SBOM and CVE information for each microservice and aggregates this data to the application level. Providing this level of ‘logical’ application visibility is needed to mitigate the risk of consuming open-source software.
The one thing constant about microservices is that they change. DeployHub tracks the changes of your microservices metadata with their ownership and how those changes impact other consuming applications, creating new SBOMs for each new version. This is the essence of microservice versioning.
As the number of microservices grows, they become harder to find and share. Domain-Driven design represents the problem space a microservice solves. DeployHub catalogs your services based on their Domain representation, allowing them to be easily found and shared to encourage reuse and eliminate redundant services.
Imagine trying to support a microservice you know nothing about. You first need to know who to call when a problem occurs. DeployHub’s microservice service catalog centralizes both the owners of the microservice and the consuming application teams. If a problem occurs, you know who to call, and who to tell.
Microservice Catalog Explored Whitepaper
Tame your microservices by displaying them all in one place. Track deployment details, SBOMs, inventory, consumers, version history, and the teams that support them.
How do microservice catalogs work? Here are some answers to common questions about microservice catalogs.
- What is a Microservice Catalog?
- Unique Attributes
- Who Uses a Catalog?
- For Developers
- For Operations
- For DevOps
What is a Microservice Catalog?
A microservice catalog simplifies cloud-native architecture by displaying all services in one place. A microservice catalog simplifies a cloud-native implementation by providing a central location to find and share thousands of services consistently across all clusters and teams. A microservice catalog facilitates collaboration across organizational siloes, saves money by encouraging reuse, and tames the difficulty common to a shared service architecture.
What are the Unique Attributes of Microservices?
Every microservice is different, and each has its own unique attributes. The attributes include ownership details, consuming applications, transitive microservice dependencies, versions, and inventory across all clusters. The attributes of a microservice change over time, impacting consuming applications and other dependent services.
Microservice catalogs track and manage the attributes, showing the changes over time, and minimizing the time for root cause analysis. They also provide a ‘predictive’ platform for taming microservices even before deployment.
What Features Do Microservice Catalogs Have?
Here is a list of standard features that microservice catalog tools typically contain:
- Microservice Organization
- Microservice Ownership
- Service to Service Dependencies
- Supply Chain Versioning
- Logical Application Supply Chain with SBOM
- Vulnerability and License Reporting
- Microservice Inventory by Cluster
- Deployment Metadata
Who Uses a Microservice Catalog?
The users of a microservice catalog include producers, consumers, DevOps teams, SREs, production support, and supply chain security. The core purpose of a microservice catalog is to provide everyone, from the API developers to the production support teams, with essential information needed to succeed in a shared services architecture.
How do Microservice Catalogs Work for Developers?
Governance catalogs help developers start creating microservices. They focus on registration of the service to a specific ‘Domain’ and track the developers’ tools used to develop and test services.
How Do Microservice Catalogs Work for Operations?
Governance catalogs focus on tracking what is running in production and maintaining service level objectives (SLOs). Their primary goal is to help support teams and SREs maintain their incident response times through ownership information and the blast radius of a problem service.
How do Microservice Catalogs work for DevOps?
Governance catalogs track the software supply chain with versions. DevOps Teams who manage pipelines use the catalog to determine where a service version runs to minimize drift across clusters. Microservice catalogs can also track who consumes the service as a dependency and manage the blast radius of a high-risk service.
Pricing & Plans
DeployHub has a pay-as-you-go pricing model. Learn more about each DeployHub plan.
- Jira, Bugzilla, GitHub Issues
- DB Updates
Helm Custom Deployment Actions
Helm can be called to replace the DeployHub default processing engine for performing container deployments. When DeployHub executes the release process, it will call the Helm Chart you have defined as your Custom Action at the Component level. Our microservice catalog includes the version of the Helm chart as part of its overall configuration data. In addition, DeployHub’s microservice catalog can track Key Value pairs and generate override files for each environment to which you are deploying.
Jenkins as an Orchestrator
The Jenkins integration uses the DeployHub Jenkins Groovy Library to perform the following steps:
- Continuous Configuration Management: The process of automatically versioning Components, like microservices, with their consuming Applications.
- Moves: Allows Jenkins to tell DeployHub to push a new update from one state to the next.
- Deploy: Allows Jenkins to tell DeployHub when the deployment needs to be executed.
- Approvals: Tracks an Approval, with audit, between Jenkins and DeployHub Pro (not supported in DeployHub Team).
Configuration Management for Testing
DeployHub integrates with CircleCI to support microservices continuous configuration management, and continuous deployments built into your CircleCI pipeline. In particular, DeployHub integrates with CircleCI to enrich the CI/CD pipeline around microservices, tracking which applications need to be retested due to a common microservice update.
Critical to the process is the ability to perform versioning and tracking microservices across clusters and teams and map them to ‘logical’ Applications. DeployHub’s CircleCI Orb includes the ability to perform automated version and dependency management of microservices tracking application and microservice relationships, their versions, and their deployment metadata.
Tracking Change Request and Issues
DeployHub integrates with Jira, Bugzilla, and GitHub issues to track your change request at three levels: Component (microservice), Application, and Release (collection of Applications). You define Jira, Bugzilla, or GitHub through an object called a ‘data source.’ Once defined, you can pull change request from your issue system and assign them at any level for tracking. When change requests are managed this way, you have a continuous feedback loop showing when the issue was opened and when the customer received the fix.
HipChat as a Notifier
DeployHub’s microservice catalog tool allows you to send notifications using Notifiers via HipChat Groups, Topics, or Room features. Notifications are defined to Components and Applications and inform the recipient(s) of the Component or Applications deployment’s success or failure.
GitHub as a Binary Repository
You can configure DeployHub to call out to a Git Repo to pull deployable artifacts (binaries, scripts, etc.) as part of your deployment. The process will check out your deployable artifacts based on commit, branch or tag specified.
Slack as a Notifier
Slack can be integrated with DeployHub using Notifiers. Notifiers can be called to report on success or fail status of deployments.
Tracking and Deploying Salesforce APEX Classes
If you are developing your Applications using SaleForce, this integration will allow you to support SalesForce deployments. By creating this Custom Action you can replace the DeployHub standard deployment processing engine and instead use a process designed specific to Salesforce including the mapping of DeployHub Environments to different SalesForce regions such as testing, pre-production, production, where the class and package files can be deployed.
DeployHub and Playbooks
Our microservice catalog supports the ability to run any Ansible Playbook you create. It does this using pre-defined DeployHub Procedures that you can use to create a DeployHub Action of your choosing. Once created, the Action can call any Ansible Playbook. The most common use is for performing deployments, but you can also use the Action to execute Pre Actions or Post Actions to the deployment.
Using Cloud Foundry to Deploy
DeployHub interacts with Cloud Foundry by using the command line process (cf) to connect to the Cloud Foundry Endpoint. To deploy a new Application (or to make changes to an existing Application) our microservice catalog tool uses the “cf push” command to upload the Application to the Cloud Foundry Endpoint.
DeployHub Environments are the same as Cloud Foundry “spaces”. Since DeployHub is an agentless solution, it can deploy to Cloud Foundry by executing the cf command automatically as part of the deployment process. It can extract your DeployHub Application code from any Repository and push the changes up to the Cloud Foundry Endpoint. It can then track which version of the Application is installed in which Cloud Foundry space.
Deploying and managing DataPower with DeployHub.
DeployHub can deploy DataPower the same as it deploys to any Endpoint types, such as docker containers, physical servers, virtual servers, cloud servers, routers, and Gateways. A DataPower multi-channel Gateway provides access, security, and control to a range of mobile devices, web applications, and APIs.
DeployHub’s microservice catalog can be used to install, configure, and reconfigure DataPower gateways quickly and easily. Due to its agentless architecture, configuration changes to the Data Power gateway can be deployed as standard. DeployHub has built-in Actions that allow zip files to be read, converted to base-64, and embedded into an outgoing SOAP message which can then be posted to the Data Power Gateway.
LDAP or Active Directory to manage Logins
DeployHub allows you to use LDAP or Active Directory to manage your User logins. The integration creates an LDAP Data Source to access an LDAP database and use the information stored to gain access to DeployHub. It also populates the Users General tab with Real Name and Email, which it gets from the LDAP database. When you define a User, you associate the LDAP authentication method. At login, DeployHub checks the User’s authentication method to determine if LDAP or Active Directory should be used.
A microservice catalog tool would be incomplete without managing the important database parts, particularly for poly databases. You can publish your database updates to the microservice catalog, tracking and versioning your data changes. DeployHub has a unique type of Component for database updates allowing you to manage your database with roll-forward and rollback processing. Check out the ‘version jumping’ DB Demo.