Note : This blog discusses the SAS Viya deployment methods and was written in June 2021. If you are looking for a more current information, a new blog (published in 2023) with various updates on this topic is available there
Our team (Global Enablement and Learning) has taught the SAS Viya 4 Deployment workshops (virtual/remote) a couple of times.
While we all miss the physical interaction and opportunity to take advantage of a full week session, we were lucky enough to receive great evaluations and comments from our attendees, and I thank them for that.
However, after the last session, we received a quite poor note from a student with this comment : "Deployment of Viya 4 will need a straight standard - that is not the case now.".
That got me thinking, and ultimately, I came to agree with this statement (to some degree). I'll explain why in this article.
In our workshop, we explained and jumped between various ways to prepare the infrastructure and deploy the software : sometimes manually, sometimes with the SAS supported Infrastructure as Code(IaC) projects, sometimes with the ansible automated deployment tool, sometimes with the Deployment operator, etc… The fact that we are now adding the support of 2 additional Cloud providers (Amazon AWS and Google Cloud platform) and that the Deployment Operator became the "preferred" deployment method does not help with the requested simplification…
While it is important to show and demonstrate the various ways to deploy the software, it is also good to take a step back and look at the current possibilities and understand how and why they are different.
That's why I have started to write this article, as an attempt to clarify this topic and maybe suggest a standard method that hopefully can work for most of customers deployments.
Disclaimers :
|
If you are really looking for a high-level summary, here is it is :
Deploying SAS Viya is always a 3 step process :
For each of these steps, several options and associated methods are available.
The purpose of this article is to help you to choose the best options depending on your customer situation and requirements.
Your deployment choices also have an impact on how you then configure and manage your deployment (ways to configure, manage and update your deployment will differ depending on the chosen deployment method).
SAS Viya ( in its version 4) only runs in a Kubernetes cluster.
Either the customer already has one (maybe with an existing workload) and wants you to use it (worst case scenario) or they will create one dedicated for the Viya environment(s).
Assuming the cluster in which the customer wants to deploy does not already exist, you have 2 options to create the cluster (and they are listed in the columns of the table below).
Custom method | SAS offered IaC method | |
Notes | Use the Cloud provider portal/CLI or Terraform or a Cloud provided IaC framework (Azure ARM, Google Deployment Manager, AWS CloudFormation, etc…) | Based on Terraform, currently supported for Azure, GCP and AWS |
Supported | YES | YES |
Flexibility | Full | Excellent : many parameters, but some limitations (storage, location, and network options pre-defined) |
Requirements | See official infrastructure requirements | Docker or Terraform installed on the jump host |
Workload estimates | days, potentially weeks | 1 day |
Automated | Yes likely. | YES |
Probability to have a successful Viya deployment from the first time | Low | High |
Recommendation | To avoid as much as possible | Strongly recommended* |
(*) While the viya4-iac tool is really the tool that each customer should use, it is the customer’s responsibility to validate its configuration and execution.
The viya4-iac projects available in the sassoftware GitHub repository, provide great tools that allow you to build the Kubernetes infrastructure (whether it is Azure AKS, Google GKE or AWS EKS) exactly as it is expected for a SAS Viya 4 deployment.
The tool reads a configuration file with several variables and is using Terraform. It can be executed with the Terraform command line directly or be used as a docker container.
There are still some limitations, for example on storage options used for the deployment (Azure File not supported), on the resource locations (GKE nodes pool nodes are always attached to a “single zone” and all resources are zonal) or on the type of loadbalancer (public by default).
However, the tools offer a wide range of customization and options such as the Kubernetes version, IP addresses allowed to access the administration endpoint, the node pool configuration (with the instance types), etc….
It can create many things for you automatically in the Cloud, such as an External Postgres Instance, a container registry, a JumpHost, an NFS VM, or a Cloud storage instance, etc…all you have to do is to provide the proper values as documented in the docs/CONFIG-VARS.md file that is provided for each tool.
In addition, the tools are constantly evolving to offer new capabilities.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
The core piece of the tool is the main.tf file (Terraform script). If needed it can also be overridden by someone with terraform skills.
The table below lists the available storage options for the Deployment Persistent volumes with the viya4-iac tools.
This step is about installing and configuring the required component for a Viya deployment (Ingress controller, certificate manager, deploy the NFS provisionner and configure the storage class, etc…)
This step is also critical as even a small deviation from the required third-party software (like NGINX or Cert-manager) could prevent a successful deployment. You have 2 options : Manual steps or using the viya4-deployment tool available as a GitHub project.
Manual steps | Using the viya4-deployment tool (ansible based) | |
Supported | YES | YES |
Flexibility | Full | Excellent : default settings can be changed, but some limitations (ex: single Storage Class) |
Requirements | See official infrastructure requirements | Kubectl, kustomize, Ansible + various python libraries installed on the jumphost. Or just a Docker image with all the required tools. |
Workload estimates | Several days, potentially weeks | 1 day |
Automated | Not by default, but can be scripted | Yes |
Probability to have a successful Viya deployment from the first time | Low | High |
Recommendation | Only if the viya4-deployment tool cannot be used (specific customer requirements, for example : need to use azure file for some of the Deployment Persistent Volumes). | Strongly recommended. |
Note that if you go with the manual installation of the documented pre-requisites, there is another SAS Software GitHub project, called viya4-ark, that you can leverage to check if the minimum requirements are in place before starting the deployment of SAS Viya. The viya4-ark pre-installation check tool will not install the pre-requisites, but it can generate a report to evaluate the readiness of the environment in terms of system requirements.
Now it is time to deploy Viya !
Once again there are several options – and they are listed in the table below.
Manual deployment | Deployment operator | Using the viya4-deployment tool (ansible based) | |
Supported | YES | YES | YES |
Flexibility | Full | Full | High but some limitations (storage types, single storage class etc…) |
Requirements | Kubectl, kustomize on the jumphost | Kubectl, kustomize, potentially a Source Code repository on the jumphost | Kubectl, kustomize, Ansible + various python libraries installed on the jumphost. Or just a Docker image with all the required tools. |
Workload estimates | 0.5 to 1 day | 0.5 to 1 day | 0.5 to 1 day |
Automated | No | No | Yes |
Probability to have a successful Viya deployment from the first time. | High | High | High |
Recommend using this Deployment method for a new/fresh install? | Depends on the cadence version | Yes | Depends on the context |
At the beginning, it was only possible to deploy Viya 4 with the so-called “Manual” method which basically is straight forward and consists of 3 steps:
However, as explained in Michael Goddard’s recent blog, since Stable 2020.1.4, the "SAS Viya Deployment Operator" has become the “preferred” method from the SAS perspective.
Using this method, you let the Deployment operator manage the Viya deployment for you.
You still need to prepare your Kustomization.yaml and your potential “site” configuration (“site-config”) transformers, but the Deployment Operator can automate most of the update steps and will also be able to assess the validity of a Viya version update that you are planning to do (new with 2021.1.2).
The viya4-deployment project available in the SAS software GitHub repository not only allows you to automate the pre-requisite phase (as we’ve seen in the previous section), but it can also deploy SAS Viya in the cluster (no matter what the Cloud provider is).
The tool uses ansible playbooks and simplifies a lot of the configuration steps by providing a single ansible variable file where you can specify many deployment options (documented once again in the doc/CONFIG-VARS.md file).
If you have used the viya4-iac tool to build your cluster, the viya4-deployment tool can directly read the generated terraform state file to discover and pre-define several variables.
In such case, there are many variables that you don’t even have to set as they will be parsed from the terraform state file (.tfstate).
Like for the viya-iac, there are still some limitations with the viya4-deployment tool, or predefined choices (no support for azure files, predefined NFS structures required, etc…).
However, it supports a lot of scenarios and can save a lot of configuration work, where several common customizations (Number of CAS workers, Storage Class creation, TLS configuration with custom certificates, Deploying from a mirror registry, Expose CAS, CONNECT services, etc…) can be done just by setting a desired value in the ansible variable file.
Last but not least, the viya4-deployment tool can also install the SAS Viya Monitoring and Logging tool for you very easily.
The tool generates the kustomization.yaml and the site-config files automatically for you, depending on your variable values and run the deployment.
We've just seen that, for each step of the deployment process (create the cluster, install the pre-requisites, deploy Viya), we have various options.
The diagram below shows the potential paths that can be taken depending on the customer requirements and constraints.
As you can see, several combinations are possible to build your own deployment path.
Your deployment choices also have an impact on how you then configure and manage your deployment (it is summarized in the yellow box).
Finally, the choice really depends on the customer's scenario and technical expertise with with infrastructure as code and Kubernetes.
You might see customers who have limited skills or interest in Kubernetes and will rely on you to help with the cluster setup. Running Viya in the SAS Cloud would be the best option for them, but if they prefer to manage their SAS Viya platform by themselves, then they will be able to leverage the SAS-provided IaC tool to provision and deploy their cluster in the Cloud (Azure, GCP, AWS).
On the other hand, you might have very advanced customers, for example connecting their "on-prem" networks to Cloud VPCs with very specific requirements on the network (for example for a VPN based access), storage type, security that might not be supported or available with the automation tools.
Some customers will also ask you to use their existing Cluster or using their existing Resource Group, VPC, subnets or network . In the latter case, be aware that the 3 viya4-iac projects allow you to do that (for example for Azure see https://github.com/sassoftware/viya4-iac-azure/blob/main/docs/CONFIG-VARS.md#use-existing ).
However, a reasonable default approach in two steps would be :
Depending on the context and customer scenario, the deployment can also be done with the viya4-deployment tool (if the customer does not require something that is not supported by the tool). Here are the reasons that would lead to use it:
If you want a CAS MPP and a backup controller, expose SAS/CONNECT or CAS binary access, have the Viya Logging and monitoring tools automatically deployed, pull images from the Cloud container registry etc…all you have to do is just to set the correct values in the ansible variable file and the tool will generate the kustomization.yaml file and the associated the configuration files and deploy everything for you.
From our experience, the main caveats of using the viya4-deployment are :
When SAS Viya 4 was first released, the deployment approach was straightforward...There was only one way to deploy Viya : get the deployment, build the manifest with Kustomize, then apply it.
While very simple, this method was not always ideal for several reasons (complexity of the configuration with Kustomize, need to redo all the steps for each new update, etc…).
Today we have the Deployment Operator, the viya4-iac and the viya4-deployment tools that bring significant capabilities in terms of automatization and configuration simplification.
However to quote some wise people, you need to learn how to walk before you can run.
So if you want to become a SAS Viya deployment expert, you first need to know and understand how to install your pre-requisites and deploy Viya manually.
Make sure you do it at least once, before starting to leverage the automation tools that will, of course, make your life much easier, but also hides the complexity and details of the implementation... (that you’ll need to know when problems arrive or when your customers’ requirements don’t fit).
Unlike its predecessors, this new version of the SAS Software is not running directly on the Operating System, but inside a Container orchestrator (Kubernetes). It is a new world for many customers and IT teams, so you’ll likely be expected to provide some guidance there... even though you are not a Kubernetes specialist.
Also, keep an eye on this GitHub projects as they are continuously extending their capabilities (BYO network, private cluster support, fast ephemeral storage provisionner, deployment operator integration, etc…).
That's it !
Thanks for reading !
Special Thanks to my SAS colleagues (Thomas Pangborn, Norman Johnson, Mano Meenaksh and Matthias Enders) for their help and support in testing and documenting the various approaches of the the Viya 4 deployment.
Find more articles from SAS Global Enablement and Learning here.
Both 'SAS Infrastructure Requirements' links not working for me.
Hi Pieter
Thanks for the feedback
I fixed the links, it should work now.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.