Background
The HANA Cloud platform was announced at the TechEd in Las Vegas.
The official page contains few details but I’d still like to use it as our start.
The SAP HANA Cloud Platform, a next generation cloud platform, is based on breakthrough in-memory technology from SAP. It will allow developers to quickly build impactful, highly scalable applications that leverage embedded analytics and the massive speed and scale of SAP HANA. Applications will deliver impactful experiences, including instant mobile access, that delight users and meet any business need.
SAP HANA DBServices: Can help enable access to HANA in the cloud
SAP HANA AppServices: Can help enable next generation applications using multiple languages and frameworks
My last blog entitled “HANA Cloud tales: EPM OnDemand on AWS is important but will it live up to its full potential?” focused on HANA DBServices.
In this blog, I’d like to concentrate on the HANA AppServices.
The first manifestation of these services is SAP NetWeaver Cloud which “ is the first application service within SAP HANA Cloud that is generally available to customers and partners. With the platform, customers and partners can rapidly create powerful Java-based applications with consumer-grade experiences on mobile and portal, integration to on-premise and other cloud applications and the reassurance of secure deployment and management delivered by SAP.” [SOURCE].
New Extended Application Services in SAP HANA
There is a curious paragraph in the press release that announced the HANA One that concerns other changes to the HANA environment:
New extended application services in SAP HANA are planned to deliver application server capabilities as services and to be embedded in SAP HANA to streamline application and data processing in one in-memory platform supporting HTML5 and JavaScript. The extended application services in SAP HANA aim to further reduce the application layers by selectively consolidating application server and real-time data server technologies together to streamline data processing and application development efforts to enable real-time applications.
New enhancements to SAP HANA® studio are intended to enable developers to build from an integrated development environment application by using SQLScript for data processing, JavaScript for logic control and HTML5 for the user interface (UI) representation in the same tooling. The additions to SAP HANA studio are planned to include an improved modeling and debugging experience and collaborative support with a new team development environment. Planned additions also include a repository browser, project explorer capabilities and source code repository natively within SAP HANA.
The extended application services in SAP HANA developments are intended to be exposed as services via newly enabled data access services, such as ODATA, ATOM, JSON, XML or XMLA. These exposed services could subsequently be consumed by any business-critical or consumer-facing applications.
Although the main focus of HANA AppServices (“Can help enable next generation applications using multiple languages and frameworks”) was on NetWeaver Cloud to build Java-based cloud – these features in HANA represents a different manifestation of this functionality that will be natively embedded in the HANA platform.
However, in my opinion, there is a block of functionality which is missing in this description.
This functionality is necessary for most enterprise applications and is usually provided by Tomcat, another application server or a PaaS. Without this functionality, then I really don’t see the ability of developers to create applications which are ready for productive use.
The questions remained, however, where was this additional functionality located?
The wide-reaching impact of this design pattern: HANA Explorer / BI
Despite its focus on a different product area – BI and the HANA Explorer, a recent blog from Chris Kanaracus sheds some light on this missing functionality
… HANA Explorer would have a two-tier stack, with the browser acting as "the front-end client hosting the HTML5/JS application," the document states. "UI orchestration is moved from the app tier up to the client."
Meanwhile, "HANA as a platform provides the web-channel connectivity, and hosts the HANA BI Services deployed in the XS engine," it adds.
No network configuration or connectivity management would be required and the "only visible protocol boundary needed for HANA BI is HTTP(s) endpoints," the document adds.
Note: SAP responded to Kanaracus inquiry with reference to the document’s status as a concept material:
The document is "technology concept material that we are discussing with our customers at events such as SAPPHIRE and TechEd as well as in our SAP Communities to gather and incorporate customer feedback and validation," an SAP spokesman said via email on Tuesday. "Generally speaking, these types of technology concepts may or may not become official SAP products, and no decision has been made as of yet about whether or when we move forward with turning the concept below into product."
The document to which Kanaracus refers also details the internal architecture of this offering which shows the missing functionality
What is curious is the technology that provides this functionality.
Products (like NetWeaver WebdDispatcher, etc) which we are familiar reappear again - a next-gen architecture based on old-school – although stabile - technology.
What is interesting point is that there are differences between this architecture and that normally associated with HANA AppCloud applications.
For example, here is the architecture for the Sales and Operations Planning OnDemand solution.
One interesting distinguishing difference is the use of the Lean Java Server vs. WebDispatcher. Could it be that there is a more fundamental difference between these types of applications? For the user, there is no difference but for a developer, the programming models are completely different.
A threat to NetWeaver Cloud?
The question that arises is whether this new development platform will be a threat to NetWeaver Cloud. Both platforms give developers the ability to develop applications which exploit HANA data and both provide the ability to use JavaScript and HTML5 to create UIs.
There are two ways in which the platforms are different.
Deployment options
There are four different deployment options which are possible with this “native” HANA Cloud App Service.
Note: The deployment pattern in private clouds was described in a recent interview with Vishal Sikka.
Note: I’ve only seen SAP-created applications on the HANA AppCloud. Thus, it won’t be an option for customer-created applications.
NetWeaver Cloud is just available as a OnDemand solution hosted by SAP.
Depending on the use case in question, a developer has definite criterion that determine where an application must be deployed. If a company is not yet willing to deploy applications on the public Cloud, the NetWeaver Cloud isn’t going to be an option. If a company wants to operate the Cloud application themselves, then a native HANA application on AWS is possible.
Development language
The two platforms are based on different development languages.
The River Development Language is a new addition and represents a different manner in which to interact with HANA.
The RDL development environment is a set of Eclipse tools that allows you to visually model application data, create database views of SAP HANA, and code business logic using a unique real-time compiler. The views are then exposed as services, which can be tested using open data protocol (OData) with a representational state transfer (REST) client simulator. [SOURCE]
Thus, there is currently no real overlap concerning the development language used to create applications on the two environments.
Note: Some might say that Java-based applications currently running on the HANA AppCloud (see the Sales and Operations Planning – architecture above) go against this pattern. I assume that such Java applications will eventually move to NetWeaver Cloud.
Conclusion
Regarding technical aspects (deployment option, development language, etc), there are true distinguishing criterion between the two environments. Where things get tricky is what business requirements can best be met on which platform – this aspect must be depicted in much more detail to provide customers with better guidance. This advice will become even more important in the future as both platforms mature.
I think the two-tier approach proposed by SAP for its Native HANA platform has potential. I’m very curious to see how it impacts not only the evolution of NetWeaver Cloud but also existing LoB OnDemand solutions (like Sales OnDemand) and Business ByDesign. The decision to move these existing solutions to this new paradigm would probably envision a major rewrite but would open up these offerings to a variety of new use cases.
- SAP Managed Tags:
11 Comments
