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

Cloud myth : once in the cloud, always in the cloud

mikeshaw747

In an increasingly digital world, our application and data analytics development needs to become a series of small, experimental steps rather than the large, waterfall projects of the past. The initial impetus for Agile development and continuous delivery was their ability to deliver higher quality outcomes.

But digitization forces Agility and continuous delivery upon us. Because the digital technology is moving so quickly, we simply can’t create a functional specification for something that will be delivered 18 months or two years down the line. Added to that, digitization can change the way that customers interact with our products. But we can’t know exactly how customers will want these new interactions to work. And so we have to try something, see what customers think, adjust, try again, and so on - a series of small, experimental steps.


With digitisation, we can no longer predict the requirements of our application’s run-time platform
This multi-step approach to application and data analytics development has an impact on the platforms on which they run. In “the old days”, we would go to IT, stick a “wet finger” in the air and “predict” how many users would use our application and the performance strain these users would put on the platform, the countries and thus the regulations we would need to meet and the industries, and again, the regulations we would need to meet.

These predictions were, of course, largely a work of fiction, but they would be then used to buy the appropriate compute platform.

These predictions were, of course, largely a work of fiction, but they would be then used to buy the appropriate compute platform. With the “lots of small, experimental steps” approach we have no idea how many users we will have - it could be 100, it could be 1 million.

With the “lots of small, experimental steps” approach we have no idea how many users we will have - it could be 100, it could be 1 million. And we don’t know which countries or which industries will use our application.


An example of a new digital service - “crop management as a service”
Imagine you make tractors. You have an idea that you could use digital technology to go from selling tractors to providing a “crop management service”.

You could put an array of sensors (wind speed, moisture, soil Ph, soil type, an so on) onto your tractors. You could combine the sensors' data with weather data and information about the crops that your customer has farmed on which fields in the past, apply some data analytics magic (creating field maps, for example) and thus provide your customers will valuable insights about the right time to do what to what crops. You could then link this to a social sharing platform and use deep learning analytics to create insights across all of your customers’ data.

You realise that you while the above vision sounds great, there are a lot of unknowns. Are the sensors accurate and reliable enough? Can you process and transmit the information from them reliably? What data analytics capabilities exist and can they be used to create field maps and the like? What will farmers, typically a pragmatic bunch working to tight margins, think about all this? You therefore rightly decide to take a series of small experimental steps, starting with a beta program offered to just your “friendly customers” in the mid-West USA.

You don’t want to commit capital expenditure (CapEx) to this project - you don’t know how much compute power you’ll need; in fact, you don’t even know if your “baby” will succeed. So you, like millions of others, choose to buy your compute platform as an operating expense, or OpEx.

Good. End of story?


A state change : from Experimental to Business Strategic
No. Not “end of story” at all.

After a few stumbling steps, your crop management-as-a-service “baby” is a success. You decide to move it out of limited release. You offer it to customers throughout the Americas and in Europe. The number of users goes from 40 to 2,000, and the numbers continue to rise.

At this point, something important happens. You and the managers in the business decide that your baby is no longer a baby. It’s now more like a young adult - it’s become important to the future of the company.

At this point, something important happens. You realise that your baby is no longer a baby. It’s now more like a young adult - it’s become important to the future of the company.

 


What changes between the experimental and strategic states?
Let’s look at what might change when our application moves from the experimental to the strategic state:

Predictability of performance
When an application is in its experimental phase, the performance requirements are all over the place. We can go from 100 users to 300 users in a week Or from 50,000 users to none in a month. But as the app moves towards its strategic phase, things become much less turbulent. Yes, performance demands may increase by 20 or 30%, but probably not by 300%. Our research into companies who have brought workload back from the cloud shows that the experimental to strategic state change is a common time for this repatriation to occur. And it’s often the stabalizing of performance requirements that is a motivator.

Assurance of performance
During the experimental phase, customers understand that it is wise not to rely on the performance of the new service. However, once we move to the strategic phase, customers do start to expect a level of performance assurance. This includes limited downtime and typically, little variance in performance - no long lags, for example. Again, it’s this ability to have tight control over performance and up-time that is a motivator for workloads to come back to the data centre once the strategic phase is entered.

