Deployment Automation series #1: Why
Deployment automation - Why?
The purpose of this blog series is to inspire you with general considerations of the pros and cons of automation and SAS Viya in particular. This series exists out of three blogs:
1: Why – Explains why when and where you may want to introduce deployment automation
2: How – Explains to start with deployment automation
3: Common Pitfalls – Will help you avoid some mistakes during the creation of deployment automation
You might be thinking, do I really need another blog post about deployment automation, DevOps, pipelines, Infrastructure as Code (IAC), Deployment as Code (DaC), desired state configuration or any other automation related topic? Good question, so when we set out to indeed make another blog post we thought it best to first take a step back and consider “Why do I want automation in the first place?” and “How does SAS Viya fit into the picture?”
This first blog post in the series will focus on these questions and tries to give some guidelines on why, when and where you may want to introduce automation. And although many of the concepts discussed here are general in nature, we will tie them to SAS related concepts where useful.
Although the need for automation can sometimes be simply mandated by a set of standards that an organization has adopted, it is important to consider the benefits and costs of automation to determine whether it is worth making the investment.
Benefits
In requirements engineering, three concepts are usually used together to express the quality of a requirement: Completeness, Correctness and Consistency. In short, completeness refers to whether a requirement describes everything it needs to, correctness refers to whether a requirement accurately describes the need and consistency refers to whether there are no conflicting or contradicting requirements. These three concepts also neatly describe the main benefits of deployment automation, especially when combined with descriptive or desired state configuration.
When deployment automation is being strictly applied, meaning that any action taken to deploy an application is being captured in an automated step, it enforces completeness. That is to say that when there is only one option to make a change to an environment, it forces you to capture all changes in your automation scripts. This means that your scripts will by definition contain all necessary changes to deploy an application.
This does not mean that a deployment automation script necessarily contains all required steps from the start. On the contrary, an automation script is usually a living document that is constantly evolving, but it does mean that all changes that were required to get to a certain state of the application are written down and documented at some level.
Correctness
We have seen that strictly applying automation enforces completeness. It also enforces correctness. When deployment steps or configuration changes are automated, there is no possibility of these steps or changes being applied incorrectly. At least as long as they are coded into the automation correctly of course. The removal of human error from deployments is often one of the main reasons behind employing automation.
Consistency
Consistency in requirements engineering means that there are no contradicting or conflicting requirements. However, consistency between multiple deployments is a more widely seen advantage.
When deployment automation is used, one can be sure that the same steps are being applied, or the same configuration is being achieved, no matter where or how often the automation is run. It again avoids human error and ensures multiple environments are configured identically. This is especially valuable when deploying multiple environments in DTAP configurations where you want to minimalize differences between environments to consciously made ones.
Speed
One benefit that was not mentioned in the introduction to this section is speed. Now this benefit comes with a big caveat in that deployment automation only speeds up deployments after you have developed your automation. The development of deployment automation takes time and effort, which we will talk about later in the “Costs” section. However, once you have created your automated deployment flow it should generally deploy an environment quicker than when this would be performed manually.
This increase in deployment speed is useful in lots of scenarios:
- When deploying multiple environments, like the above mentioned DTAP configurations.
- When deploying Just-In-Time or Ad-Hoc environments, where environments are provisioned when they are needed and decommissioned once they are no longer needed. This is only really feasible if environments can be deployed in a very short space of time.
- When performing disaster recovery activities. Where traditional disaster recovery strategies rely on having a cold, warm or hot standby in an alternate location available for when disaster strikes, having an automated and quick deployment automation means you can deploy a new environment within the time constraints usually associated with disaster recovery scenarios.
All of the benefits mentioned above should lead to increase business continuity and eventually a higher value of the solution.
Cost
Now that we discussed the main benefits of deployment automation, it is time we look at the costs of setting up automation. We will consider three main areas: Automation tooling, Initial Development and Continuous Maintenance.
You may already have automation tooling in place, but its worth factoring in the cost of creating and maintaining the automation tooling required to perform automated deployments. Depending on your choice of automation software, this could range from simply setting up an account and creating a project, to setting up dedicated hardware, network and identity and access management. Using a sequence of automation technologies allows you to create deployment pipelines.
The setup of automation tooling is an up-front cost that is independent of the software you are going to deploy. Whether it be SAS or another piece of software, the product or products you use to guide your automation is a choice you generally make for an entire company or division.
Initial Development
The initial development of an automation pipeline takes time. There may be templates that you can start from and adjust to your needs, or you may have to start from scratch entirely.
The initial development cost will largely be determined by the easy of which the software and the infrastructure that supports it can be deployed automatically. Software that can only be deployed through a GUI and requires physical or specialized hardware is probably not a good fit for automated deployments. On the other hand, container-based software that can be deployed on cloud-native infrastructure will most likely require much less effort. The development cost will also be influenced by the amount of configuration or specialization that needs to be applied to the software to make it fit for purpose. Software that requires a lot of post-deployment configuration will be more costly to automate than software that does not.
Continuous Maintenance
The popular practice of Continuous Integration and Continuous Delivery (CI/CD) is usually applied to delivering software as an end-product and not so much to software that is supporting the software development cycle itself such as deployment automation pipelines. Pipelines consists of software just as much as end-products do, which mean they come with updates and upgrades just as much as end-products do.
Maintaining your deployment pipeline to incorporate and deal with changing requirements in both the supporting software as well as in the software delivery to be automated is a cost that will be continuous as well.
In part 3 of this series we will cover some of the challenges in maintaining deployment pipelines.
Automating the SAS deployment
With the main benefits and costs clear, the question remains: “How does SAS fit into this?”
We should first discuss the typical use cases you may consider when determining whether your SAS deployments should be automated. SAS deployments are often software development environments themselves, i.e. SAS is not the end-product, the code, model or decision you make with SAS is the end-product. This means SAS is often deployed in DTAP configurations, although blue/green deployment strategies gain in popularity. As discussed in the benefits section, deploying software many times over with as little differences as possible is a great use-case for deployment automation.
Suitability for Automation
The suitability of SAS software for automation differs greatly between SAS software versions and has generally improved from version to version. We can safely say that the latest version of SAS Viya is the easiest to deploy using automation tooling. That is not to say that SAS 9.4 or Viya 3.X cannot be deployed automatically; they can and many have, but the effort required to completely automate their deployment will be higher than it would be when using the latest version of SAS Viya.
This means that the number of situations where a completely automated deployment of SAS 9.4 will be cost-effective will be less compared to SAS Viya.
Support from SAS
Although creating an automated deployment pipeline is a task that integrates with an organization in specific ways a software vendor would not be involved in, SAS does supply useful content to help you jump-start your automated deployments. This content is provided to customers through the SAS Software GitHub project.
The next installment of this blog series will focus on getting you started with automating the deployment of SAS Viya.
Articles in this deployment automation series
Part 1: Deployment Automation - Why?
Part 2: Deployment Automation - How?
Part 3: Deployment Automation - Common Pitfalls
