Cloud Source Blog

In what cloud do I host my application?

Target Cloud Decision Matrix V4.jpgOne question I regularly receive is the one of where to put a specific application. Often after a lengthy discussion we come up with an acceptable answer. However, one of my colleagues challenged me to come up with a decision tree, so the process could be more automated. I took up the challenge and four days and five versions later I came up with something that, I believe at least, does the job. There will always be the final, subjective touch, but from an objective perspective here is what I came up with.


Target clouds under considerations

The first point to define is which clouds you see as potential targets. Here are the ones I included:

  • The private cloud, an environment in your premises using virtualization, automation and self-provisioning technologies to deliver services to the end-users. This environment is owned and managed by you. It runs only for your benefits
  • The managed private cloud, a similar cloud environment, but managed by a service provider. It may be located in your premises or in your provider datacenter. It runs only for your benefits. Very often you keep responsible for managing the applications running in the environment.
  • The managed virtual private cloud, an environment set-up by a service provider in a clearly defined datacenter and with whom you have a well-established contract and service level agreement. You get full support, can audit the facilities for security and compliance purpose and you get a proper bill.  Multiple customers are hosted on the environment, but completely isolated from each-other.
  • A public cloud, an environment set-up by a service provider with preset terms and conditions, service level agreements and support options. There is no real transparency on the operations and you often pay by credit card. Such environment hosts multiple customers in a multi-tenant environment
  • Software as a service, where a particular service is provided by a service provider. Your data is held within the environment and issues such as data access, recovery and ownership need to be clarified. Such environment is typically multi-tenant.

Obviously some applications may not be suitable to the cloud and will remain in what I call the traditional environment, which is typically nothing else than the environment in which they operate today. Obviously they may still be web enabled so they are accessible from a cloud environment, but they cannot take full advantage of cloud technologies.


The first key question, core or context?

On this blog, I already referred to Geoffrey Moore’s concept of core versus context several times. To an enterprise, core are the business practices that set the company asked from their competitors and makes them being what they are. Context are the business practices the company needs to operate, but that do not give them competitive advantage. The applications and data supporting the core business processes are core, the others context.


As core truly differentiates you, you want to keep it very closely to your chest. So, you want to keep a close control of the application and data associated with those processes. So, if you move them to the cloud, it will either be to a private cloud or a managed private one of you really trust the provider.


So the first question you have to ask you is whether the application is core or context.


A core application

If your application is core, the next question to ask is whether the application is suitable for cloud. There are multiple reasons that could make it impractical to do so. Some software licensing schemas don’t lend themselves well to a cloud based running. These can apply to portions of the application itself or to key middleware used. For example if the licensing scheme is CPU or CORE (as in processor core this time) based, tanking a cloud based approach, using virtual servers, may increase cost drastically. Another aspect to look at is whether the application or middleware vendor supports a cloud based implementation. If not, going to cloud would leave you without proper support. The last aspect to check is whether there are OS or language requirements that make the plication unsuitable for the cloud, but frankly you typically have some freedom in private or managed clouds.


If the answer to one of these questions is yes, you will have to keep the application in a traditional environment.

The third question to look at is whether the application or its data has geographical limitations. Some applications have export regulations, some data types need to stay within a certain geographical boundary that can be country or region.

For example, the European privacy laws force information on EU citizens to stay within the boundaries of the EU countries. I have even seen some cases where information needs to stay within a province or state. For example, if my information is correct, healthcare data of English patients needs to stay in England. If that is the case, make sure your application and its data remains within the specified boundaries.


The next question to ask yourself is whether you are ok to use a managed cloud, do you have a provider you trust. If no, you will move the application to your private cloud.


If yes, does the managed cloud provider have an offering within the boundaries described above? If the answer is no, then again, you’ll be left with the private cloud as the option.


If the answer is yes, are the characteristics you need from an OS, language and middleware perspective available? One such requirement is that some databases run much better in a physical than a virtual environment. So, here the question becomes whether your managed cloud provider allows you to provision physical servers.


Last question is whether you are OK for your application to run on a multitenant environment or not. If yes, you’ll choose a managed virtual private cloud, if no, a managed private one.


Context applications

What if your application is a context application? Well, the first thing to do is to look at the data accessed by the application. Is that data core or context? If that data is core, you will want to keep that data in one of the environments described above, so, if we want to put the application somewhere else, it will have to access remote data. What is the maximum latency allowed to fetch the data? If it is anywhere below 200/250 milliseconds, you will want data and application in the same cloud. In that case, although the application is context, consider it as core and use the criteria described above.


If the data is context or there are network latency issues, the next question to ask is whether geographical limitations applies in the same way we did earlier. If the answer is yes, then we have to check whether a public cloud is available in the geography. If not, the target becomes a managed cloud and the checks concerning its acceptability, the licensing issues, the physical requirements and the acceptability of multi-tenancy need to be done as above.


If a public cloud is available, it looks like the best option, bit we should first check whether there are no issues with licenses and whether the software/middleware providers support cloud. Of no, unfortunately, the application needs to remain in a traditional environment.


If yes, are there needs for physical servers. That requirement often rules our public clouds as most only provide virtual servers. For the same reason we should look at OS, middleware or language requirements. Public clouds typically only support a limited amount of software versions, except if you are allowed to upload your own virtual machine images.

Not being able to address any of the points above rules out the public cloud and brings you back to the managed cloud options, the private cloud ones of in the worst case the traditional environment.


The last question to ask concerning the public cloud is whether you are OK with the terms and conditions, the service level agreements and the support options proposed. Again answering negatively to one of them rules put the public cloud.



So, in a nutshell, the key points to check are related to the nature of the application and its data (core versus context), the geographical limitations (compliance), licensing and support, the needs for physical environments, specific OS, middleware or language requirements, the proposed T&C’s, SLA and support options and finally the acceptance for the application to run on a multitenant environment. I believe I managed to integrate all of the aspects in my decision tree. Is there something obvious I’m missing in my discussion?

Labels: Cloud| CloudSource
Alexander Verharen | ‎01-28-2014 05:41 PM

I like the article. It would be nice to have a better resolution of the image.  (Could a URL be posted to a better image?).


From the arcticle text, yes, these are questions we have to answer every day in my group. Trying to build a service catalog and making sure my platform allows for a seemless and consistent implementation is our challenge.

Showing results for 
Search instead for 
Do you mean 
About the Author

Follow Us