 We're gonna have Seth talk to us about everything as code it's gonna be a little bit fascinating since it's kind of operates in my space So I'm excited to kind of see what Seth has to say. So you're live All right, how's everyone doing? Haven't been in like a lecture hall like this since I was in college. It's very reminiscent So my name is Seth and I'm here today to talk to you about everything as code This is a kind of non-technical talk. I'm actually not gonna show you any code Instead I'm going to talk about the importance of code So my name is Seth. I'm a developer advocate Wow, that was fast. My name is Seth. I'm a developer advocate for Google I focus on infrastructure and operations specifically in the DevOps space but what I want to talk to you here today is about Kind of a narrative or a history of how we got to where we are today. So When we think about infrastructure, maybe 15 or 20 years ago, you had one server And that one server ran one application and when I say server, I mean mainframe and it did one thing and it did one thing very well and That worked for a very long time. We had companies like IBM that dominated the market in this space But very quickly we realized that in order to be efficient. We need more than one of these And this is where we start seeing the mainframes getting smaller They start turning into what we call today as a server and we start seeing More and more use of them we're networking them together But we're probably linking them together with like a serial cable Or some physical connector not like something over a network where we have, you know Different packets exchanging and routers and all of that stuff yet It's important to note that in this world. We still have a mapping of one application to one machine So then we fast forward a little bit to Maybe about seven to ten years ago and we live in a world that looks like this. We have multiple data centers Multiple servers within those data centers, but they're still, you know one application to one machine And this is you know the architecture that a lot of enterprises were running They had data centers in different regions and different geographies so that they could target their users But they had a big problem And that problem was they bought these really expensive servers with a lot of memory and a lot of CPU and they could only run One or two applications on them and the reason for that was that the applications had different requirements different dependencies And it was really difficult to get those on the same machine and then we start seeing companies like Zen and Hypervisors come along and all of a sudden we revolutionize the industry So instead of having one application per server we can now Segregate at the operating system level using hypervisors, and this is where virtual machines start to become popular Additionally virtual machines give us this first concept of a disposable artifact We can build this entire virtual machine with our application and all of its dependencies and deploy it We can use it for testing we can quickly spin them up and tear them down And I'd use the word quickly ironically because you know during this time Quick was like four to five weeks, and I'll talk about the cycle in a second And today we live in a world that looks a little bit like this where we have some VMs some containers some containers running on VMs some apps that run in bare metal and Additionally, we've introduced more complexity in the system So instead of having these servers that are connected by a serial cable. We're running over hardware routers and switches that we may or may not own and we might be going over a public internet Whether that's encrypted or non-encrypted to connect all of these data pieces together And then when we think about kind of a modern application, what does what does a cloud native or or today's application look like? We have things like DNS we have things like CDN databases object storage These are all things that today are often offered as a service. So like Google has an object storage Amazon has an object storage right Google has something like cloud sequel, which is a fully managed database service for you You have third-party CDNs like Akamai and cloud front that are doing CDN management And then you have you know third-party DNS, which also like cloud front and Akamai Or we could be using something like Google DNS and these are all third-party API It's things that used to be managed internally are now an API and this proliferation of As a service so platform as a service software as a service functions as a service Have led us into this world where? You you probably have a very complex setup Especially if you've been around the block a while so a large enterprise or any company that's existed for 10 to 20 years probably has Everything here they have some things that are running in-house. They have what I like to refer to as the closet cloud Which is that one server that runs somewhere that one person manages and you never touch it They probably have some mix of VMware and OpenStack and public cloud and hybrid cloud and it's a very complex world So we have to ask ourselves Like why Why did we get here and Where are we going? But what's important to note is that this world with this hybrid mix of containers and VMs and Everything as a service requires some sort of tooling to manage this complexity Back in the day with one server you could have one operations person who would put their hands on the keyboard and run commands And now we're in a world where one person can't manage infrastructure without the aid of tooling and automation It's just not possible to click buttons in a GUI or run terminal commands. We need a higher level Framework for describing these dependencies Well, let's go back in time again because I like history lessons. How many people here know what the APID cycle is? You shouldn't because I made it up So if you raised your hand you were lying So the APID cycle is a real thing though and it stands for These four words acquire provision update and destroy and it refers to the life cycle of a machine so let's go back 15 or 20 years again and When you worked in a data center the amount of time to acquire additional compute whether that was to deploy a new application or Generate new capacity was done by a vendor you typically called up Sun or IBM or Dell and you said hey, I need some new mainframes. Hey, I need some new servers and That process went through a purchase order and there was approvals and it took a very long time Once you got those servers they arrived in a nice shiny cardboard box and your data center operations team had to unpack those Machines and put them into to racks. They had to connect the networking cables in the serial cables They had to do the initial bootstrapping the initial provisioning of these systems And then over time the sys admins or the systems administrators would be responsible for keeping that server up to date Doing the OS level patching deploying new application versions Monitoring logging alerting responding to pages in the middle of the night and Eventually towards the end of the server's life cycle the data center operations team would be responsible for decommissioning it That might be you know decommissioning it wiping it and doing a fresh install to put it somewhere else or it might be throwing it in the trash and recycling it and this is an important discussion because in The early days these were incredibly expensive processes the the process of going to a vendor Negotiating a purchase order shipping unboxing was weeks So right now if you were you know in in 1990 and you said oh I need more compute You would have to wait weeks to get that more compute Weeks is a subset of months Yeah, it's a multi-week and the data center operations team would often take days if not weeks to unbox those servers and put them in racks and connect them depending on their backlog in the amount of caffeine that they had and This was a very time-consuming process and then the update operation again This is where Jira became the enemy that update operation would take days or weeks for that ticket to sit in the queue Just so you could get Apache updated and this is why for a while operators and developers were against golden images because it took so long to get a golden operating system image updated because of this process and Then lastly the amount of time it took to decommission a server was also days So if you were waiting for a new server to be racked it could actually take six to twelve months So if today This is ironic if today in 1990 you picked up the phone and said give me a new server It could be 1991 until you got that server the cloud changed all of that And I'm doing this backwards because the middle part changed as well But I'm going to talk about the cloud first so the cloud took that acquisition phase that a in the APA cycle from weeks to minutes If not seconds from my phone right now on the Google cloud app I can provision more compute than existed in 1990 And I can do that with one API call and it'll take maybe five minutes to get a server that large for a smaller instance You can get it in two to three seconds That's how fast compute as our fingertips now and at the same time I can use that for my like burst workflow processing I need to do some crazy machine learning and train my Monte Carlo simulations for my bank I can do that. I can pay just for the compute I need and I can delete it in seconds So the cloud completely revolutionized the a and the d of the APA cycle It took the amount of time that we needed to provision a system from weeks or months down to minutes and seconds So what happened in the middle well the middle actually happened before the outer we actually saw configuration management happened before massive cloud adoption But config management took the process of initially provisioning these servers Down from days to minutes and the process of provisioning updates incremental updates from minutes to seconds For days days to seconds So you're using tools like chef puppet ansible or salt you can immediately push out a change to your entire fleet of servers And it's propagated, you know within the hour and this was something that was incredibly unique So we look at where we've come from say, you know the 80s and 90s to now is we have these amazing tools We have cloud providers that give us compute at the snap of our finger We have tools like configuration management that let us provision these systems We have tools like terraform that can manage the complexity of linking all of these applications together We have tools like kubernetes and docker that let us break things down and containerize applications and then schedule them at a large scale So we have to ask ourselves How did we get here? There are so many things This is a word cloud of like the top 100 dev ops blog posts that I found There's actually the word buzzword in there So just to point out some irony There's so much complexity that we we truly have to ask ourselves like how on I miss my mean how did we get here and I don't know about any of you, but Very frequently in my career. I've had this feeling where I'm looking at a system Whether it's an application or infrastructure, and I'm just thinking to myself. This is so unnecessarily complex Sometimes it's reading like hello fresh instructions, and sometimes it's infrastructure, but The point is that at all stages in this journey mistakes have been made and There's a number of places where we can place blame we could blame the cloud providers The cloud providers gave us every API that you could possibly ever want out of the box And it's our responsibility to pick the ones we need That's like This analogy is going to break down because I'm in Singapore. That's like driving a car But in order to go to a car dealership you have to understand how the engine the transmission the car windows the key locks and every aspect Of the car works before you can set foot behind the wheel It's like going into a restaurant and understanding where the lettuce was grown so that you can put it on your sandwich Configuration management also introduced these complexities We have whole new frameworks like puppet and chef invented a new way to describe a system And tools like ansible and salt have pushed that even further We have tools like terraform that invent a whole new way to describe infrastructure and the dependencies We have tools like vault that event a whole new way to describe security and policy and Sometimes it's easy to forget that at the end of the day We did this so that we could move fast and not break things or break few things and Because of that we need a strategy for managing this complexity There is so much complexity in our lives regardless of whether you're a developer or an operator or an AI engineer or a janitor there's so much complexity that we need a strategy for managing that complexity and It turns out that that strategy is code At least this is my theory and this is what I'm going to convince you over the the next few minutes is that that strategy is code That code is the ultimate tool for managing complexity So there's this word that I say a lot which is codify or codify It's a verb in English And it it's this idea of capturing a process routine or algorithm in a text format So if I say hey go codify that I quite literally mean write it down in a programming language or a format that is parsable codification may be declarative or imperative in other words it might describe my desired state or It may describe the series of steps. I should take in an order meaning it could be algorithmic or It can be graph-based. I could say this is what I want things to look like I don't care how you make that happen or it can be here's a series of steps that I want you to take in this exact order and There's a lot of precedence For code as a strategy for managing complexity So to help manage the complexity of managing a single system one server one node We have configuration management Tools like chef puppet ansible and salt enable us to codify a machine's definition in Something like a Ruby script or a puppet module or an ansible playbook or whatever salt calls their things and These tools introduce complexity, but they also reduce the complexity for managing a system Particularly whenever that system Could be windows or Linux or you know red hat or sent us or a bun to we need an abstraction that Abstraction reduces complexity in one area while introducing complexity in another area on the container space We have tools like docker and rocket and the OCI which are designed to reduce the complexity of an application's dependencies Applications that are not single static binaries require runtime dependencies like Ruby and Python have dependencies on the system and one of the challenges with Shipping those applications was that your target system had to have those same dependencies of the same versions and Containers change that they reduce the complexity that we needed to actually Deploy applications the codification of that was the docker file and similar specifications a single text format That allowed us to define the steps to take to prepare our system or our container to receive our application So the docker file is the codification and then docker the docker engine is the automation that Consumes that codification and produces an artifact Infrastructure is code or IAC Helps manage the complexity of the modern infrastructure We have tools like terraform and deployment manager and cloud formation that exist Solely to map the complexity of all of these cloud resources Particularly in hybrid environments where we're using third-party DNS and you know multiple cloud providers Simultaneously using different components of each of those providers together in a homogenous environment So a tool like terraform has configuration and those configuration files are the codification They are the code and then terraform is the tool that consumes that code and produces something meaningful produces infrastructure So you can start to see this strategy that I'm not telling you something new that code has always been the answer We have complexity with continuous integration servers How do you configure your ci there's so many different ways and so many different ci servers? And that's why we have the Jenkins file and the Travis YAML which are code YAML is kind of code But these are these are ways to express complex ideas and dependencies and configurations And then we have the tools like in this case Jenkins and Travis or circle which are going to consume Those configuration files and perform the necessary operations When it comes to security and policy complexity, we have things like api's and policy files which allow us to define the complexity of our system and and codify those policies and security procedures in the forms of api's and Then vault or other tools that do security are the enforcers of those codes And then we have operation complexity Where we have tools like, you know Kubernetes and Docker storm and nomad and mesos and mesosphere that are designed to reduce the complexity of operations Not running containers because that's one bit of it But it's this idea that managing a system is hard and that there is inherently going to be failure So we need schedulers and orchestrators to be able to move our applications around and handle downtime and failure So that less humans are involved in the process The codification here is your yaml your kubernetes spec or your your hcl for your nomad spec And then the tool itself is the automation. It consumes that codified file So there clearly exists this well-defined pattern for many many years that code is the answer That putting things as code is the logical solution for managing complexity but why It clearly happened I just showed you through all of these examples through the past 20 and 30 years that time and time again Engineers have chosen code as the answer, but why? And it's actually very simple. So I'm going to break it down here in the next 10 minutes. The first is linting When we have something that we have to click buttons and move things around or multiple people are involved We can't process that we can't throw a computer and say hey Does this look right to you? But the moment we capture something as code or even just as text we can lint it if you have a resume or Curriculum vitae and you just write it out on a piece of paper You can't do much with that, but if you put it in something like Microsoft Word or a Google doc you could do spell check That's codification Spell check is a form of a linter similarly to like a grammar check if we have a tool something like Go for example a programming language when we write something and go there's a built-in linter that we can ask Hey, am I doing this right and this gives us consistency it enforces consistency within our organization within the programming language And it can help find bugs So this is the first advantage of capturing something as code when we put it in a text file We can build things on top of it. We can parse it. We can use static analysis, etc The next logical step from testing is linting linting is just a subset of testing We can actually automate these tests. We capture something as code We know we have the automation framework on top of it so that we can test it and we get to test things that were previously untestable So whenever you have to provision infrastructure by clicking buttons, you can't really test that Or if you do test it, it's a very manual process the moment we capture that as code Not only can we lint the code we can do unit testing on the code But we can automate the provisioning of that code so that we can run tests on the other end So when we capture something as code we test the untestable or difficult to test One of the most important benefits is collaboration When we have something that is a manual process, it's very challenging to collaborate on that process once we capture that as code we can treat our Whatever we're codifying our infrastructure is code our configuration management the same way we treat application code We can put it in github or git lab. We can treat it as source We can do pull requests into peer reviews. We can have a full version of history So the same way that we treat applications we can now treat whatever we capture as code So change requests we can do the you know in github the automatic PR where we say this will pass or this will fail We get that by capturing things as code We effectively get CI CD For things that weren't previously possible another advantage For capturing things as code is for the separation of concerns. So on one hand we have collaboration Code enables collaboration, but at the same time it allows us to separate concerns I might have my networking team only work in the files that concern networking and they own that domain And then I might have my security team only interact with the files the code the concerns security and Codification enables this when we have manual processes or things that are not captured in a repeatable manner We can't separate concerns. Everyone's reaching into the same cookie jar code allows us to model abstract concepts When we start thinking about multi-dimensional dependencies where we have you know three and four dimensional graphs code allows us to model those dependencies and then produce Visualizations that we as humans can understand using things like D3 or graphics so when we start modeling complex things like policy in a system or network flow or Dependencies within infrastructure at this server depends on this server because this IP address needs to go into this function That is hard for a human to visualize in a two-dimensional format But once we put it in a three-dimensional format or a time series graph We can actually analyze it and we can model these abstract concepts and by modeling them We can actually make better decisions about our system I'm sure you can all think of a time whenever you've looked at a blob of data And you're like well that's some data and then you throw it into a graph or a chart and all of a sudden You see the pattern you see the anomaly you see the the regression or The trend line and lastly and probably most importantly is theft Codification gives us theft It gives us everything you already have for your applications For whatever you're codifying So it's likely that you already have some CI CD workflow for your applications might be Jenkins might be circle might be Travis It doesn't matter the fact of the matter is that you have an existing workflow that was designed around your applications and You should not have to reinvent the wheel to manage your system your infrastructure your security your LDAP your anything you shouldn't have another workflow Instead you should be able to capture whatever you're trying to manage as code and feed that into your same processes You probably have existing Code review processes whether that's you know GitHub or Garrett or you know get lab You have something that will help you review code as a team You shouldn't have to invent a new thing just so that you can use a new tool and code is the common language so You can think of code is is this unambiguous Description of something and it can be written in any language This is gonna be confusing for a second. It can be written in any language, but it lets us speak the same language So it doesn't matter that you're writing in Ruby or Python or HCL or you know puppet What matters is that you're capturing something as text. You're codifying this concept and by doing that We now are speaking the same language Which is automation and codification? That's all I have to say on that. I have this mandatory slide that I have to show all of you If you work for a startup or you think you work for a startup Google cloud is giving you $3,000 in credit You should take a picture of this slide one because it's pretty and two because it has this nice little URL That includes a form you fill out. It's a very short form. I promise it's one page fill it out and Then you'll get some credits. I'll leave this up for a few seconds and that's all I have for you I think we have some time for questions Do we have time for questions? We have time for questions. Thank you very much any questions. I Have floored your minds. You have no questions. I think everyone enjoyed the check You can ask me other questions. Well, if not Thank you Seth and it's good to have you so thank you again. Well, thank you everyone