Getting Started With Managed Service Mesh on AWS

This demo walks through how to consume HCP services, how to use HCP Network (HVN) peering, how to register EC2 machines in HCP Consul, how to bring EKS clusters into HCP Consul, and how to spin up traffic routing and splitting with HCP Consul.

In this HashiConf Digital session, there are three sections:

0:00 — A strategic & architectural overview of HCP 14:04 — A demo of HCP Consul 45:14 — A live Q&A

Transcript

Alex Jauch: Good afternoon, good morning—wherever you happen to be. My name is Alex Jauch. I'm a Product Manager here at HashiCorp. Very excited to be with you, virtually. As I'm sure as everybody's been saying today, we're bummed out that we're not with you live. But we're going to give you our best show anyway. Cody will be with us a little bit later, and I'll let him introduce himself then.

HashiCorp Cloud Platform (HCP)

Hopefully, everybody got a chance to see the keynote and talk about what's going on with HCP and our current and future plans. It’s something we’ve been working on for a while—about a year now—so we're very excited to have you all see it for the first time.

A New Flagship Cloud Offering

This is a very momentous occasion for the company. This is a chance for us to launch an entirely new platform, a new set of services, and a new initiative in the market. We're hopeful, and we hope you enjoy it—give us feedback and let us know what we're doing wrong, what we're doing right. There's a big team involved in making this happen, and all of us back home are still very focused on getting it ready. It's early days, but there's a lot of potential here.

Multi-Cloud, Multi-Product

To repeat some of the core themes here, we want everybody to understand that the goal for HashiCorp is to help you have this multi-cloud experience. I know you probably hear this term a lot—it's almost become a cliché already. But I think most of my customers are telling me, "Yes. It's clear that multi-cloud makes sense, or I have aspirations there, but it's not super-practical. When I build an application, I'm consuming the underlying services, and it's quite difficult to move things around.”

Easily Provision a Fully-Managed Infrastructure

We're finding that tools like Consul and others that extract you from that core infrastructure do support that type of mobility and help you build that long-term vision. Now, obviously, you're not going to start on day one, running all clouds all the time. That's not what this is about. This is about helping you find the cloud that you want to run on, making sure that we're ready to support you in that cloud. Then as you grow—or as you evolve—you have that mobility in your operability that you need; that's the vision. It was great listening to Mitchell and Armon talking about that this morning. I think that is a compelling vision—it gets everybody here at HashiCorp excited.

Dedicated Environment vs. Multi-Tenant

It’s also important to note that when we talk about the cloud platform, we're talking about a managed single-tenant environment, which is a little bit odd. It may not be what you're used to when you think about a SaaS platform. We mean the implementation of the way Consul is deployed is going to be completely isolated from other customers. This can be super-important for some use cases—if you have regulatory or other requirements—to ensure that you have very strong data integrity. This platform allows you to do that because you're completely isolated from all other customers.

It might not be super-obvious, but it also means is you can have exactly the same API running in the cloud that you have running on-prem.

When a new version of Consul comes out, that version of Consul will appear in the cloud service, as it does in the normal download sequence. You'll receive those new features—and those features will work exactly the same way because they’re the same bits.

That's a little bit different than what we chose to do with Terraform. Customers wanted us to make sure that we had high degrees of interoperability between Open Source Consul—or the Enterprise version of Consul—and the Service version of Consul. This approach allows us to do that. You'll see we'll repeat this theme as we go forward with other products on top of HCP.

The HashiCorp Cloud Platform Vision

We are going to speak a lot about Consul today. That's on purpose because that's the thing that's coming—that's the thing is ready to show you. But keep in mind that these are general themes. The idea is that all of our products—as they show up on HCP—will have this common push-button deployment method. They’ll have a fully-managed infrastructure, they will have this multi-cloud workflow that works across clouds. These are common themes that we're building towards over time. Naturally, this will take us a little while—this isn't instantaneous—but that's where we're heading.

One Multi-Cloud Workflow

What do we mean by multi-cloud workflow? We mean the networking itself is going to be highly abstracted—we refer to this as the HVN.

Abstracted Networking (HVN)

As you might have seen in the demo earlier, we manage the HVN as a separate construct abstracted away from the cloud. Now, of course, it has to relate back into actual infrastructure, so there's a mechanism to do that. But the idea is that these HVN constructs allow us to be consistent across clouds over time.

Multi-Tenancy Model (Organizations)

It also implies that our organizational model has to allow for multi-tenancy. We're going to have to have a very easy way for customers to create tenants across their organization—across their clouds. We refer to those structures as Organizations.

Billing Management Module (Projects)

Within that organization, you may also have multiple project teams because you might have a very large organization—so we have this notion of projects. If you use GCP, for example, it should be very similar to the way GCP uses projects.

Robust Role-Based Access (RBAC)

Finally, we have to have RBAC. We have to have a way to ensure that the people in your organization have the correct level of access. This might seem obvious, but we want to make sure that as you move into the cloud, we're ready to scale with you. Building a system for one developer is relatively straightforward. Building a system for 10, or 20, or 10,000, developers is a little bit more complicated. When we built the system, we wanted to ensure that we could scale for the largest organizations. You'll see that those structures are there from day one built into the product.

Reporting

Obviously, if you have lots of people involved, you want to have a rich reporting experience. All of these things are built into the platform, and they'll be common across the different implementations.

HashiCorp Consul Service (HCS) on Azure