The diagram below shows the transition from experimental to business strategic. During the experimental phase requirements are turbulent and unpredictable. But when we enter the strategic phase, things become calmer and more predictable.The diagram below shows the transition from experimental to business strategic. During the experimental phase requirements are turbulent and unpredictable. But when we enter the strategic phase, things become calmer and more predictable.
Assurance of costs
When something is experimental, it’s difficult to predict the profit contribution it is going to make to the company. But the strategic phase is when the business starts to rely on the service - it’s not about a bunch of engineers having fun any more. Any business person will tell you that in order to plan their business, they need to be able to predict their costs. The OpEx nature of cloud might be fine during the experimental phase, but when we enter the strategic phase, we need to be able to insulate the costs of our compute platform from unpredictability. This may involve us moving from the OpEx nature of cloud back to CapEx. This may seem counter-intuitive, but at the transition to strategic phase, CapEx means that compute supply is assured, its price is known, and the price of compute doesn’t rise as a linear percentage of demand.

When we enter the strategic phase for our app, we may want to move from OpEx to CapEx, counterintuitive though that may seem.

Continuous assurance of compliance from country, state and industry legislation
As we move from experimental to strategic, we offer our service in more countries and to more industries. In doing this, we face an increasing number of compliance regulations. And so, we need to be able to continuously (i.e. not just a one-off every 6 months) assure the compliance of our application.

Data backup and recovery requirements
As customers start to reply on your service, they need to know that you have their data safely and securely backed up, that the back an be recovered and recovered quickly.

A very modern change - a move to the edge
We are starting to see a pattern where an IoT, machine learning-based application starts out using a centralised cloud service. But as the amount of data being processed rises and/or as the application is used to take “real-time” actions, the developers realise that the app needs to be moved to a computer “at the edge”. I’ll go into this phenomena in more detail in my next blog post (it’s actually the inference and action portion of the app that moves to the edge - the piece that does the machine learning typically remains “at the core”, but often on a high performance compute platform because machine learning is very compute intensive).

During the experimental phase, requirements are turbulent and unpredictable. But when we enter the strategic phase, things become calmer and more predictable.

 


So what?
As the proportion of IT spend in the hands of business IT and CDO (chief digital officer) IT heads towards 60%, the number of new digitally-fuelled projects that are undertaken without any central IT involvement increases. I guess that this might be okay while those projects are in their experimental phase, but if and when applications become strategic, the skills that central IT has built up over the years will come into play.

Just like the guy I described at the start of this blog post, central IT can help with performance planning, performance and availability assurance, continuous compliance assurance, specialised security hardening and rock-solid and well-tested data backup and recovery.


RELATED POSTS

Will cloud will keep growing and growing until it takes over everything? History says, "no" : Will cloud keep growing forever? History tells us that new innovations like cloud will reach an equilibrium with existing technologies. It's already happened with e-books and tablets, for example. 

The Cloud Cliff : two pieces of HPE research into customers who are bringing some of their workloads back from the cloud. 

The cloud is dead. Long live the Edge : IoT means that when there is lots of data to analyze or where fast action is required, we need to use edge compute. This edge compute can't be provided by the centralized cloud model.  


Mike Shaw
Director Strategic Marketing
Hewlett Packard Enterprise

twitter.gif @mike_j_shaw
linkedin.gif Mike Shaw

 

Mike Shaw
Director Strategic Marketing

twitter.gif@mike_j_shaw
linkedin.gifMike Shaw

0 Kudos
About the Author

mikeshaw747

Mike has been with HPE for 30 years. Half of that time was in research and development, mainly as an architect. The other 15 years has been spent in product management, product marketing, and now, strategic marketing. .

Labels
Events
28-30 November
Madrid, Spain
Discover 2017 Madrid
Join us for Hewlett Packard Enterprise Discover 2017 Madrid, taking place 28-30 November at the Feria de Madrid Convention Center
Read more
HPE at Worldwide IT Conferences and Events -  2017
Learn about IT conferences and events  where Hewlett Packard Enterprise has a presence
Read more
View all