Are we reaping the benefits of Cloud Computing?
Disclaimer: Although this solution has been tested to work on AWS, this is not a SAP standard solution and is not supported by SAP. The author is not responsible for, and expressly disclaims all liability for, damages of any kind arising out of use, reference to, or reliance on any information contained within this article.
My journey on the cloud started in April 2011 when I started playing around with Amazon Web Services – specifically its EC2 and VPC services.
I had a few “wows” when realising how easy and fast it was to build servers with a few clicks of a button, and damn cheap too, although price now seemed to be a secondary benefit next to agility. The main benefit really is in how fast it is to put new SAP landscape up and running within a few days – while we could have been plugging wires (or worst still waiting for approval of purchase order and then waiting for the arrival the hardware) if we had gone “on premise”.
More than a year on and a few implementations of non-production SAP environments on AWS, I have started to learn about the other services that are available in AWS. These services made me think of the question
Am I actually reaping the benefits of Cloud Computing?
What if I find a solution that answers the following questions
- I don’t really want to do the patching of database myself any more, I just want it done automatically. I just need to tell when is it acceptable for my database to be patched and for how long (change window)
- I don’t really have to care about backups, I should just be able to tell when it should run and the acceptable duration of the backup job. I also want specify how long should I retain my backups. If I need to recover I should be able to do it point-in-time, according to the retention I set
- I want my solution to auto-scale i.e. if I see spikes in the demand for my service, my SAP should just adjust accordingly and that is for it to bump up server resources, and I could set a rule where it should add more app servers if a certain threshold is met either by CPU usage, or the number of users, or the response time, etc. etc. I don’t care how many servers, it should just scale automatically
I actually did find a solution and with a little bit of experimentation, I got it to work too!
Here is a high level overview of what I did
1. I installed a distributed Netweaver Portal (Oracle 11G on RHEL) on EC2. I chose the Portal due to the small database size. Im sure the solution works for ABAP systems too
2. To benefit from auto-patching, auto-backup, auto-scale on my databas, and high-availability (multi-AZ), I migrated the database instance to AWS Relational Database Service (RDS – http://aws.amazon.com/rds/). After a few tweaks with the TNS and DB security groups, I got my Java central instance to connect to RDS!
3. Now for the auto-scaling part, if only I could dynamically change the hostname and the instance profiles of my app server which I think is possible with a few scripting, then just follow the standard instructions of auto-scaling (http://aws.amazon.com/autoscaling/) – which I realised is really just 2 commands. So the app servers can be auto-scaled, but the SCS cannot be – though I could set a rule for my SCS to have a “minimum # instance = 1” which means, if the host stops, a new one will automatically replace it
4. For the load-balancing part, the Elastic Load Balancer (ELB – http://aws.amazon.com/elasticloadbalancing/) was pretty straight forward . This acted like the web-dispatcher (only with no maintenance of server, pay-per-use, auto-scalable service)
Now that was amazing for me.
You might wonder why bother doing this when there is already the OnDemand for a few SAP products, well there could still be a place for this as this solution still offers options and control over architecture and the combination of components (DB, OS, app level). And the fun factor of doing this, and it works