This is my first post for 2025 and I'm feeling a little retrospective. Looking back over the past year or so, I wanted to share some of my opinions on how the deployment methodologies available for the SAS Viya platform provide us with great opportunities. It's tricky to nail down the nuance in all cases, but I'm going to give it a shot anyway. Feel free to share your feedback with me and we can work to refine this more together.
Here, there, almost anywhere
Do you remember the Multi-Vendor Architecture™ approach that was employed with SAS software since the 1980's? Base SAS and the SAS Business Intelligence platform were compiled to run on wildly different operating systems that include Microsoft Windows, multiple flavors of UNIX and Linux, as well as different mainframe platforms.
Fast-forward to today and let's look at SAS Viya. From an operating system perpective, now the Viya platform is only available to run in supported flavors of Linux. Full-on UNIX, Windows, and mainframe operating systems are no longer capable of running Viya software directly. However, this isn’t a significant limitation in the modern era of virtual platforms and containerized software.
What matters more is our support for various Kubernetes providers. This includes major cloud hosting providers like Amazon, Azure, and Google, as well as Red Hat OpenShift and general open-source Kubernetes. If you can run Kubernetes, it's likely you can host SAS Viya on it.
Repeatability is better than one-off
Any large enterprise software system needs to provide configuration and customization options to ensure a good fit. SAS has always gone above and beyond in this regard… but even so, toolsets, training, and expertise do have a limiting factor in terms of what can be reasonably accomplished.
With SAS 9, we use the SAS Deployment Wizard (in conjunction with our internal SAS Planning Application) to configure the installation of the SAS Business Intelligence platform. The SDW provides a thorough set of prompts and input validation to help you get it all done. But what if there's a situation beyond what it's programmed to deal with?
SAS Viya's approach to deployment lacks a guided wizard-like utility with a point-and-click UI. Instead, it leans into a modern DevOps approach to manage all aspects of the deployment using plain-text files (often in YAML format) in conjunction with several command-line utilities. This allows us to script all elements of the Viya platform's deployment and subsequent configuration for process repeatability and reliability.
It's not "My way or the highway"
There are thousands of potential decision points to make when planning a large-scale Viya deployment for the enterprise. This is multiplied when we consider the rapid pace of Kubernetes evolution as well as the infrastructure technology underpinning it all. While there are many proven practices to ensure SAS software runs well, it's not possible to provide up-to-the-minute prescriptive guidance on everything. We simply do not have a chance to test every possible permutation as technology marches on.
To be clear, we do have ways to help. The SAS Viya Infrastructure as Code (IAC) projects are super useful to provide example guidance for provisioning hardware and Kubernetes infrastructure that is suitable for the Viya platform. With flavors of the IAC available for Amazon Web Services (viya4-iac-aws), Microsoft Azure (viya4-iac-azure), Google Cloud Platform (viya4-iac-gcp), as well as general open-source Kubernetes (viya4-iac-k8s), there is a lot to help get started.
But note, the IAC isn't the only way to do it. As a general rule, the customer is responsible for providing the hardware and infrastructure needed to run Viya - we don't do that for them (unless they elect to engage with SAS Managed Cloud Services for that kind of turnkey approach). The point here is that if a site would like to implement hardware or other infrastructure choice not offered by the IAC project or otherwise through their own standardized practice, that's fine, they can do that. We only ask that those choices remain in alignment with the SAS Viya platform's System Requirements.
This concept extends further with the actual deployment process of the Viya platform. SAS provides a number of example configuration options (requires a free sas.com user account to access) to setup Viya as needed. This is another area where a site might have new requirements that haven't been addressed specifically yet… SAS can only provide a finite number of example configurations after all. The nifty thing here is that the configuration options for the Viya platform's deployment and operation are effectively managed by open-source, plain-text files (usually in YAML format). This means that working examples are provided for a site to refer to and extend upon if needed.
Wrapping this up
Over 700 words in at this point, and I've barely scratched the surface of the tremendous versatility that the SAS Viya platform offers for running in a way that's efficient, right-sized, and flexible to the needs of your site. Let me try to sum up by combining the points above.
Because Viya can run in a range of environments in the cloud, at your site on-premise, or some hybrid of both, then you can experiment with moving things around to see how it all performs. The sheer range of infrastructure options for storage, networking, machine types, availability, elasticity, and so on means that the Viya platform deployed for one site could be optimized in ways completely different than for other sites. So, how could you try them all out to determine what's best?
Well, I really enjoy the DevOps approach where all aspects of the infrastructure and deployment can be scripted to full automation. With a fire-and-forget ability to stand up new environments on the fly - as well as tear down those no longer needed - then we can iterate through all kinds of options, configurations, and implementations to get our target state where Viya is optimized for our site's use. Extending that concept, we can continuously improve the environment as well by test new technologies and configurations. Don't forget, migration of content from one Viya site to another is also a task we can automate to make it well defined and repeatable.
In short, we can move fast and break things if we want to. Once the satisfactory production-level solution is identified, then we can establish a documented and repeatable process to recreate it or use it as a template for other environments. Almost any customization a site might require that's logically consistent with Viya's system requirements is on the table - and with the fast pace of technology's progress today, that's great!
Find more articles from SAS Global Enablement and Learning here.
