Microservices for Military Applications

The military has a unique requirement to have critical applications and data persist in a disconnected environment with no access to the cloud. This implies a hybrid-cloud scenario where on-premise can mean anywhere in the world. To seamlessly move applications from fixed datacenters to these edge locations, some challenges need to be addressed.

Chief among these is the modernization of applications to agile microservices. Terraform provides the infrastructure as code component which simplifies the deployment of webs of microservices by operators who, in many cases, are non-technical users. And Consul service mesh helps secure service communications at the edge, where the military often operates.

In this talk you'll learn how several of HashiCorp's products make sense in military scenarios, where edge computing, loose coupling, and resilience are crucial.

Transcript

Hi, everyone.

In 2014, Gartner released an article that suggested that the cost for IT downtime on average for an organization was about $5,600 per minute. That's about $2.7 million per 8-hour workday.

If you're familiar with the movie Lone Survivor, we see another example of the impact of IT downtime, but in a much different setting. In the movie, you have a team of 4 highly skilled military professionals sent on a mission to extract a high-value target. And because of some issues with their communication systems, they're left vulnerable and exposed to the enemy.

There are various industries represented in this room, but we all desperately want to be successful. We might measure success in different ways. But at the end of the day, we want our organizations to be successful. The purpose of my talk today is to describe to you how the military is innovating on its edge networks.

Just a quick caveat to level-set our conversation. To me, the edge in an unmanned situation is a sensor that's collecting data, or an edge user. That's the way I'll be defining the edge for the remainder of this conversation.

I want to describe to you how the military is innovating on the edge so that you can bring some of that same innovation to your organizations.

But here's the kicker. I want to create a conversation so that you return the favor. We want to hear how you are improving your networks, how you're making them more resilient, how you're making them survivable, so we could do the same for DoD as well.

A little bit about me: I've been working in technology since 2007. I'm a prior-service Marine. Obviously, I know technology, because I could tell you that pictured in this slide is a cassette, that's a floppy disk, that's a tube television, and a camera. So you're in good hands. No need to worry. I'm the right guy for the job.

I want to talk to you a little bit about my goals. Some of you are familiar with the band the Beatles. "All You Need Is Love." Personally, my goals are to be the best husband I can be and one day the best father I can be. Professionally, I'd love to see a passion for care and love of people returning to industry.

Harvard Business Review did an amazing article and study that talked about the impact that trust has in organizations. When there is trust between employees and other employees and between employees and managers, those types of organizations, the ones that make trust a critical component of their culture, perform up to 3 times better. Here's a quote from that article:

"… their research shows that 'trust between managers and employers is the primary defining characteristic of the very best workplaces.' These companies beat 'the average annualized returns of the S&P 500 by a factor of 3.'"

Before I tell you about how the military is innovating on its edge networks, I feel like it's important to describe to you some of the challenges that the military faces. These challenges might be unique to the military, but I suspect that not all of them are. Chief of them is size, weight, and power. The second is connectivity, and the third is security and simplicity. I'll dive into those a bit more.

Size, weight, and power

The military operates all over the globe but also operates above the globe, in space. The conditions in the environments that the military typically operates in could be harsh. They're austere environments: high temperature, low temperature, high altitude, low altitude. There are considerations to be made for shock and vibration. These are concerns that typical work environments might not face on a day-to-day basis.

The second challenge is limited access to conditioned power. We take power for granted. But when you're rapidly responding to incidents all over the world, the infrastructure that's available to you is not guaranteed.

And then finally, weight restrictions for rapid response. It's hard to deploy a rack of datacenter equipment. It's not designed to be mobile. It's not designed to move. It's heavy, it's big, it's awkward-shaped.

Connectivity

This might come as a surprise to you, but connectivity is another challenge that the military faces. When you're rapidly responding to incidents around the world, the probability that there is a high-speed data link available to you is unlikely.

That leaves you relying more and more on wireless networks and wireless waveforms, whether it be tactical radios that create point-to-point links, or more and more we're seeing a reliance on things like Wi-Fi and cellular. LTE and 5G are becoming a really hot topic within DoD.

The problem with wireless networks is that there's higher latency, they're generally lower bandwidth, and they're less reliable.

Security and simplicity

This is the one I'm most passionate about. You guys are all really smart. You are. Technical teams that know how systems operate aren't generally the ones that deploy with the system. In order to have technical expertise support the capability that's been deployed, you need to make sure that No. 2 isn't a problem. Connectivity doesn't just enable the app. It also enables your ability to talk to the person who knows how the app's supposed to work.

These are the 3 main challenges. I'll summarize them for you.

This is a typical battle space. It might vary, but in essence, it describes all of the components that you might experience in the battlefield:

• Munitions

• Vehicles

• Weapons

• Sensors

• Robots

• Wearable devices

These components are hard to move because of physical footprint. I need to be able to power each of these components. And I also have to consider things like HVAC. How do I cool them? How do I keep them warm in really cold conditions?

