DeployHub’s microservice catalog tool is a breakthrough in supply chain security, designed with a decoupled architecture in mind. DeployHub’s federated evidence store gathers security and DevOps intelligence providing a comprehensive, end-to-end view of your organization’s security profile from SBOMs to deployed inventory.
Your DevOps pipeline generates supply chain intelligence for each independent microservice it delivers. The result? Critical evidence is hidden across hundreds of logs or stored across many tools, making it impossible to see a complete picture of your organization’s security profile. DeployHub solves this problem.
You Have the Evidence - Make it Actionable with DeployHub
Enhance the Pipeline
Connect DeployHub’s microservice catalog to your DevOps Pipeline to gather security and DevOps evidence for every service update.
Track component security details based on versions, exposing how open-source packages are used across all domains, environments, and logical applications.
View Federated Insights
View federated insights showing logical application, domain, and environment security profiles, even in a decoupled microservices architecture.
What is a Microservice Catalog?
A microservice catalog simplifies cloud-native architecture by displaying all services with security and DevOps intelligence in one place. They are used to simplify a cloud-native implementation by providing an end-to-end view of your service usage, ownership, SBOMs, and deployed inventory.
Catalogs aggregated data for a comprehensive view of an organization’s security profile across siloed clusters and teams. A microservice catalog facilitates collaboration across organizational silos, saves money by encouraging reuse, and tames the difficulty common to a shared service architecture.
With Our Microservice Catalog You Can:
Centralize Security Data
Centralize and aggregate software bill of material (SBOM) data based on ‘logical’ applications. View reports and historical changes.
Version microservices with their security data and create logical application versions each time a dependent service is updated.
DeployHub Team’s microservice dashboard is a free version designed to make moving to microservices a painless experience. Our service catalog provides the organization, tracking, and visibility needed to succeed in cloud-native development. DeployHub Team is based on the Ortelius.io Open-Source Project.
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.
Application Security for DevOps Pipelines
This whitepaper will provide you with a clear understanding of how to harden your DevOps Pipeline using open-source tools at a minimal cost.
How do microservice catalogs work? Here are some answers to common questions about microservice catalogs.
What are the Unique Attributes of Microservices?
Every microservice is different, and each has its own unique attributes. The attributes include ownership details, SBOMs, CVEs, 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 Catalog Tools Have?
Here is a list of standard features that microservice catalog tools typically contain:
Who Uses a Microservice Catalog?
The users of a microservice catalog include producers, consumers, DevOps teams, SREs, production support, and supply chain security (CISO). 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.
How do CISO Teams Use a Catalog?
Security Officers need to understand a comprehensive view of their organization’s security profile. Catalogs aggregate SBOM data, CVEs, and provide compliance scorecards across teams giving CISO a single pain of glass for viewing security concerns.
Start with our Free DeployHub Team – Upgrade to Pro for Enterprise Features
- DB Updates
- Jira, Bugzilla, GitHub Issues
In order to continuously gather pipeline intelligence, DeployHub must become part of your pipeline. DeployHub integrates into your CI/CD process using the Ortelius Open-Source Command Line (CLI). The Ortelius CLI gathers supply chain data based on a single pipeline workflow at the build and deploy steps. The build step gathers Swagger, SBOM, Readme, licenses, Git data, Docker image, and other build output. The deploy step records when a release occurs, what was sent and where the objects were sent to.
The Ortelius Open Source Community maintains the Ortelius CLI under the governance of the Linux Foundation’s Continuous Delivery Foundation.
If you are not already generating an SBOM as part of your DevOps Pipeline, DeployHub’s microservice catalog tool integrates with Syft to get the job done.
DeployHub’s microservice catalog tool can consume CycloneDX formatted SBOMs. If you are already generating SBOMs, you will pass the name of the SBOM results to DeployHub.
DeployHub’s microservice catalog tool can consume any SPDX formatted SBOM. If you are already generating SBOMs, you will pass the name of the SBOM results to DeployHub.
DeployHub uses OSV.Dev to continuously monitor your Component and Application’s vulnerabilities. DeployHub scans for new vulnerabilities every 30 minutes.
Add your Microservice / API Swagger documentation. Make it easy for others to see how to use your service.
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.
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, and production, where the class and package files can be deployed.
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.
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.
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.
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.
Slack can be integrated with DeployHub using Notifiers. Notifiers can be called to report on the success or failure of a deployment.
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.
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.