Anoop Dawar is Senior Vice President of MapR Technologies.
Organizations learned what "lock-in" meant during the era of mainframes. When enterprises needed higher performance, IBM would charge them a hefty license fee and then send a service rep to “upgrade” their mainframes. The service rep simply changed a couple of jumper settings and voila -- you had a faster system.
Then, with the advent of relational databases and SQL, we saw new and rapid innovation in the mid to late 1990s. Out of it was born Oracle, and all the applications that were written to Oracle were completely dependent on the Oracle RDBMs. This was the second major lock-in wave that alerted the enterprises about the downside of proprietary APIs.
The Little Engine That Could … and Did.
And in the backdrop of that arrived Amazon Web Services (launched 2006). One of the most popular services on this system today and for the last several years continues to be redshift - the name is no coincidence as it refers to the red Oracle logo and the desire of locked-in customers that were dissatisfied with Oracle to shift to an alternative.
As enterprises large and small started to embrace AWS, it grow surely but also quietly. The silent growth of AWS from a no-name to more than $5 billion inn annual revenues in 2015 (which was the first time Amazon shared AWS figures) was a very clever play by Amazon. Today, a good chuck of Amazon’s operating income comes from AWS.
Remember the famous words of Jeff Bezos: “Your margin is my opportunity!” If enterprise vendors are not obsessed with enabling customers, it creates room for customer-obsessed companies like Amazon to take away market share easily. And that is exactly what happened.
Between 2006-2015, most on-prem server, storage and networking vendors were going through a growth period but routinely cited broader market slowdown (2008 crash and recession) as a rationale for their slowing growth. The truth was, however, that a bulk of the growth went toward going to cloud or sophisticated home-grown solutions at cloud-scale companies (including AWS, but also LinkedIn, Facebook, Twitter, Google, to name a few).
Microsoft and Google jumped into provide cloud services as well.
The Story of Dropbox, Atlassian and Netflix
Dropbox is famous for starting on the cloud and moving to on-prem infrastructure when the loads and utilization justified it. The recent S-1 also showed how this move materially improved Dropbox margins and helped them achieve the current valuation in the market. Specifically Dropbox's revenue grew from $604 million in 2015 to $1.1 billion in 2017, but the cost of goods sold actually declined from $408 million to $369 million. The S-1 “Infrastructure Optimization” section states that the decrease was a combination of user policy changes and a shift to operating their own data centers instead of using cloud providers.
At the same time, Atlassian decided to move to AWS and achieved flexibility, agility and resource elasticity,
Notice that there is a big difference in the workload characteristics and long-term business models of Atlassian and Dropbox, and that may have a big role in the decisions they made and outcomes they achieved.
However, then Amazon decided to go into the media streaming business. We may never know the real reactions at Netflix or the decision-making process at Amazon. What we do know is that Netflix embraced what we may have considered a traditional competitor -- Comcast. Recently, Netflix announced a billing relationship with Comcast for their joint customers. Rumors abound that Netflix is looking at other cloud vendors as well.
Lessons from Leading Cloud Adopters
The lesson here is simple. Your business strategy, your cloud providers business strategy or your workload characteristics may change over the years. Therefore, adopting cloud should be done in a responsible manner. Fortunately, this is not as hard as it sounds and simple principles can help mitigate the risk substantially.
What enterprises are looking for is a way to:
● Increase their development agility by unabashedly harnessing the public cloud.
● Seamlessly enable public, private, hybrid and multi-cloud when the time comes.
● Pave a path to the edge.
● Accelerate the shift of existing applications.
● TCO reduction by optimizing usage of public cloud resources.
Can I Have My Cake and Eat it Too?
Embracing cloud can certainly provide the agility you desire. Following the principles listed will help you embrace the cloud fearlessly; and with a long-term strategy to ensure that your business is protected, even if the cloud may turn around and decide to compete with you in the future.
Use a Cloud-Neutral Orchestration Layer. Fortunately, Kubernetes has matured to fill this role. There are now more than 30 large and small organizations that are part of the CNCF Kubernetes initiative that will certify portable systems.
Use Standards-Based APIs. Instead of using cloud specific/native APIs, use the standards-based variety. For instance, instead of using Google BigTable, you could choose to use HBase or other open NoSQL systems such as the Open JSON Application Interface (OJAI). This enables portability of the application if you need to run this application in a non-Google cloud.
Build Your Own application API. Even if you choose to use cloud native services like Google Pub/Sub or Amazon Kinesis, create your own company’s wrapper APIs. These serve as an “agreement/API” that you then expose to all your applications. Applications then write to your company’s API. These come in handy when you want to move from one pub/sub system to the other. The apps don’t have to change if you decide to move to say, a Kafka API, later.
Reduce complexity of your system. Stitching applications and analytics in cloud is just as hard as on-prem. Although it is tempting to use cloud-provider micro-services in the cloud -- assess the risk of losing cloud neutrality against the speed of development. It may be better to write your own micro-service or use a third-party service available across all clouds.
Opinions expressed in the article above do not necessarily reflect the opinions of Data Center Knowledge and Informa.
