Transitioning your workload to the Cloud

Various Cloud computing organizations are offering the Nirvana in terms of IT where you only pay for what you use and capacity planning can become a thing of the past because of the elasticity provided by Cloud implementations. One would wonder why more organizations do not move into either a private or public Cloud, however, the answer is relatively straightforward.

All of the Cloud implementations available today make resources available on a limited number of platforms with a limited number of software stacks. While there is nothing wrong in principle with this, it means that if you are running your business on anything other than the limited platforms offered, it will require a conversion effort to prepare systems to be moved into the Cloud. This conversion effort represents another expensive exercise effectively to put your applications on yet another proprietary software stack.

A standards based approach to Cloud will pay a lot of dividends. While the Cloud itself still leaves a lot to be desired in terms of standards, the usage of existing inter operability standards like SOAP and REST will position your applications and data to move into the Cloud. The basic concept is:

- Create SOAP or REST Services around your core assets meaning your existing applications and data.

- Moving forward, your clients or consumers of these applications will use these SOAP or REST Services to get their data.

- Identical SOAP or REST Services may then be created in a public or private Cloud.

- Data can then be moved into the Cloud implementation.

- Once completed, your consumers of this data must simply be pointed at the new Cloud based SOAP or REST Services.

While such an approach does have costs associated with it, these are likely to be similar or less than what it will cost to move your applications on a proprietary basis into the Cloud. Consider also that this approach leaves you with the flexibility to potentially move workload easily again to perhaps a cheaper Cloud provider thus providing the optimum combination of flexibility and choice of provider. One requirement you will have will be that the tool or tools you use for this effort also run on multiple platforms and technologies. The SOA Gateway is such a tool. You can find further information on this topic at the document found here.

Change management, as it used to be called, or the new buzzword ‘governance’ is a key component of any SOA.

If we consider that one of the main benefits of SOA is reuse, this can sometimes only happen when slight modifications are made to a service to allow it to be used for a different purpose. The change will normally not impact on the previous use but to ensure reuse, the change must be made.

It is key that an existing, running service does not break so there must be different versions of a service available during the transition phase. However, once working, it is essential that the existing users of the old service are upgraded to avoid having to support multiple versions of the service. As such the usage of your services is key to this change management.

SOA Governance with the correct tools can be extremely helpful in upgrading services ensuring continued reused and deprecation of older copies of the service. There are two documents here which discuss how both life cycle and usage governance of your services can help your organization. These governance capabilities are all implemented in the SOA Gateway.