SCP Learning Series:Managing My Development With Account(s)
This is part of the learning series , and this continuation of the account model post specifically. Kindly read the series in a sequence to understand our scenario and context of our post below.
Managing my development
Back to reality, we have not yet developed the application and ABC Infra does not even know about the Footfall application.
So as an application developer in Example Inc. you have got your architecture and started your implementation as well. But where do we deploy our application, where is the server , and where can my testers test the application and how do I keep my development-test-production landscapes isolated.
As Example Inc. you have got your entitlements of compute and storage and by now you would have realized 2GB for each service amounts to 6GB in each landscape. So you would need a 6GB in dev, 6GB in test, 6GB in production or even more that ! So you can ask for extra compute and get it and you will be able to see it in your Entitlements.
Lets take an example, I say that I need 6GB in total for my development but 12GB for production to cater to increased load in production. How can I manage this resource isolation ?
That’s where the sub-account comes in. Inside the global account, you create sub-accounts and can assign resources be it compute or services allowed to be used etc. individually. In this case, I would create 3 sub-accounts for dev, test , prod. I would also assign 6GB application memory for dev account, 6GB for test account and 12GB for prod account out of the total 24GB assigned to the Global account. Similarly, I would assign the services to be used for these accounts. I would say that for dev account I would need a PostGreSQL only of 1GB, and for my test I would need it say 10GB size ,while in production I would need a 20GB Sized one.
And once you have the sub-accounts created and assigned them their quota of resources from the global account’s pool we are good to go.
You can add members to each of the sub-accounts and authorize them to deploy applications, monitor applications etc.
A global account is first point of entry into SCP, and what you are allowed to use, and how much you are allowed to use is give at the global account level. Global account is just a shell for the sub-accounts and you can create as many sub-accounts you want to create and assign them their quota from the overall pool provided at the global account level. Sub-accounts is where the applications developed are actually deployed. Directly in a global account, you cannot deploy any application. Billing and invoices are generated at the global account level only!
I have seen trial account and what is that ?
SCP offers trial accounts, for developers to get a quick feel of what the platform is all about and to know about the services which the platform offers. These are not meant for productive applications as SAP does not guarantee availability or patches immediately for trial landscapes. A better non-confusing name would have been a Trial Contract. (IMHO!)
But, the concept of Global Account and Sub-accounts still hold good, when you create a Trial Account in SCP, you get one Global account with a predefined entitlements which you cannot change. You can create as many sub-accounts you want and then manage the quota assignments just like how it is done for the productive accounts. So if you are just starting or looking at SCP for what it provides trial accounts is the best place to begin. But beware, not all services or features supported in productive accounts would be available in Trial accounts and SAP has complete rights over the decision of what is available in trial accounts and what is not.
I am just starting my development, do I need to think about all of this now ?
As an architect of the solution, you should have to think about this before you start your development as you may find lot of reusable services in productive accounts like Logging service, Security Services, Portal Services, Auditing Services etc. which helps to you to concentrate more on your application domain and reuse what is already provided by SAP in the platform.
Not all services would be in trial landscape, and hence for a productive application it is better to go with a productive account rather than a trial account even during start of development. Also productive accounts are guaranteed with SLAs and hence your development experience will be smooth.
In the next post, we intend to cover specifically on how accounts are created and managed in the cockpit and get our landscape actually ready after all the theory!