Gary Bloom is chief executive of the enterprise database company MarkLogic Corp. He wrote this article for SiliconANGLE.
In a situation nearly every company will face, one of the Internets brightest stars has highlighted the value of not getting locked into a single cloud computing provider.Snap Inc., creator of the messaging app Snapchat, recently revealed that it will spend $1 billion over five years on Amazon Web Services and may eventually build its own infrastructure.
The move will provide redundant infrastructure support of our business operations, Snap said in an amended S-1 registration statement for its initial public offering of shares. Snaps first filing spurred headlines, in part, because itdisclosed how closely Snaps fortunes are tied to Google Inc.s cloud, on which it said it would spend $2 billion over five years.In both filings, Snap said it relies on Google Cloud for the vast majority of its computing, storage, bandwidth and other services, and that any disruption of or interference with our use of theGoogle Cloud would seriously harm our business.
Heres the scariest part: Any transition of the cloud services currently provided by Google Cloud to another cloud provider would be difficult to implement and will cause us to incur significant timeand expense, Snap said. It also warned, If our users or partners are not able to access Snapchat through Google Cloud or encounter difficulties in doing so, we may lose users, partners oradvertising revenue.
Its pretty clear that giving the bulk of its cloud services to a single supplier is a huge risk to Snap.The company is, as The Information recentlynoted, the biggest consumer Internet company to be built from scratch on top of cloud computing infrastructureit doesnt own. It alsoreported that Google is giving Snap deep discounting and other benefits.
Discounts are enticing, but cloud lock-in is a risk to Snaps operations and economics. By warning that it may build its own infrastructure, Snap could keep its cloud suppliers honest. But that has meaning only if Snap can quickly and seamlessly transition its information technology operations from one cloud provider to another or to its own infrastructure. Cloud neutrality in what Snap builds, how it builds itand how the company runs its systems will have to be a key attribute of its daily development operations if Snap is going to benefit from a cloud neutrality strategy.
Thisrisk is not unique. By 2020, all companies will be doing something in the cloud. The cloud vendors, led by Amazon Web Services, Microsoft Corp. and Google, will want to run and manage theircustomers capacity and may even extend discounts for volume.
For now, that may not seem like a bad deal. For many enterprises, the cloud is mostly about fundamental services, such asstorage and elastic compute capacity. The underlying architecture is standardized around Intel hardware and Linux, which works in any cloud environment.
MarkLogic CEO Gary Bloom (Photo: MarkLogic)
The lock-in starts when you move to the software services and application layer of the software stack. Cloud providers offer proprietary APIs that reduce the amount of code or work required to getapps going. By using proprietary APIs, you get hooked into that vendors ecosystem. To move services to another cloud vendor or back in house will take, as Snap warned, significant time andexpense.
Enterprises may not even realize theyre getting sucked in. Almost all applications being created rely on a database. Anybody who codes software for Amazons DynamoDB database is basicallylocked into AWS as a cloud provider. Any software written for DynamoDB cant be moved to another cloud provider or transitioned on-premises unless it is rewritten, which is costly and timeconsuming.
In addition to the time and expense to transfer Google Cloud services to another provider, Snap said it has built its software and computer systems to use services provided by Google, some ofwhich do not have an alternative in the market. This comment leaves an open question as to whether buying AWS services alone is enough to mitigate the risk of cloud lock-in. It wont if theyhave to rewrite applications and change their DevOps to benefit from cloud neutrality.
Sadly, companies have been locked in before, when they chose to outsource their IT operations to providers such as IBM Corp. and Electronic Data Systems. They thought experts could manage their IT operations and datacenters better and more cost-effectively.
In the beginning, the economics looked encouraging. Then prices went up on three-year and five-year contracts as outsourcing vendors normalizedexpenses and added margins.They certainly never planned to lose money forever. Eventually, companies paid more for outsourced work than they spent in house. Yet they couldnt reclaim thework because everyone who knew how to manage it now worked for the outsourcing companies, or companies no longer owned their own data center infrastructure.
Enterprises should avoid cloud lock-in so they can get the benefits they get from any competitive marketplace, such as:
* Bargaining on price.Just as pricing increased for IT outsourcing when the suppliers added margin to the equation, so it will for the cloud. By 2020, most cloud consumers will see cloud computing billsthat are significantly higher than on-premises costs. The ability to go somewhere else will be key.
* Picking winners.We are early in this cloud transition, which 451 Research has said represents the biggest IT opportunity in decades. It is too soon to know which companies might dominate.AWS may look like a runaway leader, but Microsoft has made impressive gains. Who knows what innovations and improvements other companies may forge? In three to five years, differentclouds will focus on different things. Youll want to take advantage of what works for you.
* Being more secure. No one is ever completely safe from potential cyberattacks. If a cloud provider has a breach, you may need to move quickly to another provider. Being cloud neutral is aninsurance policy.
Originally posted here:
The many costs of cloud computing lock-in - SiliconANGLE (blog)
Read More..