Understanding Accounts within HCP
In recent months, as more and more organisations are taking an interest in the broad capabilities of SAP HANA Cloud Platform, I’ve noticed an increase in people moving from the free trial accounts to licensed, productive accounts. This is great news for SAP, the HCP community and the world of SAP generally as we see the platform and its adoption mature and grow. The increasing number and range of complex topics covered in blog posts in this SCN space alone are testament to some of the really cool stuff that is being built.
I’m also noticing an increasing number of questions as well as having a lot of discussions online and IRL, around some of the basic topics that users of the trial landscape won’t have faced whilst using their free accounts. One area that seems to rear its head more often than others is how the general landscape and architecture of HCP works in relation to on premise systems – understanding how accounts work on HCP is fundamental to getting your build and operate model correct.
In a cloud world, the tangible & physical servers (ok, and virtual hosts) that we are all used to disappear from our grasp, as SAP owns, runs and manages the infrastructure for HCP. Instead of servers or instances, we work with accounts. With productive HCP, we get access to a global account that has all of the services and capabilities that we have licensed available. This quickly leads to the most common questions I get asked:
- How do we set up our landscape to work with our on-premise DEV, QA & Prod systems?
- How many accounts can we have?
- How many do we need?
In the old on premise days, the answer to this is pretty straight forward (in terms of design at least) in that we create an instance per tier. So if we want a pretty standard development, quality & production setup, we create 3 instances (forgive the massive over-simplification for the benefit of this post.) Most people in the SAP space will expect a similar 3 tier landscape when working with cloud solutions too.
Let’s quickly look at the 3 questions above and get a simple & concise answer within the context of cloud, PaaS and specifically HCP.
What does a HCP landscape look like?
As mentioned, when you invest in a production HCP account you essentially end up with a single account. I recommend you use this for two things:
- It is the tangible representation of your contract with SAP
You will use it as the main container for any support interactions with SAP as well as the main point to manage how you assign the resources you are paying for
- It is a logical representation of your HCP landscape
Consider an on-premise solution where you have a server room with your three DEV, QA & PROD servers sited – consider your global HCP account as the cloud version of this
With this in mind, no doubt you are wondering how you create the cloud version of your DEV, QA & PROD servers? HCP has this covered with the concept of sub-accounts. Your main, global account can be used to create as many sub-accounts as you need. So logically, you would create 3 sub-accounts to represent your 3 tiers. You would end up with something like this:
As a slight segue, here we see a massive showcase of the power of cloud – back with our physical server room if we wanted to add another instance, say for regression testing, we’d face the usual lead times and delays associated with acquiring hardware and installing operating systems and software. Not so with HCP. A simple click of a button from the HCP Cockpit and a further account is spun up and available in seconds.
I’ve highlighted below just how simple this is:
Here I’m showing a productive HCP account that has 4 sub-accounts created, each representing a different instance in a landscape.
It is important to remember that each sub-account is completely separate and independent from all others against your global account. This will be important when you begin to consider security, user management, data migration & management, integration and various other topics as you build up your HCP landscape and overall architecture.
How many accounts should I have / do I need?
If we stick with the normal 3 tier landscape then the simple recommendation is to create 3 accounts as above. However due to the power and flexibility of HCP, you don’t have to think in such formal ways. As you are completely in control of your own accounts, you can choose to have as many or as few accounts as you need. Often, the complexity of your landscape will be driven primarily by your individual use case.
Many of the cloud products and platforms I’ve worked with in recent years work with a simple Sandbox & Production, 2 tier landscape:
If you are simply working on a single custom application using HCP and maybe only have simple integration requirements, this could well be enough for you and your team.
At the other end of the complexity scale, you may well have a landscape that needs to support the following scenarios:
- HCP acting as an extension platform for your on premise S/4 HANA landscape, which has 4 tiers (DEV, QA, IST & PROD)
- HCP enabling the development of 2 custom app’s that you are selling through the SAP App Center
- HCP supporting an extension against your 2 C4C tenants (SANDBOX & PROD)
In this scenario, you have a couple of options. Let’s assume your 3 scenarios are all independent so we can create essentially 3 landscapes within your main global account:
You now have a total of 9 sub-accounts sat within your global account. If we had decided to create a separate “landscape” for the two custom apps we would end up with a further 3 sub-accounts in our overall account structure.
Some Further Considerations
Hopefully it will be clear that you are in complete control of what your HCP landscape and account model looks like. This, in my opinion, is an area open for some improvement from SAP with respect to how the HCP accounts are represented within the cockpit. For instance, in the complex scenario above, there isn’t anything obvious (other than the account name) that points out to the user what type of account each is – other than the person who defines these accounts, how do other users know which are the production accounts, which are dev, etc. I’d like to see some way of tagging or indicating this sort of information in the HCP cockpit – maybe SAP will implement some way for users to add custom tags against accounts, so that it becomes easier to identify and group different sub-accounts?
Very quickly you can setup and manage your HCP landscape to ensure it represents and enables the complexity and flexibility you need for your own scenarios. Very likely, you will move from the simple 2 tier landscape to a more complex one over time. Again, this is where we see the power of cloud supporting rapid agility.
The next thing to consider once you have your landscape modelled is how to assign and deploy resources across the landscape to support your development and runtime needs. This depends on the target runtime and the scenario being deployed, and warrants a blog post all of it’s own…
Update 13.09.2016 – I changed the images as the originals were shockingly bad in all grey and really annoying me!