The 5 Marks Of A Hybrid Cloud Operating Model

Transcript

Today we're going to talk about your digital transformation to a hybrid cloud operating model. What I’m going to talk to you about are five key characteristics that you can use to measure yourself against your digital journey.

Goals over technology

The first mark in a hybrid cloud operating model that you have to consider when you're going through this journey is goals over technology. A lot of times what ends up happening is we focus on the technology that we want to choose, and then we try to wrap those goals around it. When you're trying to transition to a hybrid cloud operating model you have to put up, "what is my end-state going to look like" versus, "how is the technology going to influence that." You're looking to say, "These are the marks that I want to hit, or the milestones. This is what I want my applications or my deployment model to look like," and then after that, "What technology is going to support the initiatives that I'm trying to achieve?"

Immutability

The second is that I want to move to a highly immutable state. That doesn't mean that you have to be 100% immutable. But as containerization starts to take over more and more, this natural progression of moving to an immutable state becomes a more natural reaction. You want to start transitioning towards that idea of immutability at a much higher rate.

As containerization has come into play, it's started a natural progression of moving towards a higher immutable state. That doesn't mean that all of your systems are going to end up being 100% immutable. But you want to start transitioning to this point where you're distilling all of your common components out so that you can have a repeatable way of deploying.

Gone are the days of these long-running systems and patching and configuring over a long period of time. You want to get to a state that when I change the application or something about my infrastructure, the natural habit is to destroy that infrastructure and rebuild it with a new version.

Security built in

The third mark of a hybrid cloud operating model is security built in. Traditionally in deployment pipelines or deployment processes, security is usually a check mark along the way. You spend a lot of time developing, you spend a lot of time working on these applications or this infrastructure. And then you have to come to a point where there's a security check—where they have to go over and comb through everything about that deployment or about those applications—and start to distill out and say, "Have you passed our security checks or not?"

In a hybrid cloud operating model, the speed and the rate at which you want to deploy—and this idea of continuous integration and continuous deployment—starts to slow down your ability to deploy at a high rate of speed. That slows down your developers, that slows down your infrastructure folks. What you want to do is bake security into that pipeline or into that process. In doing so, you can accelerate while still maintaining a high level of security.

Configuration on demand

The fourth mark of a hybrid cloud operating model is that you want to have configuration on demand. Traditionally in systems we've built a VM or we've built some type of application then we push configuration out and then maintain it over a long period of time.

The question I would ask you is what is the difference between a production web server and a development web server? It's roughly about 17K.

It's the configuration file that dictates whether or not that server is a production server or it's a development server—or in some cases it might be a database between a web server. What you want to do is get to a point where I can pull that configuration from a centralized source and then be able to push it out—federated—across multiple different systems at the same time. This allows me to push configuration out on demand—and my applications can consume that—and then behavior can be dictated or modified on the fly.

Change management baked in

The fifth mark of a hybrid cloud operating model is that I'm going to have change management baked in. Typically, when you think about change management you think about heavy ITIL processes, and having a lot of tickets or service requests—and those inbounds. If you start to move towards this ability to be able to deploy at will—to be able to change those applications—behavior on the fly—you start to apply a lot of these other marks that you have. In that context my change management could become a potential bottleneck.

What I want to do is bake this in to my process. You could use things like version control systems to be able to express infrastructure as code—to express security as code. In that context, every time I make a change, not only am I updating to the most current version of my software, I'm also updating to the most current version of my documentation. On top of that—whenever I make those changes—now I'm baking in my change management. It could become as simple as a pull request where everything is documented, and I can look at my revisions over time and see the version changes.

This helps in a context of auditing in the case of security. This helps in the context of change management when I want to understand how my environment has mutated over the course of several different sprints or several different experimentations within it.

Choose your starting point

The beauty of this whole thing is that you can start at any one of these. These aren't necessarily a systematic way to moving into a hybrid cloud operating model. These are five characteristics that you should be looking at to say, "As I progress, I should be able to see these express themselves as I move through."

In the context of goals, I should see that I'm hitting my milestones. I should see that the technology decisions that I've made are driving that home. When I look at immutability, I should be able to say, "How much of my infrastructure—or how much of my applications—do I have that are not necessarily being configured and changed over long periods of time but I can restart in order to apply that change or that update?"

When it comes to security, I should be able to have systems and applications that are at a high level of security with a low level of human input. When it comes to configuration, I should be able to—at will—change any aspect of my application; flip switches, reroute traffic, decrypt, encrypt—anything on the fly with a push of a button. The last thing is around this change management. My change and my documentation become an output or an artifact of my deployment. They aren't something that I have to do as a checkbox along the way.

Self-assessment and measurement

As you start to move through this idea of a hybrid cloud operating model, start to measure where you are in the context of these five marks. Be honest with yourself and grade it and say, "How are we in immutability," or, "Can we change configuration on demand, or is there a long-tail process that it takes to implement this?"

As you look at these, you can begin to see these as guiding principles as you move through this journey. This is not something that is going to be an overnight success or something that you're going to just push through. This is a transformation where you're going to start in one place and end up changed at the other side. Use these as those guiding principles.

Now that you know these five marks of a hybrid cloud operating model, we'd love to help you in those first steps along this journey. Feel free to visit us at hashicorp.com. Check out our Learn pages, or even go to our blogs to get tips and tricks, and reach out to be able to engage with us on how we can help you move forward.