It's hard to connect all of these disparate systems.

Here's something interesting that you may not know. For a really long time, the military bought systems that were mission-specific. Just think about that for a moment. Mission-specific. That's like the furthest you can get from agile imaginable.

Because when they're mission-specific, what do I do if the mission changes a little bit? You need a brand-new system. How do I make those systems work together? How do I operate in environments where other mission partners, who also use mission-specific systems, are working by my side? It makes it really difficult.

And finally, the access to technical personnel available to assist should things not be working well.

Solving the challenges with innovation on the edge

So I've described the problem to you. Now I want to talk to you a little bit about things we've been doing to innovate on the edge to offer a solution.

First of all, we make things smaller that can perform better. That's pretty straightforward. It's a lot easier for me to deploy a datacenter to the edge if I can miniaturize the datacenter without sacrificing performance.

Infrastructure as code. Can I detach my infrastructure from a dependence on hardware? Because if I can move my infrastructure across various types of hardware, that means I can move it across the globe.

And "start meshing around.” I'll wait to describe that to you.

Making things smaller

How do I do this?

Let's cut the fat. Let's stop deploying the things we don't actually need. This is a huge challenge, and I am eager to hear if you guys face a similar challenge in your space.

When we sit down with customers, when we sit down with Army and Navy and the Marine Corps and we say, "What are you trying to do?" they're like, "This is what we need." We're like, "No, describe to us what you're actually trying to accomplish so that we can tailor-fit a system to meet those needs."

Because we're always prone to over-provisioning, and when you over-provision, you have more resources than you need. And when you have more resources than you need, you're carrying more stuff. You have more stuff to power. You have more stuff to administrate.

Can I bring higher performance in a smaller footprint? And can I make those systems that are higher performance in a smaller footprint resilient?

This is by no means intended to be a sales pitch, but I just want to describe to you some of the things we're doing. The system on the screen on your left is 4 Xeon servers. The entire system has about a half terabyte of RAM. There's a 10-gigabit network backbone.

The whole thing weighs 63 pounds and can fit in the overhead compartment of an airplane. So you no longer need to charter an aircraft in order to deploy a system. You can have operators use commercial transport to get where they're going.

That same system in a slightly modified configuration is mounted in a Humvee on your right.

The cool thing is, internally, that's a 19-inch rack-mountable chassis.

If you think about the way the military typically operates, there's an initial entry force. There are a few guys who get there, they figure out what's going on, they lay down a little bit of infrastructure.

If we intend to stay there, follow-on forces will come along. So the ability to scale quickly from a hardware resource perspective is important.

Here's a video of this same system being dunked in a kiddie pool, then hosed down and powered on.

And some of you might be familiar with ruggedization standards in the military. That's the system being dropped. Not something you do with your typical datacenter rack.

There's a cool story. About 5 or 6 years ago, we deployed a system with 82nd Airborne. During one of their training exercises, they had thrown 1 of our systems off an aircraft on a pallet. Thankfully, there was no human attached to the pallet because the parachute on that pallet didn't open.

The system burned into the ground from 1,500 feet. We all anticipated that there was absolutely no possibility that this system would survive.

They were able to get the components inside the chassis on the network. It didn't look good, it didn't smell good, but at the end of the day, it was able to get the guys on the network. And to them, that's all that matters.

Infrastructure as code

I don't doubt for a moment that you guys are very familiar with the concept of infrastructure as code. I by no means claim to be an expert on it. But I do recognize that if infrastructure can move across hardware, it can move across the globe.

Something that's really important for the military today is the ability to scale both vertically and horizontally.

For a long time we thought that scalability meant just adding more users: I have the initial entry force and then follow-on forces, so I need to scale to support more people.

But we're finding that that's not true. Scalability outwards is equally important. I need to be able to add applications quickly. I need to be able to integrate applications from other organizations quickly as well.

So it's not just adding more components to make my network more robust. It's federating other networks for mission partners.

We have something called the Five Eyes. Australia, New Zealand, Great Britain, Canada, and America have a coalition where they share information and resources across their missions. Being able to federate other nations' networks quickly and easily makes those apps accessible on the network. That's scalability as well.

Security is the military's biggest challenge, I think. Because there is so much bureaucracy associated with getting things on a network, rather than being an enabler, sometimes it becomes an obstacle.

But with infrastructure as code, I can mitigate some of those security risks, because I can roll back quickly, I can update quickly, and I can update across the board quickly.

Get meshy

This is another passion of mine. But what do I mean by "get meshy" or "start meshing around"? You guys remember the old peer-to-peer networks? You don't have to raise your hand or admit your guilt of ever participating in BitTorrent or newsgroups. I won't judge you.

But if you recall, things like Napster offered us the ability to pull the data I needed from a million different locations. I was no longer dependent on a single centralized resource to get what I needed. I was able to get what I needed from various locations.

