Share: |

Kris Buytaert banner.jpg

We continue our excerpts from the podcast with Kris Buytaert.


This is my second sampling from Kris on 'Infrastructure as code', a core DevOps tenet, and how DevOps is a truly practitioner-led movement.





Tom:   So how important is infrastructure as a code to DevOps?  And you might just take astep back and explain to people who aren't as into the details exactly what you mean by infrastructure as code.


Kris: So infrastructure as code is the idea today, you don't go into a datacenter anymore, pop in a CD, click to enter a couple of times and then move onto the next machine.  Systems people don't do stuff manually anymore.  We are basically writing codes to managing infrastructure.  We are writing in languages like CFengine. And we're alternating our whole infrastructure up to a point where you pop in your disc in a data server and it totally configures itself. 



That's what machines have been built for.  To automate itself and not making human servers.  And the evolution of automating this is something that the tools have been around – the tools have been around for ages. So because of virtualization, the scale of the number of machines we have to manage by changing the cloud even has forced that a bit. 



And then we needed to figure out different ways of installing machines, different ways of managing machines. Those were kind of accelerators to start infrastructure as code movement. 



And if you then put that into DevOps, if you think about testing.  If you think about scale.  If you think about orchestration.  Imagine that you have to go to a test engineer, “Look here's a bunch of servers we built.  Can you please try to destroy them?  See how you can break them.” And then, after you've broke them, you have to go back and say, “Well, that's very nice.  But now we have a problem, because we cannot give you your test environment again.  We cannot help you to do your test.”



So, for example, testing is one of the reasons why you really want to have infrastructure as code.  You may even want to give it to them the way that they can say, “Oh.  I just want to roll back to a previous date and see what happens.”



Now, if you were a small shop and you have to configure two or three machines.  That's fine.  You could go there manually.  But once you grow into a couple of hundred, a couple of thousand, it starts to become really difficult.  So people really need to automate there. 



On the other hand, if you are a small shop and if you really are doing specialized things, you also want to automate stuff, because just – just those little one-offs.  Those little, “Oh I made this really special setup, and it's real difficult to do.”



Tom:   Yes.



Kris:  That's also something you want to have automatic so when it breaks, you can actually do it again.  So this whole idea helps people think about how they should deploy stuff, how they should deal with infrastructure. But tools are getting there and up until five or six years ago, tools were a bit more difficult to use than they are today.



Tom:   Yes.  Yes. Well, let's move on to monitoring. How important is monitoring for DevOps?



Kris:  So John Willis and Damon Edwards, they coined a good summary of DevOps being CAMS.  C-A-M-S, which stands for culture , automation, measurement and sharing.



Well, I think the previous question pretty much tackled the automation part.  But the measurement part, that's where monitoring comes in.



You want to know what's going on in your infrastructure.  If you want to improve your environment.  If you want to improve the way you deal with software.  If you want to improve scale.  If you want to improve the meantime to recovery.  If you want to basically

improve the sleep of your system engineers, you want to measure what's going on. 



You want to monitor your infrastructure. So you want to build systems that are stable.  You want to make sure you know how stable they are.  Otherwise, you cannot see how much progress you made.  People want to know how many times you deploy a day.  So you need to monitor how many times you deploy a day.  They want to know what changes happened.  They want to know why changes happened.



Tom:   Yes.



Kris:  And you really need to build in those kind of memory things into your infrastructure.  And it just makes stuff a lot easier.  If you don't have any monitoring in your environment, then you're pretty much blind and just trying to grab somewhere in the dark.  Monitoring shines light on your infrastructure.  And it's really important to know what you're doing so you can actually improve on what you're doing.



Tom:   Right.  Right. And that even makes a lot of sense. Well, stepping back again, I know we kind of keep coming at this topic.  But it's new enough to kind of help people fully realize, you know, what this is going on here.  From your perspective, why does the term DevOps resonate?



Kris:  I think it's for a lot of people, they see the problem.  They see how difficult it is to keep an environment up and running.  They see development groups thinking about building software.  Building new features.  And then having the operations people with totally different markets having to keep systems stable and running. 



Now the whole DevOps discussion and whole DevOps movement have been furthered by people who have been working in the industry for – for a while, who have built good reputations in the communities.  Who have built really good track records.  And they started talking about the experiences they had on how to improve the way other people work. 



And it's probably pretty much because there were a lot of people involved in the movement in the early days that we're pretty visible in different communities.  That we're pretty visible in – in start ups that were doing this kind of stuff.  That most people want to be edgy.  They want to look at how operations is done.  And they look at the big example of "wow, this is how they run operations in such an environment."  And people want to be the same.



So it's – it's a combination of a bunch of good examples.  Good track records on “this is how we can do it.”  Combined with experience and well-recognized people explaining how they actually did this stuff.  And to me, that's I think one of the reasons why DevOps is probably much faster than other stuff.  It's not backed by commercial vendors.  It's actually people talking about how to do stuff with tools.  And all about pushing a product that's really solving solutions with tools that are widely available. 






Coming next with Kris: Packaging Religious Wars, Traceability And Maturity.



Other related on-line materials:

When the Kris Buytaert podcast is published, it will be here.


Excerpt A: DevOps Needs Sushi & Mainstream DevOps

Excerpt B: Infrastructure as Code, Monitoring, and Resonance

Excerpt C: Packaging Religious Wars, Maturity & the End of Tradition