Let me continue discussing the business aspects of cloud series I published originally on CloudSource.
The number one question I receive when talking about cloud is how and where to put what application. So, naturally we end up speaking about applications in the cloud. But before discussing this in details, let me remember the point I made in my last blog, talking about the “strategic service broker” and the concept of hybrid delivery, where the CIO looks for the appropriate service, regardless of the platform on which it runs. If there is one thing absolutely certain in cloud, it is that “one size does not fit all.” I recognize four key cloud categories:
- Private Cloud, a cloud developed for the purpose of one company and hosted in their datacenter. Most often such clouds are also owned by the company
- Hosted Private Cloud, similar to the private cloud, but managed and potentially hosted in the datacenter of a service provider. The cloud is for the sole purpose of one enterprise and is often owned by that company.
- Public cloud, a multi-tenant cloud, owned by a service provider. The user consumes cloud services (IaaS, PaaS and/or SaaS) and pays per use. These clouds mostly lack transparency making it difficult to assess the overall security and compliance of the use by a company
- Virtual Private Cloud, a cloud that operates as a public cloud, but with clearly defined security and compliance/location rules, agreed upon in a proper contract. The end-user consumes services and pays per use.
So, the key question now becomes, which application do I host where, not forgetting many companies will keep legacy applications running for the forcible future. There are actually two types of cloud enabled application, traditional applications that run in the cloud and applications specifically developed for the cloud. The latter have multi-tenancy at their core and are able to scale up to millions of users, which is actually not what enterprises need to run most applications supporting their business.
Starting from Geoffrey Moore’s concept “ Core versus Context”, I advocate that core applications should be maintained in-house while context ones can be moved to more public cloud environments. Things are actually a little more complex as the data aspects also play a role. Cloud applications typically consist of individual services tied together through data sources, in a design that follows the SOA (service oriented application) principles. So, beyond just looking at the value of the application to the enterprise, one also has to look at the linkage between the actual application logic and data sources. Data can also be “core or context”. So, a context application that heavily relies on core data may have to be handled like a core application.
To make matters even more complex, there are a number of external factors that intervene in the definition of where the application is positioned. These have to do with security & compliance mainly.
So, to illustrate how to go after defining where to put a specific application, I ended up creating a little case study, using the well-known ACME corporation as a base. The management of ACME is discussing where to put its key applications and describes the key reasons for dispatching the 6 key applications they have (ERP/Financials, CRM, e-mail, HR, product development and digital product testing) across private, virtual private and public cloud. In doing so, they highlight the key elements that need to be taken into account.
With that, we have discussed where an application should ideally reside, but that’s not all. How should we transform the application to ensure it provides maximum benefits to the organization? For this, I’d like to refer you to a blog post I wrote a while ago, titled “How to transform applications for cloud migration”.
Planning the target location of applications is the first step on an application transformation journey to the cloud.