How do I get my applications in the cloud?
Companies that have been around for a while typically have a fair amount of applications, hundreds or even thousands, and it does not make sense to migrate the whole set at once. Actually, the exercise can be a good opportunity to clean-up the application landscape.
Before looking at the application transformation space, there are a couple things you need to do. First define the cloud eco-system you want to build. Keep converged cloud in mind. Are you focused on the private cloud, are you ready for managed and/or public cloud, is SaaS an option? In other words, what are the boundaries? Second, look at your applications and decide the ones you want to move to cloud. Many criteria can be used for defining which ones to include in the list. I would focus on following (a non-exhaustive list):
- Is there variability in the usage pattern of the application? Is that variability predictable? In other words, is cloud adding value in the process? If not, why would you move to the cloud?
- Will this application be needed for quite some time? If the application is sunset very soon, it probably does not make sense to migrate the application and endure the additional cost of that migration. If the application is sunset now, you may want to look at cloud to develop/source the replacement application. That’s probably a smart move.
- Is this an application suite you have invested in heavily and that you don’t want to disturb at the moment? If you spent millions in implementing an ERP system for example, you might not be interested in redoing it all over again.
Start with a small list, 8 or 10 applications maximum. So, now you have to decide where to put those applications. In which cloud (private, managed, public) will you host the application. This is a management decision as potential risks and rewards should be assessed for each scenario. I would suggest the use of the “core versus context” approach I highlighted in a previous blog entry. Which are the applications that really make a difference to the enterprise, that make the company what it is? It’s interesting to see that many corporations have difficulty responding to that question. But it is mandatory to do that in order to be able to protect the enterprise assets.
The core applications should stay in the private cloud or potentially a managed cloud, the context ones can move to managed and/or public cloud. Note I mentioned managed cloud with both the core and the context applications. Managed cloud is an evolution of outsourcing, with clear contractual agreements and visibility from a security and compliance perspective. So, if you company has been outsourcing key applications for several years, you might be thinking on whether you need a private cloud or whether you are OK with a managed cloud.
Making the decision on where to put what application requires looking at many factors, not just technology. And each situation is different. I created an example of how the dialogue could go. It’s the story of ACME Corp.
There is one additional element that you need to keep into account and that is related to the data and its importance for the company. So, for the data, use the same approach than the one used for the application, core versus context. Which data is core for the company? And which applications use that data? How dependent on that data is the application. You may end-up with several scenarios:
- If both the application and the data are on the “core” list, it’s a no brainer, this is one for the private cloud, or if you want to “outsource”, go for a managed cloud.
- If the data is “core”, but the application is “context”, you really have to analyze how dependent the application is of the data. What latency is acceptable, in other words, what is an acceptable delay between the time the application requests the data and the time it gets the data. If we speak about hundreds of milliseconds, having the data in a private cloud and the application somewhere else is acceptable. If things need to go faster, for example because the data is consulted as part of a transaction involving human interaction, you may have to keep the application on the same cloud as the data.
- If neither are “core”, well then you can take both to a public or managed cloud. Security and compliance reasons may push you to a managed cloud. Is that because a public cloud is not secure, actually not. It’s because of the lack of transparency in the public cloud.
As you see, the decision of where to locate an application is critical, and time needs to be taken to carefully analyze the different aspects before taking a decision. Map out the applications, the data and their interactions to have a clear view of what is really happening. Make sure your assumptions are correct or you may be left with surprises.
The next step is to define how the application can be transformed to the cloud. And here there are four possibilities:
- You can decide to leave the actual application in the traditional environment, but make it visible and available from the cloud through web encapsulation. That’s reasonably easy and quick to do, but you do not save money in the process. It becomes more complex to manage.
- You may be able to re-host the application, if this one has been built around SOA (Service Oriented Architecture) principles and can easily be exposed as services to the end-user. That’s obviously the most positive scenario and the easiest one to justify. You will need to retest the application, but that’s not a big cost ticket
- You may have to re-architect the application, which means transform it in an SOA compliant one. In the process you may end-up replacing some portions of the application with services you already have available (own development or SaaS). But it will imply a partial rewrite of the application, followed by a thorough testing period. Although it’s a costly operation, in the long run there will be good savings.
- If the application cannot be re-hosted nor re-architected, and you are not interested in maintaining it in the traditional environment, you will have to decide to replace it. Either with a new application you develop using SOA principles (if the application is truly a “core” application) or by sourcing SaaS services from an outside provider. It’s costly in the short term, particularly because it forces a retraining of the users and a migration of the data, but provides savings in the long run.
So, for application transformation, the second decision is which migration approach to take for each of the applications you have chosen to migrate. So, in a nutshell, application transformation is a three step process, decide which applications you will look at, decide where you’ll put them and then decide how you’ll get there. Simple, isn’t it. Well, it’s probably a little more complicated than that, but in the essence, that’s what we are talking about.
If you are interested in this topic further and you are coming to HP Discover in Las Vegas in early June, you might be interested by two sessions in the Master the Cloud series:
- Charly Bess present “application transformation in preparation for cloud” addressing how organizations can determine the cloud suitability of applications (session number BB2883)
- I will present “HP’s Converged Cloud reference architecture”, addressing the architecture and how applications can be transformed from an integration, re-hosting, re-architecting or replace perspective (session number TB2051)
Hope to see you all there.
Photo: freedigitalphotos.net