Switching back to Consul, since that's what we're talking about today primarily. I wanted to note—because it didn't come up this morning—that the core platform we're using is common between the Azure implementation and the AWS implementation. We refer to the Azure implementation as HCS or HashiCorp Consul Service.

You may have seen that beta—we announced it a little while ago. If you are an Azure customer, I would strongly encourage you to take a look at that because it allows you to get this Consul Service in an Azure context. This is in public beta right now, and you can see there's a link there to it.

I bring it up in this context because it is the same core platform—it is the same core bits, so you're already seeing this commonality today. The way you buy the product is different because HCS is an Azure Marketplace application—because that's what Azure customers want us to do. Whereas in AWS, it's an HCP application, so it looks different—it feels different, but it's still there.

Extending HCP to AWS

The big news today is that we are announcing the beta on the AWS site. That's exciting for us because this is our first beta on the AWS platform with these bits. Of course, we also announced this morning that Vault is coming as well. We didn't discuss it in the keynote, but it's important to note here that that Vault experience will be similar to the Consul experience, and it'll sit on the same core platform.

When I say platform, what do I mean by that? I mean, we built a system that allows us to manage applications across multiple clouds in a multi-tenant, secure way. This diagram is trying to show us what that means.

We built this Azure Managed App—which is sometimes referred to as AMA—and that's in gray there. But to implement it, we built the services in blue. We have Core HCP Services which have API endpoints—it has workflow management. It is very closely integrated with Terraform because Terraform does the deploys for us. That core code is common between the AWS version and the Azure version of the product.

Underneath there, we had to build specific API services to make Consul work. This little dotted line here shows us the things that are Consul-specific. That means when we deploy Vault, the rest of the platform will be reused—and we'll implement those underlying API services.

Similarly, down at the bottom—in gray—you see the Azure implementation, and then you see the AWS implementation. There is code that's specific and unique to AWS in this HCP beta that we're bringing to market, but the core platform is common. We wanted to point out we're already on this journey to multi-cloud—we're already on this journey to multi-product; you're seeing the first implementations of this now.

An MVP Focusing on VCP Peering

What are we delivering in this beta? Well, we should think of this as an MVP. This is the Minimum Viable Product that we're developing right now. It'll obviously grow and evolve over time—we have a lot of investment in this space, we have a big team working on it.

Deploy into a Single Region

At the very beginning in beta, we're focused on a single region implementation.

Multi-AZ by Default

We are multi-AZ by default. That means when we deploy Consul, we deploy the Consul cluster spread across multiple AZs because this is an AWS best practice.

Native Constructs for Managing Routing

We don't have our own security constructs, we don't have our own routing constructs—we consume those constructs from AWS. If you're already an AWS customer, hopefully, this will be very familiar to you.

Consul Security Group Requirements

The idea here is that when you provision Consul on AWS, we will use our VPC to provision all the assets that you can consume. That means the VMs—or other objects running in your VPC—won't be visible. You'll have to create a security group inside the AWS Consul for us to use in common. If you're an AWS user, hopefully, this is very simple—you've done this many times. But to review, you will have to create a security group that allows your VMs to talk to our VMs.

Once you've done that, the idea is they will be able to consume the Consul services, like they would consume services being presented in another VM. Of course, we are in a peered VPC situation. That is to say our VPC is peered with your VPC. That also implies that we're going to have to have a routing agreement between the two. We chose peering because it gives us the most flexible communication between your VMs and our VMs—or your EKS cluster, or Fargate, or whatever you choose to deploy.

It's super-important to note that Consul assumes a flat mesh network. Consul sits on top of a peer-to-peer system. All the clients you deploy inside the datacenter—which is what Consul refers to as a group of compute—the datacenter, hosts, and servers must be able to talk to all of the clients. That means you'll have to enable full mesh routing for every single one of the VMs that want to participate in the datacenter.

The easiest way to do this is to create a routing group that includes the Consul servers, and then add your VMs—or others—to that routing group. Obviously, there are other requirements—other more complicated things—but that's the simplest way. Then you can create a route into our managed VPC, using the CIDR range that you delegated to us at bring up.

A quick note—we've had some questions in the past; Are we going to support private link and other things? It's super-important to note that the Consul—because it's expecting a flat network—is not well-suited to things like private link because private link sits behind a load balancer. That's why we chose VPC peering—because it was the most applicable way of doing it; a way we can guarantee we have that connectivity we needed to form the datacenter; make sure that all the members of the datacenter could talk to each other.

The final step here—once you’ve created the routing group you need to make sure that the target for the routing group is the CIDR block that you have delegated to us. Then you need to add that route in the routing table. Once you've done that, the machines on your side will have a valid route into our VPC using that CIDR block you delegated to us in setup.

Now I'm going to hand it over to Cody. Cody is going to walk us through what the heck do you do with this thing—and what is it for. He'll show you all the good stuff.

Cody De Arkland: All right. Thanks a lot for that handoff, Alex. Really excited to come here and talk about HashiCorp Consul on AWS today. My name is Cody De Arkland. I do Technical Marketing for Consul. We're going to step through some of the ways that we like people to practically consume this platform. There are a lot of ways this can be used in real environments, and a lot of ways it makes sense to create a way of establishing consistent networking between different types of networks.

Key Considerations

Before we get started, let's jump into a couple of key considerations and some things we want to think about before we jump right into the demo. I promise only a couple slides before we get into the good stuff.

People Leverage VPCs as a Boundary Point

