Rent or Buy? Should You Go to Cloud (or Not)?

Contributed by

20 min read

Editor's note: This article is the first in a series on Cloud, Kubernetes and Dataware.

What does "cloud" actually mean?

Not only is cloud a huge buzzword, it's also a very real trend that is driving adoption. What is cloud, really? Sometimes, with all the hype, it seems as though some people think of cloud computing as something magical - that applications and data are not on hardware at all. Of course these are running on machines somewhere, it's just that with cloud you don't own or manage those servers. The basic idea of cloud is to take advantage of economies of scale by using part of a large farm of servers managed by a common team. It's the idea of computing and data storage on demand. And, most importantly, cloud is a question of whether you want to rent or buy -- and of what it is that you are renting: the hardware? computational power? storage? management? specialized services and software?

By the way, saying "cloud" in the context of this article means public cloud services (Infrastructure as a Service or IaaS, platform as a service or PaaS, Software as a Service or SaaS) that are offered as service-on-demand from public cloud vendors.

Cloud bundles, of course, a collection of tradeoffs. For example:

  • You may go to the cloud to save yourself the trouble of managing servers and networks and save yourself the cost of the IT team who does that but you trade away control over management and you still pay for someone else to do the management for you.

  • You may go to cloud to save the cost of buying hardware and paying for floor space and air conditioning, but you trade away first priority over machines or control over their precise geographical location. And what happens to your data and applications when machines fail?

These are just a few aspects of the trade-offs people face as they consider to what extent their business should run in cloud. The key to success is to understand the basic issues so that you are well prepared to plan, build and adjust your organization as needed.

The big picture around cloud does not change as fast as each cloud vendor's details do.

If you do the fundamentals right, you'll be in good shape now as well as for the future.

It's no surprise given the level of buzz that the trend to move to cloud, in part or as a "cloud-only" approach, is huge. But you may be surprised to know that there's also a growing trend to pull back out of cloud, at least in part. Let's look first at the trend toward cloud.

A ZDNet article from Dec 2018 says that annual revenue rates for some of the top cloud vendors were already in the range of 10's of billions of dollars. Not only are a growing number of enterprises making use of cloud, the relative market share for different vendors is also changing. It is certainly true that there's a rush toward cloud.

There is, however, also a growing counter-trend. As more enterprises make use of cloud storage and services and discover the realities of cloud challenges and costs, many are bringing at least some of their data and applications back to on-premises clusters. In some cases, these are systems that started in cloud, and in others, they had been migrated from on-premises to cloud and now are being brought back. Why is there this trend to cloud and back again?

Repatriation happens for a variety of reasons. A February 2019 TechTarget article titled "Cloud repatriation and the trend away from all things cloud" mentions a Fortune 500 company that withdrew from cloud because the costs were unexpectedly large. The article reports their savings as $80 million monthly as a result of withdrawing from cloud. The article also refers to an IDC report that states "...53% of enterprises were -- or are considering - bringing workloads back on premises."

Reports of repatriation should not be seen as a condemnation of cloud or an indicator that the cloud trend is over - far from it. Rather, the move back from cloud can be seen as an indication of the potential strength of hybrid architectures, a combination of on-premises and cloud environments. Hybrid multi-cloud strategies are the topic of a later blog post, but it's worth noting here that even distinctions as common as base workloads versus peak workloads differ with regard to which is better optimized for running on-premises or in the cloud. Maybe the idea of "cloud-only" is better conceived as "cloud-1st" - you'll use cloud unless there's a good reason not to do so.

Figure: A burst to temporarily expand computational resources is fairly easy to do in cloud deployments, and it can be a cost savings for peak work loads. But an on-premises data center may be more cost effective for steady, predictable base loads, especially at scale. (Based on Figure 2-5 in book "AI and Analytics in Production: How to Make It Work" by Ted Dunning and Ellen Friedman (published by O'Reilly Media) used with permission. Download free pdf of eBook here.

Most importantly, the reported trend for return from cloud underlines the importance of fully understanding cloud fundamentals - the advantages and the trade-offs - and adopting a cloud strategy that is realistic. You need a good fit to your particular needs and, most importantly, a strategy that protects your flexibility to make changes in the future.

Three Ideas That Do Not Have to Be Bundled

The rush to cloud is, in part, a desire to attain three key advantages:

  1. Cloud-style computing
  2. Access to specialized (fancy) services
  3. Renting versus buying hardware (and management of clusters)

Many people assume that these three advantages must be bundled and that cloud is the only way to get them, but that's not the case. These three ideas do not need to be bundled. In fact, for best results, they should not be automatically linked together in your mind, else you leave yourself open to the pain and cost of vendor-lock-in from attractive cloud vendors.

Once you tease apart these three advantages and examine each in its own right, you will realize you can get them as needed, either on-premises, in cloud offerings or both. Cloud-style computing or "cloud native" relies on the flexibility conferred by container-based application deployment, essentially a containerized microservices approach. In particular, it usually involves building a service out of multiple containers, rather than one container or VM per service. Furthermore, there is a presumption that these containers are managed by some cluster-wide executive (or orchestrator). While this is a good idea that we highly recommend, it is not solely tied to cloud. (Think of containers as no more than a way to deploy and run an application in a pre-defined environment and in isolation from other applications) Containerization services require orchestration of resources, applications and locations, and a great orchestration framework such as Kubernetes makes this possible in cloud but also on-premises.

Access to specialized services or special hardware is also a driver to go to cloud, but these, too, can often be used on premises. More importantly, you can take advantage of particular cloud-specific services without turning all your resources and workloads over to cloud or just one cloud. You might run the majority of applications on-premises or in a cloud service such as AWS but take advantage of excellent machine learning tools offered by Google via their Google Cloud Platform. That might lock in a particular aspect of your work to Google, but it doesn't have to lock in everything, especially if you take advantage of well-informed strategies and the right dataware.

Even if your main motivator for cloud is to rent rather than buy hardware, keep in mind that you can rent hardware that you maintain on premises. The appealing thing about cloud, however, is the flexibility to run only what you need for only as long as you need it, which can be quite an advantage. So for best results, think in advance about what you want (rented hardware, outsourced management, specialized software) and why as you plan your approach.

By recognizing that these three factors don't need to be bundled, you are free to design a system that will best serve your needs.

Motivations for Cloud: Do They Fit?

Why do people think they want to go cloud? To save money? To use cool services? Because the boss told them to?

Some motivators to go to cloud really are advantages; others are not so clearly a win. The important thing is to understand what cloud deployments really involve, what you own needs are and the realities of what cloud will mean for you.

Here's a quick look at some of the main motivations to go to cloud.

  • Burst / Compute Elasticity

A practical motivator is to temporarily burst to cloud for temporarily high computation workloads, such as initial training phase of a big machine learning or AI project. Suppose you want to do something but have no room on-premises or you don't want to put a high load for a special project that would potentially interfere with smooth running of regular workloads. It can make a lot of sense to do this in a public cloud: spin up what you need, use it as long as you need, then let it go. In the simplest sense, elastic computing means renting machines for a burst of computing and getting convenience and flexibility.

  • Fresh Start

Cloud can also be a place to go to make things right. Maybe your organization has become entangled in a cumbersome IT burden, or you have a complicated architecture you'd like to redesign. You need a clean start, but even if you are drowning in technical debt, you can't afford to stop all engines of commerce while you make changes. Here's where cloud could come to the rescue. You can build a new, streamlined and flexible system using cloud resources while you continue to run your regular business on-premises. If you find the costs are acceptable, maybe this is a permanent (or in the near-run permanent) migration of that part of your business.

Alternatively, once you have the clean design you were seeking and have decommissioned the old debt-ridden system, you can move back to an on-premises data center. The good news is: you don't have to give up what you've gained in a better overall design. You might have to make some changes in repatriation if part of your redesign use cloud-vendor-specific services, such as a cloud-vendor-specific database, but otherwise, you could move back. You would have been able to re-organize and streamline your architecture by temporarily relying on cloud-independent services. That leaves you free to move your new system back on-premises or to another cloud vendor as best fits your needs and best optimizes costs. Once again, your choice of dataware makes a big difference in how easily this works.

  • Experimentation

Some of the biggest wins in data-driven business come as a result of experimentation. One thing you can experiment with is cloud itself. A December 2018 article in ZDNet relayed results from a RightScale 2018 report on cloud that showed that among the enterprises surveyed, the percentage of use with any of the leading cloud vendors for experimentation ranged from 12% to 26%.

Although there are tangible costs plus costs in terms of effort to migrate data to cloud and try running applications there, it still is a good idea to experiment to see if this environment really is good for you. That way you get a more realistic sense of cost and you experience potential "gotcha's" before committing critical business processes to a cloud deployment. Even with on-premises data centers, you may use cloud as a way to test different architectures or different hardware before you commit.

Professional services at MapR find it useful to experiment with different hardware configurations in cloud to find the optimal set-up for a particular customer. For example, one MapR customer, a very large retail business, is completely shifting their company from traditional data stores onto the MapR Data Platform and adopting a modern, streaming microservices architecture. Renting hardware from a cloud vendor made it reasonable to do pre-tests to compare three different hardware options and configurations before settling on what was optimal. The week-long test was costly in cloud, but the combination of savings in effort, time and outlay for hardware still made it much more affordable and practical than trying to do the same comparisons with purchased hardware.

  • Special Hardware

AI and other very compute-heavy applications may best be run on specialized hardware such as Solid State Drives (SSDs) or Graphics Processing Units(GPUs). The latter are particularly useful for image recognition that is often a part of deep learning systems. If you don't already have a GPU system or are not yet sure how far down this path you will go, renting the GPUs via a cloud vendor may be a smart choice. You get immediate access, you can experiment, and you can find out if this is a long-term need without having to initially purchase the hardware.

In the MapR Data Platform, management and policies can be applied at the volume level including easy control of data placement such as on specialized hardware, shown here as darker blue servers. Volumes (shown as triangles) include files, tables and event-streams.

Although the use of specialized hardware such as GPUs is a motivator to go to cloud, it is also a motivator for repatriation. Turns out that for some organizations with a heavy and ongoing need for GPUs, it may be less expensive and even more reliable to have your own specialized hardware on-premises. For very intermittent use, running in the cloud may be a better way to use GPUs.

  • Special Services

Cloud vendors offer a wide range of special services including databases and machine learning tools. Within the last month, several new offerings may have shown up, or so it can feel as a dizzying array of special products and services are marketed to potential customers by the various cloud vendors. Some may be useful for your particular needs. But there is a serious tradeoff here: the more of the cloud-vendor-specific services you employ, the more you are tying your company to one cloud vendor. The convenience may come at the cost of flexibility and a lack of future control on expenses.

Does this mean you should not use any cloud-specific tools? Not really. There are some very useful options. You might think of the trade-off in convenience versus lock-in: it can be OK to incur some technical debt to get to market faster, especially for a startup with a short timeline for getting a first product to market - just don't do it blindly, without keeping track of costs. Like all types of debt, use it carefully, pay attention, have a limit and have a plan for when and how you will pay it down.

Most importantly: don't assume that if you prefer not to tie yourself to these point solutions that the only other option is to not go to cloud. Remember, three big ideas do not have to be bundled.

The best advice with regard to special services and point solutions offered by cloud vendors may be just common sense: consider all your options carefully, use special services selectively for those situations that really fit your particular needs and recognize how to retain portability for the rest of what you do.

  • Control Costs

One of the most common initial reasons people consider going to the cloud (public cloud) is to save money, specifically, to not have the expense of buying hardware and the expense of having a suitable place to store, run and maintain it. That's an over-simplification of the issue of whether or not cloud is cost effective, but before we tease that issue apart, it's important to note that there are many situations in which renting machines in cloud deployments certainly does save money. This is especially the case where you only need the computational power temporarily or where you are not yet sure of what your long term needs for hardware will be. Put simply, cloud makes it possible to turn on a cluster, use it and then lose it. You just pay for what you need.

That is, you just pay for what you need if your teams pay attention to what they are doing. Turns out, with human nature being what it is, "easy to turn on" is also "easy to forget to turn off!" Fortunately this problem is fairly easy to fix: you should lay out guidelines for how long clusters may be used, when they will be automatically shut down, etc. as fits your company's needs. There can be some unexpected costs as people go to cloud, but just running idle machines really does not need to be one of them.

Additional Resources

For more information on these topics try these free resources:

Blog Post: "Who Are You? Cloud Advantages Vary Depending on Your Needs" by Ellen Friedman, 2nd in the Cloud, Kubernetes and Dataware series

Blog Post: "CSI, Kubernetes and Dataware: Data Storage for Containerized Applications Just Got Easier" by Ellen Friedman

Whiteboard Walkthrough video with Ted Dunning "Big Data in the Cloud"

eBook: Kubernetes for Machine Learning, Deep Learning and AI by Sam Charrington

eBook: AI and Analytics in Production by Ted Dunning & Ellen Friedman

Whitepaper: "Realizing the Full Potential of Your Cloud Investment"

Try MapR: MapR Live! to try MapR free via a live web-based learning environment or launch MapR in your favorite cloud provider

This blog post was published June 04, 2019.

50,000+ of the smartest have already joined!

Stay ahead of the bleeding edge...get the best of Big Data in your inbox.

Get our latest posts in your inbox

Subscribe Now