So, here is part 2 – written mostly on the same trip and in the same airplane as part 1. I was just afraid that if I wouldn’t write the second part immediately, weeks may pass before I would get to it.
Now well equipped with a (hopefully) thorough understanding of the interaction of language containers with the HANA engine, it will make it easier for you to understand the difference between HANA deployed as part of Amazon Web Services (AWS) versus deployed as part of NetWeaver cloud.
Let’s begin with NetWeaver Cloud. It’s a cloud that is operated by SAP, in a SAP data center, with unique advantages particularly with regards to providing a good integration between Cloud-based applications and on premise SAP systems at SAP customers. It therefore has a unique value proposition for startups and ISVs that want to benefit from a full-fledged Java development environment in the Cloud, HANA as a database, but also an integration to SAP customer systems. From a perspective of HANA, SAP both operates the hardware infrastructure as well as provide administration services for the HANA database.
However, the “NetWeaver” moniker also means that as part of this Cloud offering, customers, partners and developers will benefit from a Java middleware that is tightly integrated with the HANA database. As you know from part 1, “tightly integrated” does not mean that a Java Virtual Machine runs inside of HANA, but that an open source based Java stack communicates with HANA through JDBC. The cool thing is that it is very easy to switch to HANA as a database. So, if you have a Java application and want to see how it works together with HANA, you should consider NetWeaver Cloud. It’s a first class cloud-based Java development environment, and to learn more about it, be sure to follow steinermatt from the NW Cloud team.
But eventually, I would hope you want to do more and make your Java application more native to HANA. From part 1 of this blog, you know what this means now: Try to find data-extensive parts of your Java application that you can move into HANA. At this point, NetWeaver Cloud supports HANA as a database through the Java Persistence service, but the colleagues are already working on integrating parts of the HANA Studio into the NetWeaver Cloud development environment. With that, you’ll get the best of both worlds: Whether you need to code with Java or code SQL Script, the development environment will support you. If you don’t want to wait and try running HANA native code in NetWeaver Cloud today, it will require a bit of Java coding to deploy SQL Script code on HANA without the luxury of the HANA Studio, but it’s possible right now.
It will require more work from both the HANA and NW Cloud development team, but I dream of a time when it will be possible to remotely debug Java code running on NW Cloud, execute native HANA content and put a breakpoint into SQL Script, which is when the combined NW Cloud and HANA development environment will switch seamlessly from a Java to a HANA perspective. We’re not there yet, but with my history in both Java and HANA development, I believe in that vision and will push for it.
The question that I asked myself is whether NetWeaver Cloud will also be a good option to run native HANA applications based on HANA Application Services (XS). Technically, it’s possible, but then you effectively stop using the NetWeaver Java parts and go straight from your Web browser to HANA. We’ll see whether developers will want to use NetWeaver Cloud for this, or if it will remain a hybrid offering predominantly for Java developers that also want to use HANA. It is too early to tell. As I said in the first part of the blog, I don’t see why a Java application that runs on HANA would have to become a native HANA app all the way. You don’t need to push all the Java logic into HANA by re-writing in to SQL Script just because you want to execute a business process step through a workflow engine, just to name an example. So, why not take the best of both worlds? Use HANA for performance intensive data-centric application parts, whereas you use HANA just as a regular database for the parts of your application that are not performance-intensive, not data-centric or purely administrative in nature. No need to push all of this to native HANA. So, who knows? Maybe the combined native/non-native development model will be much more productive than we all think today.
Switching over to the Amazon Web Services side, you will quickly see that it is a very different offering. I don’t want to get into the various pricing options in this technically focused blog, but AWS is pure virtualized hardware infrastructure that you can (and must) entirely manage yourself. That can be a benefit, but also a burden. It really depends what your objectives are. If you are interested to install your own Java middleware next to HANA, you can do that on AWS. In such, you have much more control over your development infrastructure, but are also responsible for installing and maintaining it, including the HANA database administration. In NetWeaver Cloud, you get database maintenance and a Cloud-based Java development environment directly from SAP. Make your decision based on your preferences …
One quick side note here is that I heard SAP is also evaluating options for service-providers to help with HANA administration on AWS, but I’m not aware of the exact business model. I don’t know if SAP would certify “HANA-ready” AWS service-providers, and what role Amazon would play here. Rather than guessing about the work of other groups, I will remain silent on that part, and just mark it as an item for further development.
The comparison gets much easier when it comes to developing native HANA applications based on XS. Currently, that is not possible in NetWeaver Cloud, so if you want to start right now with XS, you only have one option, and that is AWS. In the future, the NetWeaver Cloud team will need to make a decision whether to include the XS development environment into the NetWeaver Cloud offering, or whether it is better to solely focus on those use cases where a Java application developer wants to also work with HANA. But as I wrote above, I do think there is a place for a combined native/non-native development in NW Cloud.
Finally, one topic that steinermatt brought up in his comments to part 1 of this blog series: The cool thing about NW Cloud is that it’s built from the ground up on a modular open source stack, derived from Eclipse Equinox and released at SAP as Lean Java Server (LJS). The times of big monolithic pieces of software are definitely over at SAP. As such, there are no technical impediments that would prevent the LJS stack to run on Amazon either. The part that I’m a little unclear is the interface between LJS and the underlying virtualization layer, which is different in NW Cloud and AWS. But as I am sure the good folks at NW Cloud development have taken care of good modularity and abstract interfaces in this part of their stack as well, it should be possible.
But AWS is fundamentally more open; it’s Infrastructure-as-a-Service. You can’t force an AWS user to adopt LJS as opposed to their own favorite Java server, at least not as long as they have access to the OS. They can simply install their own Java server, if they choose to. The vast majority of startups in the HANA Startup Focus Program are now using the AWS environment. Many of our startups don’t even use a Java app server, but simply the Tomcat servlet engine. So, there are choices out there for AWS users, and if they don’t like LJS, or simply have years of development in another environment, they don’t have to use LJS. I’m pretty sure the NW Cloud team will carefully consider the options in whether deploying their LJS and PaaS Java environment on AWS makes sense.
At the same time, if my vision of a combined HANA and Java development environment does become reality, I don’t think there is any way that any other Java middleware stack can offer a similar level of debugging support and development productivity. Seamlessly switching between HANA and Java perspectives, in a development environment that is installed on a user’s PC, but where the execution happens remotely in the cloud would be a major accomplishment. I do hope NW Cloud will get there soon.
So, there you have it. The second part of the blog is much shorter, also because I could easily refer to the concepts that I have introduced in greater detail in Native HANA apps, language containers and HANA Cloud: Part 1 of 2 . Whether to go NetWeaver Cloud or AWS depends on your objectives. For completeness sake, I should also say that SAP has also partnered with a number of hosting providers that provide you with dedicated HANA hardware in a private Cloud model. The great news: There are many options for you. The only option that is not available (yet?) is a true private Cloud offering that is also installed on the customer's premises.
Finally, please forgive me for a little commercial plug at the end of this blog series. I will speak about all of this during my session CD 207 at SAPphire/TechEd Madrid. I was a bit disappointed that the same session had relatively few attendees at TechEd Las Vegas, but maybe the topic was too new, people had already made up their mind where to go to or the description of the session was too partner focused. The session was originally conceived to talk about the experiences from the startup program, but as you can see there is very broad applicability beyond startups for everybody who is interested in developing custom Cloud-based application on HANA and Java as well. But if you are in Madrid, please come! The session is also on the agenda for Bangalore.
