This is part 1 of my blog series about cloud architecture with SAP Cloud Platform. Find the series overview here.
I chose to start this blog series with an explanation about SAP CP Global Accounts and Sub-Accounts. To me, it's one of the first things you should think about when introducing SAP CP at a customer. This task corresponds to the landscape planning that you typically do for an on-premise landscape so the architectural design decisions you make here are quite fundamental. I also observed that not many people know about these concepts because many only have experience with the SAP CP Trial Accounts, which do not make the underlying SAP CP account structure visible to the user. At real customers, of course you must not use Trial Accounts productively, especially for legal and support reasons! 🙂
So let's get started. When I first approached the account topic I was quite confused, but the following figure that was created by my colleagues from product management (I don't know who it was, but thanks to you, good job!) really helped me in understanding and explaining the concept:
You see that in this picture, three sub-accounts are structured in one Global Account. So what's a Global Account then?
Basically, when a customer decides to purchase a productive SAP CP "account" (and in this case, "account" is technically not the correct term, one could better say "when a customer decides to sign a SAP CP contract" (which is of course in the productive landscape)), then the customer receives a Global Account.
All metrics like quota and resources, or amount of Java Compute Units, even billing, is done for this Global Account. A Global Account is always associated with one datacenter (UPDATE 2018-08: Global Accounts can now span accross multiple datacenters/regions.). This is the first thing you have to consider: Where do I actually need my Global Account to run? Compliance reasons, for example, might quickly answer this question for you.
Moving on, a Global Account is more or less just an empty shell. You cannot do much with it apart from looking at your overall resource consumption. You cannot run applications or services directly in a Global Account. For these tasks, you'll actually need Sub-Accounts. (Just as a remark: when you sign up for a trial account, what you receive a dedicated Sub-Account. You have no direct control over the trial landscapes' Global Accounts).
As you can also guess from the above picture, a Global Account can host many Sub-Accounts. This is what a typical Global Account at a customer could look like (here we have six Sub-Accounts):
You can create new Sub-Accounts in the Cockpit easily with the "New Account" button on the top of the screen:
In order to understand and be able to plan how many Sub-Accounts you might need for your SAP CP project(s), first we have to understand what a Sub-Account actually is.
When I explain the concept of a Sub-Account to a customer, I typically compare the Sub-Account with an on-premise NetWeaver system that is now in the cloud (this is not a perfect definition as such but in my experience, many customers understand the similarities and concepts when I explained it like this).
A Sub-Account
This is what the configuration start page for a Sub-Account in SAP Cloud Platform looks like ("Cockpit"):
This page should look familiar to everyone who has experience with the SAP CP Trial Account. In productive environments however, you'll notice that you can switch between different Global Accounts and Sub-Accounts in the upper center area of the screen.
From an architectural perspective and in order to plan the "Cloud Landscape", I would at least consider the following questions:
Of course, all these questions can be answered differently for each customer. So my recommendations are just my experience which you might not agree to. Also, these recommendations could also change if certain features of SAP CP are changed in the future (which is definitely possible in the rapidly changing cloud world today).
You see that there are many reasons to introduce many Sub-Accounts in your cloud landscape. But there are also reasons to not always have separate Sub-Accounts for each project/application:
In general, I would argue that there are many good arguments to make frequent use of the feature of creating new accounts. You can even create new accounts via the command line so you could automatize the creation (which could be a really cool feature if one of your customers orders a development environment for a new project in the customer's internal shop system and automatically, a new account was created for that project team… 🙂 ).
An additional topic that I do not want to cover in all detail but that nevertheless should be considered is the structure of your HANA databases in the cloud. Since there is the concept of Multitenant Database Containers (MDC), you can basically use a database system to host multiple independent HANA databases. Independent in that case means that although the databases share the same "physical" machine (= resources) and also the same HANA revision (important restriction!!), they have completely independent configurations, user management, and database content. Since not that long ago, you can also share database systems between accounts, so that you potentially can use the same HANA database system in multiple Sub-Accounts where each Sub-Account has an independent HANA database connected to it. With this, SAP is adding a lot more possibilities to landscape design and SAP CP subscription cost (distribution between projects), but I really want to cover this later as I think for now, you'll probably have enough information already to digest.
Summing up what we covered already, I just would argue that it really makes sense to put some effort in proper Global Account / Sub-Account planning. Involve also management in those discussions and find out how they plan to extend the SAP CP landscape in the future. This might give you good guidance of how you have to plan your landscapes because your decision may significantly influence subscription costs and extensibility of your future SAP CP landscape.
Feel free to contact my SAP colleagues or me if you need advice for your projects! Let me know whether you have learned something in this blog or if you have questions!
Cheers, Jakob
For further information, please consult the official documentation. I recommend the following pages:
https://help.hana.ondemand.com/help/frameset.htm?8ed4a705efa0431b910056c0acdbf377.html
https://help.hana.ondemand.com/help/frameset.htm?c4c25cc63ac845779f76202360f98694.html
I chose to start this blog series with an explanation about SAP CP Global Accounts and Sub-Accounts. To me, it's one of the first things you should think about when introducing SAP CP at a customer. This task corresponds to the landscape planning that you typically do for an on-premise landscape so the architectural design decisions you make here are quite fundamental. I also observed that not many people know about these concepts because many only have experience with the SAP CP Trial Accounts, which do not make the underlying SAP CP account structure visible to the user. At real customers, of course you must not use Trial Accounts productively, especially for legal and support reasons! 🙂
So let's get started. When I first approached the account topic I was quite confused, but the following figure that was created by my colleagues from product management (I don't know who it was, but thanks to you, good job!) really helped me in understanding and explaining the concept:
You see that in this picture, three sub-accounts are structured in one Global Account. So what's a Global Account then?
Basically, when a customer decides to purchase a productive SAP CP "account" (and in this case, "account" is technically not the correct term, one could better say "when a customer decides to sign a SAP CP contract" (which is of course in the productive landscape)), then the customer receives a Global Account.
All metrics like quota and resources, or amount of Java Compute Units, even billing, is done for this Global Account. A Global Account is always associated with one datacenter (UPDATE 2018-08: Global Accounts can now span accross multiple datacenters/regions.). This is the first thing you have to consider: Where do I actually need my Global Account to run? Compliance reasons, for example, might quickly answer this question for you.
Moving on, a Global Account is more or less just an empty shell. You cannot do much with it apart from looking at your overall resource consumption. You cannot run applications or services directly in a Global Account. For these tasks, you'll actually need Sub-Accounts. (Just as a remark: when you sign up for a trial account, what you receive a dedicated Sub-Account. You have no direct control over the trial landscapes' Global Accounts).
As you can also guess from the above picture, a Global Account can host many Sub-Accounts. This is what a typical Global Account at a customer could look like (here we have six Sub-Accounts):
You can create new Sub-Accounts in the Cockpit easily with the "New Account" button on the top of the screen:
In order to understand and be able to plan how many Sub-Accounts you might need for your SAP CP project(s), first we have to understand what a Sub-Account actually is.
When I explain the concept of a Sub-Account to a customer, I typically compare the Sub-Account with an on-premise NetWeaver system that is now in the cloud (this is not a perfect definition as such but in my experience, many customers understand the similarities and concepts when I explained it like this).
A Sub-Account
- Can host different applications simultaneously (Java, HTML5, and XS)
- Can have zero to many database systems connected to it (you could even share database systems between Sub-Accounts to some extent, please consider the documentation for this)
- Has at least one trust configuration (the configuration where you maintain users, groups, roles, … (there will be another blog in the future for this)
- Has one or more SAP Cloud Connector(s) connected to it
- Has a set of destinations (to on-prem or internet systems) that you can maintain and that all applications in that Sub-Account can consume and share
- Has ONE dedicated area where you maintain the administrators and developers for this Sub-Account (these users are called "Members" on HCP)
- Has zero to many Java Compute Units to host Java applications
- Has a git repository service where you can host many repositories for different projects
- Has other HCP Services assigned to it that can be configured and used differently for each Sub-Account
This is what the configuration start page for a Sub-Account in SAP Cloud Platform looks like ("Cockpit"):
This page should look familiar to everyone who has experience with the SAP CP Trial Account. In productive environments however, you'll notice that you can switch between different Global Accounts and Sub-Accounts in the upper center area of the screen.
From an architectural perspective and in order to plan the "Cloud Landscape", I would at least consider the following questions:
- Do I need more than one Global Account?
- In which landscape should I host my Global Account(s)?
- How many Sub-Accounts do I need? When does it make sense to have more than one Sub-Account?
- Should I host multiple projects in one Sub-Account? To what extent do I want to share configurations and services between projects/development teams in my Sub-Accounts?
Of course, all these questions can be answered differently for each customer. So my recommendations are just my experience which you might not agree to. Also, these recommendations could also change if certain features of SAP CP are changed in the future (which is definitely possible in the rapidly changing cloud world today).
- If you want to transport an application between DEV, QA, and PRD for staged application development, it might make sense to have three Sub-Accounts so you can transport between the Accounts (I will release another blog that deals with transporting)
- If you have completely different scenarios, it might make sense to distribute the scenarios/projects across different Sub-Accounts because it will make your configuration a lot easier (side-effects, access restrictions, …)
- If you have different development teams working on your projects, I would assign different Sub-Accounts to the teams so that they do not influence each other
- If you need different trust configurations for each Sub-Account (one for example using SAP Cloud Identity Service as a user store and another only an internal Active Directory), it might make sense to create individual Sub-Accounts with different configurations
- If your applications and the administrative access to these applications (developers, administrators, and support users) have to be restricted, it might make sense to have separate "high-security" accounts. You assign the "Members" of each account (like developers, administrators, and support users) individually to each Sub-Account. Also the backend systems that are available to your cloud applications are exposed separately per Sub-Account. With separate Sub-Accounts, you have more control over the access to your backend systems.
- Data security requirements and compliance rules will tell you whether you need more than one Global Account and also where to host your Global Account(s). Also network latency reasons might influence your decision concerning the datacenter.
You see that there are many reasons to introduce many Sub-Accounts in your cloud landscape. But there are also reasons to not always have separate Sub-Accounts for each project/application:
- HANA Database systems are assigned to one Sub-Account and sharing them, although technically possible to some extent, might cause confusion and unwanted complexity in the landscape. Although you can consume the DB services (e.g. xsjs OData services) from other accounts in HTML5 web-applications (with Java applications it's a different story), the maintenance and database administration is accessible from one Sub-Account. So if you have multiple similar projects sharing the same developers, same application architecture, and same database, why not gather them in one Sub-Account?
- Configurations have to be made individually for each Sub-Accounts. If you have many Sub-Accounts, this means more configuration work for your administrators (or less, if it makes your life easier when separating multiple projects on one Sub-Account)
- Connections to on-premise systems have to be made separately for each Sub-Account. Although you can copy the settings, still, you'll have to maintain them separately. On the other hand, it's easier to just shut-down all integration paths for one project when you just have to delete all integrations to one Sub-Account on the Cloud Connector.
In general, I would argue that there are many good arguments to make frequent use of the feature of creating new accounts. You can even create new accounts via the command line so you could automatize the creation (which could be a really cool feature if one of your customers orders a development environment for a new project in the customer's internal shop system and automatically, a new account was created for that project team… 🙂 ).
An additional topic that I do not want to cover in all detail but that nevertheless should be considered is the structure of your HANA databases in the cloud. Since there is the concept of Multitenant Database Containers (MDC), you can basically use a database system to host multiple independent HANA databases. Independent in that case means that although the databases share the same "physical" machine (= resources) and also the same HANA revision (important restriction!!), they have completely independent configurations, user management, and database content. Since not that long ago, you can also share database systems between accounts, so that you potentially can use the same HANA database system in multiple Sub-Accounts where each Sub-Account has an independent HANA database connected to it. With this, SAP is adding a lot more possibilities to landscape design and SAP CP subscription cost (distribution between projects), but I really want to cover this later as I think for now, you'll probably have enough information already to digest.
Summing up what we covered already, I just would argue that it really makes sense to put some effort in proper Global Account / Sub-Account planning. Involve also management in those discussions and find out how they plan to extend the SAP CP landscape in the future. This might give you good guidance of how you have to plan your landscapes because your decision may significantly influence subscription costs and extensibility of your future SAP CP landscape.
Feel free to contact my SAP colleagues or me if you need advice for your projects! Let me know whether you have learned something in this blog or if you have questions!
Cheers, Jakob
For further information, please consult the official documentation. I recommend the following pages:
https://help.hana.ondemand.com/help/frameset.htm?8ed4a705efa0431b910056c0acdbf377.html
https://help.hana.ondemand.com/help/frameset.htm?c4c25cc63ac845779f76202360f98694.html
- SAP Managed Tags:
34 Comments
