Many enterprises treated the public cloud as glorified managed hosting for their migrated workloads, but that's...
changed, as IT shops better understand the characteristics of these distributed architectures.
Experts once pitched the lift-and-shift migration approach as a simple way for companies to get out of the data center maintenance business and into the pay-as-you-go public cloud. A host of startups promised an easy transition of customers' workloads onto a public cloud, without any need to refactor the applications. But that model has quickly become passé, as enterprises squeeze more value out of their cloud experiences.
That's not to say that lift-and-shift can't work, but applications typically perform best on the public cloud when they're designed to take advantage of the attributes and scale-out architecture of platforms such as Amazon Web Services (AWS) that diverge from the traditional data center approaches.
Hightail, a file-sharing and collaboration provider in Campbell, Calif., recently migrated petabytes of data to AWS and saw the shift as a way to rework its product from the ground up.
"For us, it wasn't lift-and-shift," said Shiva Paranandi, senior vice president of technology at Hightail, formerly YouSendIt. "We took the opportunity to rewrite and rearchitect core parts of our components when moving our legacy workloads."
Hightail did so, first and foremost, to optimize costs and performance on the public cloud, where servers can be added or deleted as needed, Paranandi said. It also wants to improve lifecycle maintenance of its data storage and incorporate native services such as Amazon Kinesis, a real-time data analytics tool. Next, the company wants to incorporate machine learning, which would be difficult to replicate in-house.
A major drawback with lift-and-shift is unexpected costs -- from applications that aren't designed to scale out to underused servers that rack up bills every hour they're turned on.
SendGrid, a transactional email provider in Denver, is in the midst of a migration to AWS. If it can't deliver a customer's email on the first attempt, it will keep trying for days. On the public cloud, this would quickly rack up extra costs. SendGrid had to change its mail processor and tweak its code to operate efficiently with Simple Storage Service, Elastic Compute Cloud and Auto Scaling groups.
"In lift-and-shift, you can say with almost full certainly that you're not going to be cost-optimized," said J.R. Jasperson, chief architect at SendGrid. "If it's based on a legacy [colocation] model, then it's not built to leverage ephemeral compute and autoscaling. So, inevitably, there will be inefficiencies."
SendGrid's shift even had a knock-on effect with workloads on its private servers. It moved to object storage in-house and changed other internal practices to best interact with AWS.
Modern approaches to increase scalability, availability and performance for in-house systems have a remarkable overlap with cloud techniques, Jasperson said: "Solving for one is solving for 80% or better of the other."
Cloud shift is architectural and cultural
Part of the problem with the cloud transition for IT organizations is cloud providers don't explain to their customers what to do once they get there, according to Dave Rensin, director of the Customer Reliability Engineering program at Google. Enterprise IT employees do possess the technical skills, but lack incentive and tools to accomplish tasks at the speed they want, he said.
J.R. Jaspersonchief architect, SendGrid
"They don't want to do it that way anymore, and, until recently, they've felt stuck," he said. "They didn't have a good migration plan to get from what's keeping the lights on to a place they want to go."
Rensin helps a select set of large enterprise customers navigate their transition to Google Cloud Platform. He's been most surprised by how clear-eyed they are about the need to make that shift.
"Every large enterprise worries in the back of their head that there's some startup they've never heard of that's going to come eat their lunch," he said. "They look at this opportunity to jump to the head of the class in skills."
Of course, not every customer makes that transition easily, even with the support Rensin and his team provide. The first red flag is when a customer repeatedly asks questions that are addressed upfront within documentation. Such customers may be better off with a managed service provider, such as Rackspace, that offers more hand-holding.
"The third or fourth time when you have to help a customer configure some DNS [domain name system] or something pretty straightforward to discover, you realize, OK, this is a customer that is not in a good position," Rensin said. "They're going to have a frustrating experience in the cloud -- anybody's cloud."
Theme park operator Six Flags primarily uses dedicated hosting via Rackspace, but uses an AWS instance for a third-party application it runs internally. A lift-and-shift approach to public cloud didn't make sense, because the company's systems are already efficient through internal processes and the ability to negotiate better prices from its hardware vendors, said Sean Andersen, corporate director of interactive at Six Flags Entertainment.
To start its enterprise IT modernization project, Six Flags wrote its mobile app's API and worked with third parties to deliver the code for Android and Apple iOS operating systems. Now, it's weighing a greater presence in AWS, with ticketing systems and financial engines to handle upward of 300,000 people that visit the company's 20 North American parks on a given day.
"We want to be more nimble and flexible," Andersen said. "How do we make it easily updatable by the phone so if I have to make a change, I don't have to run back to the office or get a VPN [virtual private network] from a remote location just to log into a thick application?"
Six Flags also wants to wrap together Amazon machine learning tools, such as image recognition and natural learning language understanding tools Recognition, Lex and Polly, to improve in multiple areas, especially with better indicators of ride time waits.
"You have to figure out when is the time period to make the leap, if you will," Andersen said. "I have the advantage of working for our CIO, but sitting in the innovation side, looking at how our guests will interact with us two years in the future. That's all I look at."
Beyond refactoring for IaaS
Refactoring is one way to get the most out of the public cloud, but many industry observers see infrastructure as a service as merely the first step. Containers and microservices bring more agility to the cloud, but the next potential wave could take more of the underlying maintenance out of the hands of enterprises.
"Over the years, we've done a lot to automate away that work with containers [and] modern CI/CD [continuous integration and continuous delivery] pipelines, but still there's stuff you have to think about," said Rich Sharples, senior director of product management at Red Hat.
There is a continuum from dedicated machines to virtualization, to containers and eventually to serverless architectures, Sharples said. Red Hat is invested in Apache OpenWhisk, but all the major cloud providers push their own native tools that execute functions based on isolated code.
Serverless architectures are currently cost-prohibitive for CPU- or memory-intensive applications. But as these services expand, enterprises should look to incorporate them into their toolbox, in the same way they did to combat shadow IT on the public cloud.
"If a developer can find a faster way of doing something that may avoid having to go to their local IT and running something on Amazon or Microsoft Azure or OpenShift, they're going to do it anyway," he said. "IT organizations need to make better local alternatives or, if they need to go outside, at least they can do it in a responsible way."
Trevor Jones is a senior news writer with SearchCloudComputing and SearchAWS. Contact him at [email protected].
Ask these three questions before you move apps to the cloud
Tips to build a solid cloud migration strategy
Reduce downtime during your cloud migration