The cloud is less about technologies and architectures than it is an operating model which represents the way you do business.
At Druva, we know how the cloud has changed, because we have ourselves lived through the transition. In 2008, when we built Druva’s first version of inSync as an exclusively on-premise product, we solved the problems of that day’s enterprise. As our customers became more global, always-on, and scalable, we had to evolve, too.
As cloud demands grew, we rejected the easy choice of porting our solution using traditional “hosted” in data-center approach. Instead, we completely re-architected our product from the ground up, to fully utilize the benefits of what cloud truly is. We were born again in the cloud — and it has paid off. Today, large enterprises such as Pfizer, Reckitt Benckiser, and Kronos rely on us to protect their most critical data. I’m confident we are providing them the best service and return on investment.
This journey has helped us learn how organizations view the cloud, and the assumptions that they make in their implementations — for good and ill. Here, I share with you some of what I have learnt from our customers and our engineers. The framework I provide may help you decide whether you are making investments in the right kind of cloud architecture. Here are some well-intentioned (but wrong) mindsets I believe every enterprise IT leader should question.
The cloud is not a technology
The cloud is less about technologies and architectures than it is an operating model which represents the way you do business.
The cloud is not just a more efficient way of purchasing computing power. Rather, it is a way of facilitating new, more efficient business models. Like your business, the Cloud is highly-distributed and highly-connected. It gives you access to additional resources — compute, storage, bandwidth — which is one reason we easily can think the cloud is “about” technology. But the advantage is that you, the user, do not need to be as concerned about where or how the data is stored, so long as you can consume the resources reasonably reliably, and in a redundant manner.
I believe that this architecture is a natural outgrowth of the need to build distributed, open, scalable, transparent, and fault-tolerant applications to facilitate your business juggernaut.
Unfortunately, but not so surprisingly, today traditional enterprises still are building or porting applications to the cloud using traditional “hosted” in data-center approach. By doing so, they are completely underutilizing the power of the cloud, to the detriment of their customers.
“Cloud” cannot merely be an abstraction of data center resources. The older data center-centric model is more of a centralized and monolithic model that is focused either an individual server or a group of servers. It does not take into account the distributed computing needed for scalability nor does it solve for the service- or SLA-driven consumption of the cloud. This model limits the scale of your applications and hence, it limits the scale of your entire business.
This is a classic innovator’s dilemma, where the incumbent fails to understand the new wave of innovation. The approach is not that different from what Blackberry tried to do by patchworking their phones to make them “smarter” without addressing the underlying architectural foundation.
Where the “traditional” data center-based cloud architecture goes wrong
Data center architectures or applications were created in the client-server era. They made fundamental assumptions that are not true for today’s shared model — also sometimes referred to as the fallacies of distributed computing.
In the old way:
- There are one or just a few servers
- The network is homogeneous, secure, and reliable
- Latency is zero; bandwidth is infinite
- Storage is homogenous
- Transport cost is zero
Inside a single location, the network is usually very reliable, extremely low latency, high bandwidth, secure, stable, under a single user or group’s control, and homogeneous, or nearly so. Great.
But these assumptions do not apply to the ephemeral nature of clouds. It is wrong, almost irresponsible, to call any architecture of this description as “cloud.”
Designing for the Service-Based Model
A cloud-oriented architecture needs to be an application-centric architecture. This has similarities with other well-established distributed computing application architectures, such as Service Oriented Architecture (SOA) or Event Driven Architecture (EDA).
There are five main motivations behind this new service-based model:
- Broad network access
- Resource pooling: Manage data/compute bursts effectively
- Rapid Elasticity: Linear scale and performance
- Strict SLAs
- Economy of scale: Cost advantage
Marc Andreseen’s LoudCloud.com provided the motivation for this service-based model, and AWS pioneered it. Rather than thinking of a physical resource or locality, you start from a service best suited for the job and what SLA can it deliver. And then, you build an architecture much more distributed and driven by clearly-defined customer SLAs.
