I asked Deft’s former CRO, Brendan Caulfield, what customers always ask us before migrating to the cloud. Here’s what he said.
Is lift and shift really a viable option?
Almost every customer engagement we have centers around one question, “How quickly can we get this stuff into the cloud? Can we lift and shift everything?”
The answer, technically speaking, is yes. We can lift and shift almost anything into a public or private cloud. But if you’re talking about an environment with several hundred or several thousand servers, a lift and shift is not trivial. It’s not simply a matter of doing a VMware copy and dumping it into Amazon. What will the increased latency between the desktop and the server do? Does your team know how to run your applications in AWS?
A lift and shift is, in many cases, a great option to get you started and eliminate some of the overhead and headaches that may come with running your own data center. This is a difficult decision that shouldn’t be taken lightly. A lift and shift is deceptively easy. Don’t short-circuit it. There are a lot of technical and business considerations to think about.
How do you make a decision about whether to put a workload into a public cloud like Amazon Web Services or a private cloud?
At the heart of this, we’re talking about operating systems and code. So yes, you can technically put almost anything in a cloud. If your mandate is to get out of the data center and into the cloud, then most platforms, public or private, can do the trick. But is it the most optimized way to do things? Probably not.
If you’re a high-frequency trading firm and you need sub-10-ms latency from your service to your desktop, putting your stuff in Amazon’s Ohio data center (or any remote data center) is problematic. So clearly there are technical limitations that we all need to be considering as we decide where our applications are going to go. And that list is long.
That’s why Deft focuses really, really heavily on early-phase cloud assessments. It’s to be able to inform these major platform decisions.
It seems like so many people feel they need to hop on the cloud train just because everybody else is. Is that true?
You mean not all decisions are rooted in technology?! Yes, that absolutely happens. Look, I’m an IT guy. I’ve been an engineer for well over 20 years. When I see something cool out there, I want to be the first guy to fire it up and try it out. But that’s not always the wisest decision when you’re looking at enterprise-scale production environments.
Are there some application types that are slam dunks for public clouds?
Scale is always going to be one of the biggest strengths of the public cloud offering. Think about workloads that are elastic in nature. If you can’t anticipate your compute needs over time — like if today you need three servers, but tomorrow Oprah features your product on Favorite Things and you need 300 servers or 3000 servers — then that’s a great use case for a public cloud.
Or, if having 42 availability zones and 16 geographic regions is of interest to you, then you’re probably looking at a public cloud scenario.
If you’re looking to run a static marketing landing page, then a public cloud is the perfect place because of the edge locations and geographic dispersion of the infrastructure. You can run those things for literally pennies a day and serve them as close to the customer as possible.
How do we move to the cloud if we have existing legacy applications?
One option is to keep your legacy apps where they are and move everything else to the cloud. The hybrid model isn’t going anywhere anytime soon.
Another option is to refactor your legacy apps for the cloud. It’s resource-intensive and may not be appropriate in all cases. But when it is, you get a shiny new cloud-native app in return.
Why is cost optimization such an issue in public clouds?
If you follow any of the real Amazon evangelists on Twitter, you’re going to see these situations where, “Client X, Y, and Z achieved 97 percent ROI with their AWS move!” Well, that wasn’t by accident. It wasn’t by chance.
As much as we want to achieve savings for our clients — it’s ultimately one of our cornerstone goals — 97% is a pretty big target. But no one’s doing that without careful thought and consideration.
It’s easy to spin up more resources than you need. It’s also easy to forget to shut them down when they’re no longer needed, significantly overrunning your budget.
There are as many cost optimization success stories as there are horror stories. Planning is the difference.
If I currently use a certain development language, is that more applicable to a certain public cloud environment? Like if I’m a Python shop, does that mean I should automatically look at Amazon (or if I use NodeJS, or Java, etc.)?
I think as recently as two or three years ago, that was a really valid consideration. I don’t really think it matters that much anymore. In today’s infrastructure as a service world, the toolsets don’t matter as much. It’s looking for an operating system. It’s looking for executables.
Why do cloud companies always push for an assessment?
I hate to use the cliché, but it’s that whole “measure twice, cut once” idea.
If you skip the assessment, will your applications run? Yes, most likely. Will you be able to achieve the efficiency or cost optimization you’re after? I don’t know. I will tell you that the road to get to that end state of being cost-optimized, being efficient, gets a lot bumpier if you don’t take the time upfront to identify what the project is, what the goals of the project are, what the drivers are, and how you’re going to get there.
Look, I get it. We all want to have a very simple decision-making process where if an app is X, then it should use cloud-type Y. It’s just not that simple.
It’s not always practical, either, for us to build cloud-native apps to run on a specific cloud using the tools of that platform — AWS’s AI/ML frameworks, for instance.
Pick any cloud, and most things will work. You’re probably not going to fail. But in a world where we’re trying to eke out efficiencies and productivity wherever we can, the details really do start to matter. Especially over time.
Unless you were born in the cloud, then you need to budget for an assessment. An assessment figures out properly ahead of time what the right cloud is.
Why, if my application performs great on-site, is it not performing at the same level in the cloud?
Sometimes the answer is not code efficiency or if you have enough CPUs. It’s often way more nuanced than that. You may have thought that 22 milliseconds of latency was the issue, but you’re going to need to have the ability to really dig into all the components of your infrastructure and application to really understand if that’s true.
These types of situations are where it helps to work with a good team or a good partner, because these are things that they deal with every day. It will be much more obvious to them.
Why does governance matter so much?
Governance is a really important component of cost optimization. I have a plethora of examples of environments that were spun up without much thought given to who had access to what, or what the governance model around spend and security was, or how subnets were built, and holy cow their bills went crazy because some developer kept firing up new instances but never deleted the optimized disks that they were throwing in the background. All of the sudden, there were 1100 sitting out there. And when you’ve got 1100 of them at 15 bucks a piece, it can get expensive.
We’ve seen this scenario before. It’s real. And that’s maybe not the conversation you have when you get all the engineers in a room and you’re whiteboarding, but it’s a conversation that simply can’t be ignored.
Are people still super worried about putting their data in a cloud?
There are so many emotional and human components that go into cloud migration decisions. If your compliance department needs to put their hands on servers and see servers in a cage, that’s always going to be a tough situation in the Amazon world.
I can make the argument that if you give me your toughest compliance issues, I can point you to so much documentation from Amazon that says, “Yeah we can support all of that.” Same with most of the public cloud vendors. But it’s that emotional aspect again. Cloud fears about security and compliance are not necessarily rooted in fact, and that often makes a big difference in how a project is undertaken.
How long does it take to migrate an application from on-prem to a public cloud?
That’s a really loaded question because applications can take all sorts of shapes, sizes, and forms. Are we talking about an application that runs various components across various different OS platforms and technologies? Are we doing any sort of database transformation or UTL?
Simplest case, you want us to move your website and it’s pretty well documented and defined…give us a week. We’ll have an environment spun up and moved.
But the time to migrate the application is usually not the long tail. It’s the planning. It’s the discovery. It’s the project management. I just can’t stress how important the assessment piece is. Unless you’re running Quickbooks on a desktop in your office, in which case we can move you over in an afternoon.
How do I know if I can run a workload in a hybrid configuration?
The short answer is you probably can. You just have to have to understand the tradeoffs. If you’ve got low latency requirements between an application running in a remote cloud scenario versus a database running inside, then the hybrid environment’s impact on latency would need to weigh into your decision.
The key questions around hybrid configurations are network connectivity (latency), security requirements and overall system administration. The increase in complexity shouldn’t be underestimated. It’s manageable, but it can’t be underestimated.
Is there any way for a workload to be automatically elastic just by virtue of moving it to AWS?
A huge misconception is if I move my application to AWS, then it’s automatically resilient and scalable and I don’t need disaster recovery. Yes, in Amazon, the path to getting to those places probably becomes easier. Like it’s very easy for us to spin up a relational database service model for databases that are replicated across availability zones (which is Amazon parlance for data centers), and you automatically get some resiliency there. But it really depends on how your application was built. There are going to be some steps you need to take.
For one, you need to consider what the triggers are for scaling:
- Is it when CPU is at 90 percent utilization?
- Is it when memory is all eaten up?
Nothing is fully automatic. You need to set up your autoscaling groups. You need to build out machine images so that they can just pick up and run. There’s a lot of nuance there:
- How does your application deal with machines that come up and don’t even know their IP addresses?
- How are you dealing with sessions?
- How are you dealing with state?
- Is it okay that you’re going to spin up a new server and requests are going to go to that new server instead of the old server?
Lifting and shifting an application into Amazon doesn’t come with scaling capabilities off the bat. You’ll have the tools you need. But it’s not going to do it on its own. It needs instructions.
What if my company is too scared of picking the wrong cloud to make a decision?
If you move to the wrong cloud, you move to the wrong cloud. Move to another one. This stuff shouldn’t be scary. We’re going to get past it. At least you don’t need to sell your servers or explain to your CFO why you made a two-million-dollar CapEx mistake.
I get that most people want their applications to work, run stably, not go through massive change, and be cost-optimized. Because that’s how a lot of us are judged in our jobs.
There may be no silver bullet, but there are so many viable options. What I’m endlessly amazed by is how quickly we can do things these days. If you need to pivot, pivot. It’s not as costly as it used to be from a time and dollars perspective. If you know what you need to do, it is usually straightforward and easy to do.
What’s difficult is when you don’t know your endgame but have already taken steps toward a destination.
Remember, all decisions are valid, even if they’re not perfect. If you’re trying to approach perfection, then it’s really important to invest the time upfront (yes, during an assessment) to really hammer down what perfection looks like to you. It’s the service provider’s job to get you as close to your definition of perfection as possible.
Please reach out if you want to have this conversation one-on-one.
