Realities of Microservices in the CD Pipeline

In this webinar, Tracy Ragan, DeployHub CEO, and Brendan O’Leary, DevOps Evangelist, GitLab discuss microservices in the CD pipeline. Yes, when you begin down the road of microservices your CD pipeline is disrupted. The good news is you don’t need to throw the baby out with the bathwater. You can evolve your existing pipeline to achieve what is needed for microservices. Learn more by viewing the complete webinar on-demand.

 

Microservices in the CD pipeline – Q&A

We had some amazing questions at the end of the webinar. Here is a compilation of the questions and answers.

In theory, shouldn’t there just be one microservice for each functionality so when a microservice is updated all applications that use that microservice will automatically be using the latest microservice?

Yes, that is the preferred method for pushing microservices in the CD pipeline out to the cluster. Now that being said, you can specify the use of a unique microservice in your Helm file or Kubernetes deployment file. If you take the preferred method, keep in mind that every time a new microservice is pushed to the cluster, the ‘logical’ applications that consume the new service have a new version. From a configuration management perspective, you as the team managing the application need to know that you have a new version that your customers are running.

While the updates are automatic, you still need visibility into what is changing in order to make some data-driven decisions. DeployHub focuses on solving this configuration management and dependency problem with microservices in the CD pipeline using maps. These maps show when a ‘logical’ application has been changed due to a new version of a microservice.

 

DeployHub Mapping

 

So, does the architect become the orchestrator of microservices? (Who holds things together?)

This is exactly the right question to be asking about microservices in the CD pipeline. No one person should be responsible for understanding the entire configuration of your cluster. Think about what the Amazon or Netflix cluster looks like – or what they call their death stars. These companies have been first in pushing a fully scalable microservice architecture. And they have an army of really smart people holding it together.

Amazon and Netflix Death Stars

For most of us, we need visibility into the applications and microservices in the CD pipeline. And relying on certain team members as we did in the application build process (compile/link) is just not a solid strategy for success. Everyone needs to have the visibility needed to hold things together. We think about this problem a lot at DeployHub and are providing ways to organize the services, expose their usage across Dev and Ops teams so no one person is holding this in their head, a spreadsheet, or digging through deployment files.

We are thinking to move to the microservices architecture but are very worried about the scaling and hardware limitations, can you shed light on this?

Most companies are not starting down this path by building out private Kubernetes environments. AWS, Google, Azure, and Linode are hosted Kubernetes services allowing you to receive the benefits of a Kubernetes platform without some of the complexities and hardware cost. If you are building out your own, consider tools like Rancher to help you with the process. This environment can scale fast and wide, so a private environment will need hardware investment, but its worth it in the end.

The greater difficulty when a change happens to a microservice, there is no automated way of knowing the impacted services. Are there any tools for it?

This is precisely what DeployHub does for microservices in the CD pipeline. We track the service to service relationships by tracking the applications that they create. So if you are going to update a service, we can show you every ‘application’ that consumes that service so you can do that level of impact analysis and notify application teams that a change is coming.

How would you manage security and compliance in a microservice application? What metrics would you track?

So the kind of security you need to do around containers, in general, are:

• container scanning
• registry scanning
• production scanning
• CIS Benchmarks
• audit compliance
• container firewall
• Kubernetes

With microservices in the CD pipeline, the basic compliance level should be at minimum a container scan, and possible scanning of the code used to create the service. In general, all of your existing security and compliance should remain the same, with some of these additional steps. DeployHub helps with this by pulling together a logical view of your application so your existing practices can easily apply.

How would you capture the relationship between different microservices and how would you track compliance against those relationship?

This is a core problem with microservices in the CD pipeline. DeployHub tracks all microservice relationships in the context of an ‘application.’ An application version consumes a collection of microservice versions.

With this logical view, you can continue to enforce your compliance as you are doing today with source code and builds. DeployHub aggregates the microservices back to a logical view of the application so you can continue to work based on an application version. For example, track updates to the application like change request, build number, approvals, security, etc.

On monolithic environment Change Management is used to track application changes. It needs to have a lead time, pass thru CAB meetings. How is it on a microservices environment?

You do not need to toss out these types of controls with microservices in the CD pipeline. What you need is to be able to track ‘application changes’ as your question proposes. We agree. This is why we have worked so hard to deliver a solution that allows you to keep the concept of an application version, even though the application really no longer exists. It is there but has changed to a  collection of microservices that could be coming from different teams, making changes on their own time frame.

DeployHub puts application control back into a microservices implementation so you can do things like approvals and CAB meetings based on an application release. For tight control, you would define your microservice build file to not allow a new release of a microservice to be automatically consumed by your application microservices. Here is a blog that talks about Labels and Kubernetes Deployment files from a high level and shows an example.

What is the first thing we should do to start with microservices? Documentation? A process?

Learning about Domain Driven Design is core to the successful implementation of Domains is critical. As you write microservices, you need a way of organizing them for re-use. This is what Domains do.  Get started by learning more about Domains. Coding microservices will be the easy part. Cataloging, sharing, and versioning will be critical for your long-term success.

Can you set us up to microservices?  

No, but I can give you a way to learn about them, and their organization. You can sign up for DeployHub Team microservice dashboard for free and play with the Hipster Store microservice application. This will help you get started.

Thank you for all the great questions on CD pipelines. We appreciate your interaction. Learn more about our microservice catalog tool.