For Developers and Operators, All Paths Lead to Consul

DevOps has become a bit of a catch-all term. The idea of aligning delivery and operational lifecycles to achieve rapid deployments makes a lot of sense in modern cloud-based environments. However, while these lifecycles are deeply dependent on each other, the personas that manage those workflows don’t always measure success the same way. Developers want to iterate often and quickly, while operators are more concerned about the environment staying consistent and secure.

Although these desires seem to stem from different challenges and are often addressed using different tools, it is possible to meld them together as part of a single workflow. The glue that holds this unified workflow together? HashiCorp Consul.

The Pick Your Path infographic displayed here lays out how both developers and operators can use Consul to get the results they seek. Read on after the image to learn more about how everything fits together.

»Breaking the Bottleneck

The continuous integration/continuous delivery (CI/CD) model dictates that application updates shouldn’t be limited to large, weekend-long deployment projects. Developers should be able to iterate, test, and push out new code incrementally, as it’s created.

Moving to a microservices architecture better enables this type of delivery style, as components are independently managed rather than representing pieces of a larger monolithic application. Developers leverage orchestrators like HashiCorp Nomad, Amazon ECS, and Kubernetes to automate deployments and scaling of microservices, but just scheduling an application does not mean that it is reachable. Developers need to ensure that services have the proper networking policies in place so they can communicate with one another. Relying on traditional networking practices can create bottlenecks and potentially slow down the delivery lifecycle.

The answer to this challenge is a service mesh, but it may not be clear why developers should care about service mesh. Service meshes offer a lot of value, but at first glance they may not seem to do much to improve developer agility and velocity. Service meshes are typically considered networking solutions and developers view that as outside their scope.

However, there is a place for a service mesh in the realm of application development: orchestrator integrations and progressive delivery. From an orchestration-integration perspective, a service mesh like Consul is tightly coupled with tools like Kubernetes, ECS and Nomad. Once the service mesh is configured, users gain the benefit of Consul’s service mesh whenever they need to deliver new applications. With Consul, new services are injected with a sidecar proxy and immediately made aware of approved connection paths, what we call intentions.

Once the application is deployed, developers can use Consul’s traffic management capabilities for canary testing or blue/green deployments, sending partial traffic to test different versions of an application. Consul service mesh removes the reliance on networking tickets and enables a more self-service model for developers, something that will also make operators happy.

»Enabling Self-Service Delivery

Operators, of course, may have some concerns trusting developers to freely deploy reachable services into a production environment. Operators are often responsible for ensuring that all runtime environments are secured properly and the right users have access to the right environments.

But microservices and the cloud create challenges for operators to consistently provision and manage application infrastructure, credentials, and policies across the many teams that they support. While this group also wants to move toward orchestration platforms, they want to be sure that they can control user access and service-to-service communication. HashiCorp Vault provides some of these capabilities, but pairing Vault with Consul greatly improves an operator's ability to provide consistent and secure environments for self-service application delivery.

For example, a core security component of a service mesh is enforcing mutual TLS (mTLS) authentication between services. To do this, the service mesh utilizes a certificate authority (CA) to generate intermediate certificates for services. The services then present these certificates to one another to validate any connections. Consul can use Vault as that CA for generating and distributing mTLS certificates. Combining this with Consul’s intentions allows operators to control which services are able to communicate with one another. These intentions can be repeated across multiple environments or scoped to a single datacenter depending on the needs of the business and do not require anything from the developer to enforce them. Basically, developers can continue doing the work they normally do without being concerned about configuring intentions.

Beyond intentions, Consul service mesh supports a number of access controls and multi-tenancy solutions designed to make it easy for operators to create a shared service for their whole organization.

»Following Your Path with Consul

The purpose of this infographic and blog post is to show that while developers and operators may measure success differently, they share the same goal: creating a workflow that enables rapid, consistent, and secure application deployments.

As noted in the Tao of HashiCorp, HashiCorp tools are designed to build workflows, not technologies. And we understand that a particular workflow might have multiple motivations. That’s why a tool should focus on the _how _of a project, not the why. That is what Consul aims to be: the how of your workflow functionality. Whether you are a developer or an operator, Consul is how you achieve the right DevOps workflow.

To get started with HashiCorp Consul, check out our HashiCorp Learn guides or our documentation.