If enterprises are now admitting that everything isn’t going to the cloud, what is actually going, and staying? I’ve never believed the all-cloud hype, so for me that question is the most important. A related question is how much cloud reality is now reflected in enterprise planning, and since planning wrong got us into the wrong cloud position, this second question is important too. I’ve gotten 281 comments on these points over the last couple months, so let’s use them to try to answer both.
Nearly all enterprises (currently 426 of 477) say that they’ve made mistakes in their cloud adoption, moving the wrong stuff and doing the cloud wrong. Of the 426, 421 explicitly blame cloud hype, and all cite the more general cause of “inaccurate or insufficient information”. This probably doesn’t surprise many people, but it’s not really all that helpful to planners trying to do better. Let’s try to dig a bit deeper in search of useful insights.
The biggest problem? According to 411 enterprises, it’s best summed up as “I didn’t know what a good cloud application looked like.” Most interesting perhaps was one CIO’s comment: “I didn’t think about what any of my applications really looked like.” Obviously, if you can’t identify a good cloud candidate, you probably will target the wrong things. Less obviously, you won’t recognize techniques that maximize cloud value.
Enterprises say that their driver for cloud use is lower TCO, period. Obviously, lower is a comparison with on-premises, usually data-center, hosting. Of the 477 enterprises who offered comments, 465 said that the total cost to add a VM in the cloud was greater than that of the data center unless they didn’t have space. The cloud provider profits have to be considered. Thus, they say, there has to be something pushing changes in IT usage in order to validate the cloud.
All 51 enterprises who said they had not made cloud mistakes said that something was greater dependence on the Internet for prospect/customer interaction. All sold to consumers rather than to other businesses, 34 were online retailers, and 40 had transitioned from storefront-only operation. They indicated that the Internet created a different sales process even if online sales weren’t offered; the prospective buyers expected to “shop” online, and their desire was stimulated by what were largely random factors, like a commercial or something else on TV, an interaction with someone, almost anything. When stimulated, the Internet became an almost-immediate channel for product/service exploration. No more going out later, it was all right now and you either satisfied it or missed the opportunity.
This contrasts sharply with the 426 enterprises who admitted to cloud misses. In that group, 302 said that online customer relationships were not the major driver of their cloud adoption, cost savings were. The 51 cloud-satisfied enterprises all said they had adopted the cloud because it saved money too, but that group was citing the savings in an application mix that was changing to accommodate a change in their business.
We can propose a rule here: If you are not experiencing (or have not recently experienced) a change in opportunity, competition, or other major business factor that mandates application changes, you need to think carefully about moving something to the cloud. Abstract notions of cost savings apparently don’t work out well.
Now lets look at the 124 enterprises who had cloud misses but did have a major online relationship shift. Why did they go wrong? They tend to offer only generalized reasons, like “We moved too much” (said 41), “We did the cloud wrong” (38), or said they didn’t know. The happy group of 51 had some experiences that might shed some light.
Of the 51, 40 settled on terminology that suggested they had planned a separation between interaction and transaction (my terms). The former described the portion of online activity that related to making and supporting a decision, and the portion that actually executed it. The former was a “new” application piece and the latter just a tweaking of their current core application set. This had the effect of creating (with the interaction piece) a set of components that fit the cloud’s optimum profile.
Enterprises largely (roughly two-thirds) agree that where the cloud shines in benefit is where demand on resources is highly variable, which most say means peak-to-average utilization varies by 30 to 40%. Online interactions with random stimuli driving them fit this model.
The biggest challenge in creating the new two-level interaction/transaction model is data utilization. Many enterprises think data is really the only challenge, because it can muddy the separation between the two pieces of an application and generate ingress/egress charges. It has “gravity” in that it pulls components out of or into the cloud depending on where you put it, and often a seemingly simple change in data placement and access has major cost consequences.
The key to cloud success seems to be establishing and maintaining interaction/transaction separation. If that can be done, the rest of the application development decisions can be made by reasonably qualified teams, but if it’s not done projects get off track. However, those decisions need to be made based on just what that separation looks like. Sometimes it’s a narrow barrier, and sometimes it’s a broader zone.
Enterprises tell me that the biggest development decision for cloud applications is the placement of components along the path between pure functions and serverless and containers or VMs and monoliths. Those with the greatest cloud success (subjective) say that it’s often true that as the interactive/transactional boundary is approached, the need for and benefits of scalability decrease and the optimum software model becomes more conventional.
I think the lesson here is that it’s how a cloud project starts that matters most. Focus on the reality that it’s creating an online experience that really justifies the cloud in the first place ensures that the components of the application are properly and optimally divided between cloud and data center, and within the cloud between agile and more monolithic component strategies. Getting the right start doesn’t ensure success, but the wrong start seems to guarantee trouble.
