The Great Cloud Migration
The cloud has quickly become the de facto platform for launching apps and services, in both the B2B and B2C spaces. Today’s service providers can quickly offer the necessary computing power and scalability, as well as increased flexibility and speed-to-market. But what about an existing offering that’s been around for a while? What’s the best approach for migrating it—or even multiple apps and services—to the cloud?
It’s tempting to focus lots of energy on decisions about technology and architecture choices. Certainly those matter (a lot), for a variety of reasons. But migrating a product to the cloud also involves major changes to business processes and company culture that require buy-in across the organization. If that doesn’t happen, you could be in for a bumpy ride resulting in a half-baked product that frustrates your development team and your customers.
SparkPost’s Cloud Migration Journey
I’d like to share some of my own company’s experiences with this sort of transition. SparkPost released the first beta version of our cloud-based email delivery service over three years ago. When we launched, a handful of customers sent a few million emails a month. Now, our API is used by tens of thousands of customers—including Pinterest, Zillow, Workday, and Intercom—to send more than 16 billion emails a month.
In that time, our business made the shift from providing on-premises email infrastructure to operating as a fully cloud-based email delivery service.
I recently wrote about some of the decisions we made regarding service architecture and API design (and evolution) in an article at DevOps.com. But as I suggested above, the tech considerations were only part of what we needed to decide. So, today, I thought I’d take a step back and look at some basic questions that informed those development choices.
Here are four questions we needed to ask before embarking on our cloud migration adventure. They might also help you make sure your newly cloud-enabled apps and services can lead lives full of innovative updates from your team that will keep your customers happy.
1. Why do you want to do it?
“Because other companies are doing it” isn’t the best response here. “Because the rest of our company is doing it” is a better one, especially if there’s a push for a standard architecture across all of your offerings. Here are some other good reasons to do it:
- You want to reduce operational overhead and the need to manage underlying infrastructure
- You’d like more agility and flexibility when it comes to deploying (or decommissioning) services
- You need elastic resource scaling because customer demand is increasing, and sometimes it really spikes
- You need a disaster recovery system for a data center, and the cost to implement a physical setup is daunting
- You want to expand into new geographic territories and the thought of setting up infrastructure in each one fills you with dread
- A data center lease is expiring in several months, so an opportunity has opened up
Whatever the reason is, just make sure it’s a compelling one. You don’t want to find yourself knee-deep in a migration project only to wonder why you’re even doing it.
2. Have you considered the potential drawbacks?
I’m all-in on the cloud. But there are trade-offs—and some apps or services face extra challenges in a cloud setup. You may want to be careful of issues such as:
- The virtual network and hardware paradigm is radically different from classic models developed in the on-premises world. Do you have expertise in-house to avoid making fundamental mistakes early on?
- The costs of cloud infrastructure can be surprisingly high, especially if you try to simply replicate a traditional server model rather than architecting and fine-tuning for the cloud
- The cost structure of the cloud can change how you perform financial calculations such as capitalization and amortization
- You store sensitive data and could face additional questions, processes, and changes to your operational tooling due to privacy laws and other regulations
3. Are you prepared to audit your apps and services?
Before you say “yes” to a cloud migration, conduct a thorough audit of the apps and services on your list, along with any related technologies used at your company. You’ll soon discover that some migrations aren’t too complicated, while others will be heavy lifts.
Whenever possible, start by migrating the low-complexity apps and services first, which will not only give you some morale-boosting quick wins but also offer valuable lessons for the next products on the list. You may learn along the way that your high-complexity apps require more effort than they’re worth – it could even make sense to retire ones that really don’t serve a purpose anymore, or whose functionality could be covered by another app that runs on a modern platform. That’s especially likely to be true in the case of highly demanding functions that require specialized infrastructure and expertise. These use cases might be better served by a specialist provider (such as in the case of running email in the cloud).
4. Are you prepared to make a serious cultural shift in your company?
If your apps and services have been around for a while, there’s a good chance that some teams have become entrenched in their businesses processes. Before beginning the technical migration process, make sure you plan out the cultural migration process too.
Success in the cloud requires a move toward loosely coupled, independently scalable services that can take advantage of benefits such as autoscaling, containerization, and serverless technology supported by your cloud provider. Moving in that direction takes a different mindset than traditional development and sysadmin roles in the on-prem world.
This is why most cloud businesses have adopted the DevOps philosophy. DevOps makes it easier to implement continuous deployment and a microservice-based architecture, both of which enable teams to work more independently and at a faster pace. Microservices increase flexibility – you can develop and deploy smaller units of functional value, with the ability to quickly roll back a release if show-stopping errors are found, without impacting other microservices in the product.
Making the Leap
Increased speed, agility, and flexibility are big wins for businesses that move to the cloud. And while the tech challenges are a big part of that change, they’ve got to be made with a good understanding of cultural and process issues as well.
I hope thinking about these questions will help you begin the cloud conversation at your company and lay the foundation for a successful migration to the cloud. Got questions about cloud migration? Send us a tweet!
P.S. More food for thought.
Last year, I was a guest on Jeffrey Meyerson’s Software Engineering Daily podcast. He asked me some really thoughtful questions about how we built the SparkPost service for the cloud. We touched on these kinds of questions as well as got into the technology choices and challenges. I enjoyed the conversation, and if you’re in the midst of a cloud migration yourself, I think you might enjoy it too.
SparkPost’s CTO and co-founder, George Schlossnagle, also wrote about some of what he learned about these challenges. His piece has lessons about the evolution of an on-premises infrastructure like an MTA from his perspective as both a technology and a business leader.