These are ways that we separate things like teams, different technologies. Some people even use it to separate different platforms within AWS. Knowing that these are consumed in different ways, the part that Alex talked about becomes very important—how we establish that VPC peering relationship.

Manage VPCs Should be Expected

We understand that people are going to come with a number of VPCs into these environments and say binding one VPC to this and shoving everything into that VPC isn't very realistic—it's not how people are going to consume the service. People could expand this beyond VPCs and even into multiple accounts.

Alex and I being on different teams within HashiCorp—we might have different accounts entirely, but we might want to subscribe to the central Consul service platform that we would use jointly in different ways.

Likewise, people use Consul in different ways and consume different functionality out of it. So it becomes important for us to be able to acknowledge the different ways that people consume this platform and create a welcoming experience for you to bring those different concepts into the product.

Smaller Kubernetes Clusters

We've also seen it as design patterns emerge and cloud-native applications are developed. In the early days, you'd see very small amounts of large Kubernetes clusters, but now we're seeing a more team-driven approach to Kubernetes environments. We're seeing the proliferation of many small Kubernetes clusters inside the environment. So it becomes very important to have a platform that lets you bring those in—in a very frictionless way.

Mixed Workloads Will Continue to Exist

Likewise—and this is one that stands out to me—I came from a heavy enterprise background; legacy doesn't always mean older platforms. Legacy doesn't always mean that the thing being used isn't a modern technology. Customers have spent a lot of effort to get into public cloud and consume some of these public cloud—path services, things like RDS—like I have in the following bullet. We need to create an environment that lets people use that as part of the service mesh and bring that into Consul in some way as well.

Application Lifecyle

Finally, the big one that I get most excited to talk about is how we handle the application lifecycle. Being a little snarky, we sure talk about service mesh a lot—we sure use that phrase a lot. But ultimately, what matters most is how applications are lifecycled inside an environment. Why do people deploy infrastructure? To put applications on. Why do people connect these things? So applications can talk to each other. Why do people run things? So applications come up running. Applications are the first-class citizens inside all of this. Lifecycle can only be done elegantly within a service mesh, so we're going to touch on that a little bit inside this presentation as well.

Common HCP Workloads

Traditional Cloud Infrastructure

Jumping forward, we see a couple of trends emerge on common workloads we expect to live within HCP. Things like traditional EC2 instances. One of Consul's biggest powers is its ability to be multi-platform, multi-runtime. So we create a first-class experience to bring something like an EC2 instance inside of AWS into that service mesh.

Workloads Spanning Multiple VPCs

Likewise, we want to have these workloads potentially span multiple VPCs. If Alex manages a team that builds the frontend, I might build the backend. We want to have an environment—a platform—that allows us to have those two things connect in a consistent way. That keyword right there is consistency—whether you're on EC2 instances, Kubernetes clusters, Docker hosts, we want a consistent way to consume network automation. That's what we target inside of HCP, and Consul at large.

Elastic Kubernetes Service (EKS)

It wouldn't be a conference talk if we didn't talk about Kubernetes several times in it. We expect people to have many Kubernetes clusters joined to these environments—we expect people to mesh services between those Kubernetes clusters. A typical architecture would be to keep applications within the same cluster, but how do you create failover scenarios? How do you create an environment that allows you to have a primary and secondary and failover, even a third and fourth? We do that inside of Consul really well.

This is a rough picture and something to get everyone thinking about when I start talking about these modern environments—what that environment could look like. We have HCP on AWS living on the bottom. We have these different VPCs attached on the top—maybe one that has primarily EC2 instances, maybe another one that has purely Kubernetes clusters; something like AKS or cluster API on AWS.

Finally, how do we have APVs that are both of these, and what does that look like? We peer all these together—to Alex's point—how we have these things talk in a very consistent way; again, hammering on that consistency. We do that through VPC peering, and we do that through our service mesh and how we allow the sidecar proxies to talk to one another.

The Demo Flow

What is our demo going to look like? We're going to log into the HashiCorp cloud platform. I'm going to show you what the common operations within that platform look like. I'm going to show you how to pull down configuration files, generate a bootstrap secret—how to get started with the platform quickly.

I'm then going to show you what the peering relationship looks like within the platform as well—how we take networks that live within different VPCs inside AWS, and peer them with the ones that live inside of HCP—or HCP creates at least. Mostly I want to show you what that user interface looks like between the two.

We're also going to show how we can bring EC2 instances into Consul—how we register. I have a jump box already set up that should show bringing that in very easily. Then we're going to get into the good stuff where we start to bring these different EKS clusters into HCP and use them. We're going to spin up some traffic routing and see how we can split traffic between multiple environments.

It's demo time now. We're going to jump in. I also like to call demo time, the time where I apologize for how high my cloud bill is this month. We're going to jump over. Get started.

HashiCorp Cloud Platform Demo

Here we can see the HashiCorp Cloud Platform login screen. If I hit sign in, you can see that I'm prompted to log in with my GitHub account. We have GitHub authentication set up against it. If I hit login, we can see that I'm brought into the HCP environment.

A First View of the HCP Environment

I've already created my Consul cluster inside here. You can see the setup steps already accomplished on the right. If I go down to Consul, we can see that I've already deployed my cluster here. Here, I could download my client configuration—that's a basic server config and the certificate that's part of the cluster. I also generate my bootstrap token. We deploy this environment in a secure fashion by default—ACLs are enabled, and the UI is disabled.

