Navigating 5 common cloud concerns

Cloud adoption isn’t just growing—that growth is still accelerating. Cloud computing on AWS now accounts for over 11% of Amazon’s total revenues. Microsoft Azure is growing at over 60% quarter-over-quarter. There’s no denying that the major providers of cloud-enabling technology are investing an increasing amount of their development budgets in delivering new cloud services, in preference to making those solutions available in on-premise, self-hosted products. But inside our own organizations, we don’t all necessarily share the same enthusiasm for adoption of these new trends—we didn’t all cross the adoption chasm at the same time. Application developers, solution architects, and their immediate managers (and, of course, consulting firms like ours) tend to be enthusiastic adopters of new technologies and platforms. We’re excited about the promise they hold for faster deployments, greater responsiveness to changes in client or customer needs, and a simplified deployment and monitoring model.

However, if your organization doesn’t happen to have cloud advocates sitting in the decision-making seat, crossing that adoption chasm can be a long, slow process. The objections you’ll hear from stakeholders can stymie your cloud progress. In our experience, objections don’t come from an aversion to change, they come from an aversion to loss of control. How, then, can we understand what people are worried about letting go of, find the root of their reluctance, and demonstrate a path forward that creates value for all stakeholders? If you’re involved in your own organization’s decision making (or can influence that process), we want to equip you with the right information to understand and respond to common concerns and get your cloud migration project off the ground.

Objection 1: Our internal ecosystem is too complicated

If you look at your cloud migration through the lens of a greenfield development effort with a single “Big Bang” switchover date somewhere in the near future, your initial conclusion is likely to be “This will never work.” And you’d be right! Our first instinct in a major new initiative like a cloud migration project is to want to start by “getting it right this time” with a complete, ground-up rewrite of our applications.

One of our core engineering principles at Headspring is “Tiny Steps”—breaking work down into small, safe increments that each add value and can be deployed to production independently. What we’ve found is that just as much as this applies to our application development, we can also apply it to a cloud migration project. While there’s a clean, cloud-native system architecture waiting for us at the end of our journey, we’re not ever going to get there in one leap.

Most companies should plan to spend several years in a hybrid environment, with some workloads running on-premise and some in the cloud. All of the major cloud providers now offer bridging solutions to allow for seamless integration between the two, providing hybrid solutions for identity, security, networking, and even data access. Can you identify which application or system would benefit the most from running in the cloud instead of self-hosting? Now, can you identify the smallest possible unit within that system that you could migrate first? One of the best ways to demonstrate the viability of a cloud migration is to show a small piece of it actually working in harmony with the rest of your on-premise infrastructure still in place.

Objection 2: It’s cheaper to run our own servers

This objection often comes from operations and infrastructure teams charged with maintaining a company’s current hardware infrastructure. And, on the surface, it seems pretty true: Owning an asset is almost always less expensive than renting it. Obviously your cloud provider needs to turn a profit too, and if they’re operating all the hardware on your behalf, then it’s not hard to see that they’re going to rent those services to you at a markup. If you look at initial costs for virtual machines in the major cloud providers, you can do the math pretty quickly to see that renting a cloud VM for a year would almost pay for that same server if you just bought it outright.

Is it possible, though, that those costs aren’t quite the same? Remember, your servers are assets, but they don’t appreciate in value. They break down and need to be serviced and maintained. You’re probably retiring them every three years. What’s the total cost of owning that server? Have you factored in the cost of downtime? The power and cooling costs? The labor costs of your ops staff? The time required to keep the server OS patched and up-to-date with critical security releases?

At the same time, are you doing a full analysis of which tier of cloud services you actually need for your applications, and are you matching the type of service to the performance characteristics of your application? In an on-premise data center environment, we tend to buy in bulk and deploy homogenous server configurations to carry all our workloads. But in a cloud environment, it’s a lot easier to tailor the runtime environment for each specific workload. Maybe you need a lot of really small, cheap virtual machines for basic applications, and one really large one for a particularly complicated processing job. Knowing that, you can take advantage of multi-year reserved pricing to bring your total operating costs of a single VM as low as $35 per year.

Another consideration is to make sure that you target and price the appropriate service. It’s easy, especially at the first stages of a cloud migration, to assume that you’re operating a “lift-and-shift” of your current server architecture directly into cloud-hosted VM’s. But what else is possible? Could you take some of your lightweight, high latency batch jobs and move them to a serverless architecture on Azure Functions or AWS Lambda? If you’re only paying for the few seconds or minutes of time those services run each month, how much more could you save compared to keeping the dedicated server in your on-prem rack that’s sitting idle 95% of the time? When you consider these kinds of incremental adjustments to your deployment target, you can quickly bring your total cost of ownership in a cloud environment well below what it costs them to operate on-premise today.

Objection 3: We might lose our data

