Native HANA apps, language containers and HANA Cloud: Part 1 of 2

Yes, I know, it’s a rather omnious title for a blog bost, but my goal is to provide a different view on the recent HANA announcements.

Business travel is always a great way to work on a new blog; lots of time spent at airports and in airplanes. Last week, I’ve been to TechEd Las Vegas, where I helped the SAP HANA Startup Focus Program (SFP) answer questions about HANA and presented about HANA as a platform. It’s amazing to see how the SFP has grown over the last few weeks. When we started the program in March, I’ve helped the first batch of 10 companies get ready to demonstrate their HANA-based solutions at SAPphire in Orlando. Since then, I’ve moved back to my role in HANA product management to define platform features for partner and ISV enablement. Kaustav, Ben, Hardik, David and the rest of the team have taken the fire and turned it into a volcano!

From TechEd, I went straight to visit one of our North American customers which has trusted SAP with its business for many years. They are just in the process of transforming their business and are evaluating HANA as an Agile Data Mart to quickly discover new patterns in ERP processes.  HANA appealed to them because their new business model is such a dramatic shift, that it’s essential for them to determine quickly when supply chain, production processes, global transportation, trade compliance and market development are not optimally synchronized. They wanted the flexibility to quickly discover how core metrics in their business were changing during this transformation. Rather than building ERP-based reports, they will instead derive KPI metrics from the core ERP data replicated into HANA to monitor their business. They plan to initially provide HANA’s modeling environment to their business analysts, but will gradually build new agile applications on top of HANA in order to quickly adjust to new business conditions and best practices.

It was a little strange to move so quickly from startups, which are just trying to kick-start their business on HANA, to a very mature enterprise using HANA for an agile business transformation. But it’s pretty damn exciting. At the core is HANA as a platform for new type of business processes and applications, which brings me to the topic of this blog. There have been many announcements at TechEd regarding HANA as a platform that can be operated on premise as well as in a public or private cloud. I had many people ask me questions, so I decided to provide my own spin on these new technologies and deployment models. It’s obviously work in progress, and I’m sure more will come at TechEd/SAPphire Madrid. But for now, here is my take, which I didn’t try to synchronize with marketing, so we’ll side if I get my hands slapped because I’m not “on message” 😉

My hope is (beyond not getting my hands slapped) to get lots of questions from you, because we will be working on a public slide deck that will explain all this, so your questions will give us a sense of what to focus on.

The announcements were two-fold: First, there was a lot of talk about programming languages and language containers. HANA Application Services comes with JavaScript support, and HANA deployed in the NetWeaver Cloud comes with a Java engine, and as a result, obviously support for every Java VM based language like Groovy. Second, Vishal announced support of HANA on Amazon Web Services. In other words, NetWeaver Cloud is both a deployment model as well as a language offering for HANA, whereas AWS stays silent on what programming language to use. That’s not a surprise, because AWS is pure infrastructure, a machine and an operating system in a virtualized environment, whereas NetWeaver Cloud is both infrastructure as well as middleware.

HANA on NetWeaver Cloud also comes with its own Java programming environment based on Eclipse, whereas HANA on AWS offers HANA development tools and suggests HANA Application Services (aka XS) as a programming model – which is however not mandatory because you can certainly install additional middleware on the AWS instance to communicate with HANA and not use HANA Application Services.

That’s already a lot to digest, but now I want to throw in another topic into the mix: What is actually a “native HANA” application? I tried to write about both language as well as cloud infrastructure aspects of HANA in one blog, but decided that it would be too much. As a result, this part 1 of the blog will deal with language options and explain the concept of “native” applications, and in part 2, I focus on explaining the cloud deployment options for HANA.

It is certainly easy to see the point that an application that entirely runs on HANA, and that requires nothing but HANA is “native”. Effectively, this means that an application using HANA Application Services is per definition “native” – it doesn’t require an external Web server or middleware to connect to a Web browser, because it has a Web Server built in. Web requests are dispatched straight to a JavaScript engine which then allows to build the application logic (make database calls, generate HTML5 etc).

However, this Web server/JavaScript infrastructure is technically separate from the actual HANA in memory database kernel, and there are of course different access methods to the HANA engine than just through XS, like JDBC and ODBC. SQL code that is being executed in the HANA engine by means of JDBC from a Java middleware is executed with the same performance as if it was executed from within XS. There is just one big disadvantage of doing it through Java: Every SQL call through JDBC will require a roundtrip between the Java middleware and the HANA server, so if larger resultsets are copied, performance is lost.

Yet, that doesn’t mean that Java applications will always run slower through JDBC than on XS – it simply means that as an Java application developer, you need to avoid round trips, and the way you do this is by moving as much of the data processing logic where the data actually sits – into the database, by means of using SQL Script or the modeling capabilities of HANA. That has multiple advantages: First, the round trips are avoided, but more importantly, the SQL Script application code that ties multiple SQL statements together is executed as much as possible in parallel on different processor cores of the host computer. Any procedural statements within SQL Script are also compiled into machine code and are not interpreted at runtime, so it’s fast.