We're going to get into the UI a little bit, and that's because I've set it up for this demo specific to be able to show it. But it's typically not enabled. Pretend like it's not there—but you're going to see it anyways. We're going to click on this Assigned Network—this is the HVN that Alex talked a lot about.

We can see that I've created it on this network. I've got an ID here. If I go up into my peering connections, you can see the different networks that are peered—two of them are active, and then one of them is not active. These are the two sets of networks that I have peered up. If we jump into the AWS Consul, we can go down to our peering connections here. We can see the currently active connections that have been set up.

If we go into this third tab—this is the access to the UI that I set up. It's typically not enabled, but I wanted to show a full demo so you could see the configuration. If we go into Nodes, we can see the different HCP nodes that are configured inside this environment.

Right now, if we go to the Services view, you can see no services are currently registered. All we have is the Consul Service in play. Let's think about how we practically start using this environment.

How Do We Start to Use This Environment?

Out of the gate, we need to be able to bring workloads in. We know that things like EC2 instances and Kubernetes clusters are going to be used.

I'm going to flip screens over and show a Packer manifest. This is a very easy way to get started building out access to the environment. That's how I do it for all of my demos and my presentations around these things. I'll build a Packer image. It's a very simple deployment here that will create an AMI inside of AWS that I can use to deploy EC2 instances that are automatically joined to the environment.

Furthermore, I've done this to also allow me to deploy out a Nomad environment. HashiCorp Nomad works inside of HCP as well.

This build is one. The other build I showed was one that deploys a vanilla EC2 instance. But you can get all the way down to configuring workloads to run inside of the environment. This Packer file will build a set of images that will let me deploy out Nomad clients and servers inside of the environment as well.

In one hand, you can have a vanilla instance that allows you to join, install and configure whatever applications you want on it. But you can also get down to configuring applications with it.

I'm not going to waste your time showing building these out. These are already built inside of my environments. We'll swap back to the UI and show that. If we go into my instances view inside of AWS, we can go down to the AMI view and we can see the AMIs that I've created here.

Joining the Workload to the Environment

We're ready to join the workload to the environment. Fortunately, I already have one built here. I'm going to start up the service. Starting this Consul service, but I'm also going to start the Connect service, which is a Consul service mesh functionality.

If I go in do a consul members we can see that I'm in the cluster—I've joined, I’m a client node; this is now available. This server is going to focus as our ingress into some of our traffic splitting scenarios. Immediately, we're going to need to have a service registered for that functionality. If I go into my Services view, we can see the ingress has been registered. I have a sidecar proxy associated with it for allowing communication between the environments.

You'll notice this UI looks a little different from some of the other presentations you've probably seen so far. This is still running on Consul 1.7—1.8 has some updates to this, so you might see a little inconsistency there but it functions the same. I have the ingress service already registered. If we take a look inside of the UI, we can go to the Consul directory and take a look at that service registration. Service registration registers ingress on port 80. It's got the token associated with it, and it's telling what services it can talk to. This can talk to the frontend service on port 80.

By default, we have no intentions enabled inside of the environment. While we have the service up, it's not going to be able to talk to anything until we can enable those intentions.

Deploying Kubernetes

We're going to jump in and get started deploying out the Kubernetes portion of our adventure. I'm going to switch back into the UI. I've got all of this plotted out in a very straightforward way. We'll start off with step one, which is deploying out our first EKS cluster.

It takes a few bits of input that I've already configured—the HCP bootstrap token, the encryption key, and the cert. These are all part of that bundle that I should have been able to download from within the UI. We bring these in and we create Kubernetes secrets around them. If I do kubectl get secrets, we can see those secrets have already been created inside of the environment. If I do a kubectl cluster-info, we can see information about this cluster.

Let's take a look at how we can get started now and deploy. If we do a helm install, against our file one, we can see I've run this command before—we can see the cluster I'm interacting with on the right. I'm going to hit enter, and it's going to start to deploy. We'll very quickly switch back into the UI. If we take a look at the nodes, we can see those nodes start to come online in a few moments. There's the first one, the second one, and the third one. That's a three-node EKS cluster that's been deployed. It's already finished deploying.

If we do a kubectl get pods, we can see the client nodes are running inside the environment. This is now joined to our cluster as a client. To use that, we deploy an application—I'll do our demo application. We'll see this start to come online and start to run checks, as well as start to return services.

By default, we can see that this is not connecting successfully right out of the gate—it's going to take a few moments to finish updating. We might see some error messages in the actual logs as those services come up. Let's get our pods and take a look—it takes a few minutes for it to come up and register.

We can see our service is finally running. If we look inside the UI, again, we can see that the service has come up. We have our connectivity between the environment. If we switch back, we can get the load balancer for that—which is right here. We can see our application is currently up and running, but it's unable to connect successfully.

We'll need to enable intentions to allow the communication to take place. We'll jump back over to our jump box, and we'll do consul intention create frontend api.

In a few moments, we should see that connectivity successfully established—we can see now that's working, but our database connectivity is still not working. If we do consul intention create api db, that connection is successful as well. If we go to Consul's intentions, we can see that connected as well.

This would be simple enough if this was a single cluster environment. We have our service mesh up and running. We can see the communication is happening successfully. But what we want to show the ability to bring multiple Kubernetes clusters in and the ability to consume multiple levels of an environment.

We're going to create one more intention before we get started. That intention is to allow our ingress service to be able to talk to our frontend service. This is going to be very important in a few moments here. That intention is created. I created that one through the UI, but we can also create these via API.

