Skip main navigation

New offer! Get 30% off your first 2 months of Unlimited Monthly. Start your subscription for just £35.99 £24.99. New subscribers only T&Cs apply

Find out more

Home / IT & Computer Science / Cloud Computing / Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline / Environment Deployment

Environment Deployment

This step describes the advantages of having your Infrastructure in a Code form rather than sticking with manual deployment
View transcript
17.2
Let’s talk about environment deployment, getting those machines out into a test, a dev, or a production environment appropriately. Now, a lot of the ways people do it today is through manual deployment of servers into their environments, and those environments may stick around for a long period of time. Let’s take a look at some of the problems that are caused by that. First of all, we get this snowflake effect, these snowflake servers, these would be servers that, frankly, are all configured independently and differently. It could have been through a mistake. It could have been through some old DLLs that were deployed on the server.
54.7
But when we have a server that sticks around for a long period of time, it gets all sorts of deployed artefacts onto it. And it differs from the other servers in that farm. If a server has been sitting there for, I don’t know, three years and we add a new one this month, it might not have that same thing. So what we have is this difference between the servers and our infrastructure, often called snowflake servers. They’re all different and need to be treated specially. Deployment steps also vary by environment. When we’ve got a different environment configuration, often, we’re going to have to deploy things into that environment in a different way than we deploy it into another environment.
97
So for instance, we deploy into the test or the pre-prod differently than we deploy into production. Now, granted, we’re always going to be pointing to different server names, but we don’t have to have– that could be a configuration thing, not a complete difference in the way that we do our deployments. But traditionally, those deployments are quite different if they’re done inside of a manual process. So what does that give us? First, environmental drift. We’re going to start to drift our environments. Our servers are going to drift away from one another. Secondly, people might be coming in and making changes to those servers.
131.9
Every time they change those servers– one and not the other– we’re starting to drift away from the servers themselves and away from our core, defined environment. Sometimes we need downtime to be able to recover from that. We’ve got to take a server down. We’ve got to pull it out. Our entire app may have to come down. Next, if we want to scale it up or scale down, that requires a lot of manual processes as well. That generates– engenders– this fear of releases. This is that vicious cycle that gets back and gets us again. Now we’re afraid of releasing. Because every time we release, we spin up a new environment, potentially. It might break. We deploy that environment, it might break.
170
And so we want to deploy fewer environments or slow down that cadence. The other is that, very often, that configuration of those machines is very tribal, the knowledge. It’s only a few people that know how to treat those very special physical machines. So what do we do? We add more verification steps. We add more documentation. We start to flesh this stuff out in ways that slows our delivery cadence. So what’s the alternative? The alternative is infrastructure as code. And in infrastructure as code, we’re going to have consistent servers across all our environments. And those environments can be created or scaled almost trivially. Now, what does that do for us?
212.2
It starts to create this virtuous circle of things that we can do. We can start to treat our servers as cattle, not cats– or cattle versus pets, however you want to talk about it. But instead of a named server, who we care for and we know all of its foibles, that server is just part of a server farm. It’s managed as a herd, not managed as an individual pet. And that lets us spin up other things like blue-green deployments. So in other words, if we want to deploy, we can have our existing infrastructure, we can deploy the new infrastructure beside it, and we can simply start syphoning off or directly point into the new infrastructure from the old.
252.8
So we can create brand new infrastructures– bring them up, tear them down. We can automate the creation and updates of all of those environments through version control. It gives us a really consistent and a confident deployment. We can look at the logs afterwards. Did anything go wrong? If something did, let’s not swap over and move into the green or the blue for the production. And it allows us to transition to this idea of immutable infrastructure. And immutable infrastructure is this idea that once we deployed an app or deployed a server, it’s done. We don’t ever touch it again. We don’t run updates against it. We don’t run new versions of the app on it, new deployments. Instead, it’s done.
304.7
If we need a new update or we need to update, we simply spin up a new machine and swap it out with that new machine. It’s this idea of an immutable infrastructure. And all of these come together to start giving us much faster release cadences and much more confidence in our ability to deliver quickly in that DevOps environment.

We completed the previous activity with a step illustrating the benefits of configuration management. In this activity on deployment and configuration, we will start off with a step covering environment deployment.

Infrastructure As Code

If you’ve ever received a middle-of-the-night emergency support call because of a crashed server, you know the pain of searching through multiple spreadsheets, or even your memory, to access the manual steps of setting up a new machine from scratch.

There is also an age-old difficulty of keeping the development and production environments consistent. An easier way to remove the possibility of human error when initializing machines and treat environments like code so that they are stood up from a single consistent definition is to use Infrastructure as Code.

Want to keep
learning?

This content is taken from
CloudSwyft Global Systems, Inc. online course,

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

View Course

A common analogy for using Infrastructure as Code is the distinction between owning pets and cattle. When you own pets, you give them names, you treat them individually, and if something bad happens to them, you care a lot. If you have a herd of cattle, you might still name them, but you treat them as a herd. In infrastructure terms, without treating environments as code, there might be severe implications if a machine crashes and you need to replace it (pets). If you use Infrastructure as Code, if a machine goes down, you can just spin up another machine with no issues (cattle).

When designing scripts or definitions for Infrastructure as Code (IaC), it’s important to make sure that the code and tools are set up to be idempotent, or able to run multiple times without error and with consistency.

Infrastructure as Code can also be set up with developers’ help because many tools offer the ability to write code in familiar programming languages, even ones as simple as JavaScript Object Notification (JSON) definitions. Some examples of common tools you use can in order to work with Infrastructure as Code are Vagrant, Ansible, Puppet, Chef, Docker, Microsoft Windows PowerShell DSC, and cloud-provided tools such as Azure Resource Management templates.

The following table lists the major differences between manual deployment and Infrastructure as Code:

Join the discussion

Have you encountered any of the issues mentioned in relation to manual deployment? What workarounds did your team come up to deal with this?
Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.

Want to keep learning?

This content is taken from CloudSwyft Global Systems, Inc. online course
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
View Course
See other articles from this course
This article is from the online course:

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
Join Now
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now

Register to receive updates

  • Create an account to receive our newsletter, course recommendations and promotions.

    Register for free