Throughout the evolution of analytics, something has remained constant, preserving the capability to execute the same programs that you could run some time ago. Over the years and the different releases, SAS has always been able to execute classic SAS program code. How does the new SAS Viya (2020.1 and beyond) run SAS code?
SAS Cloud Analytic Services (CAS) is SAS Viya principal execution engine, providing an optimal run-time environment for data management and analytics thanks to its in-memory, massively parallel processing capabilities.
Yet, when you want to execute some code that requires traditional Foundation SAS, you can still use a traditional SAS engine. It can be just very basic code, such as
proc print data=sashelp.cars; run;
This program will run in any environment, from SAS 6 on a mainframe, to SAS Viya 2020.1 in the Azure cloud. Obviously, the underlying mechanics of how the different host environments execute it will change.
What are the components involved with running SAS code in the new SAS Viya (2020.1 and beyond)?
This slide by itself may be overwhelming, but it is a guide to the intricacies involved in running SAS code. For this post, it will simply be a visual reference for a light introduction, without the expectation of explaining every single box and arrow.
The key point to get from this diagram is perfectly stated, with a concise sentence, in the official documentation: A programming run-time environment includes several SAS Viya servers.
If you look at the diagram following horizontal lanes, you may recognize 3 main servers: SAS Compute, SAS/CONNECT, and SAS Batch. All 3 can execute SAS code submitted by end-users.
For all 3 components, the flow is represented moving from the left to the right. Clients interact with front-end services (SAS Compute service, SAS/CONNECT spawner, SAS Batch service), which all use an intermediate SAS Launcher service to start the back-end servers, thanks to SAS Launcher integration with Kubernetes API.
Other SAS Viya services provide additional capabilities, ranging from authentication (SAS Logon service) to context definitions storage and retrieval (SAS Infrastructure Data Server), but describing them all would require a level of detail that would push this post to be unbearable by many.
All three use the Launcher service, a microservice that provides API endpoints for running a process. A new Kubernetes pod is created each time a service makes a request to the Launcher service to start a new process. With the current release, the pods are launched through a Kubernetes job.
A brief note to help you transition, if you are familiar with previous SAS releases.
The SAS Compute server has a similar architecture in SAS Viya 3; a notable difference is the removal of the SAS Launcher server, which is a process used in SAS Viya 3 by the Launcher service to start a back-end Compute server process.
As you can see in the above diagram, the Launcher service, in the new SAS Viya (2020.1 and beyond), talks to Kubernetes, which is responsible for launching the back-end servers in a new Kubernetes pod.
On the other side, SAS Viya 3 did not have a batch client or server, yet these components are not totally new: they are an evolution of the SAS grid client utility (a.k.a sasgsub) and SAS batch sessions available with SAS Grid Manager in SAS 9. Although the current SAS Viya release (2020.1) still does not include all the workload capabilities available with SAS Grid Manager, Kubernetes provides the required infrastructure to support submitting batch jobs and distributing them on multiple back-end servers (executing in Kubernetes pods).
All three SAS Viya servers - SAS Compute Server, SAS Connect Server, SAS Batch Server - are implemented using the same common base image, called sas-programming-environment.
To execute SAS code, the common image contains all SAS Foundation binaries, but no license - this prevents any fraudulent distribution of SAS. The license is applied at run-time from Kubernetes and controls what PROCs can be executed, based on the solution that has been licensed.
The following picture represents the Kubernetes artifacts involved with the execution of the back-end servers.
Again, horizontal lanes represent the three different servers - Compute, SAS/CONNECT, Batch. On the left, you can see different Kubernetes pod-templates: sas-compute-job-config, sas-connect-pod-template, sas-batch-pod-template. They contain information for Kubernetes about how to instantiate a new pod; they all reference a common base image, called sas-programming-environment, plus specific information to describe how to instantiate various kinds of pods, which correspond to specific servers.
Kubernetes uses that information to create specific containers, called either sas-programming-environment, just as the image, or sas-batch.
The containers, finally, run inside the pods that represent an instance of a Compute server, SAS/CONNECT server, or Batch server.
This overview clearly only scratches the surface of the SAS Programming Run-Time architecture in the new SAS Viya 2020.1. For additional information, please refer to the official documentation. Even better, you could deploy Viya, and have a look at it yourself!
Note: This article addresses features of SAS Viya 2020.1 (and later)
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.