In parts one and two of this blog series we’ve discussed the “Why” and “How” to get started with deployment automation. This third installment focuses on some of the common pitfalls you may encounter as you embark on creating your own automations in deploying SAS environments.
Creating a pipeline that works in all circumstances and encompasses all steps in a deployment is a complicated task. Trying to create the perfect pipeline from the get-go is a plan destined to fail. Like the move from waterfall projects to more agile projects, creating a pipeline in a step-by-step approach is a better way to get started.
The previous blog post showed the starting points you can use when creating a pipeline. Using these resources will kickstart your pipeline creation. So start out with deploying your infrastructure in a minimal viable configuration.
You may have several internal guidelines or SAS Viya design implementation decisions that you have to follow, but these should be implemented in a step-wise approach. The SAS IaC repositories contain sample files you can use to deploy a minimal set of infrastructure. See for instance the sample file for the IaC scripts for Microsoft Azure.
The same principal should be applied to deploying software onto the infrastructure as well. Whether it is supporting software like the NGINX ingress controller or the SAS software itself, again start out with the default configuration. Once you’ve got the initial deployment of the software out of the way, iteratively applying changes to the software makes for a much more pleasant experience. Like the IaC repositories, the SAS documentation also contains an initial kustomization file you can use to deploy the default configuration of the SAS software.
In short, start simple and improve over time. Redeploying software or infrastructure does not have to be a time-consuming process anymore, you’ve got automation for that.
So, you’ve followed all the advice dispensed so far and built a fantastic pipeline that can deploy your infrastructure and software automatically according to all the requirements and specifications you were given. Time to move on to the next project, right?
Not quite. You see, all these fantastic automations have brought in a ton of inter-dependencies.
When any of these technologies need to be updated, it may trigger an update to many other components. Even if you want to remain completely static, you may be forced by outside influences to perform updates. Whether these are security vulnerabilities that need to be addressed or deprecations instigated by your cloud provider, it is up to you to address these changes.
Your approach should be similar to your initial development of your automation. Try to avoid having to do many changes at the same time, as the risk that something will fail will be much higher.
Perform regular maintenance on all these components to stay on top of a changing world around you. It is much more relaxed to be able to update a component at your discretion and following your timelines than having to perform multiple updates with your back against the wall with a looming deprecation over your head.
We would like to end this series of blog posts with a number of short and sweet pieces of advice:
In this blog series about the deployment automation process we have provided you with you with information about why and how to get started with deployment automation. In this last post of the series we provided guidelines to prevent you from running into some common pitfalls. The next step is for you: Get started with your automation journey.
Part 1: Deployment Automation - Why?
Part 2: How do I start with SAS Viya deployment Automation?
Part 3: What are common pitfalls when starting with deployment automation?
Available on demand!
Missed SAS Innovate Las Vegas? Watch all the action for free! View the keynotes, general sessions and 22 breakouts on demand.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.