From 9c81840d9ad52b16cb86768c2881567eb4bb3812 Mon Sep 17 00:00:00 2001 From: Bas van der Linden <33874522+BvdLind@users.noreply.github.com> Date: Fri, 12 Jul 2019 15:47:20 +0200 Subject: [PATCH] Update chapter3.md fix casing of an instance of the word "GitHub" in chapter3 --- manuscript/chapter3.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/manuscript/chapter3.md b/manuscript/chapter3.md index 48a4205..5c30f62 100644 --- a/manuscript/chapter3.md +++ b/manuscript/chapter3.md @@ -17,7 +17,7 @@ I don't want to downplay the difficulty involved in actually creating this capab The reason DevOps has "Ops" at the end of it is because Operations _doesn't go away_. Developers don't "take over." Our job is to provide developers with a _managed_ set of capabilities. So yes, a developer working on a project should be able to spin up a virtual environment without anyone else's intervention, and they should be able to recycle - that is, delete and re-create - that environment anytime they want. That doesn't mean they get to change the environment's specification on their own, nor does it mean they get free reign of the virtualization infrastructure. -Let me offer you a really simplistic, yet incredibly real-world, example of this. Amazon's Elastic Beanstalk service is designed to spin up new environments - that is, virtual machines - more or less on-demand in response to customer load. Each new virtual machine starts as an identical copy of a base operating system image, and each new virtual machine can load content - like a web site - from a GitHUb repository. So right there, you've created some of the automation and consistency you need. With a button push, or in reaction to user load, you can automate the creation of new environments, and because they all come from known, standard sources, they'll be consistent. +Let me offer you a really simplistic, yet incredibly real-world, example of this. Amazon's Elastic Beanstalk service is designed to spin up new environments - that is, virtual machines - more or less on-demand in response to customer load. Each new virtual machine starts as an identical copy of a base operating system image, and each new virtual machine can load content - like a web site - from a GitHub repository. So right there, you've created some of the automation and consistency you need. With a button push, or in reaction to user load, you can automate the creation of new environments, and because they all come from known, standard sources, they'll be consistent. It's extremely likely that developers will need environmental changes beyond what's in the OS base image, and so developers can specify additional items. They can set environment variables, specify packages to be downloaded and installed, and so on. In the past, a developer would have tinkered with their development environment until everything worked, and then hopefully communicated the results of that tinkering to someone in Operations. Ops would then, hopefully, faithfully re-create what the developer did. But did you get the right versions of the packages? Did you set all the environment variables?