In other words, while a Java application accessing HANA is certainly not native to HANA because it always requires an additional middleware that runs outside of the HANA engine, a Java application can most certainly use a number of native elements of HANA that will make it much faster. But it comes at a price: It requires re-coding of the Java application and moving more processing logic from Java into HANA. You can’t have it all: If you want super-fast performance of data centric applications, the logic needs to shift into HANA and out of Java. For anybody who has ever worked with stored procedures of conventional disk-based databases, this is probably a well-understood concept.

As an extreme case, the Java application only does the HTML rendering – the rest all moves into HANA. You could say that this Java application is then “almost native” 😉

You could further ask whether any “almost native” application should become “fully native” by removing Java and utilizing XS for rendering instead. There are certainly additional advantages, like the fact that you wouldn’t need a Java middleware any more. Also, the XS JavaScript engine is very tightly integrated with the HANA engine, and such additional overhead through JDBC is avoided. XS is basically a very lean infrastructure, tuned for extremely high performance and low latency.

So, should it be a design goal for every application to become HANA native? My personal view: No. Java is there for a reason. It has different properties. It has maximum openness. It has a huge developer community. Even though SAP HANA may have aspirations to rival the Java community at some point, forcing every Java developer to immediately convert into a HANA developer would simply be the wrong approach. It also wouldn’t make sense, and the best way to explain why it doesnt make sense is from the perspective of the startups we have worked with.

A lot of the startups we have worked with came with a huge Java code base. If we would have required each startup to completely rewrite their application from the ground up to become a native HANA application, we may not have dozens but only a few startups working with HANA right now. At the same time, we have also delivered to the startups a very important message right from the very beginning: Don’t assume that just because HANA runs in memory, that connecting an existing Java application to HANA as a database will make the application run faster. Yes, it will likely run faster, by a factor 2 or 5, but it won’t get the dramatic performance improvements we were seeking in the program. In fact, we have preferred startups that had a problem that couldn’t be solved with conventional disk-based database technologies. They were most motivated to rewrite those parts of their application that by moving data-centric code into HANA would get performance improvements by a factor 100 or 1000.

At the same time, an application is more than performance-critical algorithms. It may have an administrative user interface. A workflow engine. Things, that just don’t need to have performance improvements, and that were just “good enough” the way they were written right now. Those could simply move their data into HANA, but leave the Java code untouched. The only issue we have encountered is that lots of startups have used Hibernate as a persistence technology, and unfortunately, there is currently no Hibernate database driver for HANA.

One final thought before I conclude part 1 of this blog: There is also another reason why not every application can become a native HANA application at this point: It is just a fact that Java as a language is more expressive and allows to implement more complex algorithms than SQL Script. SQL Script is what it says it is: A scripting language. It doesn’t have classes. It doesn’t do dynamic creation of objects etc. Even the combination of JavaScript and SQL Script together in XS may in certain cases fall short of what a developer can do with Java. JavaScript is a full programming language, but it is also weakly typed. You can implement object-oriented concepts on top of the core JavaScript engine, but the performance will never be as fast as a JIT-compiled strongly-typed, truly object-oriented language like Java.

From that, there is a certain dilemma: Keeping too much logic in Java will never get you to optimal performance results in HANA. At least when it comes to data-centric algorithms, there will be just too many round trips between HANA and the Java algorithm. You can move certain data aggregations functions into HANA and keep the core algorithm in Java, but that’s not ideal. But moving code from Java into JavaScript/SQL Script will likely hit the limits of the JavaScript interpreter. I don’t have proof for that, because XS is very new, but since I’ve written significant amounts of JavaScript code in my past, I don’t think it could be any other way.

I know what you will say, because several people have asked me that already:  Why not bring a Java engine into HANA? To that I will only respond with this: It’s not just the language, it would also require a tight integration of the Java Virtual Machine and the HANA engine, so that the JVM had knowledge of how HANA stores its database tables. For that to happen, Java would have to be open and free, because under the current licensing regime such a change would not be possible.

Since this dilemma exists, what HANA has done instead is to move as many standard data mining algorithms as possible into HANA itself, thus allowing application developers to use libraries such as the HANA Predictive Application Library. But for custom algorithms, SAP can obviously not offer an out-of-the-box solution in HANA. They will have to stay in Java, thus cannot be executed natively in HANA and therefore doesn’t yield optimal results.

I hope that you now have a good sense of the concept of native HANA applications, and the pros and cons of the various languages with which native and non-native HANA applications can be built.

With that, I leave you with hopefully lots of questions to ask, before we continue with part 2 of this blog, which deals with the cloud infrastructure options supported by HANA, and their various properties. You will see that the background of the programming languages and language containers will help you significantly to understand the infrastructure options as well.