Let's talk a little bit about who actually does this job of Ops. If you've seen the HBO show Silicon Valley, there's a Dev guy, a Dev character and an Ops character. We didn't have enough money to license the image, so I'll try to paint you a picture. The Dev guy is named Dinesh and I think he's from Pakistan and he does not wear glasses and the Ops guy is named Gilfoyle and he does wear glasses and he has long hair, not super long but shoulder length. That should be enough for you to tell them apart if you see the show. It's very funny, of course it's hyperbolic. But, there has always been an inherent, intrinsic tension between velocity and stability. When we try to move new features at the door really quickly, the reality is we increase the risk that something goes wrong in production and that ends up on the lap of the Ops person, at least classically. There's some latent issue because we move fast and we broke things as people say. Then it's usually the Ops person or somebody acting in that role who would get the two am call, oh my god there's an emergency, wake up and deal with it and nobody likes that. A lot of what DevOps is about, is mitigating that natural antagonism and helping everybody help each other do what makes sense, because the way that you get to a good outcome and a nice stable system, is stuff that happens way back in the development cycle and moves forward in a way that makes sense all the way through the pipeline into production. Classically, the person that did this job had to do a lot of stuff manually, they probably knew a bunch about the Linux operating system and computer networking, so TCP/IP networking and they had to deal with all that stuff and they probably had to deal with it from scratch, from as we say bare metal, actually dealing with the physical boxes and there were a lot of manual steps. Now, the movement is towards treating this as more of an engineering problem and that's driven by the ascent of the serverless architectures, the fact that that allows you to treat this stuff as an infrastructure. In fact, even if you run your own data center, there are software packages now that you can run that really allow you to abstract away the physical machines and layer this stuff better. The other big catalyst that has affected the job of Ops and the immediacy of these interactions between Dev and Ops is the ascent of SaaS, the fact that many companies now offer their software online through their own facilities rather than putting on a CD or making it downloadable and giving it to people at arms length that way. Plus just everything moves super-fast now. So, these Dev and these Ops people need to work together in a way that makes sense, how did they actually do that, well instead of a Dev person working with an Ops person or Ops person having to piece things together and write a five-page, 12-step guide to one-by-one upgrading the software on each server. They might work together on a script or a manifest that goes into some tool that automatically does all this stuff and that would be an example of infrastructure as code rather than infrastructure as a set of instructions written down and read by a person and typed in and hopefully executed properly, for obvious reasons. The second second works a lot better, it's less error-prone, way more testable and an extremely scalable. Another term that you might hear a lot in this area is SRE, Site Reliability Engineer. So what's the difference between that and DevOps. On the one hand they're different bodies of work in different things and the communities don't always in practice overlap all that much, except in practice, they overlap at time, they're doing the same basic job especially on this kind of ops angle of DevOps. SRE stands for Site Reliability Engineer, it's a really popular job role and very well standardized variable scale job role at places like Google and Netflix and Apple. Sometimes they operate in separate groups but very frequent they're embedded in product teams. Usually, you have a product team, setting its own budget and deciding how many SRE's do they want and things like that and the idea is that, once the software is ready to go to production, the SRE works very tightly with the developers to look at how they are going to put it into production, whatever that infrastructure is that they're going to use and keep it running and makes sure that it stays running. There's an interview in the course resources with a guy named Ben Treynor, I believe he still runs the SRE program at Google. There are a few things that he talks about that are quite specific and quite forthright about how they get what they call SRE's and SWE's, software engineers, developers working together, they do a lot of things in hiring to make sure they're hiring the same type of person and to keep the pay scales consistent. They also give the SRE's a lot of flexibility to decide what project they work on and that's good in general, but it's really good specifically in this area because the classic antagonism is that the software engineering team, the product team, pushing the software engineering team, make software go out the door that isn't stable or isn't well put together enough to be something you can deal with in production. Either it breaks and it has bugs or it's just not well-instrumented and it's hard to understand if it's working properly or not and it's easy to make a mistake for instance deploying it. Those are things that are a real bummer for the SRE or the Ops person and so, how do you mitigate that when teams are trying to move fast. There's a lot of great texture in an interview about how they do it, but it's essentially about SRE being a function to make the job of the SWE easier and the fact that if things don't go well, it does escalate back up to the development team and the engineering team to deal with. So, helping SRE's keep the products stable is something that everyone has a stake in, and that's pretty important for obvious reasons. The job of Ops is being evolved through a set of serverless architectures, the approach to Infrastructure as Code and the immediacy of all this stuff through companies operating SaaS. The next few items that we're going to go through, we'll talk about the fundamentals of what exactly needs to be done in this job and how companies are approaching these things.
