This talk was delivered as part of the internal Reply conference, Xchange 2021. In this article we are going to start with some theoretical concepts and then, in another article, we will explain in a more practical way by showing the results of our demo during the conference.
We will start by talking about automating the infrastructure for a 5G networking solution. Network disaggregation is going on as we are moving towards the 5G network deployments and automation at different levels has become an important challenge. Technologies such as Kubernetes, Terraform, Docker are helping to meet this type of strategic goals of Telco providers. On the software development level, microservices also demand automation during the software development lifecycle to avoid risks and human error. Moreover, it is becoming increasingly important to not only automate the software lifecycle, but also the infrastructure provisioning. We will use Gitlab CI, Terraform, Docker and AWS with the aim to automatically provision a Kubernetes cluster on AWS and then deploy an ORAN solution in an EC2 server; all done in automated ways.
To begin with, we looked at the problem with an automation mindset. When we discuss automation within the software lifecycle, we are inheriting the DevOps mindset. DevOps infinity loop, as shown in the figure below, provides an overview of this mentality. DevOps is the convergence of "development" and "operations", where both of these are performed within the same team. In the development phase, the team will plan, code, build, test and release the product. At this point, they will shift towards the operations side, and actually deploy the product to production, operate and monitor this. All of these steps are automated, meaning that once you code, this software will be built automatically, tested on, and if all tests have passed, then it will be deployed and be monitored by an automated tool as well. This will give quick feedback on the product; are there any issues that the developers didn't account for? Are there any improvements that can be made?
To summarise, a major benefit of following the DevOps mentality comes down to agility and customer satisfaction. If the developers quickly fix issues and/or deploy innovative features, then customers will be happy that their product has an improved quality. For the team themselves, this process makes it more enjoyable as the boring tasks are automated.
A way of adopting DevOps practically is by utilising CI/CD tools. CI/CD stands for Continuous Integration and Continuous Deployment/Delivery.
As the name gives away, CI will help you with the integration of your code into a shared repository. Once the developer has finished programming, maybe for the day or for that particular problem, then they will push their code to the CI repository (e.g. GitlabCI or Jenkins), which will integrate this with the existing code, the software will be built, tests will be executed and finally, a report will be returned with the final outcome. CD will take over by building the software, performing higher-level tests and finally deploying it to production.
In short, the benefits of CI/CD comes down to efficiency. Again, we see lower costs, as there will be fewer errors during the process of deployment, but also the developers don't have to spend time on tasks that become automated. The concept of CI/CD means that there is continuous integration, therefore this implies that we have smaller code changes, which also brings us to the next benefit, which is more reliable builds. The smaller code changes make it so that the build fails less, or the issue is easier to find and fix. And of course, we get faster release rates with CI/CD.
At this point, we have covered the concept and aspects of software development automation. However, we have not yet provided a way to automate the underlying infrastructure provisioning. Before we get there, there is another concept that we have to cover. In order for automation to be possible, we need a programmable control method.
A recent concept that has been getting more traction with time is Infrastructure as Code (IaC), as the name suggests, this allows developers to write a piece of software that provisions the infrastructure for us, instead of having to manually go onto your cloud provider and click buttons and write configurations many times. The figure below provides an illustration of the process. A developer will write some IaC software, which can be version controlled if working within a team, and once the code is pushed/deployed, this will manage the infrastructure. IaC can create, update or destroy the infrastructure.
IaC provides us with most of automation benefits, such as:
Proprietary examples of IaC are AWS CloudFormation, Azure Resource Manager and Google Cloud Deployment. These are proprietary as they only work with their relevant cloud providers. However, other tools exist which work with many cloud providers. A couple of examples of these are Terraform and Pulumi, although we will focus on Terraform for this post.
Terraform is an open-source software produced by HashiCorp. It works for most existing and popular service providers such as AWS, Azure, Google Cloud, Docker, Kubernetes, Oracle… Furthermore, another major benefit of this tool is that it allows for custom in-house solutions, by simply creating a plugin using their API. Moreover, Terraform code must be written in HashiCorp Configuration Language (HCL). HCL is a declarative language, and it is very similar to JSON and easy to understand and quick to learn. When you provision your infrastructure using Terraform, it will create a "state" file, which will save the current state of your infrastructure. This allows you to change some of the IaC and rerun your Terraform code without it reprovisioning all of the infrastructures, but instead only updating what you changed within the code. Similarly, this state file allows Terraform to destroy everything that it has created, and only what it has created within this project, as it will know exactly what this was.
In order to further automate the provisioning of the infrastructure, it is necessary to incorporate CI/CD within the process. Instead of running the IaC software manually on our machine, we can push it to a CI tool and then let this build and deploy the infrastructure. The state file can then be stored in Terraform Cloud, also provided by HashiCorp, or in any other artifactory repository such as an AWS S3 bucket.
Before you go away, we would like to thank you for reaching this point. We really hope we have managed to transfer some knowledge to you. This article has outlined the concepts of DevOps and Infrastructure as Code (IaC). We have kept it at a theoretical level. In the next blog of these two blog series, we are going to explain more practical examples.
If you would like to explore more of these services and concepts, at Reply we are offering the opportunity to discuss these topics and adjust them to your services and needs. Feel free to browse at Reply Online Services (ROSe) - rose.reply.com and book an appointment with us.
Otherwise...
We are technology consultants at Net Reply UK. The team consists of software developers, technology enthusiasts specialising in Telecommunications and technological concepts such as Software Defined Networks (SDN), Network Function Virtualisation (NFV), DevOps. Our mission is to build the Next Generation Networks leveraging the art of software and the latest technological trends. If you would like more information, feel free to reach out on LinkedIn (stelios-moschos) LinkedIn (thayná-dorneles). Alternatively, you can learn more about us on LinkedIn (Net UK) and Twitter (Net UK)