Understanding Resources within HCP - part 1

[Former Member]

Introduction

Back in August I completed this post looking at the general approach to setting up and managing your HANA Cloud Platform from a landscape perspective.  If you are trying to understand how to transition from a trial account to a full productive one, I'd recommend reading that post to get a (hopefully) decent handle on how SAP's cloud platforms support you in setting up a sensible landscape.

Following on from the basics around managing accounts, the next logical thing to consider when setting up a proper landscape is resources.  This is another area that isn't always clear or apparent for newcomers to productive HCP accounts.  Most of the quality, informal content available is focused on the trial landscape whilst typically, the productive accounts have to depend on the official SAP help documentation which is somewhat dry to say the least.

My aim here is to give an overview and insight into how resources are used within the context of HANA Cloud Platform.

What are Resources?

Lets try to get some simple definitions down first as resources, within the context of HCP, can actually cover a fair bit of ground.  For the sake of simplicity, I'll focus on some of the more common areas in this post and try to explain the typical use cases they support, as well as referencing back to the cloud landscape we looked at in my last post.

With this in mind, lets quickly remind ourselves of the 3 scenarios we defined at a high level in the last post and flesh them out a bit in terms of overall architecture:

1. HCP acting as an extension platform for your on premise S/4 HANA landscape, which has 4 tiers (DEV, QA, IST & PROD)
   With this solution, we want to deliver a "Fiori-like" custom app that is browser based, online only and keeps all of its data in the S/4 system.  In other words, a pretty common and straight forward entry to the world of custom app's on HCP.  This requires no data persistence on HCP but will make use of the cloud portal services, cloud identity for authentication and of course SAPUI5 development via WebIDE. 
   
   
2. HCP enabling the development of 2 custom app's that you are selling through the SAP App Center
   Here we are talking about a more complex solution, similar in architecture to the ESPM app currently being used to support the openSAP course which I hope you are all following.  These need a data persistence layer in HCP, a runtime environment to act as the app server and of course some sort of front end, which for the sake of simplicity we'll again assume is SAPUI5.  Let's assume these app's are for some B2B functionality such as a supplier managing lead times for their customers and they have both transactional and analytical features.
   
   
3. HCP supporting an extension against your 2 C4C tenants (SANDBOX & PROD)
   This is a simple app that enables your customers to create and check the progress of tickets in the Service component of C4C.  A SAPUI5 frontend allows direct interrogation of Cloud for Service data to B2C users, with no persistence needed.  Cloud Identity for social authentication would be used.

Here is a reminder of the HCP Accounts we would typically set up for the above scenarios:

Now let us define the most common resources (and a few obscure ones to support later examples) used with HCP:

• Persistence
  Probably the most obvious resource thanks to the buzz around HANA is the persistence layer.  Most likely (and certainly I suspect SAP would prefer) this is going to be a HANA database.  It doesn't have to be of course.  It could be an ASE instance too.  Indeed, it is perfectly feasible and common to build HCP solutions that have no persistence within HCP, where all data is stored in other, remote systems.  Scenario 1 above is a good example of this.
  
  Typically the options here are varying sizes of HANA such as 32Gb, 64Gb, etc. and can also include options around ASE such as 120Mb.  It is possible to mix these options too.  You also need to consider unstructured storage which is often in blocks of 10 or 2Gb.
  
  
• Runtime
  Again, a pretty obvious resource required when building solutions is the application server itself.  Traditionally we may consider something like Apache Tomcat or Node.js or even your ABAP/Java SAP stacks to be the application server.  HCP currently has 3 distinct runtime flavours that will dictate what resources you need to support your scenarios - these are Java, HTML5 and XSJS.  As we will see shortly, the use of these three runtimes is dictated by the use case you are building and in turn dictates which resources you need.
  
  You select your runtime based on number of cores and memory such as 2 Cores & 2Gb through to 16 Cores & 32Gb and these are commonly referred to as compute units.  You can adjust this as necessary but please understand that cores and memory only apply to the Java runtime container.  In other words, if you only want to run HTML type apps you DO NOT need any compute units (although you will likely end up with some through the packages available.)  Further, if you want to make use of the XSJS runtime then you must have a HANA instance.
  
  Clear?!
  
  
• Users
  Hopefully anyone in the SAP space will understand the concept of a user.  With a purely internal scenario, such as number 1 above, it should be pretty clear how you define the number of users you need.  With B2B or B2C scenarios such as 2 and 3 above, it isn't so clear.  When selecting resources for HCP this is further complicated as there is a distinction between users, site visits (for the cloud portal services) and logon requests (for the cloud identity services.)  If you think about this a little, it is probably becoming clear that choosing the right number of resources can get complicated quickly and is very much dependant upon the scenario you are deploying.
  
  You typically need to decide how many named users you want in your landscape, then if you have B2B or B2C scenarios with external users, you also need to consider how many site visits you expect per month and maybe how many logon requests to Cloud Identity you expect per month.
  
  
• Custom Domain
  As the name suggests, this is a custom domain that you can use to point at an application on your HCP account.  This is probably more important for B2B and B2C scenarios like 2 and 3 above where you would want your users to navigate to a memorable url, rather than https://some.random.name.hana.ondemand.com/ for example.
  
  Thankfully, this is pretty straight forward and you select and pay for the number of custom domains you need.  For example, in scenario 2 above with 2 custom apps served up we would need 2 custom domains (one each.)
  
  
• Data Transfer
  Quite simply this is the bandwidth consumed by your HCP account applications.  Something to be very mindful of if you are deploying a complex B2B/B2C scenario with lots of content or large data volumes is how much bandwidth you will need.  I understand HCP-PS (HANA Cloud Platform, Psychic Services) can help out with calculating what you need for this resource.
  
  This is usually measured in blocks of 10Gb/month or maybe in bigger chunks like 512Gb or 1Tb/month for some of the higher end packages.
  
  

To add to the complexity, the resources mentioned above are generally allocated against your global account but not all of them can be specifically assigned to sub-accounts.  This is a very important point and one we will come back to a few times, as it does make the managing and running of your HCP landscape a little tricky.

In the next post, we'll take a look at how the above resources can be mapped and allocated to the scenarios and accounts we talked about above and in the previous post.

If anyone has any specific questions or comments around this topic, please do post to the comments of these posts and I'll address them in the next post in the series.

Footnotes

For more info about the resources available and associated costs, please check out the official document.  Whilst I do make some tongue-in-cheek comments about the complexity of HCP resources, as this is a cloud platform you aren't tied in for 5 years with one set of resources when you sign your contract and do actually have a lot of flexibility.  For instance, if you get 6 months into a live B2C solution and discover that it is vastly more successful than you had originally planned, it is perfectly feasible to increase resources such as bandwidth, users, logons, etc. to cope with the demand.  Please note though that it isn't easy to simply expand the capacity of your HANA instance - if you start off with 32Gb and want to move to 256Gb you need to perform some migration steps rather than simply turn the dial up to 11.

Please also bear in mind that the SAP Marketing Machine™ is still changing the names of many of the services and products associated with HCP as I write these posts and as a result, there is a chance some of the products I mention will no longer exist, or at least will have new names.  For instance, HCI is now HCP-IS (HANA Cloud Platform, Integration Services) and SAP Cloud Identity is now HCP-IM (HANA Cloud Platform, Identity Management.)  I was going to update my posts but there aren't enough hours in the day...