#23 - The "Dev" in DevOps

This week we discussed whether "ops" engineers should know how to code, and if so, to what degree. We went into languages, frameworks, when and if should you start as a junior. We shared our views on everything around "Dev" as it relates to "Ops" when it comes to actual positions within a software company.

Things mentioned:

• The Grand Budapest Hotel
• https://github.com/spf13/cobra
• https://github.com/spf13/viper
• https://click.palletsprojects.com/en/8.1.x/ 

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

Transcript

Copy Transcript Copied

0:00

Well, Mayor, are you ready? Mayor, are you ready? I am ready. And action. Action. Action. That is applied. Action. Okay. So, hello everyone. No. And welcome to the DevOps topics session, our 2020 12 session. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. We are going to talk. As Omar said a minute ago, when you weren't there, he said the dev in DevOps, which stands for like the development paths in DevOps, or maybe programming, or anything that is related to the dev in DevOps. So only, I mean, tricked, thank you for coming today. Thank you. As we always do, what is the first thing that comes up to your mind when I say the dev in DevOps I want to like, I want to give you a very short answer, and that's it. And close the closed session and go eat lunch. Make sure my very short answer is just go. And that's it, period. Bye bye. Thank you for coming to my TED talk. But I don't know. For people who are not familiar, you need to say go long. When you say go, it sounds like just go. I actually just read the debate yesterday whether you should call it go longer enough. In any case, what I was saying is, let's talk about the dev part in DevOps, right? Because DevOps is what we've used to call a fusion of development in ops, right? The ops is what we both know being able to develop infrastructure, build things, take them up, maybe plan them accordingly, or you can fancy your name is architecture, et cetera, et cetera, et cetera. That's the part of ops. What today, what we call DevOps is actually the ops part of everything. There's also a big part that's called dev in DevOps. Dev is being able to create an application, write some code, I mean, the entire idea behind DevOps is fusing, sorry, operations and being able to deliver an application, literal code that someone writes. That's not always the programmers, as in something we don't know that does things. I think I believe, well, not only me, DevOps should have been a methodology, not a title or a job title for someone. So there's ops engineers and development engineers, and I think today, in the modern days, when you have DevOps engineers, while this wasn't the purpose of the thing, they should know both worlds, operations and development, and for that, I think you should know a programming language. And I'm not going yet into which one, but I do think you need to know how to code or how to deliver something. It doesn't have to be a full-fledged application, you should start from knowing how to read and write code. And one comment about that, and you can tell me what you think. Not bash. When I'm saying not bash, I don't mean don't know bash, bash is extremely important. You should be fluent in bash. I'm just saying something beyond that, bash is nice. It is a programming language, but it's more of a scripting language for Linux. Can you give me maybe an example of when or why can a DevOps engineer can develop a very small part of code, and then upload it to the cloud and then run it? Can you give me a quick example of like, as DevOps engineers, when do we find ourselves writing code, maybe to invoke something very, very small as a DevOps engineer? When do you do that? Let's start from very easy examples and straightforward, which we probably have all encountered and then go to a bit more complex stuff. Easiest thing I think we can both think of is creating steps in a CI pipeline, right? So hopefully you're not using Jenkins, but if you are, you are writing some kind of groovy to create a groovy code to create your plugin or bash script, even Python and other languages that can be compiled into this step, but essentially you are creating some kind of logic that can be a deployment of application, maybe building, testing, checking secrets, collecting parameters, it can be all sorts of stuff that you are required to create logic around. I don't know why. If you are working in this field, at least a few months, you probably know that. So that's an easy solution. Another pretty straightforward example is when you create containers, sometimes you need to wrap the application that runs there, right? When you start a container, there's an application process that starts, and it does something. Maybe you want to create a wrapper around that to do something before the application starts, maybe start another process, maybe fetch secrets from a secrets manager, fetch environment variables, maybe you want to query some kind of a health system that can tell you whether the process can run or not, et cetera, et cetera. These are very simple examples, and I have a more complex one, which is why I started by saying go, do you know what platform everyone are using? It has eight, in its name, it starts with a K, and ends with an S. Do you have any idea what I'm talking about? Kubernetes. Kubernetes? Kubernetes. Yes, so Kubernetes. Not only it's written in Go. I don't know if you know, I mean, I think most of the obscen engineers don't go as far as creating controllers and what we call operators in Kubernetes. I think we have discussed that in the past. Basically, I'll keep it short because we're not discussing Kubernetes today, but Kubernetes is a built of many, many controllers that are viewing events in the system. For example, trying to create a pod, there's a controller that in charge of reading what I've requested from the cluster and needs to implement or apply what I've just created the pod, run the container, apply things around it, networking, security, blah, blah, blah. What ops engineers can do is create their own controllers. For example, you need to deploy something to the cluster. In the past, people used to wrap that with CI processes, like I mentioned in the beginning, create some kind of a script that does thing maybe with QBCTL or something like that. And then today, again, modern edges, someone developed an operator based on that. For example, Argo CD, which is exactly an operator that sits within the container and does DevOps stuff, right? It's basically doing CD, the CD part of deployment. And that's not the only one. There are tons of operators just like that. So what I'm saying is, if you, as a DevOps engineer, air quotes are trying to do something within the cluster, that may very well be a good use case for implementing your own controller within the cluster, installing it there, and having that run your logic inside. We can go into that later. It's a bit more complex. It requires you to understand deeper development knowledge. Let's call it. You do need to be able to read and write go and develop some kind of code. There are help for helping frameworks around that. But that's just a more complex example. Do you have any more? Any more? I'm okay. So if I'm a startup, let's say I'm a newbie, right? I'm not familiar. Well, I'm a new DevOps engineer. I'm a junior. Now, I'm wondering, should I learn go, should I? Do you think, is it a good accommodation to tell you DevOps engineers, guys, you should go, guys, girls, you should go and learn go, go along, or is it an oval keel or maybe don't learn it until you need it? Like, why would you say about this language? Is this something that people need? Like, DevOps engineers need in their tool set? So these are a few questions. So your last questions, whether DevOps engineers need go in their tool belt, I can confidently say yes. But with, you know, we always like to say it depends. It depends a lot. At the end of the day, you said tool belt. I'm thinking of Batman now. You dropped me to Batman. I said tool set. You said tool belt. I'm like, okay, Batman throws his, you know, a keyboard and a knife. Yeah. So yes, okay. Again, again, saying, third time modern ages, since we're in modern times within DevOps, if you are working around the cloud, I'm pretty sure that you are using tools that are written in go. For example, Kubernetes, Docker, Argocyd, kind of part of Kubernetes, most see a lies you can think of. It's all written most of it is written in go. Okay. So that's why it depends. If you're not working with Kubernetes and Docker and you're working with a completely different architecture, so maybe it doesn't matter all that much. But many, many, many systems around that, even for example, the CI server, we both like drone and harnesses products are written in go. I found myself being able to either extend drone at the point in time or understand what's happening in the system. So while you don't have to write the code, if you know how to read it, it can help you a lot. You can read literally read Kubernetes code. If you are dealing with Kubernetes and working with Argo, you can read Argo code. If you are running a server, see I server, that's just going to be more standard. Also terraform, by the way, all of HashiCorp solution, terraform, vault, packer, whatever else. No matter. No matter. It's endless. And it's all written in go. So if you are using it and it's one of the major platforms you have in your day-to-day work, I mean, knowing go can help you a lot. Now, the second question you asked me is whether you should, you're a junior DevOps engineer and you just starting out, should you know that. It's a complicated answer. Let's say that we passed the test of, it depends. And it's no longer, it depends because yes, you have go tools in your, in your workplace. That's what you, you run on Kubernetes with Docker, et cetera. I think, after you, you are confident with bash and you control that and you can write scripts, you don't have to jump in to go. You could use something like Python, which you probably want to speak about a little bit more in a second. I just want to say about go sometimes it feels like a lot more than it actually is. It's not a hard language to pick up as opposed to things like C or Rust, surely C++ and it's friends. It's relatively easy to pick up and start working with. However, if you don't know programming languages at all, maybe take on Python. Again, you be quick this language that you can find everywhere. Most containers, most operating systems you will start with. You will have Python installed and you can run with that. Almost any CI server has a plugin for you to write Python logic into it. Another great topic. I have something. For me, I have a rule of thumb like when to use Python, when to use go learn. I wonder if you have the same. I would even like to start with you because I know my idea in my head, just wondering, do you have a cutoff? What do you say this one should be written in Python? This one should be written in go learn or you say on everything. This one should be written in go learn. Do you have any cutoff point where you say I think I should write it in Python or go learn? No. I usually like to say use the right tool for the job since I'm using writing so much go learn code site project in my day-to-day work. I'm using it for everything nowadays. Just because it's even easier for me. Getting started is nothing. It's like another language I'm using day-to-day. It's easy. I know the libraries, I know the frameworks. Obviously, I'm very familiar with the syntax, error management, etcetera, etcetera. It's my go-to. What's your cutoff? Okay, so I like to think of Python as if I need quick enveloping thing to do and it doesn't have to be super efficient when it comes to speed. So anything that is not customer facing and anything that needs to run like to be written very fast and easily fasted because it's like it's a run time language. We don't need to build Python to run it. Go needs to be built. You need to compile it. You're making a lot of listen. There's very angry right now. Why is that? Just because Python is a full-fledged language that can support huge backends in large scales, I can be the first, you know, the go supporter is that we'll say go is better. It's better. We're talking about DevOps engineers. We're talking about scripts, small applications, small automations. So sometimes I don't need to have a fully blown application. I just want to write maybe a short script, a lambda function or anything like that, you know. Yeah, I get it. So for that, I go with Python and especially if I have maybe an unstructured model. So if I need to read a JSON file or any unstructured model that I'm not familiar with its structure before reading it, so usually I would go with Python and not with Go, because with Go, I need to do it like it's a typed language, right? You need to type in structures and everything. So with Python, everything can be maybe quick and dirty. You can just iterate over the stuff, like a intelligent, maybe a while loop, follow, read it, analyze it, and do it, you know. Let me give you, for me, Python is quick and dirty with unstructured language and go long is when I need performance. I want to give you the 180 degrees opposite opinion on that. What he said about you having not having types in a language. Well, Python, yeah, it doesn't force you to use types. The fact that go at the beginning when I just started with Go, I thought exactly like you and I said, damn, that is so hard. I'm fetching. Let's talk about what we normally do, fetch things from a cloud provider like AWS and I was fetching this long JSON that I didn't know even know that I had a structure and I was trying to do stuff with it. With Python, not even talking about Bash that you can just grip stuff or use JQ. With Python, I was starting to just look for the string and then from that turn to a special array with that string, try to extract something out. That is a source for every error you can think of in the world as opposed to running with Go. For example, AWS, same example, if you're using the Go SDK, everything, you have a documentation of the entire set of types of return methods, how a method, I mean, how a function work, its signature, what it accepts, what it returns, the exact types on Amazon, you have the types and the structure, you can understand every bit and every field that you need to either return or accept. And then querying because it becomes so easy. You just write the type dot something, you get a list of everything that's returned, you pick that and things can never break. Never with obviously a caveat, there are handlers for null return types and stuff like that, but it's so much safer than running with just a little type. Yeah, I was trying to be, I was trying to be, you know, communicate with everyone, not just with Go. So that's my point here. Okay, and then still, if you say, okay, so if you, let's take a lambda function, that needs to send maybe a slack message, doesn't have to communicate with AWS SDK. So I need a lambda function that I don't know, maybe it's a webhook or something that can receive an event from AWS API gateway or something like that, and then send a slack message. So for you, you're seeing it would be faster for you to hide it in Go. And in my eyes, it will be faster to do with Python, because it's quick and delty, it doesn't have to be complicated, doesn't have too much logic in it, usually, you know, because it's smaller application, but you will go with Go. Yeah, so that's what we're going to say. There's a huge part of making decisions, both in languages and technology is what you're comfortable with is another factor here, because sometimes time to market and the ability to deliver comes in and plays a huge role. If that's something you're going to write that supporting production and something's burning, or not break burning, you're just trying to deliver an application, and it is an oxygen near your part of the info that's delivering the product, you want to go faster. So there's always this fine line between being able to deliver something fast and do it in high quality, right? I usually tend to go more with the quality stuff and be a little bit more on the slow side with being able to deliver. That's me, and that's why I like a type language that can return things in a safely manner, if you compare it to just raw Python that stuff. But you're right, I mean, in this consideration, you have to make, there's no, it's not black and white, there's not the fin, not a definitive answer to everything. Okay, so do you have maybe a good framework, because we're talking a lot about Go. Okay, so just let's do a very small dive into Go. Do you have maybe a recommendation of which framework should I use if I want to write a CLI in Go? Okay. I will give the other direction in Python. So if you want to write a very quick and short application in GoLang, you know, a quick CLI that maybe uses AWS CLI or AWS SDK, which framework would you use? Okay, I have a great answer, but let me take one little step back and say everything starts with you being able to be productive, and you being able to productive means you have the right environment to work in. Doesn't matter if it's Python or Go or Bash or Per, if you're, I don't know who you are. Use the right IDE, when I'm saying ID, I mean, again, you know me, I'm using NeoVim, everything's configured around that. You can use PyCharm, you can use IntelliJ, you can use VS Code, you can use Atom. As long as you have it configured, and using, if you're using VS Code or NeoVim, you probably want an installed LSP, which is a language server that can support your language and make your life so much easier. You get syntax highlighting, you get code awareness, the libraries are all fetched for you, and that's what I said earlier. You can turn within Go, for example, you can turn to an object, you can press dot, and that dot opens every method that object has, and every entry that that struct may have. So it's very convenient, it turns you to real productivity machine. So that's what I'm saying, just configure your ID. Moving on from there, you've asked about a framework. I think I know, since I'm working so much with Go, I have a framework for everything, yeah? Yeah? I'll give you a hint, what I meant for, it's like I want to give you a hint. That's very, very hard. So yeah, I guess that was the sound of a snake. And yeah, most, most CLIs in Go, I mean, the famous ones are written with Cobra, Cobra is a framework that makes your life very, very, very easy to run. There's another one, but I think it's called just CLI, which is also great. I'm using Cobra for most CLIs I write these days, and it just helps you with being able to write sub modules and sub commands and add flags and add environment variables, etc. Cobra has a small brother that's called, who? Viper. And Viper is a great framework by generally, by the way, for glowing applications to provide the set of configurations. So you can use environment variables or YAML configuration or JSON or anything that you choose, but you get a set of configurations that you can then provide to a container or even just to see a lie that's running locally. So I use about Cobra and Viper. How about, we're talking a lot about snakes today, but how about Python? So Python, I'm using the click framework to write a CLI, and it's super easy, super fast. And if I compare it to Viper and Cobra, you know, compelling it to the go path to go land in writing a CLI. So I think in Python, it's also very easy. Like, and the documentation is very good for click framework. So if you want to write a CLI in go land, I'd go with Cobra and Viper, like you mentioned, and Python and go with click framework, right? Like as a DevOps engineer, if you want to do something quick and dirty, those are the things that I'd go with. So can you give me maybe, I'll give an example of a program on a very small application that I wrote in Go, and I want you also give me, also give me an example, but DevOps oriented. So for me, I wanted to generate a YAML for GitHub action, because GitHub actions does not support YAML anchors. So I decided, wait, I need to convert to that, say, maybe I want to migrate from drone or any other CICD to GitHub action. And my existing YAMLs have YAML anchors, YAML anchors are the ones with ample sense and aspects for those who don't know, like you can write the references and expand and whatever, like a raise to dictionary. Please get to know them. They can be huge. They can be huge in helping you not repeating yourself. Right. So if you want to do it in GitHub actions, you can't. You need to write maybe a local action, but we're not going to speak about that. But if you want to convert a YAML with YAML anchors to maybe expand this to a regular YAML, so it will be used in GitHub actions, how would you do that? So I wrote a very, very, very simple and short and small go up and go application. Okay, when I say go application, eventually it's a binary. Okay, I call it YAML cell, you know, stands for YAML parcel. So YAML cell parcel. And it uses, and I'm glad to say what it uses, because I didn't even write anything by myself. So I'm using YQ, which is also, YQ is like, you know, JQ, but for YAML. Okay, so it knows how to read and parse YAML files. So YQ and I also used the Cobra framework to write the CLI. So it's a CLI and I also used something like a file watcher. So each time you change something in your YAML file, you save the file and boom, you see the results as an output and then it provides you a hot reload and provides you two things. First, if you want to migrate files that have YAML anchors to regular YAMLs, amazing. The other one is if you want to practice your YAML anchors to see how it goes, you know, how it how will it act, you know, because sometimes you write YAML anchors, but you're not sure how it expanded because you're new to that. So that can also help you. I think I wrote this tool. It didn't even take a day or something. It took a few hours. It was very, very, very easy because all the packages and frameworks were there. I just had to connect the dots, cheat a little bit, you know, like connect a few dots with that. Yeah, we will with that in the context. Perfect. And so that's the also. That's very interesting. I want to see that. Give me your example. Okay, I will give my example and then I have a question for you. So actually, I have to him, but it's first of all, that's my day two day work. I'm zesty. I'm developing an operator for Kubernetes. So that's very easy. You're walking at zesty? Oh, yeah. I didn't mention. Yeah. So that's that we never talked about it. Yeah, yeah. So that's the first time if you don't know me. Yeah. That's what I do. In any case, part of my day to work is writing an operator for Kubernetes specifically for a tool that I had in mind developed. It's open source by the way. And I'm looking for maintainers that kind of already forgot about it. I wrote a tool to know about, I mean, we talked about it a lot, but about SSM is ability to SSH into instances on AWS. It basically lets you create a shell. You can do it from the web browser. The cooler way is to do it from your own shell with a plugin. So you can literally from your computer SSH into a instances on AWS without an SSH key. And without them having to be in a public network, which is amazing. You can't do that with SSH. So I wanted the tool to basically help me understand what instances are connected to SSM. If they're not connected to SSM, I wanted it to be able to take over the instances. And for that, you need to do things. You need to attach a set of permissions through a roll. And then you have to reset the instance because you need to kind of wake up the agent that's hibernated on the instance. So it needs to do a lot of things. By the way, if you're sitting in a private network, I had to either create a private link or something else to help you connect to it. I wanted a set of tools and features to be able to be combined into one tool that I can then take over instances for that. So basically being able to SSH into any instance on AWS with one tool, regardless of whether it's private, it has a key. I don't care. As long as I have keys, I want to be able to attach into it. That was the tool. It's called SSMX. It's still on my open source GitHub. I kind of built it so it can be also in a library. It can be consumed by other tools. And it can be used as a CLI using cobra. That's my CLI tool. But now I want to take a step back and I want to ask you a question. We started by talking about the dev part in DevOps and whether engineers do need to know code and read, write, etc. And how far or how deep should they go? I'm assuming not all of us are huge coders or maybe that's not their passion. Maybe people are more passionate about infrastructure or security or stuff like that. I wouldn't know what's your standpoint on that. And the two questions that you asked me, what would you say to a junior developer or a junior ops engineers rather? And what would you say to someone who was more advanced but didn't go, didn't take the step into code, right? I'd say to both, you've got to learn how to code because coding means you can automate the things that you do on your day today. And just like I did with the else cell, I created an automation for my Yaman files to make my DevOps work easier. So if you know how to code, you can automate your day-to-day and create tools that will plug-ins or extensions or anything like that. It will make your life easier. So coding to me, I think, first of all, I think anyone in the world should know coding, you know, because eventually like if you want to automate stuff and have fun with it, you just need to code. Okay, for DevOps specifically, it looks like I think like in the, especially in the past two years or maybe in the last year, I really saw my Galatian of Yaman's and infrastructure and everything going from configuration files to code. So you can look at Pulumi and how it grew. You can look at how AWS CDK, you know, with Terraform CDKTF grew. So all the attention is going to code now because the industry wants developers to also be DevOps. And to tell developers now, you need to learn configuration files and Yaman files. It's difficult because everyone used to their own language. So instead, it looks like the industry is going to towards. So you won't be called the Yaman engineer. Yeah. Yeah. So we are Yaman engineers. That's just a lot to be called the Yaman engineer. Exactly. So if you want developers, you know, the developers who are currently, they're not DevOps engineers, but the developers too, or maybe even QA engineers, to be part of the DevOps thing, you know, DevOps concept, they need to know how to code and use everything. So if everyone is coding and all the DevOps stuff like Terraform and CDK SDK, whatever is also with an encode, everyone is talking the same language and it's not like you need to come to me and say, listen, I read your GitHub actions Yaman style and I didn't understand it. Can you help me? Yes. Okay. Perfect. And by the way, that's my point of view. What's yours? I told you, Mike, but I want to hear how often do you find yourself not wanting to write code? How often do you find yourself having to write code in your day-to-day work, just for standard things that you do, either a GitHub action and operator or controller or see a like? I can say I find myself having to write code. I find myself needing to write code because I want to ease my day, but it's not like, okay, I can bypass, I think I can bypass a lot of writing code, but because I find it may be faster to just write something that will ease my work, you know, sometimes you do the, we always talk about the sweet spot. I'm thinking to myself, how many times, how frequently am I doing this? How much time will it take to me to write a piece of code for that? How much time will it take to me to maintain it? If I write the docs, will it take two hours or will it take 10 minutes? And how much time will it take for me to explain to other developers how to use my tool? So I'm doing all of these calculations usually takes a minute, you know, to do that because you're like, mmm, I'm going for it, you know, or ah, it's too much or I've just Googled and found out that someone else did it, you know, so as we always say, it depends, okay, but I don't write a lot of code because I need, I think your job requires you to write the Kubernetes operator as you said, so you are more oriented to development, I think. Okay, and now I have another follow up questions on that. When you do find yourself having, needing whatever, you write some code to support your, your day work. Are you enjoying it? Me? Yeah, yeah, I enjoy it, I totally enjoy it, totally enjoy it. Okay, and and that's and that's a point I have because I think you and I are kind of similar in that, in that sense, we like it. We enjoy the process of creation of writing code and I do accept that not everyone are the same, not everyone out of the same, no way. Yeah, yeah, I had to learn that hard way. Oh my god. But yeah, I thought initially that everyone, I actually still kind of do, I think most engineers need to know how to code. If you're a junior, it's debatable. I think if you're a senior, you don't have to write a full-fledged application. I don't care, you don't need to write the next Js. I really don't care, but you don't need to be able to support a CI pipeline with not only bash. That's what I think. I don't care if it's Ruby or JavaScript or Python or a Go or Rust. I don't know. Just be able to write an application or sorry, write a logic with a programming language. I have one more thing to say about it, you know, what about the programming? As a DevOps engineer, most of the time, well, you support developers, right? A lot of time you support developers. Now, I found that it's easier for me to support developers if I understand their language. So if I have experienced maybe in Node.js or several language like Python or anything like that, and then they come to me and say, listen, I need to create a Python package and I've already done it. I've already created a Python package and distributed it, or maybe they need to create a Node package and distribute it. So if I've already done it, why? Why? Why? Why? Because how is that not the first thing we said? What? To support developers? Yes, we work with developers every day, we read their code, we're apt, we read literally deploying their code, we're taking things that they do and apply them. If we were part of it, and we could read the code and understand the shared libraries and understand changes that they've done, not only we can take part in what they do and maybe offer a pull request, maybe offer a contribution of some sort, and then they could offer us, us, I'm saying them and us, it shouldn't even be them and us, we should be one team that doing both, but let's put that aside. They, they, developers can contribute to the infrastructure and create a pull request for our terraform codebase, and we can create a PR that does something, it doesn't have to be, it doesn't matter if it's just configuration or infra side, but it's code that supports their code, and we can be part of the contribution and it grows from there. So that's, that's just the entire point, we should have started with that. Do you know where is the, like, where I find myself, like where is the, there is a clear border, like when I see a developer and a developer's engineer, and I'm like, but where is the border between us? So somewhere in the, in their code, there is a part where we are in charge, and there is a part that they're in charge, right? So you know where I see the border line is, it's like, I have an annoying question. I have an answer. Yeah, yeah, shoot. No, I have an annoying answer. So what I wanted to say is that I let you finish, and then I'll bring my annoying answer. Okay. So, so to me, as I just said, it like, it's in the package Jason, or in Python, in the requirements, the xt, or in going in the go some, go mode, why? Because everything is related to a third party packages, or ratting, or building, or maybe even in the Webpack config, because I'm more used to developing, like, uh, ratting stuff and building stuff. So I find myself being more familiar with the Webpack, even though it's not a DevOps thing, it's written for developers. You know, Webpack is for developers, but I find myself more, more familiar with DevOps, with the Webpack than, uh, developers, because it's more DevOps oriented air quotes, because it's related to the build path and distribution path and packaging part of the application. So I find myself, well, when I talked about the border between developers and DevOps, it's usually in the package, Jason, or requirements of their parties, and building and distributing the application, you know, this is like, this is where I see it. Well, do you see it? Uh, annoying answer? I don't. Okay. Okay. I'll, let's go. So I did speak about this, uh, two minutes ago, but I'll say that again. First of all, we were all part of the same, uh, all, uh, UNI. We were both part of the same consultancy. Uh, I think we both read the Phoenix project or at least spoke about it many times. Part of the idea of DevOps is, um, not reducing, but breaking silos, completely not having silos, not having silos mean it's not us and them. There is no border. DevOps is the idea of taking the guys that were in charge of the physical servers down there in the basement, taking those hipster engineers that drink off the old day and put them together and have them work one side, like alongside each other. And what I'm saying is that we, we should take it a step further and we should all be in charge of the same thing, both the application and the infra. It can be and lots of different ways. It can be the same thing that one is more, uh, oriented within infrastructure and the other is more oriented with code, but I think we should try and, uh, you know, if there is a border, we should try and narrow it down, almost to a non-existing, uh, line. And that's exactly what I said. I'm going to tackle you on this one. I'm going to tackle you with my horns on this head. Okay. I don't have I don't have, uh, sign. Also, you don't, I know that you don't have an engineering science degree. We are both, um, industrial engineers. It's totally not related to programming or computer science or whatever. Okay. So we've never written something that requires at least I can say about you, I know, but myself that requires, um, a complexity time of n log n and log n and whatever, right? We've never done, I've never done. I'm not sure if you, but I can guess if you also didn't have to concentrate your focus on that. I'm also sure you haven't written code in C++, like the developers in BNA AI that do, because like the algorithm for living vital signs, requires, uh, having knowledge in C++, because they actually write to be hardware. Okay. They read right from the hardware and it's super complicated. So when you say there is no border, I can assure you that to, you know, to, uh, reduce that border and maybe to, uh, reduce the gap between us. I need to study four years of, of computer science and, and then specifically focus on C++ to truly understand what they're doing in this black box that is reading vital signs from the camera in BNA AI. So for, like for the C++ project, and I mentioned it a few sessions ago, we are using, for example, Conan is the package manager for C++. It's a very, uh, famous one, and this is where we usually talk. This where our conversation starts and ends. I, literally, if ever, can read their C++ code and say, hmm, I can see the algorithm is minus this and that. I think we can change it over there. Now, this, like, it's a black box. I have no idea what's going on there, and it will take me years to truly understand and help them over there. So this, like, was tackling your point of, we are all doing the same thing. Now, take help me back. Uh, let's start with the, with the, uh, let's say academic part of it. First, I spent a little bit of time in a CS degree and just decided it's, it's too, too big of a burden on my life and then move, but I always felt like my orientation was code and programming and software development or if you want to call it software engineering. But that's me. Uh, now I have, uh, in the DevOps team where I work people that have a CS degree and we have many developers in the, uh, back end teams that don't have a CS degree. Now, to the extent of, or let's touch about what you said. Some of us do have to write very, uh, let's call it deep code, right? We need to write C++ code. Maybe we, uh, write stuff that are directly speaking to the kernel, things like that. So Linus had to have some kind of orientation of deep knowledge of software engineering. But I think most engineers, especially in the internet world of, uh, web applications or things that interact with, um, development platforms, even Kubernetes, by the way, a lot, a lot of parts of that speak directly to the system. But many other parts are just deployment or, or basically scripts around, uh, deployment. Let's call it components. You don't have to have a CS degree. You can learn on your own. Yes, there are concepts you will have to take on and grasp. By the way, you can learn everything of your own. There are amazing, uh, CS courses that can teach you the basics within, uh, sorry, you can get them on YouTube. Uh, but putting that aside again, uh, I think you can go a very long way and do most of the work today just with, uh, basic knowledge, which you'll build on from there using your, uh, experience or free time. Now again, I'm saying the for the first time, uh, modern times or modern ages today, we mostly use libraries that people have already written. So not going into what you said, but if I'm writing a CLI, again, I'm using something like cobra that someone invested a huge amount of hours and thinking into it. They're probably far better developer than I would ever be. And I'm just using something they built. And even cobra is using tons of other libraries. And GitHub is full of libraries that people just take on and build on and take on and build on. And today, the surface that we know, the languages that we use today, if you look at Python, are nothing like the, uh, like the, you know, the, uh, the origin or like the original gangsters of the field, like Linus and his friends. Um, that's it. So you can go a long way without a CS degree. Um, obviously you do want to know the concepts, you do want to know, uh, every time you say CS, I'm like, I'm like, you know, uh, you say CS degree. And obviously it's a computer science degree. But every time, like, accountants, like, degree, you know, every time you say CS degree, I'm like, kind of, like, kind of, like, kind of, like, kind of, like, yeah. Um, yeah. Yeah. Hey, I hear you. And I say, wow, accountants, like, degree, I wish they had a thing for that. Okay. Anyway, anyway, so I think, okay, I can say, we are, uh, like, contradicting each other on this topic. But I think when it comes to algorithms, specifically algorithms, it's hard for DevOps engineers to be familiar with the code, but surely for web applications and for automations and for, I don't know, maybe I can't even say what is a standard application. Yeah. Yeah. Maybe for web applications. Yeah. DevOps engineers can definitely learn TypeScript node and whatever. But for algorithms, it's very hard for DevOps engineers to get inside that black box, which is called C++. You may have to be a mathematician, right? You may need to have a math degree alongside. Right. Right. So it's very much depends. Like, we always say. Yeah. Yeah. You should see the, I don't know, have you seen the movie Grand Budapest Hotel? Nope. Okay. So you gotta watch this movie. They have a part. Maybe you should put it in the link. Uh, in the description, I'll put them the big precise time for that. What do they say? It depends. And they say, they say, of course it depends. You can say anything. It depends. You know, they argue about it depends. We definitely need to use that a lot. So what do you say? Do you want to move to the corner? Yeah. Yeah. Let's go on to move to the corner. Okay. So the effects, moving on to the corner of the week where we talked about things that we did experience knowledge or anything that we want to talk about that we've done this week, last week or even next week. So I'll start with your experience, the corner of the week. Okay. Um, I promise we'll have a deep dive into containers sometimes in the next few weeks. Uh, we'll record something. And I'll connect to that by saying deep dive into connectors, uh, containers or is also understanding where they come from, what they are, how they relate to the kernel, et cetera, et cetera. Understanding containers will also help you reduce their size, build them faster, quicker, more secure manner, let's say. There's a great tool that's called dive. I'll add it in the description and dive basically. Let's see you take a look into the different layers of every container. So you can kind of analyze the container that you have locally and it tells you what are the layers, what is the base image, maybe take it a step back and see the image that it was based on, you know, the, the from line at the beginning, and then you, you kind of debug your own container and understand what layers are in it. Obviously for security reasons, but mostly to be able to reduce load from the system that you probably don't need. There's a lot of, a lot of waste and a lot of fluff waving containers. So that helps you understand what's going on and getting rid of things that you don't need. So this like, have you used the new read about dive and stuff this week? Yes, I mean, I found it because we started talking about deep dive into containers and then I found it on GitHub and I went to, you know, right away to start it and it seems that I've already started in the past. So I guess I viewed it and forgot about it. Well, what you just said, it reminds me like when you search for something in Google where you need to find an answer for it and then you all, you see the link is already purple. So like, man. Yeah, so there's no way to hang an answer for it. Oh, man. Yeah. So this week, I had a great experience actually with our friend, Chet GPT, where I had a full conversation with him about how to build the Bina's algorithm for iOS. Okay. And actually, I like to ask him a question, like how I debug with Chet GPT and I really enjoyed it this week where, well, I tell him, listen, I need to build an application for iOS in using a Conan and CMake, right? And then he writes down the process. So then I copy the error that I have on my machine and tell him, okay, so I did it and then I got this L and then I paste L. So then it tells me, listen, this, this error means your application is trying to be built for Linux instead of iOS. So you should use this flag and I was amazed because it was true. And because I'm not really familiar with all of the, uh, interesting or whatever you say, like all of the little things. And when it comes to building intricacies, yeah, I think I know how to spell it, but not how to say. So intricacies, um, uh, curriculum and sticky. So I don't, I'm not familiar with everything in iOS. So when he told me about that flag, when he, like, Chet GPT is a thing, is something real. I was shocked because I really learned, you know, and then I kept, I just learned from the my mistakes. So I had an error, copy paste it, got an input from Chet GPT and then I was able to ask the following error about the following error until the application was built. So it was a great experience with Chet GPT. I admit that so far, I didn't have, uh, you know, a great experience with it. But this week was a great experience. Maybe the model also was improved, I'm not sure, but they really had fun with Chet GPT this week. Can I tell you about my short experience with Chet GPT this week? Shoot, shoot, shoot. Uh, I'm writing an open source telegram bot and I wanted to find the time, just the time object of last Saturday in 6 p.m. And I asked Chet GPT and it just immediately returned it and it looked great. So I ran it, like, I always do in the go playground. And what I got was Tuesday at 6 a.m. and I said, okay, fuck that. I'm gonna write it myself. Thank you very much. Goodbye. So that was me and Chet GPT. But sometimes I tell it, sometimes it answers a question and then I already know how it's gonna, okay, so listen, listen carefully. I'm going to predict how Chet GPT is going to reply. You write something, it writes back something that it's not really related. So if you write something back, like, listen, what you said is totally wrong and usually it's distant that it will tell you apologize for the confusion. If you meant to do this on that, yeah, if you meant to listen that, so it's usually apologizes, you know, it's very polite. Apologize, apologies for the confusion. So don't give up if it doesn't answer on the first time. It's not a great developer. Yeah, but if it's like, if it's wrong on the first time, it's not so bad because you can also help train it. So I think this week I really trained it to build for iOS. It was very nice. I made open AI and Sam Altman are very thankful for your work this week. Yeah, I just gave up. Yeah, maybe I'll chat you PPT for it will be better. I hope so. Oh, hopefully. Okay, so we are done for today. By the way, audience, you gotta understand, Omele and I didn't say the old session, but we have a huge delay between us. Like, I'm not sure if you see that, but I think I see maybe after a minute, yeah, I see you after a minute. So I'm not sure how it's going to be after the recording. Maybe it's going to be funny, but sometimes I'm not even sure if you, if you hear what I said. So, so let's see how it goes. So like, like chat GPT, we apologize. We apologize for the confusion. Okay, so thank you everyone for listening and for watching and for coming and for not coming. And see you next week. See you next time. Yeah. Bye. Bye, Omele.