 Welcome, thank you very much. Excellent, so thank you very much for having me today and being the last session. I would like to make it easy to digest and to move forward because the topic is a really interesting topic, at least for me, I think that for everyone around. But before jumping into the actual content of the session, I would like to present myself and also the company that I'm working on. As you said before, Mario Neto2Code is a relatively small solutions company focused 100% around providing network automation solutions. And within this company, there is the architecture team that I'm part of. And here you also see the screen mark and my kale that they are working together, creating and helping the different teams that are providing new solutions. A holistic view about how the different components can work together. What makes the company different is that we make everything as open source projects. So we try to create the solutions, build the solutions, composing the different pieces that are available. Obviously, we can work with multiple vendor solutions. But if there is a gap, there is always an option to put an open source piece. And everything that we do, we contribute back to the community. And also we create and we sponsor projects by ourselves. Then to try to narrow down the topic because we actually had a network related session before myself, one before. What we are going to talk today here, when I talk about network automation, this is a really open question. You can think about networking in a not really concrete way. Because actually in networking, there are different planes. So if we look at the bottom of the stack, we see the data plane that is where the actual packets are forwarded. So one packet is coming in one port and it's going in another port. This has been pretty static for a long time, but since the ratio of SDN with open flow and other protocols like before, or just directly programming the A6, you can change the behavior of that. We are not focusing on that. On top of that, we also have the control plane. The control plane is where traditionally the network routing protocols work. So they work together, they bring a distributed understanding of the network. And then this representation of this state is pushed into the A6 just to change via tables the behavior of the packets. So it's where the packets are defined is the definition. But the topic for today is in the upper plane, in the management plane, where we as engineers, as an architect, we can define how the control plane, how the data plane is going to look like. So simply set is the way that you connect to the devices traditionally via a command line interface and you change the behavior. And being this set, I think that is good for me to give context about one of the main reasons that I'm here today. As I said at the beginning with the introduction, Marie already mentioned that I have been working in networking for more than 15 years. And for the first seven, eight years, my main focus was about network architecture, network operations. And I had been working mostly as a CLI focus engineer. So I had knowledge of multiple vendors, multiple syntax, and I was able to translate my knowledge into the network behavior. But there was a moment that I understood with the DevOps ideas to change the way that we operate the infrastructure, not only the network, the infrastructure as a whole. And I changed my career. I went to a company where I started as a DevOps network engineer. And I remember perfectly the moment that my mind blow up and I discovered the beautiful open source. It was where I was dividing a problem with an SNP client for a monitoring solution that was open source. So we were trying to understand what was going on. We understood that there was not behaving as expected. And my third reaction, as I was used to, was, okay, we detected the problem, we just called the vendor or the solution, and at some point the solution will be solved. This was my default behavior. But luckily for me, side by side, I had a more smarter guy than me with more experience. And he took the keyboard and went into the PDV session in Python because it was a Python application. And he was able to understand what was going on, was able to fix the issue. So we had a working solution at the moment. And finally, he contributed back to the community, to the AppStain project. You can imagine for myself that was used to interact with the devices, with the operations in a predefined in a common line with really narrow options. This completely break my mind. And this was the reason that I jumped into natural automation as a whole. And the same journey that I did, a lot of people is doing these days. There are a lot of companies that we are working with them that are doing this transition from traditional network operations. They are used to understand how the network should work, but the way to communicate it, the way to enforce that has been really manual way up to date. But this has been changing and open source has a big role here. This is something that we are going to see later that help you to do this transition. You can use Ansible framework to change the configuration management like you are doing for the servers, for the network. This is not new. This has been for a while there. But we are seeing, as working with multiple customers, multiple projects, that there is a big dilemma, a big decision that you have to take. One thing is just focus on the tools and specific project and just move forward with the project. Or try to think on your network automation strategy, the way that you provide solutions to manage your network in a more overall understanding. So you understand the whole picture, not only how a tool solves a specific problem, because maybe it's not solving the whole solution. And this decision is the one that we are going to try to solve today. And the approach of the presentation is as simple as try to share the same prime work mindset that we in the architecture team in network to code and network to code as a whole applies to all the project that we are working on. We try to focus not on the tools, we focus on the different functionalities that compose a network automation solution. And then when you have the solutions, sorry, the functionalities, you can then place the different components that can solve the problem. So we have to start first on the network automation framework. This is not rocket science, but really, really helps for everyone to understand what we are talking about. And we define our framework network automation framework in these seven different components. Remember that we are talking about network automation. So in the bottom layer should be network infrastructure for sure. This network infrastructure, we're going to see there could be different types. But then if we go to the top, we have the user, the user is the one that is going to start and control the whole automation. In the middle, there will be different pieces. The source of truth, telemetry, orchestration, we are going to go one by one. And in the left side, we have the CICD process. We have to not forget that this is network automation, but this is a software development project. So any tooling that we are using for developing any kind of application these days can be applied to this. And we try to keep this in mind always as we work with these projects. So let's try to start one by one. The user interactions really important one because everything starts here. You have multiple options here. And you have to select the one that solve the problem for your user. Maybe there is a user that wants a user interface, a graphical user interface. There are options. Maybe there are other users that they want a programmatic interface, an API. Maybe they want a GraphQL API. Maybe another one. Another one wants a dashboard just to visualize the data. So it's the work of the architect when things about the network automation solution to understand which are the user interfaces that has to be implemented because maybe not all of them should be in the project. Once you have the user interfaces, you have to start focusing on defining how your network should look like. Traditionally, the way that network operations have been working is that the state of the network is the state of the network. There is no reference. The reference, if there is, is in your head. So you remember how the network should look like, or maybe in some diagram in some wall, but nothing more sophisticated. The idea is to achieve the goal of automating your network. You have to properly define what is the intended state, what the network should look like. And we call this the source of truth, where your variables are defined about how your data, how your network is going to be modeled to eventually move into the desired state. How we want the network to behave, how we want the routing protocols to be controlled. All this information should be properly defined in the source of truth. When we have the source of truth, because we are automating a process, you can imagine that there should be an orchestrator, a workflow orchestration in some place. The future, the functionality of the orchestration is nothing else than coordinate the multiple steps of the execution. Maybe there are multiple steps that have to be executed in order to fulfill a solution and has to be in the middle of everything. We are going to see in an example how this fits together. Then we move into what actually is more specific of network automation. Why? The automation engine is the place where we put the different tooling that is going to help us to move the intended state that is a data model, a reference into something that the network infrastructure understands. Because on the network infrastructure, what we have are routers, firewalls for multiple vendors, supporting different interfaces. Maybe one only supports CLI, because it's a legacy device, or SNMP maybe. But we have to actually deal with new interfaces like GNMI, NetConf, or even dealing with cloud network services, you have to interact with custom APIs. Whatever it is, the automation engine is going to take the reference, the model, and translate simply a translation to move from one to something that we can actually activate. Then the network infrastructure is really heterogeneous. We have multiple devices that are physical boxes, virtualized, cloud network services, everything. We should be adaptive to whatever we have and just offer the different interfaces just to be able to get an operational state and to set an operational state. So, first, we can take the configuration and then we have to be able to show, to communicate what's the operational state. And this is what the telemetry and analytics block is going to do. It's going to collect information, enrich the information because information without metadata sometimes is useless. When we collect information from a device, because we know which device we are connecting to, maybe we can enrich this data via the source of truth and maybe a part of the device we can get the different sites, more information that then when we visualize this data in a dashboard, we can enrich and we can classify the data in a more educated way. Finally, all this data, because it's a lot of data, has to be stored. As we are going to see when we talk about the related open source projects, the beautiful that we have here is that we are not reinventing the wheel when it's not needed. Obviously, we have to talk within the interfaces that the network devices have, but for the rest, for transferring the different messages, we are going to use open source projects. To store, we are going to use other open source projects. When I say open source projects, I mean general proposed open source projects. Finally, as I said before, CICD is helping us to deploy a network automation logic that takes care of not breaking production. So the same practices that we apply to the software development lifecycle, we are going to apply to the networking automation. Obviously, taking into account the different specificities of the network devices. And now we are going to try to do an overview. It's not exhaustive at all, but we are going to try to do an overview of what the different projects in the different areas belong to. And this is only taking into account open source projects. We are always using this in a brownfield environments where there are some vendor solutions that we integrate. But here today we only mentioned some relevant open source projects. First, an important piece, the source of truth, where we can define this data. Obviously the data has different particularities, different characteristics, depending if the data has to be changed super often or by a user. It can be stored in different places, like in GIT or maybe in relational databases. Here we have an example of two pretty common source of truth that are complete for data centers infrastructure management, IPAM management, multiple of them, like Netbox and Mautode. There are two on multiple available solutions for source of truth that are tackling different parts of the data information that we have to store. When we define this information in the source of truth, what's coming next? Obviously, someone has to change this. And here we can offer multiple solutions in open source projects. We have chat applications like Mattermost. We can build our CLI applications in Python with click, in Go with Cobra, multiple of them. We also have complete IT services management, like GLTI or ITOP. And to visualize, we have Kibana or Grafana that can help us to get data from the telemetry storage. Then to orchestrate everything, just to name two of them, AWX, RANDEC, are orchestrators that help to play with the different components that are part of this architecture. And there are multiple of them because all any kind of tool that can be used to orchestrate processes can be used in the natural automation ecosystem. And as I said before, what makes natural automation a bit special are the different libraries that we have available to automation engine. The automation engine is using first languages that I have not pictured here. That is, for instance, JINJA to render templates of configurations from the data that we have in the source of truth. And then we have multiple projects like Napalm, NetNiko, PNGMI, Nordnir, Scrappy. Multiple applications that work in different languages to connect to the different interfaces for each network device and change the state. The same device applications or libraries that work to change the state can also be used later in the telemetry part. As I said before, you set the state and you actually get the state. But I added here just to be more specific on the place. But here, also, you have to notice that there is AMSIVOL, there is SELSTAC, just as configuration management. The same way that you configure servers, you can configure network devices. And also Terraform because a part of configuration management, there is also the provisioning of network services if you are running in the cloud. This is also part of these features that we have to fulfill. And the definition of the state is going to come from the source of truth. We have in the telemetry part, obviously, what makes this special is the interface. So how we connect to the devices, because usually a lot of devices cannot install an agent. So you have to do an agent list. Telegraph helps a lot here, hosting multiple libraries to connect to the devices, get information and reach from a source of truth and finally consolidate into a 10-city database like Prometheus or others. We also have to use Kafka because in some places we have a lot of data to transfer and to distribute to multiple receivers. But there are also specific tools for network automation, as for instance, SUGQ that helps to get the information from network devices. And when we talk about network monitoring, we are not only talking about metrics and logs. We are also talking about flows, flows of data. Tools like PNGCT or GoFlo can help you in order to get all this information together with the logs and the metrics. And this is really important because network automation here works together with application monitoring. So all the information from network servers and applications could go together to the same place. And you can imagine what can make possible this convergence of information. Last, as relevant open source projects, as I said before, all the things that you can use on software development lifecycle can be used here. But you also have a specific tooling for networking. There is like the simulation tool called Batfish that help you to get a configuration and create an analytic model to represent how this network device is going to behave. Or you can even simply run the network operating system like a container or a virtual machine with different projects like container lab or Kubernetes network emulator. Multiple of them that can help you in the way of deploying a new change on the network automation infrastructure. We are talking about management. You can first speed up network device, push the configuration, see that the configuration is good, and then you can heavily deploy it to the network. As I said before, this is a really, really quick summary of all the different relevant open source projects. But the best way to understand this is to see an example, a really quick example. Imagine that you want to implement a firewall rule automation. Using this architecture, this framework, we can understand that the first thing that we have is a user that we present an interface that is a chat application, matter most. So he can set what's the state that he wants to change on the network. What happens next is that this change in the intended state has to be pushed to the source of truth. In this case, we receive this change from the chat ops integration in an autobot. An autobot changes the state of the intended state and automatically triggers a workflow, a workflow that eventually will deploy this change to the network. So AWS takes care of connecting to Ansible. I'm saying, okay, with this information that we want to change, get some templates from another source of truth from Jeep and render the configuration. What's the configuration that we have to push to the network? Then thinking on making a reliable automation, we can spin up a bad fish container just to test if this configuration is syntactically correct. If the outcome of the configuration is what we expect to be. And when we are comfortable that we are not going to break anything, it's Friday afternoon, so we should not break anything. It's time to deploy. It's time to connect to the different network in the devices, could be physical devices or could be in the cloud and change the state. But this is not over. When we change the state, what's next? We have to close the loop. We have to, in the telemetry and analytics part, we are going to collect the flows from these devices and see the feedback to the AWS. Are these flows that I am seeing consistent with the change on the source of truth? I mean, if we have created a rule that enables the flows, the flows that I should be seeing should be accepted. So this is the point. We are changing the state, observing the state and validating that. If not, the loop can be continuously doing until we get into a state that we are comfortable with. The same that I mentioned for firewall automation, here there is a quick summary of multiple real use cases that we have been solving in multiple places, from managing OS upgrades, firewall compliance and remediation, implementing device lifecycle, how an upgrade has to be done, or just managing circuit maintenance when an operator changes something via mail, your source of truth can be updated in order to reflect these changes. There are multiple of them and all of them at the end has to be approached the same way. In a framework that you understand what has to be solved because every network is different, you have to adapt everything, but the idea is exactly the same. And just to wrap up this session, I just want to give you a quick hint about how to approach this kind of projects. First, you have to prioritize what you have to automate, and this means that you have to take something small, but with high value and low risk. And usually, this is getting data, getting information, giving you some educated comprehension that you can use. This is a good starting point. When you understand the problem that you want to solve is have to go deep onto what are the different details that this operation looks like. So maybe what is like one sentence, if you drill down, you will understand that there are three, four different steps. So all of them have to be clearly understood because you as a human, you can infer this and automatically do these things, but a computer has to go one by one and understand how this works. When you understand the different steps, simply try to simplify them and normalize. Because, as you know, a computer only understands data that is well normalized. And when you have everything clear, just try it. You cannot keep thinking, planning for the future. Try it with something that has low risk. Maybe just getting data from your network is good enough. This is a starting point that will help you then to step by step trying to move and not changes that really change the global orchestration of your network. And as a take away three takeaways. First understand, try to understand what you are doing. What are the workflows actually doing to try to simplify them understand what are the functionalities that you have to implement. Don't start with the solution of the tool. Don't think that, yeah, Ansible is the solution or Python, whatever, or no, the solution is never a tool. Maybe you are going to end up using that tool, but before you have to understand what are the different things that you have to cover, because not always you have to cover all of them. Then understand that you are not going to find a project that solves everything for you. This is not even true in a vendor solution. Usually you have to combine multiple of them. And open source here has the extra benefit that you can customize this you can adapt your the different pieces just to suit well together. And as a conclusion, natural automation that few years ago was like the last resort on network on infrastructure operations today in 2022 is no longer the exception. So, every day, every project we are working automation is there, we are just extending it improving, but there are always some starting points on natural automation. Because without natural automation, you cannot achieve the scalability and the reliability that your network operations deserve. And probably your network users are used to have because everyone today is used to work to the cloud, click into places and get a service up and running. The same user experience maybe is going to be expected also from your network. And that's all. Thank you very much for your time.