HANA Cloud tales: Are new extended application services in SAP HANA a threat to NetWeaver Cloud?
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:
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?
There are two ways in which the platforms are different.
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.
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.
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.
Great blog as always! I do want to point out a couple of things that I think SAP has been doing that really stir up confusion around their cloud strategies. I see some of the results of this show up in this blog.
First - HANA Cloud, Netweaver Cloud, HANA App Cloud, and HANA One on AWS (the Cloud?). Oh my. The only way I can make sense of this is as follows:
HANA Cloud (as used in the first screenshot) - SAP seems to use this terminology to refer to any HANA deployment in the sense of a private cloud. I don't think this use meets the standard definition of "Cloud", and so it is disingenuous to call a HANA deployment a "Cloud". I wouldn't use this term.
HANA AppCloud - SAP's name for the HANA cluster(s) that supports its public PaaS and SaaS offerings. These HANA instances are never (as far as I can tell) directly accessed by SAP's customers, so in my opinion this nomenclature is just marketing. SAP could replace these clusters with something else and no one would know the difference in a lot of cases. For example, in BI OnDemand, the database for the public free version is SQL Server. Meanwhile Netweaver Cloud provides both HANA and traditional database persistence options. I think it's questionable to call this a "HANA" cloud because it can't be bought directly.
Netweaver Cloud - A PaaS cloud that meets the standard definition of a cloud. It runs (at least partially) on the HANA AppCloud.
HANA One on AWS - A standard HANA single-instance server available for deploy on AWS (a non-SAP IaaS Cloud). Providing AWS as a HANA deployment option is not a cloud strategy. It's just a different flavor of traditional deployment options. It's good, but it doesn't cloud-ify HANA.
Cloud apps - SAP has several applications that are legitimate SaaS cloud offerings. ByDesign, S&OP, Streamwork, Successfactors, and the new EPM OnDemand are all examples. Perhaps this is what SAP means when they say "HANA AppCloud", but I don't think so.
I think we all agree that SAP desperately needs to straighten out its terminology here. There are standards around this stuff and SAP should follow them. Currently SAP often ignores standard definitions, which is making it look foolish.
Second, I find the definition of 2-tier vs. 3-tier very problematic in general. Overall it's very hard to tell. I'd argue that XS Engine in HANA is a sort of 2.5-tier, since it actually is a separate application server bundles with HANA. It's interesting that in the architecture diagrams shown in the blog, there are almost always the traditional 3 tiers shown. In the case of S&OP it is especially explicit.
For the moment, I believe that a 2-tier architecture based on HANA and a thin layer of application services will be helpful for some types of apps but will fall short for the vast majority of apps for some reasons you discuss (security, monitoring, lifecycle management, developer tooling). I also believe that adding a full-featured applications server to HANA won't really provide much value and will introduce significant overhead for HANA deployments. I don't see why an application server that is part of HANA running on the same hardware is better than an application server running next to HANA.
I'm hoping SAP can make this clear as well, or clarify where they are planning to stop if they don't plan on adding a full-featured Java application server to HANA.
I agree that with the term "HANA Cloud" SAP has muddied the water even more and made things more confusing. I'm hoping that there will be more clarification in Madrid.
I especially like this comment, because it illustrates the confusion which occurs when definitions - in this case "cloud" - aren't defined succinctly enough.
I think I understand the motivation behind this push on two-tier - moving as much logic to the client (browser, mobile, etc.) as possible but the costs - as you correctly imply - are adding complexity and "significant overhead" that would otherwise not be present if HANA was just acting as the data layer. I'm sure SAP Basis consultants are jumping up and down in glee - these are tools (WebDispatcher, etc) / problems with which they are very familiar.
As always an interesting blog from you Dick!
Can't comment on all of it right away as I'm still a bit jet-lagged coming from Vegas and I just spend the whole day at EclipseCon. There's much to set straight, but let me get to the most important question first:
Why do you get that impression?
In general, the idea of the HANA Cloud platform is to provide a coherent and complete platform that supports many programming languages/models including Native HANA (e.g. RDL on top of XS) as well as JVM-based languages and Rapid Application Development tools.
That's fully in-line with our ambition to make the platform attractive to as many developers as possible, regardless of what language they prefer: Dennis Howlett put it perfectly by calling it "bring your own language!"
At the moment, NW Cloud is first the tangible implementation of the HANA Cloud platform, but other capabilities will follow shortly.
So, no... the answer is a clear NO. Any further questions?
You may want to (re-) read my recent blog on NW Cloud to see how it fits the bigger picture of HANA Cloud platform.:
I asked the question but then I said that HANA XS isn't a threat to NWCloud, because of different deployment options and, as you also say, different development languages.
Are there are other aspects which must be considered? If I'm a large company with Java and SQLScript developers, I could use either platform to solve a particular business need. What sort of problems are solved best by HANA XS and which ones by NetWeaver Cloud?
Guess Michael Bechauf gave a great answer to this on in his blog today: Native HANA apps, language containers and HANA Cloud: Part 1 of 2
The thought of bringing ByD/LoB over scares me.
Good post though. I'll hook you up with some stars.
I'm sure it won't help but the thought of what it would imply is an interesting one.
Sounds like you missed our CD100 session at SAP TechEd Las Vegas, "SAP HANA Extended Application Services". It will be held in Madrid as well. I presented this session together with Tom Jung.
XS works together with the SAP HANA repository, which provides lifecycle management features such a object versioning, transport, software component delivery and patching, etc. Monitoring is provided by the administration perspective in the SAP HANA studio. The users in XS are DB users, which simplifies security. As of SAP HANA SP5 we support simple authentication and SAP logon tickets, in SP6 we plan to support Kerberos and SAML2 SSO.
Essentially, XS is a key part of the "SAP HANA as a platform" story, it provides an application development platform for building browser-based (or mobile) applications which run against SAP HANA.
Best Regards - Ron Silberstein, SAP HANA Product Management
Thanks for the additional details.
I'll be in Madrid - so I'll try and make your session.
Sounds good Richard, Tom Jung will be there presenting CD100 and also CD163....CD100 is a 2-hour lecture with demo, CD163 is a 2 hour hands-on session for the same topic (SAP HANA Extended Application Services).
This was a very helpful explanation. I'll also check out the slides for the CD100 session. There is a ton of confusion floating around about this right now (I talked to at least 2 people I can remember at TechEd who gave me the impression that HANA was embedding a Java application server), so it might make sense to publicly post the deck from CD100 now rather than waiting for more TechEd session attendees.