Working with Multiple Kubernetes Clusters and Consuming Multiple Environment Levels

We're going to flip back over to the CLI. I'm going to switch now to a different EKS cluster. We can see that this cluster is currently empty as well. This one does have a Vault instance in it. That's because I'm going to be using Vault to secure my secrets inside my demo application.

Like before, we're going to use a configuration file that takes in a set of information that we've already populated inside a Kubernetes secret to allow this to join the environment. These are all part of VPC networks and VPCs that have appeared with the HCP environment.

We're going to do a helm install. We're going to do this against EKS2 using the Consul Helm chart. We'll switch back into the UI. We'll go to the Nodes view. We should see these nodes quickly come online—there's one, two, and three. There we go—those came online. If we switch back in, we can see that's been installed successfully. We can see that our actual instance is up and running. We now have two Kubernetes clusters joined—just inside the time of this demo, we were able to add two EKS clusters to this environment.

Getting the Workload Going

We're going to switch back to my other environment, and we're going to deploy one arm of the environment this time instead. You'll notice that I'm not taking down the existing application—the existing application is currently serving traffic; people might be using it.

We're going to look at my files, and I'm going to apply the initial demo for site one. Looking at the actual file, we can see I'm injecting the connect bits for allowing service mesh communications. I'm setting a version on the application—which is unimportant for this demo—I'm setting it to port 80. I'm telling it to talk to the API service on port 5,000.

I'm going to do an apply on file three, which is going to create our frontend application, but it's creating a v2 of the application as you can see—we can see that initializing right there. In the interest of saving time, I'm going to quickly switch back over to the other instance and deploy the second part of this application.

Let's switch back over. Take a look at our files. Apply file five—which is going to be our API two and our database two. If we look through this file, we can see the database getting injected—which is a simple Postgres database. Then we’re also bringing in a pod that has some of the Vault configurations to automatically inject Kubernetes secrets in. It’s interesting that we're using HCP, but I'm also able to bring in Vault as part of the EKS cluster—and still use that against workloads. It might not be integrated with HCP right now—in this case—but I'm still able to use that Vault Helm chart inside of the environment.

That's been deployed. If we go look at Services, we can see we have a whole bunch of services in this environment now. We've got our API in place—we've got a couple of frontends in place. If we switch back in kubectx to our primary environment, we have a load balancer deployed for the second one—but we're going to use our ingress to access this resource now. We're going to switch back into our EC2 environment—we're going to grab the IP address for that ingress service. I threw that on port 80 to be a little bit different.

Splitting Out Traffic

This is now the ingress coming in. The ingress was allowed to talk to the frontend. We know that whole service all the way through is allowed to talk—so the intentions are allowed. But we're going to start doing a little bit of traffic splitting now.

We're going to switch into our jump host. If we take a look inside of this directory, I have a set of files here that allow us to configure this. I'll bring these files up, and we'll step through at a high level what each one of these does.

We're creating service defaults that tell it that these are HTTP services. This is how we tell it that it's an actual web application that we're going to be able to split traffic against. We're then setting up a service splitter that is—in this case—telling it to send all traffic to the new service. We probably want to switch this back so that it stays going to the primary service and then show it flip to the new service.

I'm going to edit this file—I'm going to change this down to zero, I'm going to set this to 100, and we're going to apply these two files to Consul—consul config write one, consul config write two, consul config write three.

If we switch back into the user interface for Consul, and we look at that actual service for the frontend and we look at routing, we can see we have a router setup now that's routing traffic between these two environments.

If I switch back and take a look at our UI, we should see that nothing has changed. It's the same application that we had in place before. Now, we'll go back and return that file to what it was before—100% in the other direction; we'll flip this to the version 2.

In a typical environment, you would want to gradually make this change. Since we're at HashiConf, and in a whole different time zone—doing it digitally—we're going to yellow the change and allow it to go through to flip 100% of the traffic over.

That change has been made now. We can see that the connectivity is erroring because it's no longer connecting to the service. We can see this error message is changed to this upstream connect. That's because I haven't set up intentions to allow the ingress service to talk to the new frontend. This is how Consul keeps you safe—by requiring explicit communication enabled when ACLs are turned on. I need to allow the ingress to be able to talk to the frontend version 2 as well.

If I go into the Intentions view, I can create a new intention here. We can say, ingress is allowed to talk to frontend version 2. We're also going to set up our other allowed communication as well—frontend v2 talking to API. Frontend v2 talking to database.

To save on time, we'll set up a future set of the configurations. We're going to allow the frontend to talk to API v2 as well—we'll do frontend v2, talking to API v2. A bunch of communication is allowed now. If we switch back into here and we do a refresh, the application comes up, and we’re on our dark mode of our application—we’re happy, we enjoy the darker theme of the application, and our connectivity is allowed successfully.

If we take a look at our actual API, we're able to reach the backend service. But this is an older version—it's not the version 2.0 of the API that we would expect. We're going to do the same traffic splitting between the API tier as well. This is our old version of the API.

Let's switch back into the command line. Now, again, to do a four, five, and a six—we can see we're doing roughly the same thing with an API tier as well—we'll do a consul config write on four, five, and six.

Again, normally, you would not shift everything at once—you would do it gradually, but for the sake of time, I'm going to flip it over to 100%. We'll flip back. If we hit refresh on the screen, we can see we're getting the version 2 of the API and we're getting a little bit of a different message. The API has been migrated now to the second Kubernetes cluster. But the ingress still lives as a VM—and we're now splitting the traffic between these two EKS clusters. We can flip this back and forth as much as we want.

