- SAP Managed Tags:
This blog is part of the larger series on all new developer features in SAP HANA SPS 11: SAP HANA SPS 11: New Developer Features
The History and Value Proposition of XS
From the very beginning, SAP HANA was always intended to be more than just a database. SAP has long referred to SAP HANA as the SAP HANA Platform. And with good reason. HANA has all the traditional capabilities of a relational and analytical database, but also has many extra features like full text search, spatial processing, and predictive analytics.
Figure 1: SAP HANA Platform
These features have been designed to be deeply intertwined and embedded in the core HANA processing. This way they also benefit from the In-Memory and massive parallel processing capabilities of HANA.
As SAP was building the first set of applications that leveraged all of these extended capabilities of SAP HANA, we began to see the possibility to build complete applications where almost all the processing took place within the database. Therefore it seemed disappointing in these cases to have to add to the infrastructure footprint of such applications by requiring an additional application/web server if that part was only providing minimal functionality.
We saw an opportunity to embed a small footprint application and web server within SAP HANA itself. And so SAP HANA extended application services (or XS for short) was first introduced with SAP HANA SPS 05. This enabled SAP, customers, and partners to develop applications which ran completely within the single SAP HANA "box". We could reduce architectural layers and by doing so delivery applications with a lower total cost of ownership.
This simplified architecture meant that a single process was used to install, patch and administer both the database and the application server layers within SAP HANA. It also meant that single application archive could be used to install with one step a complete application composed of everything from the data model, application logic, service enablement, and user interface.
XS Evolves Into XS Advanced
Requirements change over time and so too has XS within SAP HANA. SAP HANA extended application services in SPS 11 represents an evolution of the application server architecture building upon the previous strengths while expanding the technical scope.
Figure 2: XS Architecture as of SAP HANA SPS 11
Cloud Foundry
One of the driving requirements for the new SAP HANA XS Advanced was the desire to better unify the architecture of solutions built in the cloud and on premise. The SAP HANA Cloud Platform was already looking to adopt the open solution of Cloud Foundry as the base of their next generation offerings. Cloud Foundry provided the kinds of scalability options and flexible runtimes that are needed in the cloud environment and therefore makes a perfect match to the functionality HCP wishes to offer.
Today SAP HANA XS and the HANA native development model is offered both in on premise HANA systems and in SAP HCP. However XS in HCP is rather separated from the rest of the HCP technology architecture. The primary goal for XS Advanced was to unify these two delivery channels on a single base architecture.
Therefore XS Advanced is essentially based upon Cloud Foundry. In the near future it is planned that HCP itself will run based upon Cloud Foundry. For the on premise delivery of SAP HANA, we felt that delivering the complete Cloud Foundry technical stack was too much. Therefore we have created our own implementation of the Cloud Foundry APIs as XS Advanced in the on premise HANA delivery in SPS 11.
This means that the core concepts of Cloud Foundry will be present in both SAP HANA on premise and in SAP HANA Cloud Platform. For example Cloud Foundry standard build packs will be utilized for the language support in both environments. A single set of service brokers will be created for things like user authentication and HANA database connectivity and will be made available in both environments.
Runtime Support
By moving to the Cloud Foundry basis, one of the most obvious impacts is that now we have the foundation in SAP HANA XS to support multiple languages/runtimes. We will use standard Cloud Foundry build packs as the basis of the XS language support.
Therefore starting with SAP HANA SPS 11, XS Advanced will be delivered with and fully support both Apache TomEE Java and Google V8 JavaScript/Node.js. We will also have a C++/FastCGI language runtime, but at least initially this is reserved for SAP internal and perhaps limited partner usage.
In both of these runtimes, you will find a quite pure delivery of the standard runtimes. For the node.js runtime we only create a small variant to add supportability aspects for example. This greatly supports the easier porting of existing applications onto SAP HANA.
SAP's general approach to the usage of these language runtimes is that most new development will be done in Node.js while the JAVA runtime is primarily utilized for porting of existing libraries and applications. Therefore you will notice that SAP makes a larger investment in custom tooling and libraries/modules for the Node.js runtime. However both are fully supported by SAP and customers/partners and choose whichever works best for them.
Speaking of choice, this overall architecture being so open creates the possibility for the future to have a true bring your own language/runtime scenario. Customers/partners will have the ability to utilize other Cloud Foundry buildpacks. There are many such buildpacks for many popular languages such as Ruby, Go, and PHP. See listing here.
Micro-Services
But the benefits of this new architecture aren't limited to just the choice of runtimes. The core architecture is designed to operate as Micro-Services. But what exactly do we mean by Micro-Services?
In today's XS environment we have a single operating system process called XSEngine. Within this process we create a pool of JavaScript Virtual Machines. The are clones of a single runtime version. Therefore there are no options to control which version of JavaScript your application runs against. There are some limited configuration parameters that apply to the entire pool of JavaScript VMs, but no way to configure memory or other scaling parameters per application. Finally as all the VMs live within a single operating system process, if anything goes wrong there is the potential to crash the entire XSEngine process.
In the new Cloud Foundry based architecture of XS Advanced, things work very differently. First when you deploy an application or service a copy of the entire Java or Node.js runtime goes with. This way each service is isolated and locked into their version. Even if you upgrade the entire HANA/XS system, already deployed services continue to run with their existing runtime providing better stability over time. It isn't until you would deploy the service again that you could pick up a newer version of the specific runtime. This allows single services to target different runtime versions in parallel.
At the operating system level, we also no longer have one monolithic process hosting all the runtimes. Each runtime instance has its own operating system process. This allows for much better process isolation ensuring that a single poorly written or behaving service can't disrupt other services/applications.
Figure 3: Separate Operating System Processes for Each Service Instance
This also means that you have much better scaling options. Single services can have different memory limits and can be scaled to multiple instances on a single host or even across multiple hosts. This will often then lead to different designs where single applications are broken into many different services. Therefore you can mix and match multiple languages/runtime versions within a single application. You can also scale and tune applications accordingly. For instance the service part that serves the static web content probably needs less memory and fewer instances than the transactional REST services within the same overall application.
Figure 4: Applications with Multiple Services and Individual Instance, Memory, and Disk Limits Per Service
Scaling and Deployment Options
The new scaling options don't end at the individual service level, however. With XS Advanced the overall architecture is a bit less intertwined with SAP HANA in general. This brings more deployment options.
The default installation/upgrade option will still place XS Advanced directly on the HANA server for the "all in one box" experience. This way we continue the primary business benefits that drove SAP to create SAP HANA XS in the first place.
But now SAP HANA XS advanced can also be installed on a separate host from the SAP HANA database. This can be done to scale XS independent of the database. You have many more XS nodes than SAP HANA database nodes. You can also install XS advanced on a non-HANA certified hardware. This allows for using cheaper hardware to run the less memory intensive XS processing. We will also allow XS advanced to be installed in a separate network from SAP HANA itself. Therefore you can install XS advanced into a DMZ and have a firewall between the XS and database layers.
Backwards Compatibility
Its important to note these innovations described here are delivered alongside the existing functionality. We haven't removed or disabled any of the current architecture. All of your custom development objects remain exactly where they are today and will continue to function as they do already. The current XS Engine remains a part of the HANA infrastructure, although now renamed XS Classic so as to distinguish it from the new capabilities delivered as part of XS Advanced. Likewise the HANA Repository remains in place even as we move to Git/GitHub as the future design time/source code repository. Eventually these older capabilities will be removed from HANA, but that point hasn't been decided yet. SAP won't removed them until we see a critical mass of customers moving their development objects to the new capabilities we describe here.
Therefore customers can upgrade with confidence to SPS 11 without fear that the new innovations will somehow disrupt their existing applications. Customers can decide how and when they want to begin to move applications to the capabilities and only do so once they are comfortable with everything involved. In the mean time everything they have continues to run exactly as it does today.
Closing
All of the architectural changes we've described here can be summarized down to one key point: choice. SAP HANA XS advanced offers customers and partners the freedom of choice of technologies, tools and deployment options for high-scale development and operation of native SAP HANA applications.
We also make it easier to choose between on premise and cloud deployment. Because of the shared architecture described here, it will soon be easy to develop a single application that can be deployed on premise, in the cloud or both without any coding changes.
51 Comments
