Learn the 5 characteristics to measure your journey towards a hybrid cloud operating model.
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
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.”
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?”
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.
We thank HashiCorp for these 5 Marks!
Ask us more about Hybrid Cloud Operating Model!