As more companies adopt Software-as-a-Service solutions for various parts of their businesses (e.g., Salesforce, Office 365, G-Suite), and file sharing via platforms like Dropbox becomes more common, this objection doesn’t show up as much. The one stronghold for it, though, is in core, self-owned, systems of record. Financial systems, customer relationship systems, and all the on-premise databases that serve internal line of business applications are still candidates for stakeholders to point to and say, “We can’t afford to lose that.”

Usually, mission-critical systems are an area where on-premise ops teams would spend a lot of time establishing regular backup and archiving processes. Sometimes that might go as far as to include off-site storage of hard drives, so you end up with geographic separation as well as logical separation of your backups from your production systems.

What we find in looking at modern cloud-based solutions—especially at the data tier—is that backup-and-restore facilities are built into the core service. For instance, did you know that an Azure Sql service instance, without anybody needing to configure it, is automatically backing up your database for you, for up to seven days of point-in-time restoration availability? And if that’s not enough coverage, that you can opt in to a fully configurable backup and restore infrastructure. This includes real time geo-replication of your database with an automatic hot switch in the event of regional failure, so you have a guaranteed 99.995+% data availability.

The fact is, the cost in time, people, and infrastructure to consistently generate that level of data protection is usually far beyond what a typical small, medium, or even enterprise-size company can reliably implement on their own. The economies of scale that that major cloud providers offer make it possible for your cloud solutions to operate with infrastructure and network management maturity well past what you could build for yourself.

Objection 4: Our security and privacy issues won’t let us move to the cloud

It seems like we hear about another major data breach nearly every month. The risk to a company’s reputation in the event of a breach is tremendous. Certain industries like finance, e-commerce, and healthcare are especially sensitive to security and privacy issues. Those concerns can make it seem really alluring to keep all your data on-premise—behind a set of policies and processes to keep it locked away from any intruders.

One analogy you might find helpful is to think about your personal money and assets: where you keep them, and how you secure them. Very few of us keep stockpiles of cash on-hand at our homes. We trust that to the bank, because banks are in the business of keeping money safe for people, and we‘re not.

You can look at your data security and privacy concerns similarly: The fact is that the major cloud providers are all heavily audited and certified by over 90 different certifying organizations. They can reliably deliver data and account security at a depth and consistency that most of us would find hard to deliver in our own networks.

Another trend in security management is cloud providers’ increasing focus on AI-driven monitoring, detection, and elimination of active intrusion probes. Unlike a typical self-hosted datacenter, the cloud provider security teams are collecting information about millions of applications across thousands of businesses worldwide. They can use that information to reinforce and enhance their detection monitoring through machine learning. When we build and deploy to the cloud, we can take advantage of a security infrastructure that’s not only more sophisticated than what we could build ourselves, but one that’s also learning and adapting to new exploit types as they emerge.

Objection 5: We don’t need to host in the cloud, because we don’t work remotely

Two months ago this might have been easier to absorb. Today, of course, we’re dealing with a rapid distribution of workforces across a variety of industries and businesses, resulting in the proliferation of completely decentralized, 100% remote teams. If you’re one of these businesses, you might be  experiencing two realities, often at the same time:

  • Realizing you actually can operate in a fully remote environment, and in some cases even be more productive
  • Supporting enough VPN connections to your on-premise network is creating an unplanned bottleneck and slowing team efficiency

Now is a great time to play offense: Reassess your critical, must-access applications and migrate them to a highly available, easily accessible endpoint in the cloud. Which of your core business applications, if they were cloud hosted right now, would unlock the most productivity and engagement for your employees, partners, and clients?

Making the choice between cloud and self-hosting isn’t just about where your teams are located. Even if you’re going to operate your business 100% on-premise in the future, there’s another cloud phenomenon that a lot of our clients are starting to get excited about. That’s the rise of cloud-first architectures. Now that infrastructure-as-a-Service (IaaS) has become nearly completely commoditized, cloud providers are competing with each other by developing new, innovative Platform-as-a-Service (PaaS) offerings on top of that core infrastructure. Most of those offerings aren’t even available in an on-premise model. Azure CosmosDB, for example, is a global-scale, schema-less document database-as-a-service. But you can’t install and run it on your own servers. Amazon’s Kinesis, for high volume event processing, is another great example—as are Azure’s Cognitive Services for image detection and natural language processing. There’s no way but the cloud to take advantage of these new offerings in your custom applications!

Conclusion

Cloud migration objections are typically rooted in a stakeholders’ concern about loss of control. As we continue to see our industry re-orient around cloud computing as the default approach to implementing business applications, you can help prepare yourself, your team, and your organization’s decision-makers by first understanding and empathizing with such objections. With a common understanding of the most likely tradeoffs you’ll need to make, and simultaneous advantages you can gain, you’ll be able to help everyone envision what’s possible, and accelerate your organization’s journey to the cloud.

Let's Talk