News/Trends, Tech/Engineering, Product

Thinking Cloud: Why Most Of Us Get it Wrong

Jaspreet Singh, Founder and CEO

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 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.

Cloud storage diagram

Building a file storage system based on cloud-based principles is dramatically different than traditional “block” storage. That’s not just in terms of cost, performance, and scale, but also in design principles and mindset. A new design had to evolve based on simple metadata-data separation to really exploit the benefits.

And thus “Object” was born.

Objects are the magic that enable massive parallel access to data without worrying about scale, durability, or availability. In the SOA world, details of block gave way to the simplified object approach, in which the details of durability, redundancy, replication etc. were elegantly abstracted by simple SLAs. Where the block had to be managed and paired using RAID, the object was self-healing and replicating.

I don’t think I can stress enough the importance of selecting the right cloud architecture. By doing so, you can maximize your gains by thinking afresh about data architecture and thus exploit the public cloud for its full benefit — and the joy of your users.

Are you considering cloud for backing up end user data? Download our new guide on top considerations when going cloud: