The HANA Cloud Platform evolves further: Reflections on Wednesday’s press conference
Similar to analyst Holger Mueller, I was expecting/hoping for news concerning CloudFoundry at Wednesday’s press conference. Despite my initial disappointment, I still found a variety of interesting aspects that require deeper examination.
A branding shift for the HANA Cloud Platform
The most important change is an expanded definition of “HANA Cloud Platform” (HCP).
This graphic depicts the new enlarged scope of the HCP.
[SOURCE]
Previously, HCP only referred to SAP’s PaaS offer.
The offers now included in the HCP scope existed previously in one form or another. For example, if you look at the archive for the HANA Marketplace, you will see that the Infrastructure Subscription for HANA was already present in December. Both the DBaaS and IaaS offers weren’t really connected to a broader entity – they were often loosely associated with the HANA Enterprise Cloud (HEC). These two offers are now placed under the umbrella of the HCP, and along with the PaaS, they have new product names emphasizing their service character.
The relationships between the entities are also tighter as demonstrated in this description of HCP App Services.
SAP HANA App Services builds on the capabilities of SAP HANA DB Services and allows you to build and deploy the real-time applications required to succeed in today’s always-on, mobile, social, and data-driven world. [I added the italics] [SOURCE]
The specific offers for each service are also tightly connected. For example, App Services include the exact options that are present in the lower layers.
This inheritance of options establishes a certain level of structure as well as visual / logical interdependence between the new services.
HANA Enterprise Cloud: Looking for clarity
In the past, the architecture / marketing for the HEC was confusing.
[SOURCE]
It was never clear – how could the HEC be based on a PaaS?
Wednesday’s announcement focused on HCP and indirectly impacts HEC as well.
I hope the resulting clarity will soon be reflected in HEC’s marketing efforts as well.
Note: Some might say that HEC is based on HANA and therefore should also be based on HCP. For me, HCP refers to a distinct set of offerings for customers / partners, etc. Using a HANA in the Cloud does not mean that an application is based on HCP. SAP can’t have it both ways – is HCP a technology stack or is it a set of offerings? Based on the press conference on Wednesday, I’d like to suggest that it is a set of offerings available for purchase on the HANA Marketplace.
Infrastructure Services vs DB Services: More clarity is needed
Let’s take a quick look at the description of the Infrastructure and DB Services to start our comparison.
The SAP HANA Infrastructure Services subscription allows customers who have existing SAP HANA licenses to deploy SAP HANA without capital investments or hardware setup. SAP provides customers access to certified infrastructure that is hosted and managed by SAP. Network access is provided via VPN connection. System sizes range from 128 GB to 1 TB of RAM.
The system comes with SAP HANA (SPS7) pre-installed and includes a web based management console for instance administration, data backup, and life cycle management. SAP HANA Cloud Integration for data services, a cloud based ETL tool, is included with the system to help provision data from SAP backends and heterogenous sources securely.
[SOURCE]
The SAP HANA DB Services offers customers immediate access to SAP HANA on a monthly basis without capital investments or hardware setup. This service includes SAP HANA license, infrastructure, and support. SAP provides customers access to certified infrastructure that is hosted and managed by SAP. Network access is provided via VPN connection. System sizes range from 128 GB to 1 TB of RAM.
The system comes with SAP HANA (SPS7) pre-installed and includes a web based management console for instance administration, data backup, and life cycle management. SAP HANA Cloud Integration for data services, a cloud based ETL tool, is included with the system to help provision data from SAP backends and heterogenous sources securely.
[SOURCE]
The options for the DB Services include that of the Infrastructure Services but the main distinction appears to be whether the customer has a HANA license or not. This difference is also in the evident in the comparison page provided by SAP– just compare the columns for “SAP HANA DB Services” with that of “SAP HANA Infrastructure Services” and you will see that the greatest difference refers to licensing rather than technology.
Note: This is the just the first iteration of this new structure, so greater differences may occur in the future.
In my opinion, the use of the term “Infrastructure Services” is a bit misleading, because the service includes a database in addition to pure infrastructure elements (as are usually the focus in other IaaS offers). Yes, I know that different options for the Infrastructure Service are infrastructure-related but the infrastructure is there to support the installed database rather than to act as a foundation for other scenarios (for example, ones that don’t include HANA).
Logically or commercially, DB Services are based on Infrastructure Services but technically / architecturally, both services have the same result – a HANA database running in the cloud.
Let’s give our diagram a stronger architectural character and adjust it accordingly.
Note: It is very interesting to play with the various configurations in the HANA Marketplace and look at how the prices change with different settings. For example, compare a DB Services (Platform) with an Infrastructure Service offer of the same size and you will see that the price difference is approximately $10,000 – that is the cost of HANA license via monthly subscription.
Migrations and other practical matters
HCP App Services (PaaS) already use HANA DBs. Indeed, the use of HANA XS within the PaaS is currently one of the most popular scenarios in the environment.
For customers wishing to start with the App Services, they purchase a HANA database when making their initial order. There is another possibility, however, one that involves a migration.
This scenario is definitely possible and although the HANA DBs created through both services run in the same Cloud Infrastructure, I have no idea if such a migration would even be possible.
Comparing the new Infrastructure Services offer with that of AWS
There is also an IaaS offer for HANA from AWS. Let’s make a quick comparison of the two offers.
SAP offer
[SOURCE]
AWS offer
[SOURCE]
A direct price comparison isn’t possible, because there are no prices for the AWS offer but a quick analysis show that there are still broad similarities (for example, max size = 1.2 TB vs 1 TB).
Note: Speaking of AWS, HANA One – “a fully-featured SAP HANA hosted in the public cloud” – isn’t getting very much love these days – it has all but disappeared. It is similar to the DB Services but is charged on an hourly basis.
Thanks Dick,
Again we face a slight change in terminology - but at least in this case only a slight shift and won't require a full reworking of all hashtags, presentations and marketing material.
Wondering if you had time to reflect on the apparent disappearance of MaxDB option from the PaaS offering? It still appears in the HCP cockpit as an option, but wonder why/if customers will be able to choose it.
If referring to the PaaS should we still use #saphcp? Methinks yes, but interested in your take.
Cheers,
Chris
Hi Chris,
yes, please continue to use the #saphcp hashtag for all packages comprising the platform. Given that HANA itself is more than a DB, but rather a platform in it's own right the lines between DBaaS/PaaS are blurry...
Cheers,
matthias
Dick thanks for another essential post.
Did you get any clarity on how the HANA Enterprise Cloud fits into this? I know there have been some questions, I was asked this again today and frankly didn't have a terrific answer.
Though I think there can be an answer in terms of partners using the HEC to provide just about any SAP software in "cloud" service form to customers But while I like a lot of what SAP is doing here the rapid pace of change and naming/product clarifications also leaves a lot of folks asking questions.
Hi Jon,
HEC's positioning is focused around providing a managed service to host customer complete or partial customer landscapes with at least one HANA-based solution.
As we have outlined we envision several scenarios where HCP and HEC can complement each other. One we have talked about in the past is providing HCP as a custom extension platform running within a virtual private cloud setting within HEC. I've started to write a blog post on the matter and I'm hopeful I'll be able to get it out the door in the coming days... so stay tuned.
BR,
matthias
I know that I should wait for your blog but.....
Hosting an environment that is multi-tenant in character in what I can only assume is a customer-specific private cloud sounds a bit weird and an overkill.
D
Can I dispatch all the folks that ask for this to you?
I'm with you - yet there are people that want a VPC. The way I see it the answer to all of these challenges lays in Software Defined Network and being flexible on defining network boundaries...
Looking forward to reading about your SDN-related ideas. I know that SDN is already a big part of HEC.
I think a lot also depends on your internal operational processes regarding HCP and to what degree typical changes must still be made manually.
D.
Matthias and Dick - thx for the thread, points noted, including pros and cons of VPN offering. From a naming and product clarity perspective, HEC really muddies some waters so I hope the customer demand is worth it. Might be time for another renaming exercise. 🙂
Matthias I don't know if you agree, but my view is now that HCP is not just the PaaS offering but DaaS/IaaS, I think that opens the way to clarify these kinds of questions more easily than in the past. I found that the other day when trying to explain this to a reporter type...
I'm heading to the HANA SAP Insider show in a bit more than a week and I'm looking forward to getting the customer views on these announces and what makes sense and where the confusion lies. I'm hoping to reduce the confusion rather than add to it. A little better now than before...
No, that's not how I would describe it....
Yes, HCP is sort of both DBaaS and PaaS, but that's due to the fact that HANA is more than just a database, but rather a platform in its own right (as I tried to explain in my own blog post).
All SAP-managed infrastructure (IaaS) is operated within the HEC organization and they also provide the infrastructure underneath HCP. HCP simple provides the infrastructure abstraction and adoption layer on top and ties into the automated provisioning from the HANA Marketplace.
As you know the value proposition of PaaS is to abstract from the infrastructure as much as possible - freeing development organisations to focus on their job, rather than having to worry about operating and managing the infrastructure themselves. That's by design...
That's the concept we share with the HEC offering... we want to enable people to focus on innovation rather than keeping business systems up and running. This is why I'd emphasize on the "managed service" aspect of HEC. HEC's value proposition is to bring complete (or parts) of a customer landscape into managed environment. On demand this environment can be integrated with other environments via VPN.
Here we see how the two offerings can complement each other e.g. by offering HCP within HEC so that customers can use the PaaS capabilities to develop new custom applications or extensions on top. Of course, you could also use the public PaaS landscape and use our connectivity service to connect to your HEC environment. It's a matter of customer preference... private clouds, virtual private clouds, public clouds... at the end of the day it's just a matter of defining the environment's boundaries. That's why I mentioned SDN in my reply to Dick.
Another use-case I see is a sidecar approach: given that PaaS is somewhat regulated when it comes to installing additional components people may want to deploy/run such components inside HEC so that they run in close proximity of the PaaS.
(Note: this trade-off between flexibility/convenience between IaaS/PaaS is something people have to acknowledge. If you want full flexibility you may be better of sitting on top of IaaS. If you want convenience and agility in development you may go for PaaS. Fact is, you cannot operate PaaS as a provider if you give people all the flexibility to mess around with the environment without setting boundary conditions on what they are allowed to do.)
So, I hope this helps a bit in making it more clear!
Thanks guys for all you do in this area - having people like you and Dick around providing your PoV greatly helps us in identifying where we need to communicate better!
Cheers,
matthias
sigh. 🙂 Well, the SAP HANA marketplace spells it out simply at any rate, so maybe some of the nuances you described won't matter as much if the customer can just buy what they need (PaaS, IaaS, DaaS)?
Your explanation does make sense but I see that as tough to get across to customers given the complexities of HEC vs HCP so maybe it can be hidden under the hood somewhat - though I think the private versus public choice options is a good way to describe it while keeping it simple.
As a sidenote I am very interested in SDN also, though I keep having SAP Developer Network flashbacks when I use that acronym...seems SDN has the potential to change how we think about managing some of these deployments. Well I will look for your blog on that.