What that allows me to do is it reduces a single point of failure. Because when we go back to this connectivity problem. If I don't have connectivity, then I don't have access to my datacenter. I don't have access to my centralized resources.

What if I eliminate the need to have access to my datacenter? If it's online, great; I'm all about it. I'll use it. But if it isn't, can I begin to leverage peer nodes that are deployed around me in the same region?

We were talking yesterday with some of the HashiCorp folks. The data that the edge collects is the most relevant data because it's the newest data. Is there a way for us to infer on that data? I know about garbage in and garbage out. I'm not saying that's not a problem. But can I make better use of that data without a reliance on a centralized facility?

Another advantage of distributing across a mesh of systems is I can distribute the application. Remember, we talked about the problem of making things smaller so that they work better. When I can distribute an application across multiple systems, the amount of hardware resources that I need goes down as well. The application becomes more lightweight.

I think that over the next 5 years, we're going to see a reemergence of peer-to-peer-like networks. I'm by no means suggesting that the cloud era is over. By no means am I suggesting that. I just think that, especially in DoD, we're going to start seeing more peer-to-peer-like communications.

Think about it. You have things like HoloLens. We saw Google Glass, things like that. More and more data is being collected by the edge user. And we want to make that data actionable as close to the edge as possible. That's one of the chief catalysts for 5G. One of the chief catalysts for 5G is the reduction in latency. So that I can make data ingested at the edge actionable. So let's get meshy.

Software that can solve these problems

I talked to you a little bit about the problem. I described the solution to you, or some of the solutions we're looking at. By no means do we claim to have it all figured out, but some of the things we're working on. And I want to ask you the question, Does this sound familiar? Because it should.

In my eyes, innovation is not just coming up with new ideas. It's taking existing ideas and applying them in new and creative ways. What I just described to you are problems that the military faces. I have not yet made a comment about software or how we've applied software to solve those problems. But I want you to take a look at this.

Making things smaller so that they perform better. Some of you may have seen this video before. [Screen shows a still shot of Armon Dadgar talking about Consul.] But isn't that what we've done with monolithic applications? By taking the app and making it microservice-friendly, I've taken something big and made it smaller so that it can perform better.

Abstract infrastructure from hardware for agility. In other words, infrastructure as code.

If I can deploy my infrastructure quickly and, more importantly, if I can make my infrastructure deployable without the reliance on a technical expert, if I could find a way for the user who's there with the system to just press play, and all of the resources will be provisioned and all of the applications will be deployed, then I've done my job well. It might mean that I'm out of a job, but I've done my job well.

Isn't that what Terraform does? Or what Terraform is intended to do? Simplify the provisioning of resources so that I can get my applications out quickly. I could recover from an incident rapidly. I could repurpose quickly.

And finally, use a mesh for resiliency and simplicity. Some of you guys may know where I'm going with this. But in many ways, that's some of the features that are accessible to us through Consul: a service mesh where services become aware of each other. They can discover each other. They can keep their configurations consistent. And it requires little intervention from you.

First, define the problem you need to solve

When I started this talk, I told you that I wanted to describe some of the ways that the military is innovating on its edge networks so that you can bring some of that innovation into your own networks. And hopefully return the favor with some of your good ideas.

As I close today, I want to share a quote with you from Albert Einstein: "If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask. For once I know the proper question, I could solve the problem in less than 5 minutes."

You're starting your HashiConf journey now. You're going to hear a lot of great ideas, and you're going to hear a lot of ways that people have implemented tools and software to make their organizations more resilient.

My challenge to you is, as you sit in on these sessions and as you have these conversations, ask yourself the question, "What problem am I trying to solve?"

Because if you do and you find a solution to that problem, it may have an impact far beyond your own organization. It may have benefits that are long-lasting and benefits you may not know about. "What problem am I trying to solve?"

The next challenge to you is be courageous and make suggestions to your leadership.

I recently had the privilege of participating in an innovation symposium with the Marine Corps. And I was by far the youngest person on the panel, and I don't say that pridefully. I probably wasn't supposed to be on the panel, but I was there.

I took that opportunity to share what I thought the Marine Corps needed to do in order to keep pace with innovation. And my biggest exhortation to the Marine Corps was, there was a day where Marines were trusted to fix anything with a little bit of tape and some rope. You could give a young Marine some 550 cord—it's essentially rope—and some duct tape, and he could fix a tank. It's amazing.

But with the emergence of technology, we've removed that ability from them. We've elevated where decisions are made and how technology is used to higher echelons, to commanders and other leaders.

But are we still listening to the young Marines and asking them, "How would you solve this problem? What problem are we trying to solve?" So I tried to encourage the Marine leaders at the symposium to listen to the suggestions that their young Marines come with.

And most importantly, love others along the way. Remember that Harvard Business Review article that talked about trust? I really do believe that trust is a product of how you care and how you love the people around you. Good luck building trust with someone that you don't treat well.

That's all I have for you today. Thank you so much for spending your morning with me.