Optimize DevOps with these key Azure concepts

Optimize DevOps with these key Azure concepts

We just wrapped up another webinar with Softchoice’s Azure experts, this time speaking about the future of application deployments and infrastructure provisioning on the cloud.

And while the entire discussion is worth watching (again or for the first time), we wanted to boil down the biggest takeaways from the event.

Why should you care? If you’re like thousands of other businesses moving workloads to the cloud, you know migration is just the first step. Once you are in the cloud, what can you do to optimize, speed up and make your workflows and app management more efficient? There is tons of opportunity on the table, and plenty of risk if done incorrectly.

To get clear on these concepts, keep reading…

1. Immutable Infrastructure:

When we talk about DevOps, we mean automating and making more agile the way you deploy apps and infrastructure in environments such as Azure. Given the importance of automation in this concept, wrapping your head around what is “Immutable Infrastructure” is key to your success.

The word “Immutable” means unchangeable, something that doesn’t get altered. For decades, we’ve tinkered, patched up and repaired our local infrastructure and apps to make them work better. But on the cloud, it’s a different story. You don’t change existing infrastructure, you swap it out with an image almost exactly like the last (sometimes), but with the key components updated as needed.

You basically deploy an image in its ideal state, which is why we often call them “Golden Images.” You replace the old with something better.

2. Vanilla or Half Baked images – a compromise

We get the most push back with the idea above. People tell us all the time “But that’s not how it works, that’s not how I run my environment!”

True. And we understand. That’s why there are two “compromise” alternatives, that can help ease your team into the idea of immutables. The first is what we call “Vanilla” images. Here, you are basically starting from scratch each time you deploy a new infrastructure component from the cloud, such as a server environment. This takes longer but allows admins to customize and build out the application as needed. The second option is what we call “Half-baked” images. Here you are launching images with the majority of the customizations needed already in place. It allows you to deploy faster, but still leaves room for some manual customization and attention before it goes to production.

If immutable is “golden,” needing no manual work, vanilla and half-baked images are the other two ends of the customization continuum.

3. Pets vs Cattle:

As you can see from the points above, the entire way we think about infrastructure and applications needs to change when we start deploying from the cloud.

It used to be that we cared for our app infrastructure like we do for our pets. Much time and love used to go into naming things like servers. When stuff broke, we would patch it. It was a long-term investment that we cared for and tried to make better.

Not anymore. Today it’s more like cattle. We rarely take the time to name the infrastructure we deploy from the cloud, perhaps because it’s replaceable and short lived. Instead of patches, we just swap out the old with the new, as discussed above.

4. Infrastructure as Code:

With Infrastructure as Code (IaC), we are basically stealing (or borrowing) ideas from developers, and applying them to the world of app infrastructure. You see this in two distinct ways.

First is the idea of the “repo.” Developers always rely on a central source repository, such as GitHub. IaC does the same thing, keeping basic infrastructure components saved in a central repo, easily accessed, duplicated, forked and customized. Second is the idea of iteration. With IaC, you are learning and constantly improving as you go, replacing each new version with something better.

All said, IaC can simply be defined as managing and provisioning infrastructure using code – instead of doing it with manual configurations or arduous hardware setup.

5. Azure Quickstart Templates:

Speaking of repos, if you are working with Azure, you already have access to an enormous and rich repository of pre-set, pre-existing infrastructure components. These are called Azure QuickStart Templates. And there are literally hundreds of them freely available to you to duplicate, fork and deploy as you see fit — here on Github.

It’s worth heading over to the site to explore what is available, and even test out a few test deployments to gain confidence and understanding about the process. it’s helpful to remember these are IaC templates that are vetted and screened by Microsoft’s own team, even though they remain open source.

6. Blue-Green Deployments:

The final key concept is how you can avoid disruption and limit your risk by adopting the “Blue/Green” Deployment approach.

Basically, this is a variant of AB testing that allows you to slowly, gradually push users to a new version of your application, and test it out live. Users of the old application slowly are sent over to the new one. But if complaints start rolling in, you can easily swap back to what was there before, and fix the issues.

The result reduces downtime for maintenance, upgrades and ensures better end user experiences in general.

For the IT leaders who joined us on the webinar, only eight percent said they have automated some aspects of their application deployments. Fifteen percent said they were considering it.

What about you? With the concepts above, we hope you will be a few steps closer to automating and simplifying the deployments of your modern, cloud-based applications.

Watch the entire webinar below. Or get in touch to learn about our Azure TechCheck Assessment our Azure services and platforms.

Related Posts

About Tobin Dalrymple

Tobin Dalrymple is a longtime Softchoice contributor and the IEF program writer living in Montreal.