If you are wondering why you don't use Amazon cloud - and instead Sap Cloud or JPaaS here you might find the answers of your questions.
When we were transferred to the Gravity project ("Gravity" is the project name, but the tool is the "collaborative process modeling tool in SAP StreamWork") back in the end of 2010 it was still a mystery where the landscape would be.
First we decided to go with Amazon cloud and particularly in the US region.
The landscape consisted of a Database (MaxDB) and two instance called Sandbox and Production. Later we also developed a monitoring instance based on Nagios (Stoyan Tabakov was the heart of this operation). The application was deployed manually which was taking 2-3 hours. It was unexplored territory for us so we started with research and reading lots of Amazon documentation on Operations. So long story short here are the key things that we learned during the Gravitys hosting on Amazon:
- Load Balancing - the Amazon Load Balancer is working perfectly we have used load balancer under our domain names for convenience. In amazon and most of the cloud systems if you reboot an instance it would loose your current IP, so this was one of the reasons. To minimize the downtime we were starting a third instance out of the sandbox. And after assuring it is good to go we were switching the instance under the Load Balancer. Later when the Elastic IP was introduced (with limited numbers to be used) we have adopted it and used a direct Domain - instance redirection. At this point Gravity's development was not supporting clusters so the Load Balancer was not needed and we continued with a single instance development until we switched to JPaaS. The Load Balancer was tested from our team with simple applications that we developed and it appeared to be working just fine - determine which instance is loaded and switching to another if needed.
- Auto Scaling - the auto scaling was operated by a command line tool and we documented how it can be used. We also tested it and presented in our review meetings. It is simply a command with set of parameters giving you the option to increase or decrease the number of instances from a pre selected image based on different Triggers - CPU Load, Number of transactions etc. Still it was not a simple operation and needed a descent amount of time to be set up.
- Elastic IP's - The elastic IPs come in handy when you need a constant IP of your instance - like the productive one. Otherwise starting an ESB image and restarting it will inevitably bring to IP loss. Of course this nice addition comes with some "good" payment plans.
- Installations - All the installations that we performed were manually executed. Connecting to the instance using ssh connection and executing bunch of commands in the osgi console. Painful and unpleasant process - with the time the installable bundles were growing in number, also we had a dependency on the installation order, so if something went wrong we had to install all over again, in the last days of the Amazon hosting I did an installation which took me around 4 hours with 4-5 attempts.
- Cost - The benefits from the Amazon Cloud are endless - constant updates and new tools will help you a lot, also new images with all kind of OS and configurations that you need. But on the other hand is the cost. With the time we build up an army of images and instances. We were operating 2 DB's for sandbox and production, we were doing backups every day, we've started numerous instances for development and testing which was increasing the total cost drastically.
Then the time for JPaaS came.
We actually used our own tool to track the migration process (see screenshot) of the productive Gravity App from Amazon to JPaaS - we planned a downtime of 60 mins but we managed to do it under 30.
At the begging it was a bit of mess because we were revoked from our OS access rights. We had to ask for almost everything from the JPaaS team which was annoying, but after setting the things up everything started well.
- Installation: The deployment is done via cmd tool which uses a properties file and it is really easy to start/stop an instance. Also the bundles are no longer deployed manually instead the command line tool uses the p2 installer and it is done really fast. So the first improvement came with the deployment time - from 4 hours to 10 minutes or less. Of course a lot of effort from Megha (Dev Team) team to make their deployable working without dependencies.
- DB: All the responsibility for the DBs fell off our shoulders and it was no longer our business. The DB in JPaaS was backuped every hour so this came also as an improvement with 12 times higher backup rate than before. The persistency was not a problem and after good job done by dev team the Gravity models were persisting perfectly.
- Monitoring: Our monitoring measurements were adopted by the JPaaS colleagues and we continued receiving emails with warnings and problems increasing our capabilities of reaction and high product Availability.
- Instances: This time the instances were 3 and 3 only. 1 maintained into the PROD JPaaS Landscape - used for automated tests execution and functionality verification, 1 on Factory JPaaS Landscape - which is used as a final step check before releasing to the final 3rd productive instance. The first one is accessible via Sandbox Streamwork but only for authorized users for executing tests and the other two via Streamwork. The staging of course is "undercover" for test purposes and the productive Gravity a.k.a. "Process Flow - Beta" is accessible from Tools Catalog>Beta.
The operations activities have been sufficiently reduced with only update, test and monitoring check procedures. Starting with a team of 5 we now run the operations only 1 person needed to handle it all. Of course it wouldn't be possible without the previous operations and development efforts put together.
Finally I can state that JPaaS came as a really good solution and everyone will agree with me. We maintain around 100% Availability and the product is really stable.
You can always find improvement points of JPaaS like some dependencies that you never thought of, or the lack of OS access to your systems but if you put all on the table it seems better than the Amazon.
Gravity is already in GA and you can read more about it here: http://scn.sap.com/community/bpm/business-process-modeling/blog/2012/03/20/generally-available-to-on...
- SAP Managed Tags:
1 Comment
