 I think so. OK. Yeah. Try your mic. Yeah. Do you hear me? Yeah. You're good whenever you're ready to start. OK. Then we can start. So there will be a talk about automation. And as we know, today we have the ability to automate our task like never before. And should I stay here? It might just be a directional thing. Try it again. Hello. Sorry. We have the ability to automate our task like never before. And this can range from simple to very complex tasks. Automation is a huge benefit for us, giving us a lot of time back. And as we know, automation is a setup tools. And like any other setup tools, it comes with risk that we need to be aware of. It's a complex topic because there are different pieces that we need to integrate together. So if we want to solve that problem, we need to look at that from different angles and perspectives. There are different forms of automation. We have process automation, industrial automation, robotic automation, system automation, and so on. And today I'm going to talk about the automation of the most fundamental part in our technology stack, which is automation of infrastructure. Before diving deeper into it, a few words about me. My name is Tannas. I work as a cloud infrastructure engineer for a company called DNB. DNB is Norway's largest financial service group and one of the largest in Nordic region in terms of market capitalization. And we try to automate our system as much as possible. We try to migrate our data from mainframes, legacy systems to more modernized cloud-based infrastructure. As a system developer, I like to simplify and automate tasks as much as possible. After all, computers are greater at doing the same thing over and over again while humans get bored and annoyed of doing the same things multiple times. And the chance of doing something wrong is really high. According to Uptime Institute, where they do surveys every year on IT performance outages, the majority of the data center failures are caused by humans. That's because the more line, the more action, the more code we put into our systems, the more likely it is that we introduce some sort of error to the systems. And consider that we need to do the same things, the same performance in different systems for different environments. The chance of doing something wrong is really high. That's basically why we need to embarrass automation. So as developers, as IT engineers, we have a responsibility to recognize if there is something that can be automated. We should consider looking for some ways to automate our tasks, however, we just do it twice a year. I often hear that it's just a simple task. We don't need to automate that. But since we don't do it regularly, we forget that. And hopefully we have documented that so we can find it again. But there isn't a case always. So we have to figure out what we did last time in order to do it again. So we are going to spend some time on that. So why not spending that amount of time to write a script or function in order to automate that? Not everything can be automated when it comes to complex testing, when it comes to visualization and user experience. We cannot automate those things, but there are so many APIs that can help us to automate other things. So some of the advantages of automation is that it basically helps us to speed up tedious processes. We can produce more frequently, and by that we can recognize errors and bugs much faster so we can fix it also faster. It increased productivity as computers can help us to produce tasks now. We can put our effort and energy on more strategic works. And as computers are more apt to do the same things over and over again, the chance of errors is less, and that will improve the quality and safety. Both people who are needed to fix the fails and if we have downtime in our systems are really costly. So by automation we can also save a lot of time and frustration. It also reduced latency at the dependency. Since now we can have scheduled jobs that can be run when there is less traffic in our systems or whenever it's needed so not a person can sit and run that task anymore. It is also highly available. It keeps up and running and avoids disasters. It is also more consistent. It ensures that jobs are running and are not forgotten or out of sequence. And all of these will optimize performance. So now we can transform on interesting processes to more interesting processes. Now we can work smarter. All of these will help us to improve efficiency, accuracy and standardization. That is a huge benefit in the industry and this is what we are looking for. Talking about automation, we should definitely mention DevOps. Since automation is a principle key in DevOps. And when you hear DevOps you probably think about an infinitive loop with different tools and practices. Something like that. Most organizations have already heard about the concept of DevOps and they have some sort of DevOps in their practices. And we will go through different stages later on but before that let's take a look at the definition of DevOps. This is by Red Hat. It says that DevOps is an approach to culture, automation and platform design intended to deliver increased business value and responsiveness through rapid high quality service delivery. So it's much more than just tooling. As you know DevOps is a strategy that bridges gaps between developers and operators. And in my opinion it's bridges gaps between different teams no matter what. You have heard about concepts like the sex apps, the design apps, the admin apps and so on. So the idea is to involve people that we are needed into our deployment process from the earliest stage. So they can be involved in every discussion and not just developing something and just giving them for doing some tests. So the idea is to collaborate better. DevOps is about culture. Because in order to make automated solutions we need autonomous teams. We want to make our teams as independent as much as possible. We want to have teams that take shared responsibility. They produce something together in a collaborative way. And this is so crucial to implement that culture before we can choose technologies and practices. Before we can re-brand our teams to DevOps teams. We need to have that mindset. Because it took decades before the tech industry realized that people who are working with tech, people who are creating technical solutions are important. And in order to make companies achieving good results we need to focus on our people. And it's basic things like how people feel, do they feel belong to the teams, are they one hundred percent themselves? How is the collaboration between different teams? Do they collaborate or do they just communicate because they have to? Because people are different and we have different needs. We have different speed in learning and adopting new things. So we want to make sure that we have teams with shared cultural culture and responsibility. It's like we produce something together so we need to take full ownership and taking care of that product in the whole life cycle of that product. Another thing that is important in order to achieve a good culture is that not everything is measurable. We cannot measure culture with metrics and data and numbers. And that can be so challenging for some organizations. So DevOps journey consists of a combination of people, processes and technologies. And in terms of infrastructure, many companies have already some pieces of automation and measurement. But when it comes to people, culture and sharing, they face challenges. Sometimes it's because it involves organizational shifts in thinking. It can be the lack of empowerment or due to some legality concerns. So the transition from a waterfall approach to more agile, to more test-driven development, it's required also a really huge mindset shifting. When we in a waterfall approach, we had fixed dates, requirements and out times while in agile and DevOps, we want to produce much more faster. So we can realize and identify if something is running much faster. So building a culture is not something that can happen overnight. And it's not like technology that we can pre-define some template files. We cannot say that if it's like in a test environment, do this and if it's in the production, do that. It's an ongoing process and it requires work from every single individual because we want to be a part of the culture that we like to be part of. So we have to take care of our people and the way that we are working. So, yeah, another thing when it comes to culture, this is something that worked for me, so I hope it will help you as well, is that to listen for things that is not being said and look for patterns because that's how you realize what's working actually and what is not working. Because when we have a collaborative culture, then we can be more creative and think out of the box. So let's assume that we have the dream culture, how is automation applied in DevOps? Automation starts when we push the code out to the production and then we need to test, monitor and make sure that the system is up and running. So the entire DevOps pipeline consists of continuous integration, continuous delivery and deployment, continuous feedback, testing, and continuous operation, so on. And we do all of these things to decrease possible errors. Back to our loop. So continuous is what we are looking for in DevOps. Instead of one of tests and schedule deployments, there is a function that's just like an ongoing process for every test that we do. Continuous integration is when we are making frequently commits to a shared code repository and we integrate the code changes into an existing code base. So if some conflicts happens, we can realize that and we can fix those conflicts really fast. When we push our code with continuous integration, we keep a build that verifies every changes and if something fails, so we can go back and do some changes around the test once again. And when it comes to CI, if we are not pushing to the same code repository, we are not doing CI and if we have developers that are working on isolated, long-living future branches, so then we are not doing CI. The other thing is continuous delivery is when we push to a main branch. We have a main branch that is releasable at any time, if we push and something doesn't work, we can always go back to our main branch without fear of failure and things should be working. So for doing that, it requires pre-production environment. We need to have a test environment where we can test things to make sure that we identify errors before we go to the production, before we merge our codes to the main branch. Continuous delivery and continuous deployment are similar. The difference is that in continuous delivery, we always have a manual stage where a person can check everything before pushing it to the production, so it's not happening automatically. While in continuous deployment, everything happens automatically, so we have so robust tests that verifies every build and can be pushed to the production. And that is quite rare and unnecessary since we don't have tools that can do all tests so good yet. Another thing that is important is continuous feedback. It was one of the main reasons that we went from waterfall to more agile. It was a lack of timely feedback. So now with DevOps mindset, monitoring and testing continuously, we can give feedback to our developers much faster. While in waterfall model, it took several months or years to just realize that what was not working and then sending feedback to developers and then finding out what was wrong was not that easy. Then we have continuous testing. We deploy tests all the time for any stages. And that will lead to a faster releases and highly quality products. In DevOps, it's also important to have continuous operation, continuous alerting and continuous uptime. So we want to make sure that the system is up and running all the time. While every pipeline is unique, many organizations have similar concepts and it's like we, after each step, we test things and if it doesn't work, we go back, fix the errors and test again. We develop, test, deploy. This is what is DevOps about. So we also need to make sure that we can do all these processes over and over again. And if something fails, so we should not be afraid of going back to our earlier version. This is a survey that DigitalOcean did for a few, I think it was two years ago, from 6,000 different companies that they contacted around the world. They found that on average 45% using CD while 58% using CI and over 60% of large organizations have already some sort of CI today. And the largest benefits that they said they had of using CI CD was faster code review and deployment and the other one was version requestatory help them to work better in their teams. So let's take a look at an example how we can implement things, how we can automate our infrastructure. As a part of our modernized infrastructure, we want to run things in a cloud. So imagine that we have access to a public cloud and we want to set up our platforms and applications. We can have a Kubernetes cluster to run our modernized applications and then we can have a VM to run legacy applications on that. And we might need a VPC virtual private cloud to isolate infrastructure to make these things, these different components connect together. So what happens if we want to add another VM? Then we want to test everything in our test environments after development. So how we can do that should we set up the whole environment once again? What if we realize that we need to add another VM and then go to the production? How things will work? Here is when we can take advantage of something called infrastructure as code. Which is basically the concept of automating task end-to-end. So by implementing and building processes using IAC, we can scale and create configuration that tests and ensures the right results all the time. So now with infrastructure as code we can treat our infrastructure as we treat our application code. We can realize every changes we can track everything and make sure that we don't do anything wrong. And if something is wrong, we can fix it quickly. And there are so many different tools that can help us to achieve automated infrastructure. But there isn't only one tool that can automate everything. Now that we have different tools, so we need a mix and combination of different tools in order to automate the infrastructure. So let's break it down. When it comes to infrastructure, there are three main categories. We have provisioning, configuration and deployments. Provisioning is the first time when we spin up servers. And then we might need to do some network configuration on the servers, some routing, and maybe set up a load balancer. Then we need to do configuration on that. When we have that, so we can go to configuration, which is the part that we are going to prepare our servers to run our own application and platform on them, like installing and managing applications and different packages. When we have that, we can go to deployment and now we can deploy our applications. With container technology, we can merge configuration and deployment stages into one step. Because then we can install our application and the configuration that the application needed into a package and then install that image on our servers and it's ready to go. There are also two different phases when it comes to automation of infrastructure. The first is initial setup and the next is all the other times. So the first time that we want to set up the servers, the initial provisioning, initial configuration, initial installation of software. And for all the other times, we just need to take care of our infrastructure, like doing some adjustments, maybe add some VMs, remove some VMs, do some reconfiguration of our network, and so on. So the difference between AIC tools is that to automate tasks in different stages for different phases. And I haven't had the opportunity to use all the tools, so I'm going to talk about my own experience. I mostly worked with Ansible Terraform and Puppets. So for example, we can use Terraform for provisioning our infrastructure. The first time we want to set it up and then use Ansible to do some configuration to make sure that the system is always up and running and it's in the same stage. We can also, like with Terraform is that we can say that, okay, do all these things and then call Ansible to do all the other things. We can also call Ansible, say that, okay, the first step is to call Terraform to do the provision and then when it's done, you can do your work. There are also different approaches when it comes to infrastructure. There are imperative and declarative approaches where in imperative, we can say like every steps, we should say every steps is like, okay, create VM1, create VM2 and then add these on VM1, add that on VM2. So it's like CLI and writing a shell scrape or Python scrape. It gives us more freedom, but it also can be more complex when our system is much larger. We also have declarative approach where we can use Terraform. With Terraform, we can say that we only need three VMs and those VMs should run on a Kubernetes cluster and the tools will figure out how it will set it up for us. So it depends on which task we have, we can use different form of automation. Then we have mutable and immutable infrastructure. Immutable, as it says, it cannot be changed. So every time we want to do some changes into our infrastructure, we bring up a whole new environment. We do our changes and when we are happy with the new environment, we can bring down the old one. And it's like when we run the script several times, we end up with several environments in immutable infrastructure. While with mutable infrastructure, we can easily manage and configure the existing infrastructure. And no matter how many times we run the script, we make sure that we end up with the same environment. There are also different tools, like master and master less, agent and agents less. They are like, do we need to install masters to run on the background and make sure that all the different tasks are running or not? Like, Puppet needs a master while Ansible and Terraform don't need that. So, I was quick. Now we are on the conclusion, yeah. Well, so when it comes to automation, there is no right way to do that. It depends on your team and your organization, how you want to, how you can actually set up automated teams. DevOps is all about people, processes and technologies. And it requires cultural changes, management principles, and the use of different tools and technologies. And there are so many different, so many different technologies that we can choose between. So, based on how your infrastructure is and how do you want to automate it, you should do your research and find out what is worth for you. Automation is necessary to improve efficiency, accuracy, and a standardization. And with a standardization, it validates and accepts that what we have in our systems is what we are looking for. Like, we achieve the same results over and over again. So, automation can look something like this, but it should be more like this with planning and preparing the tools that we can use with building a culture where our teams can collaborate well together. We can achieve automation much faster and be more successful. So, by that, I can wish you a happy automation. But before that, this is a good comic from XKCD, which says that it is possible, but it's not easy. So, yeah, that was it, I think. Thank you. If you have any questions, you can also find me on Twitter.