(Yet another) Intro to HANA as a Service
Hi! I’m Lucía Subatin. You may remember me from tutorials, blog posts and videos about HANA Express and HANA native development in general.
Source: Lynch, J. (Director) & Oakley, B. (Writer). (November 5, 1992) Marge gets a job in James L. Brooks (Producer) The Simpsons
After the first mini-codejam on First steps with HANA as a Service at SAP Teched Las Vegas, I’d like to share some insights from the perspective of an on-premise HANA user (if I can call myself a user…). Particularly, an SAP HANA, express edition (ab)user.
In this series of posts, I’d like to cover the fundamental differences with other HANA offerings, some architecture basics and it wouldn’t be me if I didn’t point at how to get started/play with it.
What is the SAP Cloud Platform, SAP HANA Service?
Also referred to as HANA as a Service, this is a fully-managed offering for SAP HANA.
What is “fully managed”? It means that all you need to do is decide where you want your instance to be hosted, what kind of functionality you want and how big in terms of RAM you want it to be.
Administration tasks such as installation, backup and upgrades are taken care of the ones who also make the platform, SAP! I call this letting businesses mind their own business.
Choosing where to run
As opposed to its similar sister offering, in the Neo stack, HANA as a Service runs on the Cloud Foundry stack in SAP Cloud Platform. This means that you can also choose between (currently) Google Cloud Platform and Amazon Web Services to host your HANA instance within the available regions:
You can check the available services and regions here.
Choosing what to run
Creation of the database instance could not get any easier. I will show a detailed walk-through in a later blog post, but you can choose between two flavors:
- A standard edition: Core database + Series data
- An enterprise edition: Same as standard + cool advanced analytics (text analytics, graph, geospatial, predictive, etc) that SAP HANA knows how to do so well.
In reality, this is done before the creation of the actual service instance as your account should have quota available for any or both services. This means you or someone has purchased such quota.
How many SAP HANA blocks
This is one of the sweetest differences, as well as one of the clear advantages of running in the cloud: taking the fear of sizing running short as adding more hardware is not your problem.
Of course, you should do your homework and use any of the sizing tools available to anticipate how much your legacy database will shrink when data is migrated (and compressed) into HANA. However, one of the beauties of the cloud is that you have the possibility to scale up.
Source: Sandoval, S. (Director) & Groening, M. (Writer). (July 1, 2010) Attack of the Killer App in Futurama
I’m an advocate for free and trial for developers and I’ll get to that in a future post. But the amount of HANA blocks (RAM) and cost go hand-in-hand and is the only math you need to do.
You will see variations of the cost depending on the region and the edition (standard or enterprise).
You should also notice that you can have a subscription for what you are planning to consume in advance or you can pay for what you consume, metered by the hour.
And that’s it. Choose the region, flavor and blocks. You can then use those blocks all in the same instance or in many instances, it does not matter, as they are your blocks.
In technical terms, what is HANA as a Service?
Plain and simple, when you deploy an instance you get access to your very own tenant database in its very own system database, which you are not sharing with anyone else.
The service piece of it is that SAP will take care of everything related to making your instance run and make sure you get the backups every 15 minutes and saved up to until a month in time since they are created.
The juicy technical details are interesting enough to deserve their own post. Check it out here https://blogs.sap.com/2018/10/26/sap-cloud-platform-sap-hana-service-some-architecture-drawings/