SAS ESP 5.2 – Highlights for Architects and Installation Engineers
As explained by Mark Thomas in his comprehensive article, SAS Viya 3.3 introduced improved integration with SAS Event Stream Processing 5.1 components and products.
In a nutshell, SAS Event Stream Processing (ESP) is the SAS solution to run event stream processing models in real time, a very high-throughput and very low latency engine with streaming analytics capabilities.
The objective here is to revisit Mark’s article with the new SAS ESP 5.2 version and SAS Viya 3.4 integration and also to touch on some important changes brought by this latest ESP version from an Architecture and Deployment standpoint: docker deployment for ESP on the Edge, security changes, etc.
ESP products
If you are new to ESP, you might be a bit lost at first and confused by the various ESP products and components.
There are only a few changes compared to Mark’s article for SAS ESP 5.1. We still have 4 ESP products, but they have different licensing rules and deployment modes and platforms.
Let’s recap!!!
Hopefully, this table will help to quickly identify the key differences between the products in terms of licensing, deployment mode, and platform support. However don't take it for granted for always. The licensing rules are not static and may continue to evolve.
Deployment options
Until SAS ESP 5.1, there was a difference in a “stand alone” deployment of ESP compared to what you would do when ESP was a part of a larger SAS Viya order.
With SAS ESP 5.2, no matter if ESP comes alone or bundled with another SAS Viya solution (VA/VS/VDMML, etc…), the deployment will be done with an ansible playbook and the ESP components will be integrated with several SAS Viya Services.
Add-on products such as SAS Event Stream Processing for CAS, SAS Event Stream Manager (ESPCLUSTR), or SAS Event Stream Manager (ESPMGR) are also deployed via the ansible playbook.
If you are familiar with SAS Viya deployment with ansible, the table below can be useful to understand the SAS Viya host groups and services that come with the ESP products.
So even the stand-alone version of ESP comes with all the SAS Viya services required to the ESP-Viya integration (only the items in bold correspond to the ESP core capabilities).
Therefore:
- ESP Studio and ESM will now always use the SAS Infrastructure Data Server (PostgreSQL) by default to store their content. (Note that Streamviewer continues to use the small footprint H2 database in SAS ESP 5.2.)
- Authentication in ESP Studio and ESM, like any other SAS Viya web application, is now done through the SAS Logon Manager.
- ESP Studio and ESM end-user’s identities are now managed through the SAS Viya Identities microservice.
- The SAS message broker allows other applications to communicate with ESP application (notifications when a model is selected as a champion in Model manager).
The "Host Group placement" and "HA" considerations explained in Mark Thomas’s article remain valid and are now true for any type of ESP Server installation (either stand-alone or integrated in SAS Viya). I encourage you to read them if you are working on the architecture design of your ESP solution. The only case where the deployment method is different is the ESP for the Edge computing.
ESP for Edge computing deployment
SAS Event Stream Processing for Edge Computing requires a separate order and is a smaller footprint version of SAS ESP to allow it to run on edge devices such a sensor, routers, etc.
The table below shows the differences in terms of components included in ESP Edge versus the full ESP. Also, the SAS Viya services and infrastructure servers are not part of the ESP on the Edge deployment (which significantly reduces the footprint).
ESP for Edge computing is also quite unique for a SAS product. In the current licensing policy SAS® Event Stream Processing for Edge Computing is licensed under a perpetual license structure. The customer pays a one-time fee to purchase a given quantity of the software and owns it forever.
However, annual support and maintenance is a separate charge and has an annual fee (But again the licensing rules are subject to chaneg in the time).
With the 5.2 release, the deployment of SAS Event Stream Processing for Edge Computing can be done in 2 ways: standard Linux deployment or Docker.
To ease the roll-out of ESP on edge devices, it is convenient to have a "central software repository" with the ESP packages or image, so the remote devices can simply pull, deploy, and run ESP in an automated way.
This central repository will be either a package mirror or a docker registry with the ESP docker images.
Standard Linux deployment on the Edge
The first thing to
ESP deployment on devices with ARM processors (the most widely used architecture in mobile devices) is also supported but only with Debian Linux or Ubuntu Operating Systems.
A mirror repository is required for SAS Event Stream Processing for Edge Computing and will play the role of the "central software repository."
The "edge_mirror.sh" script provided as the "Mirror Extension for SAS Event Stream Processing for Edge Computing for SAS Viya 3.4" (see screenshot below) will orchestrate the mirror manager to create a specific Edge repository and place packages in separate directories (basic, analytics, astore, gpu, etc).
Finally, the customer can selectively deploy packages to the edge devices using specific edge package managers (rpm, deb). The linux packages can then be installed (respecting the package dependencies) using the customer preferred way (rpm, apt-get). Note that it is up to the customer to manage a potential automation of the pull and install procedure on the local edge device.
Docker deployment on the Edge
If the customer is running Docker on the edge devices, it can greatly simplify the deployment and its automation. Nevertheless, keep in mind that the docker version comes with some restrictions compared to the Linux version (no GPU support, no ARM support).
Instructions are provided in the "ESP for Edge Computing" deployment guide to create a local docker registry that can be used as a centralized repository to deploy ESP on edge devices. Once it is in place, all you must do to start ESP on the Edge is to run a single command to "pull" and start the docker image. Note that two flavors of the docker image are available, "esp-edge-base" or "esp-edge-analytics" (includes SAS ESP Analytics and ASTORE support). The "base" image size is 750 MB, whereas the size of the "with analytics" one is around 1.5 GB.
Security
A key change for the security topic in SAS ESP 5.2 is the way to configure encryption and authentication for ESP servers and clients with the new Security Configuration file. This file is read by the ESP server at startup time to determine if the ESP is secured (TLS encryption for communication from ESP clients) and, if ESP Server authentication is in place, which authentication method is used.
Here is an extract of this configuration file:
Select image to see a larger version.
Thanks to the improved ESP and SAS Viya integration, "SASLogon" will almost always be an option for ESP Server authentication (even the stand-alone installation comes with SAS Logon manager).
Finally, another new feature is the support of an additional authentication method: OAuth 2.0 Cloud Authentication and Authorization, which can be very useful for integration in PaaS Cloud platform such as Cloud Foundry.
Note that this authentication method (unlike the existing OAuth method) requires a “live” UUA server to validate end-user credentials in real time.
Conclusion
This article is far from being exhaustive on architecture and deployment changes in SAS ESP 5.2. It is simply an overview and provides considerations for some of them. However, if you are looking for more details about the architecture, deployment, and security with SAS ESP 5.2 then stay tuned. A new SAS ESP VLE with deployment hands-on will soon be available.
Thanks for reading!
