Technology’s choices | LinkedIn
Python is the language used to write Ansible. It is an open-source configuration management and automation application that may assist businesses in automating their operations and infrastructure. The product was created to aid corporations. Ansible was designed to be user-friendly by incorporating a straightforward, declarative programming language. It is not necessary for the target systems to have any agents or software installed, which makes it simple to handle a wide variety of systems and settings.
Configuration management, application deployment, and cloud provisioning are just some of the many activities that can be automated with the help of Ansible, which is used extensively by businesses of all sorts. In addition to this, it has widespread support, including a sizable and lively community of users and developers, as well as a diverse selection of plugins and modules that may be used to enhance its functionalities. It is impossible for me to determine whether Ansible is the “ideal” technology for your firm because I do not have enough information about your requirements and needs. Nevertheless, there are a few reasons why Ansible might be a suitable match for your business, including the following: Ansible was developed with the goal of being easy to use and understand. It has a straightforward, declarative language and a straightforward, minimalist style. Because of this, it is an excellent option for businesses that wish to automate their infrastructure and processes without investing a significant amount of time or money in acquiring a significant amount of specialised knowledge.
Agentless: Ansible does not require any agents or software to be installed on the target systems, which makes it easier to manage a wide variety of different systems and environments. Agents and software may be downloaded from the Ansible website. This may be especially helpful for businesses that have a complex and extensive infrastructure. Idempotent: Ansible was built from the ground up to be idempotent, which implies that executing a playbook or task more than once would provide the same results as doing it only once. Because of this, deploying and managing systems may become less difficult for you, since you won’t have to worry about keeping track of the state of each system or resolving any disputes. Extensibility: Ansible has a big and active community of users and developers, and a broad variety of plugins and modules that may be used to enhance its capabilities are available. This may make it simpler to combine ansible with many other tools and systems, as well as to adapt it to better suit your own requirements. The individual goals and requirements of your business will determine whether ansible is a suitable fit for your organisation. It is recommended to investigate Ansible and see how it stacks up against the various tools and solutions now available on the market.
YAML, which stands for “YAML Ain’t Markup Language”, serves as the primary data source for the configuration information that Ansible uses. YAML is a data serialisation language that is legible by humans and is frequently used for configuration files. It also has the capability of being used for data storage. It is comparable to JSON in that it is a method for encoding data structures; however, it is more legible by humans and has less unnecessary words, making it simpler to implement. YAML is utilised inside ansible in order to create the configuration information that is associated with tasks and playbooks. Ansible is capable of carrying out a variety of discrete activities, known as tasks. Some examples of tasks include installing a package and transferring a file. Playbooks are compilations of activities that may be carried out in a particular sequence in order to achieve a particular objective. The YAML markup language is used to create not just playbooks but also tasks.
Ansible may be used for a variety of activities, one of which is deployment, which refers to the process of transferring code and apps from development environments to production settings.
Ansible should be used for deployment since it enables you to construct ansible playbooks, which specify the steps and activities that must be completed in order to deploy your code and apps. These playbooks can include actions like as developing and packaging your code, publishing it to a repository, and deploying it to your production servers, amongst other things.
Ansible’s user-friendly interface, which has a declarative language and a minimalistic design, makes it an exceptionally excellent tool for deployment. This makes Ansible an extremely valuable tool for deployment. Because of this, it may be simpler to design and manage deployment playbooks, even though both your infrastructure and apps will likely continue to grow over time. If you are searching for a deployment tool that is not only simple to operate but also adaptable enough to deal with a broad variety of different deployment circumstances, Ansible may be a suitable option for you to consider. It is in your best interest to investigate Ansible and see how it stacks up against the other deployment tools and solutions now available on the market.
Because of the nature of Ansible, which enables me to extend it to become a deployment orchestrator while Azure DevOps may serve as the executor, I was able to separate the execution of particular operations from the chain of CI/CD tools so that I could perform those operations outside of the chain. I do this by invoking Ansible plays. This is of tremendous assistance in the event of a catastrophe recovery, as a catastrophic state often entails the simultaneous failure of several different systems. The fact that I can leverage Ansible to interact with other components of my system, such as a CMDB and a Data Mesh portfolio management, is helpful to me in coming to a conclusion regarding this matter.
Instead of only being thought of as an IaC tool, Ansible need to be seen as a metadata and execution isolation tool instead. It is vital for your company to be able to define a build of material (BOM) and a collection of recipes in order to make progress toward the industrialization of software, as I explain at the beginning of the book. Both Ansible and Terraform are examples of tools that may be utilised to automate the deployment and administration of infrastructure; however, these two technologies are designed to accomplish different goals and include distinctive sets of capabilities.
The automation of the deployment and configuration of applications and services may be achieved via the use of the configuration management tool known as Ansible. The syntax is straightforward and declarative, and the overall design places a strong emphasis on making the system as straightforward and user-friendly as possible. It is common practise to make use of Ansible in order to automate the process of installing applications and services on servers and to maintain the configuration of servers after they have been brought online and are operational. On the other side, Terraform is a tool that allows users to construct, modify, and version their infrastructure in a manner that is both safe and effective. It is intended to be used to manage infrastructure across different cloud providers and on-premises systems, and it is especially well-suited for managing infrastructure as code. Its primary purpose is to simplify the process of managing infrastructure. When it comes to automating the development and administration of cloud resources, networking settings, and storage volumes, Terraform is frequently the tool of choice. In general, Ansible is a superior option for configuration management and application deployment, whereas Terraform is better suited for creating and managing infrastructure. Both of these tasks may be accomplished with both of these tools. Ansible may be used to setup and deploy apps on infrastructure that is controlled by Terraform. This can be done by combining the two tools’ capabilities.
My objective in a large enterprise is to lower the Risk Change Index, which is easily determined when a configuration drift is discovered at the intent declaration. Because of this, I have a strong preference for Ansible. This indicates that I am able to compare the metadata and playbooks utilised in earlier stages of deployments with the current intent. In addition, I am able to transform the audit of my architectures into a metadata model, which enables comparison to be accessed in accordance with the rules that I have predefined for myself.
My experience as a senior cloud architect has shown me that expanding Ansible with my very own inventory plugin has made it possible for me to develop an appropriate architectural schema model that accurately depicts the internal solution. By leveraging my very own collections, subsequence modules, and plugins, I am able to codify the recipes for each of my company’s building blocks. This lays the groundwork for a cross-platform design that provides a controlled exit plan while connecting with the systems that are all around them.
It is possible to assign subject matter experts to each collection thanks to the capability of splitting domains inside each collection. This, in addition to an existing schema and roles governance, enables the company to make the move to the cloud in a way that is both effective and efficient. The company will have complete control over all of the requirements for each and every composition, as well as the ability to set audit points and controls.
Standardization is essential because it provides us with the leverage to advance more quickly on typical architectures, which in turn enables us to concentrate on innovating and experimenting. After putting into practise various approaches of IaC over the course of the past seven years, using technologies such as PowerShell, C#, Terraform, Bash, and Python, in addition to the obvious ARM templates, I have come to the conclusion that this particular application of Ansible is where I can get more sustainable results. This strategy not only benefits us in the here and now, but it also stands to benefit us in the many years to come and makes us more resilient to change.
When working as a senior cloud architect, it is essential to keep in mind the long-term viability of the architecture as well as the technologies that are being implemented. It is essential to have the ability to standardise and apply effective IaC processes in order to have a successful cloud adoption, and Ansible, when appropriately extended and used, has the potential to be a useful tool for attaining these objectives.
In the subsequent parts of this book, I will illustrate how to practically put all of the information that was presented above into action.
18 March 2023
Zug, Switzerland
