Everyone, my name is Michael Zion. I'm the co founder and CTO at Meteorops. We are a DevOps services company, and I'm here to talk to you today about DevOps course, but more specifically, a handbook that I created for ctos mostly, but actually it's for anyone that wants to understand, in simple words, what's DevOps and wants CTO get simple principles in order to make decisions easily. And hopefully by the end of this talk, you'll have a bunch of principles that are useful with some examples of what you should be doing and when. And, yeah, let's jump right into it. So maybe you are a CTO, maybe you're a DevOps engineer, maybe you're VPR and D in your company. Either way, this handbook is useful. Hopefully it's useful for you. Okay, so the goals, it's mostly to understand what's DevOps in simple words. And why am I saying in simple words? Because for some reason, with every role in the R D organization, if you ask someone what this role is and someone gives you a definition, no problem. But with DevOps, try telling someone what DevOps is. Somehow it's controversial. People will tell you, no, it's something else. Every company whats its own philosophy. So I'm aiming to give you a very simple, very common definition and practical one as well. I want to tell you what's possible. So many founders don't know what to expect from DevOps. They don't know. Okay, so I heard about this thing called DevOps. I heard it should help me do this and that, but what should I expect from it? So, what's possible? And I'll provide you with some simple examples. And the final thing is when to do what. This is the principles part. This is the part where I give you some use cases, and you can take those use cases and apply those scenarios in your company. I don't have everything from the handbook in this talk, so I do have a link. At the end of the stock, you can scan the QR and go to the full handbook. And, yeah, let's jump right into it. So, first part, understand the desired result. So, as a software company, you have two goals. One is to serve your product to your customers, of course. And the second goal is in order to do the first one, you want to be able to build and improve your system all the time. Okay, so what do you need in order to be able to build and improve your system? So, in essence, run experiments and test changes. When it comes to software engineering, it's computer science, right? There's a reference from a lecture of Uncle Bob. It's the clean code guy. He said he was talking about Dixta. Diexta is one of the founding fathers of computer science. And he thought programming is going to be a mathematical discipline. He thought people will, programmers will write functions, mathematically prove them, and then we'll have sort of a library of mathematically proven functions which will be used to build more and more elaborate functions. Of course that's not the case. We don't mathematically prove functions, we test them. We treat it as a science, not as a mathematical discipline. So we do something and then we test if it works, and if it does, that's good. So second thing is, DevOps has a simple meaning. And I know some people won't agree with this definition, but I'm using this definition because I find it useful. Or for so many companys that adopted this definition, just found it easier to go forward with DevOps. So the idea is this, originally it's a culture, originally somewhere in 2008. Whats just about the idea that developers and operators should work together in practice today the definition is developers operate system. And I'll say what it means in a sec, you already see it on the screen of course. And DevOps engineers enable developers to operate the system and to some extent operate the system themselves. So when I say operate I mean provision. So provision is creating infrastructure, resources, et cetera, test, course, deploy. This means we did something, we want to push it into the system. So introducing changes, monitor. So this means seeing the state of the system, getting alerts for it, et cetera, secure. So this means limiting the network access to the system, limiting access using authentication and authorization, limiting and preventing any potential issues, vulnerabilities, et cetera. So next thing is configure. So configure is just a way to sort of modify configurations in your system. This could mean changing configuration in git, could mean changing configuration in a database or in any KV store, something of that sort and scale up and down, scale the system up and down based on the demand. So taking all of that, I think some people might already look at this slide and say this guy is delusional, developers should do all of that. So I'm saying yes to some extent, and the DevOps engineers should do the rest. To some extent. When I say the rest, I mean both developers and DevOps engineers have responsibility over operating the system. And every company chooses the balance between how much the developers should do it, how much the DevOps engineers should do it. From this slide, the key thing I want you to take is this words enable. So the main function of a DevOps engineer is to enable to operate, okay? So if you had to take one thing from this slide. So now choose a balance. We said in the previous slide, developers operate the system. DevOps engineers enable developers to operate the system and operate some of it themselves. And operate some of it themselves. How much do they operate it? This is choose the balance. So when I say choose a balance, there are three things within this balance that you can tweak. So you can, as a DevOps engineer, like the DevOps engineer in your company, can choose how much they enable, how much they do, how much they automate. Okay? There's overlap between these things. So enabler, an enabler provides tools and knowledge, okay, so a tool could be ready made, community built tool could be a tool that some company built and sells. It could be a script that you built, any abstraction that exists. And knowledge, of course, it's the knowledge for how to achieve something. So that's enabler, Doer does the tasks, of course that's the most time consuming for the DevOps engineer and the least scalable way of doing things because it's completely relying on the available capacity of the DevOps engineer in the moment. Okay, automator. So automating any repeating tasks. So this means you're taking some of the stuff that you did and you automate it. This is before enabling it for someone else, meaning maybe you, let's take the example. So a developer asks for DB, an enabler gives them a script or some tool to create the database. The doer just creates the database, goes into the UI, clicks some stuff and gets the database. The automator will maybe create a script, but give it to the developer or sorry, no, the automator will create a script and use it himself. So that's one step before the enablement. Okay, so one principle here is tools have bigger leverage, better leverage than knowledge, and enable has much more leverage than doing so. If I want you to take one thing from here is this line, because that's the guidelines principle for your decision making. And every company has it differently. Meaning I saw companies whats just decided to give developers full freedom and make sure part of the onboarding process is them learning some tools. So they went completely with knowledge. I saw some companies that the DevOps engineer abstracted away everything. The developers don't need to know anything about it. And that's another discussion. The next thing is choose the right tools. So when I say choose the right tools, this one is so important, it's about tackling common use cases using solutions that were already built to tackle those use cases. And I found there to be three things that are the biggest time savers. One is that the tool whats native state management built inside, like terraform does, like Kubernetes does, like Pulumi does. So just to name a few examples of tools with state management. And why is it such a time saver? Because when you operate a system, as its complexity grows, understand what the current state is, is crucial in order to introduce any change. Because if you don't know if something exists or not, it's very difficult to make any change to the system. We know that with Git, for example, git is a perfect example, right? You want developers to collaborate, they have to agree on what the source of truth is. They have to agree on what the truth is. That's the entire idea of continuous integration. Again, another conversation. But in order to collaborate, in order to introduce changes, you need to understand the state. Managing the state of the system is not trivial. If you don't have native state management, you'll have to implement it yourself. Second thing, it has a big community and good docs. Why is that important? Because when you stumble upon any issue, if there isn't a community there that you can get their assistant, their assistance, and if you have no good documentation of the issues, so you'll find yourself solving problems, that you'll have to solve them yourself. So the more common a tool is, the more popular a tool is, the more likely you are to have solutions or common problems somewhere. Okay, so that's the idea. Saves time. Debugging stuff. Whats multiple interface types? API cliui why is that? This is because when you use a tool, it's not the only thing you use. Probably, you're probably using other tools as well. You might use some scripts to glue stuff, you might write service cto glue stuff, you might do all sorts of things. And having a native interface that you don't have to hack around in order to understand how it works and integrate it in non native ways. So having official APIs or having an official CLI, having a UI, having all of those interfaces, makes it easy to integrate the different parts of the system, which is something you are most likely going to do. So as multiple interfaces. So these are the biggest time servers. Okay, so next up is set useful goals. What do I mean by set useful goals? I mean you want to do DevOps. And of course we gave some abstract definitions, we gave some practical definitions we discussed some very practical things, right. But now what should your goal be? There are some goals that are derived from the previous things we discussed, and I'm not going to cover all of these, but let's take two examples. So one click environments. So earlier we said software engineering is a science discipline, it's a scientific discipline, meaning in order to understand if your system works or if it works as expected, you perform a test, you run an experiment. So one click environment is something that says, it's a goal that says let's be able to, we want the ability to create an entire environment of the system with one click, run, keypress, you name it. So in some companies it could be Jenkins pipeline that creates everything, in other companies, something else, maybe a script that someone is able to run. The idea is I want an entire environment in order to run an experiment in order to introduce a change to the system. Okay, so another goal, let's take this example. So split shared and end specific resources deployment. What does that mean? So as your company scales up, let's say you want to run an end to end test on every pull request. So when your company scales up, this becomes difficult. Why does it become difficult? Because deploying an entire environment is one, it costs a lot as your company scales, of course. And two, it might take a lot of time. So let's say if you create a database, every time you deploy a new environment, this one click environment. So this takes time, it takes budget. So the idea here is let's split the shared resources. What could the shared resources be? Database, the network. Let's say everything is running on Kubernetes cluster. So the Kubernetes cluster and the NF specific resources. So what's the NF specific resources? That's the application. Maybe a migration that you can run in order to create a new database within your database instance. So the idea here is when you deploy a new environment, you only deploy the end specific resources, the shared just underlying infrastructure that stays there, you deploy on top of it. So just to name a few. So atomic commits and automating local dev to production. I can elaborate on that. I'm not going to do it now, just save you some time. But feel free to reach out and ask me about it. What does it mean? I'll be available Twitter, LinkedIn discord. So I'll be happy to answer any questions about that. So let's do some examples. So when to do what? So when you walk alone and the system is simple, so you should simplify development. So dockerizing your application doing some post commit test. The idea is don't complicate things, just keep it simple and make it easier for you to work and introduce changes into the system. And yeah, I see many founders this stage writing telephone code and wondering why. Maybe in some cases it's justified, but most cases not sure. So you need new ends quickly for devs, for clients. Let's say you have a new client, they want a new environment. If you are b two b startups startup, maybe it's a hospital and they want it on their own cloud account for compliance reasons or whatever. Or maybe it's for developers, they want to test changes separately. So this is probably when you want to implement a one click environment. When you have this demand from developers and clients, end to end tests become hard. There are many code changes. So let's say you used to create an entire environment on pull request and run an end to end test, and now it hurts. Now you have, let's say 30 open pull requests at any given moment. So if you deploy a Kubernetes cluster per pull request, of course that's very expensive, very painful, very slow. So split your one click environment into shared and specific resources. So that's the example I gave earlier. Now your system's complexity increases and you need to standardize how you operate it. Have a typo. So that's probably when I would say implement an orchestrator, just something that's very useful to standardize different processes. With something like kubernetes, there are more when to do what use cases, and it's all in the full handbook. Again, you'll have a QR at the end of the presentation. You can go into the handbook and see everything there. And again, feel free to ask me anything. So regarding that part, of course that's not necessarily the case, but I'm just oversimplifying it to sort of get the point across. Let's do a quick recap. So this is the full CTO DevOps handbook. You can scan the QR and get to the original blog post to do a quick recap. Devs operate. DevOps enable and operate. You have to choose a balance. The balance is between an enabler, a doer, and an automator. I had a nice phrase that sort of encapsulates this balance. The phrase goes like this. It's called other phrase, it's a term, it's called automation. Automation is sort of choosing the balance between these three goals are leveraged, use them wisely. Tools can be a huge time saver. They can also slow down your operation to such an extent where it's detrimental for it. Set useful goals. So if you want to be able to words, you have to have goals to work towards when it comes CTO DevOps there are very useful goals that you can set and that of course, they depend on your roadmap, your company's requirements and so on. So set useful goals. We mentioned the one click environment, the splitting, shared and specific resources. And the last thing is, know when to do what. Again, there are some more examples over the handbook. I think that's it. If you want to ask me anything, you can go over Twitter. That's my handle. Feel free to follow and send me a message. And you can also use this QR code to reach out to me on LinkedIn. Just say something that starts with, I was over your talk, I have a question or I have a note. I know that you came from here and. Yeah, I guess that's it. It was a pleasure giving this talk. I hope I didn't miss out on anything important. And yeah, looking forward to hearing from you guys. Cheers.