Enabling Progressive Delivery

This is a way that we can enable something called progressive delivery. When you think about how we lifecycle applications and how we bring applications into the enterprise, we don't often want to do full flip over and instantiate a whole new application and then change our load balancers—change our DNS to be this new application. We want the ability to come in, set up a gradual failover, and a gradual path to migrating services over—and that's what we're able to do inside of Consul and service mesh.

When you look at HCP especially—with AWS being as big as it is, with so many different application types in there—people want to be able to come up with ways to gradually migrate services into a new environment, gradually failover or set intelligent fallbacks to other environments. The Layer 7 traffic abilities inside Consul make it easy to do that.

Quick Demo Recap

To highlight what we've accomplished so far—I got one more trick in my pocket before we wrap up the demo here: We've deployed Consul. We deployed two EKS clusters, as well as a virtual machine. We have that virtual machine acting as an ingress for these services. We're setting up splitting behind them so we can fail traffic back and forth. We could go in and set these to 50-50 and bounce back and forth between, but I think you understand how this works so far now.

Deploying Additional Workloads in EC2

Finally, I want to show how easy it is to deploy additional workloads from an EC2 perspective in here. We showed—starting up the other service—how it came online. Let's deploy a couple of EC2 images real quick that will bring up Nomad inside its environment as well.

We're going to go into EC2—we normally would do this in Terraform—but for the visual, I wanted to show it inside of the UI. We’re going to go the AMIs, and we're going to use this Nomad AMI server down here on the bottom. We'll do select, we're going to set this to three instances. We're going to change this to a specific subnet inside of the environment. Actually, we’ll change this to a specific VPC as well, enable our externals. We’ll hit review and launch. We’ll use my existing key pair, and we’ll launch the service. In a few moments, we’ll see this service come online.

I need to go in and edit the security groups to give us appropriate access to the environment. We can see those coming online. I’m going to quickly go in and switch the security groups. All of this could be very easily automated using Terraform to include this all this one shot. It gives you a way to have it be a declared state inside of the environment—there we go; those are all configured.

If we switch back into the Services view, we can see that Nomad cluster is starting to come up. Now, these are the server nodes—I haven't deployed the client nodes—I could deploy those as well. I figured it's easier to show that we're able to bring that on. But we can see once we have an existing AMI that has all of the configurations for HCP in place—how fast and easy it is to get workloads running.

This demo has been going for about 30 minutes. We've already brought a virtual machine in, two EKS clusters, as well as stood up a Nomad server cluster inside the environment as well. It's incredible when you look at how much value you can get very quickly inside of the environment.

That about wraps up the demo portion of this. I hope you've enjoyed what you've seen here. I'm going to hand this back over to Alex to take back over; Alex, you want to take it away and bring us home?

Alex Jauch: Thanks, Cody, that was an awesome demo—I really appreciate all that detail. Hopefully, everybody got excited and energized about what this thing can do. I said it at the top of the show, but keep in mind that we're just getting started here—just starting to show the tip of the iceberg. Lots of good stuff to come. Please stay tuned.

Sign Up for the Private Beta

In the meantime, we would appreciate your feedback, input, and engagement on the product today. We have two different flavors, as I mentioned. We have AWS-native—which is the big announcement today. And then we have the Azure beta, which we've been working on for a couple months now.

There are links here. Please do click through; give us information, and we'd love to see you on the platform. That's it for us today. Thanks a lot, and enjoy the rest of the event.

HashiCorp Cloud Platform Live Q&A

Rob Barnes: Absolutely amazing. Thank you very, very much to Alex and Cody—really enjoyed that session. Now I'd like to welcome you both back for a live Q&A discussion. Welcome Alex, and welcome Cody.

Rob Barnes: Over to you, Dom, to take care of this Q&A session.

Dominique Top: Of course. Thank you. Before I ask the question to either Alex or Cody, I would also like to ask this to the audience: Please use the chat on the sides to give your answers.

What Does Service Mesh Mean to You? What Does It Solve?

Alex, could you start us off?

Alex Jauch: The interesting thing for me about service mesh is how applications and systems are evolving over time. We're seeing there's an enhanced complexity as microservices become more common. That complexity leads to issues such as connectivity, security and observability. We're seeing service mesh is an interesting way to ensure that all of your various parts and pieces can talk to each other.

The concept between service mesh is—in some ways—extremely simple. You deploy a service as a certain set of APIs, you advertise those, you have consumer services—and that allows you to make this brokerage between the consumer and the provider. It's a very neat, very clean way to develop microservices. Our customers are telling us that—as their applications grow in complexity—service mesh is a great way for them to keep that complexity under control, and allow secure connectivity between the various parts of their system in production.

Dominique Top: Makes a lot of sense. What about you, Cody? Same question for you.

Cody De Arkland: Similar answer. What's interesting about service mesh is that—I eluded to this during the presentation—we throw this term around quite a bit. But when you focus on the outcomes of service mesh, and on the things that you're getting out of it—or the things that you're chasing, accomplishing—it's an easy thing to digest at that point. Things like automatic mTLS, encryption, being able to control traffic flows, and the way you split traffic.

I mentioned progressive delivery. That's something that James Governor over at RedMonk came out with and pushed a few years back. The only way to achieve that within applications is within service mesh. These outcomes become super-important for why you go down that path and why you want to achieve a service mesh. It's about making the applications that we deliver and connect much simpler—and easier to consume. I generally agree with the same things Alex said.

