Digital Transformation
Showing results for 
Search instead for 
Did you mean: 

Cloud computing is a means, not an end.


A means to an end.jpgBy Christian Verstraete


This article originally appeared on the Cloud Source Blog.


Last week I was at HP Discover where I had the opportunity to talk to many customers. It’s always good to be able to hear first-hand what is top-of-mind for CIO’s and other IT leaders. Obviously the term cloud came up often, but it was always discussed as a means to reach an objective, not as an end in its own right.


Infrastructure-as-a-Service is increasingly seen as a commodity and many clients are actually getting upset when feeling like they are locked into a particular technology. The latest price reductions continue to demonstrate this commoditization as they remove the possibility for suppliers to truly innovate. These days, the debate focuses on the workloads, on what you put on that infrastructure. And discussion is important because it forces a new thinking.


From technology to service focus

Traditionally, IT departments have been technology focused (with heavy emphasis on the latest tool or feature). Organizations were, and often are, organized around technologies. This brought with it costs and delays most IT teams can no longer afford. The use of cloud and the focus on workloads and services changes the game. The question now is what service you deliver to the end user, and how well and quickly you can do so. This leads to a rethinking of the role of IT all together. Combining the needs for changing in focus with the increased pervasiveness of information technology in the digital enterprise, requires companies to rethink their approach to technology. But they need a trigger. From what I heard in Barcelona, three triggers can initiate the “journey to cloud”:


Trigger 1: Datacenter migration or closure

Although this is not a scientific survey, around half the companies I talked to brought this up as the reason for rethinking how they were bringing their services to their users. Some were struggling with lack of power in their datacenters while others had their leases running out. The result was often the same, they were no longer interested in setting up a new datacenter. They rather consumed services from others. They realized this was an important shift and were often puzzled on how they could do this quickly. I’ll come back on how we suggest to do this.


Trigger 2: Cost reduction

As much as we all hate cost reductions, the need is still there for many companies. And the prices advertised by some of the public IaaS providers give non-IT people the impression you can get infrastructure for next to nothing. Well, we all know that is not true, but go and explain that to your CFO. So, reducing costs is an important topic. Virtualization, automation and self-provisioning brings you a long way. But you have to get on the journey.


I had the opportunity to listen in on a discussion between a CIO and one of HP’s IT Vice Presidents. He explained how HP had ramped up the amount of applications it runs in the cloud over the last year. It improved the utilization of our server farms drastically. The combination of this with the use of “MoonShot” servers result in us being able to close two of our six datacenters pretty soon. Now, you speak about cost reductions.


Trigger 3: Agility and responsiveness

The third trigger, although less often present, is a push from the business. It comes in one of two ways, either key business users demand the CIO to improve his responsiveness in addressing their needs, or the CIO realizes the risks of “Shadow-IT”. Both have the same effect, the need to increase the speed at which IT responds to the demand of the business.


The response often comes in two parts. On the one end, development teams start using agile methodologies to come up with new features faster. Rather than having yearly or by-yearly updates, they now have biweekly or monthly sprints. I discovered we have actually gone as far as doing monthly releases for most of our software products. The consumerization of IT has shown end-users the benefits of such approached.


On the other end, the automation of all routine tasks. This includes the use of cloud technology to support the developers in managing the environments they need during the development process, and automation. Continuous integration, the automation of the test processes, and continuous deployment, the “devops” integration, speed-up the transition from development to production. As I mentioned in a previous blog post, they have many side benefits.


It’s all about applications and workloads

All three triggers focus on the value you get from using cloud. And these are related to how enterprise business processes are supported. Guess what- this brings us directly to the applications world. As I have mentioned many times before, application transformation to cloud is NOT a one size fits all. Different approaches are taken to enable applications to run correctly in a cloud environment.


Application transformation.png

The approaches go from a “lift-and-shift” to a complete application regeneration in a new technology, using the business logic extracted from the original one. For each workload you want to port to the cloud, you will have to identify the actual approach you take. This one will depend on the future of the application, the technologies used, the target platform and the fact you want to fully use the new features provided by cloud. The latter are essentially interesting when you want to mobile enable your applications or have them supporting new online business models for example.


A one or a two-step approach?

Beyond the approach itself, you also have to look at the available time. What I noticed in talking to customers was that in the case of datacenter closure, the typical timing was less than 6 months. So, you may not have the time to do a proper re-architecting of your application. My suggestion is then to take a two-step approach, first migrate the application as-is in the cloud (re-host) and then transform it (re-factor or re-architect).


DevOps, don’t get confused

The other element I had to stress at multiple occasions was the difference between PaaS and PaaS. Customers hear about CloudFoundry or Azure and believe that will solve their issues when going to cloud. Unfortunately it does not. Both are excellent for the development of new applications as long as you are willing to restrain to the use of the features included in the platform. Unfortunately, existing applications cannot easily be integrated into them, and applications needing to interact with the existing environment (applications or data stores), may not be able to take full advantage of the environment either. So you may need a different environment, one that does continuous integration and deployment, but without locking you into a platform. And that is where we are positioning the transformation platform we work with in enterprise services.


Go to cloud, but with your eyes open

Ultimately what you are looking for is supporting the enterprise business processes with the agility and responsiveness needed to allow the business to thrive in the volatile marketplace of today. It results in transforming the way you develop, manage and operate your applications. It’s about automation, agile development methods and flexible delivery environments. Cloud is one of them. That’s why cloud is a means, not an end in its own right.

0 Kudos
About the Author


This account is for guest bloggers. The blog post will identify the blogger.

Drew Dimmick

Hi Christian - great note.  I would like to point out that any app migration requires enterprises to be constrained to the capabilities of the platform - whether it be IaaS or PaaS.   But a very important point is missing for true PaaS applications.  Applications can be new or refactored to operate within the constraints of a PaaS such as Cloud Foundry - and when this is done, the workload becomes completely portable to a wide variety of targets.  If you go outside of the constraints, you can no longer do this.  This is not, in fact, an issue with PaaS delivered applications - it's actually the desired effect!   Enterprises would serve themselves well staying within the walls of their open source  PaaS (and avoiding proprietary extensions) as it opens up complete flexibility should they desire to move the application later on to a different nexus.



See posts for dates
See posts for locations
HPE at 2018 Technology Events
Learn about the technology events where Hewlett Packard Enterprise will have a presence in 2018.
Read more
See posts for dates
HPE Webinars - 2018
Find out about this year's live broadcasts and on-demand webinars.
Read more
View all