Cloud migration – Points to consider.

Migrating Enterprise Software to the clouds

In today’s IT decision-making many CTOs consider seriously moving systems to a 3rd party cloud (Iaas based).

This article is not about pros and cons of migrating your IT systems to a cloud-based platform, but more of a “points to consider before making the decision”.

(The following points were written as reference to SAP ABAP JAVA apps but can also be taken in account regarding any other multi-tier applications).

Cloud platforms come in all shapes, sizes and can take several forms. Companies like SAP, HP, Amazon, Microsoft, Virtustream and many other have different cloud solutions for your IT scenarios. They vary in their management capabilities, virtualization platforms, compatibility with your current domain, pricing and more.

A recent poll by Virtustream concludes that 69 per cent of large organizations are planning to migrate their business-critical applications, such as ERP systems, into the cloud by the end of 2014.
Migrating a system to a cloud, in general, means – transferring the application infrastructure to a different site somewhere other than your IT site, this way you can have different and in most cases (depends on the agreement with the cloud service provider) lower maintenance costs.
(Of course it means virtually transferring and not physically putting your servers on a plane ???? )
There are all kinds of maintenance plans – from just having virtual servers that are maintained by your own IT people to a complete end-to-end maintenance and support of your hardware and software.

So what are the points to consider before making the leap towards the clouds?

Well, there are so many key factors to be considered but in most cases the critical one is latency due to physical distance between your site and the cloud.
Some of you might think that in today’s very fast internet and dedicated lines it won’t be a problem. Well that is true in some cases. It all depends on your current architecture and usability of your software.

Let’s say you have a classic 3 tier app architecture: GUI, APP and DB.
Transferring just the APP tier would result in too many round trips – from your users GUI to the APP which is in the cloud to the DB in your site and back the same way.
This can and will result in performance degradation.
So the obvious solution would be transferring both APP & DB tiers to the cloud.
As simple as it may look, aside the licensing issues you might face regarding transferring your DB to the cloud, this holds other issues, for example – system copies.
Copying a very large DB from one environment to another is time consuming even in your current site. Of course it depends on your physical configuration and type of copying (SAP standard sys copy, EMC clone, RMAN etc.) but you need to take it into account because no system is a truly stand-alone system now days.

Speaking of stand-alone systems, what about interfaces with other systems?
As long as all your communication to other systems is based on web services using REST or xml you have not much to worry about because it is fairly lightweight on the networking channels. But what happens if your system needs frequent access to file shares on your local network (dedicated file server or other app server….)
What about CR transfers inside your SAP landscape?
If your landscape is distributed among your site and the cloud – you might find it frustrating at some point in time.

Some organizations consider moving all their Non Production systems to the cloud, leaving just their production on their site.
This way all of the communication between the non-prod is optimal, however this scenario holds other problems to consider.

If you put aside the previous subjects mentioned (CR transfer, system copy/refresh, external interfaces to other systems) you will have to address issues such as load tests.
Most load tests are done in the QA systems using 3^rd party tools. Performing load tests from your site on your cloud apps could have negative effect on the results.
Could you rely on those tests in order to go live for production? The ideal load test is done on a scenario which resembles your production scenario as much as possible.
By the way, some cloud providers also provide load tests on their behalf because of this.

So what would be the ideal candidate for cloud migration?
That’s a tough one to answer but I’ll give it a shot.
The ideal candidate for starters would be a system which is as stand-alone as it can possibly get and the user front end is http based (browser for example).
If you could have the APP & DB tier in the cloud and the GUI tier is browser based – you would definitely gain from cloud migration.
I would suggest anyone considering it to start with a stand-alone Enterprise Portal, with its own local UME (instead of LDAP or ABAP), with minimal JCOs as possible (unless the backend is in the cloud as well) and minimal iViews of external sources.
This would be the ideal test case.

So to summarize:

• Optimal apps for cloud are browser based 1^st tier.
• Optimal external interfaces would be web services.
• Moving entire landscape should be considered.
• Heavy use of file transfer (the use of external file shares, big CRs and etc.) should be avoided.
• Licensing for DBs should be taken into account.
• The use of load tests in the cloud is recommended.
• System refreshcopy should be taken into account regarding size ime.
• A simple EP with local UME would be a good case study.

Of course there many other things to consider and in time I will update this article, but these are just the basic ones that should help anyone contemplating with Iaas for his Enterprise Apps.

Don’t get me wrong, the cloud services these days are far better than the early days when cloud was just a buzz word.
Migrating systems to a cloud provider could be beneficial for many organizations when it is done wisely and with careful planning.

Adi Jabkowsky