Dominique Top: Amazing. Rob, did we get any audience feedback on this or any questions?

Rob Barnes: Not specifically on the definition of a service mesh, but there are some interesting questions that's come in. I'll ask this one here.

Will Connectivity through Transit Gateways Be Possible in the Future, and How Will Peering Be Initiated? Will the HVN Trigger It?

Alex Jauch: That's two questions in one. Let’s talk about federation first. In the current version of the product, we chose to use the simplest networking model possible—which is peering inside the VPN. In the beta, you would trigger a peering connection from within the ACP portal. I almost said the Consul console—Cody; that's not good!

Cody De Arkland: I do it so many times. I've done it so many times.

Alex Jauch: Inside the portal, you would trigger that peering relationship. We did it that way because it was the simplest way to allow connectivity. You'll also note that the Azure product—which we sometimes refer to as HCS—works exactly the same way, so we have parallelism between the two versions of the product.

TGW is a very interesting conversation. For those of you that don't know, TGW stands for Transit Gateway—it's a service by AWS. In effect, it's a little virtualized router. It gets presented as a virtual machine, then that virtual machine presents ENIs into the VVCs that you want to connect—then as a simplistic routing application built into that thing.

It's a little bit newer than peering—extremely powerful. It's also not free—that's a service that AWS charges for by the hour. We would expect that customers that have larger or more complicated networking environments will eventually want to use TGW. It's definitely something that we are looking to support, but the current beta is focused on the very simplest case to get this out the door.

The phrase that we tend to use is MVP—Minimum Viable Product. You want to make sure that we can host Consul in a meaningful way, running meaningful workloads. Then we'll add complexity to the solution as we go forward.

If you are interested in Consul Service on HCP and want to push harder on TGW, please do reach out to us, either through social media or through your account team or through GitHub issues, or however you wish to. Smoke Zoo works too—because we're actively recruiting customers who are interested in that—and that feature and—and we’d to you about that in detail.

Dominique Top: Awesome

Rob Barnes: Amazing. Thank you.

Dominique Top: All right. I think the next question.

Rob Barnes: Oops. Sorry, Dom. I want to ask this audience question if that's okay.

 Could We Use Service Mesh with a Traditional DC inside a Single VLAN? What’s the Difference between SW Micro-Segmentation?

Alex Jauch: It sounds a Cody question.

Cody De Arkland: This is one of my most favorites—absolutely. My team and I talked a lot about this concept when we talked about the Consul 1.8 launch that’s just happened. This idea that we've started to frame this conversation about service mesh to be specific to cloud-native applications and the next generation of computing. It definitely lives more natively in that space—there's a fair statement there.

But with Consul, we focus on making virtual machines and traditional datacenters a first-class citizen in their ability to participate in service mesh. So, yes—you can absolutely use this within a traditional VLAN set up inside of an environment with traditional SDN players in the marketplace and have Consul sit right on top of that.

There is a slight overlap between the intention-driven policy of Consul and what you'd see in typical micro segmentation. But there's also a very different approach there. Consul's focused on making service-to-service communication truly identity-based. The idea that a frontend is always a frontend, whether it's IPs are 22, 25, 29, and 30; all of those servers are frontend servers.

We know those frontend servers should talk to the API server, which might be 52, 57, 59, and 60—and those IPs might change. In EC2, if you power on a VM, the odds are high you're going to get a different IP address. In that case, a frontend service is always a frontend service—an API service is always an API service. Intentions allow those to communicate—that's why they're called intentions. It's the intention for the communication path between those two things.

There's a bit of overlap from a micro seg perspective and the way SDNs typically approach that. But there's enough difference between what we're looking to accomplish in Consul versus those—that it's not an either or in that case. It depends on the workflow you're chasing. If you're chasing a zero trust networking policy, then maybe Consul is the better route for you to go, because it is simple to get intentions up and running. But it's a workflow question there, not necessarily a technology question.

Rob Barnes: Amazing—thank you! We have one more question, so I’ll read this out:

This Looks like a Great Start, but I Noticed the Secrets Were All Pre-Baked. Is There a Plan for Properly Managing Roots of Trust vs. Baking AMIs and Cake Files?

Alex Jauch: I think that was simply an artifact of the demonstration. To be clear, every Consul deployment is completely secure by default. We do not have public IP addresses, root keys are generated only upon demand and you have full access to create additional keys as you wish—as you do on-prem with Consul.

You saw on the UI there was a button to create a root key. The reason for that is just expediency, so we can make it work. Over time, you'll see is the Consul client itself will learn how to bootstrap itself into Consul. There's a little bit of detail here—but normally on-prem is you don't have a standard root of authority when you install the product. There's a sequence of events you have to go through to—in effect—unseal and bootstrap a product.

That's not the case here. We are using what's called a managed NSP token, which allows us to manage the Consul cluster on your behalf and delegate root access to you. That delegation process will appear inside of Consul itself—and specifically, in the post-1.8 release. Those bits are still in flight, so we have this sidecar method right now. But in time that will become a constant feature.

Cody De Arkland: To unpack the question a little: There was definitely some pre-baked stuff in my demo, no doubt about that. But that to Alex's point, it was purely because it was a demo. There are aspects of this that could have been made more dynamic and could have been made in a more true secure fashion outside of a demo. It’s really meant to show the ability to deploy some apps, get a mesh in, and get traffic splitting set up between them. But by the nature of making that a quick demo there was aspects of it that were very quick. It didn't have to be that way.

