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.
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.
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” ;-)
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.
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.