Different routes to the cloud
I moved to Cary, North Carolina in 1995. Within a few weeks of settling in, I had already heard the same joke from several of my new colleagues here at IBM: “You know what Cary stands for? Containment Area for Relocated Yankees!” Clever, and indicative of a common view at that time – that there were two types of people in the area: those that were born here and those that relocated from some other place.
What does this have to do with cloud computing? Well, we are seeing a similar view in the types of enterprise IT workloads running on the cloud. In the early days of cloud in the enterprise, the focus was on taking existing workloads/applications and delivering them by way of the cloud. Cloud delivery was the logical next step of IT transformation – consolidation, standardization, virtualization and then automation. Taking virtualized workloads and then automating the delivery by cloud allowed for a much more efficient model.
For example, if you have an internally developed Java application, the approach is to create a virtual machine (VM) with all the requisite middleware (like WebSphere DB2) in the VM. This image is then stored in a private cloud, and dynamically provisioned as needed. This is what many call a “born-in-the-enterprise” application that is “relocated to the cloud.” The original application was developed outside the cloud and then adapted to take advantage of the cloud delivery model.
This is in contrast to a “born on the cloud” workload – an application that was designed to run in the cloud and exploits the capabilities afforded by the cloud. As cloud computing matures in the enterprise, the shift is on to more and more “born on the cloud” workloads. An IBM study concluded that by 2015 more that 65 percent of the workloads running in the cloud will be “born in the cloud.”
What distinguishes a “born on the cloud” application or workload? Essentially it exploits the services and capabilities that are inherent in the cloud platform on which they run. As vendors put more capabilities into their cloud platforms, “born on the cloud” applications will be able to leverage these functions to handle some of the traditional heavy-lifting of IT operations and delivery. For example:
- Relocated apps leverage a runtime environment (“middleware”) that is included in the same virtual machine. Born-on apps leverage APIs that are in the cloud platform.
- “Born-on” apps are built to automatically “scale-out,” taking advantage of the elasticity and built-in capacity management of the cloud infrastructure
- “Born-on” apps can be built in a multi-tenant model
- Relocated apps are managed with traditional system management tools, while “Born-on” apps leverage the cloud for resiliency and availability (the Recovery-Oriented Computing guys were ahead of their time!).
IBM is working with a number of clients who are looking at the “born-on-the-cloud” model for their next generation of internal applications. For example, there is a strong requirement for mobile support (smartphone, tablet) for customer-facing employees (sales reps, insurance agents) or customer-facing applications (mobile banking). The “born-on-the-cloud” model makes a lot of sense for these types of applications, as it contains the web app model, Internet-facing and elastic backend features that are attractive to these types of applications.
Understanding the difference in the two application types can help in seeing where IT is headed. Geoffrey Moore talks about this in his “Future of Enterprise IT” white paper. I have seen some articles where people align “born in the enterprise” with Moore’s “systems of record” and correspondingly align “born on the cloud” with “systems of engagement.” There is definitely a Venn diagram alignment (many “born in the enterprise” applications are systems of record, most “born-on-the-cloud” applications are systems of engagement), but there is clearly not a one to one correspondence.
The key takeaway is that enterprise application developers need to learn from the consumer world and develop applications that handle the dynamics of a highly interconnected world with streams of new data and information coming in every minute. The “born-on-the cloud” model is a good fit for these types of systems.
Relocate, rewrite or replace? As you are working through an enterprise cloud strategy, it is important to understand the differences so as you look through the portfolio of applications you run. Decisions can be made as to what approach to take:
- Relocate an application to the cloud
- Rewrite the application to exploit the cloud
- Replace the application with a software as a service (SaaS) equivalent
- leave the application in a traditional delivery model (“if it ain’t broke don’t fix it”).
Understanding the dynamics of each option, and choosing the right path for your enterprise applications will lead to a much more thoughtful and sustainable cloud strategy.
Great and inspiring article Ric… Thanx was glad to read…
Hi Ric. It is an excellent article. Thank you very much.
I was pleased to find this very clear explanation of "born-on-the-cloud" when I searched Google on the topic. This is an article that many of us in the technology world can use with business buyers who are trying to understand some of the cloud terrninology, concepts, etc.