To Alex's point also: There are a number of features coming to help with this bootstrap process and the way we bring these systems online. There are big conversations that I had late last week around this topic—there is going to be some mind-blowing stuff that isn't that far away; keep an eye out for things.

One thing—this is a shout out real quick in a positive stance. I'm seeing a lot of engagement on this conversation on Twitter also. I love the fact that people are diving in and having good conversations about this stuff now. It's exciting for me to see this space grow—so thanks to everybody out there in the social media space for jumping in and having some good conversations about this right now.

Rob Barnes: Amazing.

Dominique Top: Awesome. Thank you so much.

Rob Barnes: Can I sneak in one last audience question?

Sorry, Dom. I want to give the HashiCorp family a chance to talk to us; that's all.

Sorry, Dominique. This is a good one:

Will HCP Hold Any Security Attestations, Like PCI DSS?

This sounds like Alex, I think.

Alex Jauch: The answer is yes, absolutely. We fully intend to have the product certified—there’s a couple of dozen—honestly—globally that we were working on from US Federal Government; PCI, HIPAA, etc. The system was designed to be extremely secure, and to pass the highest levels of attestations that we're currently aware of.

Obviously, a lot of these programs are rather involved—you have to hire an auditor, the auditor has to go through your system. Usually, auditors like to say something and have a few changes, because that's how they get paid! But in all seriousness, yes, our intent is to do that and see those coming out over time as the product evolves.

At the moment, we're focused on the basics—making sure the product works, making sure that it's secure, making sure that it's stable. Then once we have all of those things in place, we'll go for the exterior, all the hardware; get a nice little certificate you can hang on your wall. We have a place picked out in the office for those.

Rob Barnes: Amazing. Thank you very much. Over to you, Dominique.

Dominique Top: I've got a few more questions that I would like to fire off the gentlemen’s way. It may be a bit of a biased question:

When Should We Use a Managed Service for Service Mesh vs. Building Your Own?

Alex Jauch: That’s a super-interesting question. A lot of customers are asking me that question. The answer is a little subtle. We’re working very hard to ensure that Consul—for example—as a managed solution, is similar to Consul as a hosted solution. It’s not a technical answer per se, because, in theory, you should be able to do the same thing.

We have found customers who go to cloud tend to be in the position where they would prefer not to operate their own infrastructure. They see that as low-value work—whether it’s worrying about patching, or uptime, or taking pager duty calls on a failed server. This is not core competency for them. They don't perceive that they're adding any value to their company so they like to outsource that work. Similarly to consuming a service like RDS—from AWS—consuming Consul as a Service from us makes sense for those customers.

Cody, I don't know if you have some other views here. But to me, it seems a customer preference—largely—depending on how you want to operate their system.

Cody De Arkland: I think when you artisanally craft a Consul cluster that you can get very deep into configurations. You get very customized configurations on a line by line basis and tune things in a very specific way. But generally speaking—as a former operator—I would rather have the system manage itself. If possible, I'd rather use the managed service and be able to have the system manage its own uptime—have another group be responsible for keeping this up and running. It generally comes to a cloud consumption conversation because a lot of the cloud platforms are that way.

If I needed to bake things and be very handcrafted around this, I would deploy it. In the case of AWS, I would drop it on EC2 instances or into an EKS cluster. But generally, if at all possible, I want to consume a service.

I don't want to worry about if I set up redundancy zones or what my backup schedule set like. If I can say that the managed service handles all that for me, that's all the better for me because if something goes wrong, I hold HashiCorp responsible for it. I get to say, "Where are those backups? Take care of that for me." Managed services are possible—if I need special compliance reasons, and things artisanally crafted, I'll drop it on EC2 instances and roll that way.

Dominique Top: Amazing. So, I think the question that's on everybody's lips.

Where Can People Learn More about This?

Cody, do you want to take this one?

Cody De Arkland: I think Alex probably has been closer to the building of how to get started with this. I'm going punt it to him instead.

Alex Jauch: We're taking signups for what we call private data right now. There was a link in the main stream. You can also go to hashicorp.com in the cloud section of the marketing page, and sign up there—You'll get a prompt where you fill out a form.

At the moment, the beta is by invitation only—with what we refer to as private beta. We'll be bringing on a relatively small number of customers to make sure that the system is stable and ready. Once we hit that stability milestone, we'll open it up for public beta and you'll be able to self-serve without being gated.

But in the meantime, please do click through the link that was on the page. I think we dropped it also in the chat. If not, I will drop it in the chat in a moment. We’d love to have you on the system and get your feedback.

Cody De Arkland: A quick follow up comment around that—not about HCP, but in Consul in general. I don’t think people always realize how easy it is to get started trying out Consul. If you’re not somebody who can jump on and deploy this in HCP and, for some reason, you can’t get that going right away, or you need time to get into the beta, stuff like that—Consul is easy to get up and running. Give it a try and give it a spin in your own environments.

Check out the Helm chart. Go and look at our consul.io webpage. It was redesigned. Look at the Helm chart—it's easy to get up and running, easy to get started consuming. If you want to deploy it on virtual machines, it's easy to do it that way too—we have a great set of learning guides around it. Please go check it out—Consul 1.8 dropped some awesome functionality—we're excited for it.

Dominique Top: Alex, Cody, thank you so much for joining us. I'm aware of the time difference at the moment. I've appreciated you joining us today and answering the questions for your great session. I will be seeing you soon. Thank you very much.