Hello and welcome to the SAP HANA Academy.
The topic of this video tutorial series is SAP Cloud Platform, Getting Started and in
this video we will discuss account models.
This video has been recorded in October 2018.
For the most recent tutorial videos on this topic, please check the playlist on the SAP HANA Academy.
Hi, I am Denys van Kempen.
OK — in the previous video in this series we looked at the SAP Cloud Platform Planning
and Lifecycle Management Guide, and zoomed in on the Getting Started Checklist.
So for this video, I am going to assume you are familiar with the basic platform concepts
(regions, environments, accounts and capabilities/services);
That you have made your decision on building teams: SAP recommends a DevOps approach, as
this fits cloud native development;
And that you have taken note of the shared responsibility model of the cloud platform.
With this out of the way, we can tackle the topic of Account Models.
What’s at stake?
Well, the way you set your account structure up, the way you define your account model
should match your business and development requirements.
Your Global account is the realization, as it is phrased here, of your commercial contract with SAP.
You may have multiple global accounts for compliance or other reasons, multiple contracts,
and each account will have its administrators, entitlements (the quotas) and license types.
Here we have my global accounts, for example.
My Home is in Europe, Amsterdam.
We see three global accounts.
You can give them any name you want, so I have named Customer - Run and Partner - Build,
both Enterprise accounts, to highlight the two main overall usage scenarios.
When we select a global account, we get access to its subaccounts, the entitlements, and its members.
Subaccounts are either Cloud Foundry or Neo environments.
Cloud Foundry environments are typically used to build applications using the latest technologies,
this may involve SAP Leonardo (Machine Learning, BigData, Blockchain), and they are hosted
by cloud provider partners of SAP — the multi-cloud concept — an open system, freedom of choice.
Neo environments will be, in most cases, use to extend cloud or on-premise applications
(add functionality) or provide integration between both worlds, maybe hybrid scenarios,
a combination of all types, often this will involve SAP Software-as-a-Service (Ariba,
SuccessFactors) but not necessarily, could be non-SAP software as well.
As a service or on-premise.
No surprise, Neo only runs in SAP data centers, worldwide.
This is where the software, the platform, and, to some extend, the infrastructure-as-a-service is hosted.
You can add your Subaccounts here.
Select your environment, your provider, and your region.
We will go hands-on in the next video.
The links here, below, point to the SAP Cloud Platform Planning and Lifecycle Management Guide,
Account Model section, which is where we started.
Entitlements are linked to your global account.
What’s part of the contract.
You can edit them here.
Add some more, tune it down a bit.
As required.
And Global Account members; these are all administrators.
You can add your members here, also your task.
As user base, you can use accounts.sap.com, the SAP ID service, the default selection,
or a custom user base, maybe Microsoft Active Directory, your company’s identify provider.
We will address this in another video tutorial.
That’s global accounts: members, entitlements, subaccounts.
You can get your monthly usage overview here.
As mentioned, to develop and deploy applications, to use services, and to subscribe to business
applications provided by SAP, a global account member must create subaccounts and distribute the resources.
So each global account will have 1 or more subaccounts and there is 1:1 match between
a subaccount and an environment.
It is either a subaccount for Neo or for Cloud Foundry, not 50/50.
Subaccounts are independent, so with dedicated quota and member management and a dedicated
identity provider for business users.
SAP ID for Neo and Microsoft AD for CF in AWS, for example, or the other way around.
But then the question is how do we set this tup?
Well, for this, we have several examples.
Account Model 1, 2, 3, and 4.
In general, SAP recommends to create at least 3 subaccounts for a staged development environment:
development, testing, and production.
However, you can also create subaccounts for other purposes.
Here are some examples.
Maybe separate the work of different development teams, restrict access, different subaccounts
connect to different back-end systems, separate projects, could also be a reason.
Some things to consider: resources are monitored per subaccount, not per application.
So, should this be a requirement, to monitor resources consumed by a specific project,
department or app, you need to create a dedicated subaccount.
The region might be a consideration.
To reduce network latency, load distribution or legal requirements.
Connections to on-premise systems must be made separately for each subaccount.
This is more work, for sure, but also, or course, provides more control.
In most cases, this is probably a good thing.
Then, for Cloud Foundry, we also have the concept of Spaces and Orgs (organizations).
Some of you will be familiar with this.
To simplify the setup, there is a 1:1 mapping between orgs and subaccounts.
So, each subaccount is an org.
You could decide to only create a single space in each org, so it will match the way Neo
is structured.
However, you can also create dedicated spaces for applications or projects if you do not
need the dedicated user management.
Let’s take a look at some examples.
Number 1: Here we create the staged development environment we talked about.
3 subaccounts in both the Neo and Cloud Foundry environment with separate, dedicated, spaces
for particular applications or projects in Cloud Foundry.
When using SAP Web IDE Full Stack, you can use both environments and all of its services,
so you want to have the same stages.
This does require, however, that you use the same identity provider.
Makes sense, but, keep this in mind.
Account Model number 2: Use a subaccount as base template.
This only works in Neo.
Why?
Well, if we switch to the cockpit for a moment and create a new subaccount
Then, when we select Neo as the environment, we have the option to copy settings from an
existing subaccount.
And we can select to include certificates and trust settings, the destinations, and
members.
This option to clone subaccounts, so to speak, does not exist for the Cloud Foundry environment.
So here, in this diagram, we see a subaccount serving as a base template, which is then
used to clone, create, our staged project environment (dev, test, prod), and for individual development projects.
OK — number 3: Here we are using separate subaccounts for data and API management.
The advantages of this model are that it allows you to scale quickly while ensuring that connections
to your back-end systems are always established via APIs.
Access to back-end systems is managed centrally by the IT department via API management in
three dedicated subaccounts.
It also keeps costs low due to the sharing of the SAP HANA databases across subaccounts.
In Cloud Foundry environments, you have the option to use one account and three spaces,
or, as discussed, use the same hierarchy as in Neo.
And number 4, where we create a staged development environment using
continuous integration / continuous delivery (CI/CD).
We talked about CI/CD in the previous video, when we discussed prerequisites, so I will
assume that you are familiar with DevOps.
Here we see dedicated development subaccounts for each project with the apps developed in
these accounts consolidated, tested, and published in one single testing and production subaccount.
This ensures a high degree of governance, data security, and compliance.
For Cloud Foundry environments, there is no need to create different subaccounts for the
different development projects per se, of course.
You can use spaces for this.
Unless you have specific needs concerning user management or monitoring, as discussed.
OK — this should give you some ideas about how you can setup, how you can design your account model.
It is probably a good idea to give this some thought before your start your development project.
In particular, keep the differences between the Neo and Cloud Foundry environments in mind.
However, it is flexible enough to be adjusted, should the need arise.
You can always adapt the account model to changing circumstances.
That’s it for SAP Cloud Platform account models.
Thanks for watching.
You can find more video tutorials on our YouTube channel.
If you would like to be informed about new video tutorials, please subscribe to our channel.
You can connect with us on LinkedIn or follow us on Twitter, as well for updates, and if
you are watching this video on YouTube, do not hesitate to leave your comments to the
video page and, if you like, give us your vote on this video.
Have a great day and thank you for watching.