Cloud migration is a big topic of discussion. Overall, I’d say we’re still very much in a state of flux when it comes to cloud strategies, with estimates that point to as much as 65% of companies still relying on on-prem, enterprise data centers.
That is changing and changing quickly. Data from 2017 shows that 95% of IT professionals have already moved (or tried to move) critical applications to the cloud. That same survey by IT security firm SolarWinds cited that nearly half of the IT pros they talked to did not “believe that IT professionals entering the workforce now possess the skills necessary to manage hybrid IT environments.”
With Sketch’s experience migrating some of our clients’ apps to the cloud, we understand the apprehension. Cloud migrations are often more complex than they look, and most IT folks are pressured to produce results quickly. That pressure often leads organizations to decide on a “lift-and-shift” migration and mindset that doesn’t deliver on the upfront investment in your cloud strategy the way it should.
A one-to-one migration always looks like the simplest approach. To capitalize on the benefits the cloud offers, you have to completely change how you think about the cloud.
When and where is a lift-and-shift strategy appropriate to get your apps into the cloud?
Scenario one goes like this. You’ve got third-party vendor software that can’t be reconfigured easily. That particular app may need a more straightforward lift-and-shift just for the convenience and security of getting it off-prem.
Scenario two (generally more common): You have to ramp up fast due to compliance issues, or you’re at capacity with your current data center. A straightforward lift-and-shift is the quickest, easiest, and cheapest path of least resistance to get you into the cloud. But once you get that quick win, the job’s not even halfway done. It's essential that you examine your cloud strategy from a business strategy perspective and not just as a substitute for a data center.
If you’re treating the cloud like you do your current on-prem environment—either because you don’t yet know any better or because it’s the result of a lift-and-shift—here are three areas where you ideally should focus to get the full benefit from the cloud.
There’s a lot of resilience baked into the cloud if you know how to use it.
I should clarify how resilience and disaster recovery differ. Yes, they’re related. However, if you understand how the former works, you’ll never have to worry about the latter again.
In a cloud scenario—specifically with AWS—you easily have access to six data centers per region. When you deploy your application, you can leverage each of those data centers seamlessly if you know how to mix and match (this is AWS lexicon) “availability zones” (AZ).
A good application deployment includes leveraging multiple AZs properly. If one goes down, the infrastructure is smart enough to reroute traffic to a server in an available data center/AZ that’s still up and running.
How does that differ from disaster recovery? DR basically means you’ve got remote servers with (hopefully) remote backups. When and if something goes wrong, you get the engineers hustling at any and all hours of day or night to reroute traffic, get the backups up and running, and so forth.
You can also enhance your SLAs by using multiple AZs if your application demands more resilience. A multi-regional strategy with one provider (AWS in this scenario) and just two regions gives you direct and immediate access to 10 data centers.
Deploying apps into the cloud this way ensures you have minimal user impact and near-constant uptime. The notion of a DR strategy doesn’t necessarily become moot at that point. But emergencies become a lot less painful, especially for your engineers.
When there’s an outage, your team doesn’t have to go into emergency mode to prevent more business and/or data loss. In short: Architecting your infrastructure to leverage the resilience offered by the cloud—rather than treating it like you would your on-prem—is always going to surpass whatever your current on-prem redundancy is.
In an on-prem environment (or even back to the data center model), you have to over-invest in infrastructure. Let’s say you need four servers for peak demand, even if that peak demand happens only once a year.
I like using TurboTax as an example. Imagine what its utilization looks like throughout the year. It likely sees a massive usage spike in January, which probably jackknifes from February through Tax Day. But what about May through December? Who does their taxes then?!
Now imagine that they invest in an on-prem/data center structure to meet that peak demand. For basically nine months of the year, that infrastructure they’ve invested in and paid to maintain is basically idle.
If all you know how to do is mimic physical capacity in the cloud, you’ll still pay for demand you don’t need all year long. In the cloud, your application environment can be configured to autoscale. As demand increases, so does server capacity. As demand diminishes, so does the number of servers running your app. If you simply replicate your on-prem setup in the cloud, not only are you wasting money through over-provisioning, you’re also risking not having adequate capacity for peak demand if it exceeds what you’ve provisioned.
The cloud offers you better performance for far less of an upfront investment. When you have a surprise spike in traffic, you can grow in real-time to meet demand and then scale back without continuing to pay for that physical infrastructure. You’re always poised to pay for what you need and nothing more.
This brings us, finally, to cost.
Most cloud resources use pay-as-you-go pricing models. You’re paying only for what you use. If you need only one server for nine months out of the year, but you have a very busy (going back to our TurboTax example) quarter, you’re paying only for that usage.
Additionally, you can maximize how you leverage cloud services to cut down your costs even more.
This utilization graph (which is hours in a day, but imagine it could be anything like days/week, months/year, etc.) shows usage patterns for very hefty servers. This app uses 41 of them during peak demand.
In another scenario, here is the same load being processed by 70 smaller (and therefore less expensive, from a hardware standpoint) servers. Because it’s easier to balance on a granular level, it’s easier to conform to the demand curve more efficiently—there’s less over-provisioning.
The math is astounding at a 69% cost reduction.
Yes, more servers can equal less money. CPU and RAM come at a premium. Rather than paying for half or three-quarter utilization, you’re maximizing value in hardware that simply doesn’t require as much upfront cost. You shouldn’t be paying for waste.
Remember, just because you have/had n number servers with x CPU and y RAM on-prem doesn’t mean you need a one-for-one match in the cloud. By using smaller boxes at a cloud data center—and leveraging elasticity as was discussed in the previous section—you have exponential cost savings.
Your IT professionals are undoubtedly experienced and could theoretically experiment with your organization’s AWS or cloud configuration. But there’s a learning curve that’s probably steeper than you realize. Back to those numbers from SolarWinds, IT pros also know it’s a refined skill set.
To get to break-even faster and the best ROI possible, I usually tell people it’s a good idea to work with someone who already has some foresight and knows the hurdles you will face. Hard knocks are a lot harder when you’re experimenting. Experimentation, when your app is running in a live environment, is often stressful and expensive.
We’ve worked with enough companies at Sketch to be well aware of those hurdles. There’s probably nothing we haven’t seen already. We want you to get off the starting line quickly and deliver faster value to your customers. More importantly, we’ll set you up for success from day one.
Even if you’re pretty sure you’re doing it right, or you did it right, reach out to us for a check-up to make sure you’re following AWS’ Well-Architected Framework to ensure you’re maximizing resilience, availability, and cost optimization.
If you are ready to dive in and connect, or learn more about cloud infrastructure, contact us here!