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 are going to create subaccounts for our Neo and Cloud Foundry environments
using the SAP Cloud Platform Cockpit for an account model based upon the DevOps approach
and including a staging environment for development, testing and production.
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.
In the previous videos of this series, we looked at the prerequisite Getting Started
checklist, the basic concepts, and discussed the different ways how you can set your account
model up, and looked at the workflow for account creation for the different environments.
This is all documented in the SAP Cloud Platform Planning and Lifecycle-Management Guide and
the SAP Cloud Platform Administration Guide both available on the SAP Help Portal (help.sap.com:
SAP Cloud Platform).
This video will be hands-on as we are going to create the subaccounts for both environments
using the SAP Cloud Platform Cockpit.
Let’s connect.
Log on
Global Accounts
This is my home page.
We can see three global accounts.
Let’s rename this to Demo.
You can name your global account any way you want.
Let’s connect and navigate to the subaccounts area.
We can see two subaccounts.
One for the Neo environment and one for Cloud Foundry.
Lets clean this up.
So, we can start from scratch.
Fast forward a bit, done.
The links here, the URLs, on this page point to the documentation, we have already covered
this in the previous videos.
Make sure you are familiar with the concepts before starting to create your subaccounts
because once you start your development project and have your entitlements set up, your members,
it will be a lot more difficult to change.
We are going to create five subaccounts for the Neo environment.
Let’s review our Account model.
Example #4.
For DevOps.
Separate development projects and consolidated test and production environment.
We will do this first for Neo, where we can use the concept of template subaccounts and
cloning.
We can see that here in Example #2.
And then for Cloud Foundry, this will be a manual effort, so that we end with an account
model similar as well as Example #1 with a staging environment for both Neo and Cloud
Foundry, with the difference that we are only going to create a single Space in our Cloud
Foundry subaccounts so we keep our environments aligned.
OK — To create a new subaccount, click the button on the Subaccounts page.
Give the account a name.
I am going to call it Dev Project A.
The environment is Neo.
Provider is SAP.
The only choice we got.
Region.
I will pick Rot, in Germany, near the SAP head quarters.
Availability of services can vary between regions.
We talked about this in the basic concepts video and also showed you the regions and
services overview page.
For development, it might make sense to enable beta features.
Again, think before you leap.
You cannot switch this off.
You will need to recreate your subaccount.
Create.
That’s number one.
Takes a few seconds.
In the background some provisioning will be going on but this won’t stop us with our
setup.
Note the BETA indicator to show that we have enabled beta features for this subaccount.
Number two.
If we pick the same region for our Neo environment, we now have the option to copy settings from
an existing subaccount.
We can copy Trust, Destinations and Members.
Let’s cancel out for one moment and take a quick look.
If I select my Dev Project A subaccount, expand Security and select Trust, we get to the Trust
Management section where we can configure local provider and application provider settings.
Here we can configure any external identity provider we might want to use for our application,
maybe Microsoft Active Directory, for example, or some other SSO service.
There is a lot to configure here, as you can see.
We are not going to cover that here and now.
It is all documented, of course, in the SAP Cloud Platform guide.
In the Security chapter.
Another good topic for a tutorial video.
Same for destinations.
You create them here, under Connectivity.
Create a new one, import one, or upload certificates.
Then we also have members.
You can add them here.
We have already seen that at the Global Account level, we only have administrators.
At the subaccount level, we have a bit more control, as there are five different predefined
roles.
You can define this here.
All in all, a fair amount of work.
So, for this reason, being able to copy these settings from environment to environment avoids
duplication of effort and allows for automation.
I should mention, we are now creating our subaccounts using the SAP Cloud Platform cockpit.
However, we could also perform this task using the console client, with the Neo command,
which is, in fact, how SAP does this when you request a trial account.
This is all automated, of course.
Note that because we enabled beta features for Dev project A, this will also be enabled
for project C.
We cannot change this.
Next, we are going to create our consolidated test environment.
This could be in the same region, this could be somewhere else.
No cloning this time, and no beta features any more.
Same for production, but let’s assume that for this application most of our customers
are in Brazil, so we are going to create this subaccount in that region.
We have set up our staging environment for Neo with three development subaccounts, beta
features enabled using environment copy, and a consolidated subaccount for testing and
one for production, to make this a DevOps account model.
Quick review.
Here we have our model
And this is how that looks like in the Cockpit.
OK —Next, Cloud Foundry.
This will be a bit more work.
No copy environment here.
We could automate the creation of spaces and orgs once we have a cloud foundry environment
using the cf CLI, the command line interface we have talked about in our preparation videos,
but we need to create one first.
Dev Project A
Environment: Cloud Foundry
Provider: well, this is the multi-cloud concept in action, your choice.
I will select AWS, as this will provide me with a data center in Frankfurt, very close
to Rot.
For Cloud Foundry, we need to provide a subdomain, this will be included in the URL of the application:
..cfapps.
You can enable beta features here as well for your development project.
The same way, we are going to create our other development subaccounts, the consolidated
test account, and the consolidated production subaccount in the Brazil region.
OK — here we have model: Staged development environments for both Neo and Cloud Foundry,
and with separate development subaccounts and consolidated test and production accounts.
Very well.
We are not there yet.
For Cloud Foundry, we need to enable this.
Open the subaccount.
I will take the Test one, as an example.
Click Enable Cloud Foundry
You will need to provide the Org name, the organization.
You may recall from our previous video where we discussed this that there is a 1:1 mapping
between a Cloud Foundry organization, which is a generic Cloud Foundry concept, and the
specific notion of subaccounts inside the SAP Cloud Platform.
By default, this field will be populated with the global account name (Demo) and the subaccount
subdomain prefix we specified earlier on.
Org names need to be unique within the region of this provider, but we might want to use
a different name because global account names can be easily changed, as we have seen, and
we not want to reference that here.
Test is already in use, no surprise.
Lets try demo-test.
Yes, that works.
The Org is created by AWS in the Frankfurt region … and here we have the details.
Zero spaces, one member, and the API endpoint.
We would need this for the cf CLI command line interface, for the cf login command,
for example.
You can disable Cloud Foundry here, should you want to keep your account model setup
but not incur any charges.
We can add more members here at the org level.
We can add destinations, we can add a trust configuration.
Conceptually, this is all the same as found under Neo.
We will need to create a space.
And, as discussed, you could very well create a staging environment (development, test,
production) at the space level using a single subaccount.
In which case, you would probably want to configure Quota Plans for each space.
However, to keep this conceptually the same as our Neo environment, I am only going to
create a single space here.
I Will also call this Test, just like the subaccount … and then if we open the space,
we can add our members at the space level, add our service instances, bind them to the
app, as discussed in the previous video.
It may be clear, there is a lot more to the configuration of a Cloud Foundry subaccount.
A lot can be done with the command line, we can certainly automate the configuration.
We will cover this in subsequent videos.
Here, we are just showing you an example of how you can set your account model up.
This is the view in cockpit.
Of course, we might also have development projects just in Neo … lets delete project
B.
And for project C, only do our development in Cloud Foundry.
So for project A, we are using services in both the Neo and Cloud Foundry environments.
For B only Neo, and for C only Cloud Foundry.
The way you set your account model up, all depends on the requirements for development
and your business needs.
OK — that’s it for creating Subaccounts.
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.