All roads lead to Rome : Three Tables and one Diagram to review the SAS Viya deployment methods
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 :
|
TLDR;
If you are really looking for a high-level summary, here is it is :
- There are several ways to deploy Viya today : manual deployment, deployment operator or automated deployment with ansible (viya4-deployment GitHub project).
- There are also several ways to build and prepare the underlying Kubernetes cluster for a Viya deployment.
- Depending on the chosen ways you won’t have the same possibilities and you also have to maintain the resulting environment a bit differently.
- A good summary of the article is provided as a Diagram in the
"Recap" section at the end of this article..
Deployment is a 3 step process
Deploying SAS Viya is always a 3 step process :
- Create the Infrastructure (includes K8s cluster and other components like an external DB),
- install the pre-requisites for the Viya deployment,
- deploy SAS Viya
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).
Step 1 - Create the Infrastructure
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 GitHub project
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.
Step 2 - Install the pre-requisites
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.
Step 3 Deploy Viya
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 |
Manual Deployment vs Deployment Operator
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:
- Get and unzip the deployment assets on the jumphost
- Run the kustomize build to generate the manifests
- Apply the manifest in your Kubernetes cluster with the kubectl command
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 GitHub project
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.
Recap : the deployment methods landscape
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).
OK but what is the recommendation ?
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 :
- Prepare the infrastructure and pre-requisites:
- Create the cluster : Work with the customer to create the cluster with one of viya4-iac GitHub tools (remind the customer that he is the one in charge for this part and for the long-term maintenance of the Kubernetes cluster).
- Install the pre-requisites : run the viya4-deployment GitHub tool (use only the “baseline” tag), so all the expected pre-requisites with the proper version will be in place before the deployment.
- Deploy Viya :
- For a stable cadence : follow the documentation to deploy SAS Viya with the Deployment Operator (SAS default preferred method). The deployment operator simplifies the upgrade process which happen frequently with the stable cadence.
-
- For an LTS cadence : consider the pros and cons between Manual and Deployment Operator depending on your customer requirements, a manual deployment might be simpler…it doesn’t require the customer IT team to be familiar with the concepts of Kubernetes operator and Custom resources and the upgrade process is less frequent.
In which cases should we deploy Viya with the viya4-deployment tool ?
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:
- Limited time to perform the deployment and the common customization : the tool is ideal to quickly setup a complex and rich environment (perfect for a PoC or demo).
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.
- If the viya4-iac tool was used to build the cluster, the tool can also take advantage of that to read directly several of the required configuration values from the terraform state and even more simplify the deployment.
- When you are working in a destroy/rebuild mode : the tool is using ansible and as such brings a good level of idempotency. It is easy to uninstall/reinstall.
From our experience, the main caveats of using the viya4-deployment are :
- It expects a predefined specific NFS structure for the deployment Persistence Volumes. While the tool can create the structure for you, it is not always possible, and it might not correspond to the customer requirements.
- It hides the complexity of the configuration (which is good). But the drawback is that when you want to make your own post deployment configuration, the way to do it is a bit different from the standard officially documented steps.
Conclusion
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.
