I work for a large IT outsourcing company and I have seen the opposite of it with our clients. Most of our clients wants to be on cloud but without any change to their habits so we end up building complete traditional data centers in the Azure or AWS.
Most applications are simply cloned from existing On-Premises Infrastructure because every project have a 2 weeks deadline and every single stakeholder just wants to stick it in. Patterns like Auto-Scaling etc is just a far fetched dream.
Supporting such Infrastructure where every server is a pet trying to survive in a Slaughter House is a deeply painful.
In big companies, 95% of apps are still old school: firewall -- load balancer -- 5 front ends -- 3 back ends -- two database servers. And the people who developed most of these apps left these companies long time, what these companies have bunch of managers and some developers who maintain that code.
People of this kind are extremely conservative, because they are not in a position to fix major issues if something goes wrong--esp new architecture. So, they want to lift as is to aws.
A decade ago, I was involved in physically moving three solaris servers that were running un-supported BEA weblogic instances. When I powered on these three servers on a different rack, weblogic cluster failed. No IP change, just moved machines to free up racks in one row. And the people who developed the app, and the dev architect behind it were so mad at us. In the end, they gave up on that app.
In principal yes, they look like any modern web application but reality is different.
For example stateless web component is a primary requirement to allow servers to fail as well as auto scale. Most enterprise applications I have seen falls flat on face.
I have seen enough cases in which customer endlessly debates why his snowflake of a web server went down and expects a RCA with god knows what details.
IMO this is why Google Cloud was behind AWS (talking 2008-2013 or so). Google bet on PaaS while Amazon bet on IaaS. The dumb corporate money is still behind IaaS, as inefficient as it can be.
Well a lot of these people are smart BUT who wants to risk his job for an adventure which if successful will help the company and if unsuccessful will probably get him fired.
There is nothing wrong with doing a lift and shift as phase 1. But too many companies stop there and too many “consultants” are just old school net ops guys and that’s all they know.
I said in another post that I was a dev lead for a company that decided to move to AWS. After dealing with “consultants”, realizing how shallow their knowledge was after I started learning about AWS and seeing how much we were paying them, I changed my whole career focus.
I got another job at a small company that was running completely on AWS who needed some “adult supervision”, self demoted to an individual contributor and I’m getting real world AWS experience so I can become an overpaid consultant who actually can consult with developers, devops, and infrastructure departments.
I am "lucky", I think, as my employer has already been through some very painful experiences (and learned nothing, apparently) - and they seem content to let me do whatever the fuck I want, as long as I sufficiently song-and-dance them. And yes, I've made some mistakes along the way. But I've also delivered results I didn't even think were going to be possible when I started. Advice I'd give to people walking this path:
1) You begin in an emergency. Everything is always an emergency. Because production is down. And you will always be wondering why your customers just don't drop you. But do take a moment to establish baseline metrics. Some way to measure how much you're getting, performance-wise, in terms of uptime, records processed, users, customer calls per day, cloud costs. Whatever you can pull out of your ass for minimal effort. Get SOMETHING as a baseline. As you go along, if you miss a deadline, nobody will question you if you can show progress in your metrics against that baseline.
2) The theoretical ideal model web apps may perform radically differently when you start monkeying with the architecture. If the original developers are gone, if the code is more than 5 years old, it may not be feasible to debug the squirrelly behavior you see when you change from a traditional proxy to say, an AWS load balancer. You can burn a shit ton of time trying to troubleshoot things like this. Slapping a band aid on top of 10 years old band aids is not always the right thing to do. But sometimes it's the best approach to delivering results that keep people convinced to fund your effort.
3) even if nobody else in your company has a fucking clue what you're doing, or understands it; document everything.
Get them on the cloud, then they can have the 'option' to start utilizing pure cloud type services, and migrate over.
Just reproducing their current setup on the cloud in many ways makes perfect sense.
Remember that for most companies, IT is just IT - it's an enabler, but not a huge differentiator. What 'works works', and tech change is expensive and risky.
Going to the cloud and shifting paradigms is two big steps, they can be taken one at a time.
But yes - any HN reader would be kind of 'shocked' to walk into almost any company in the world and see how 'high tech' really works. It's a valuable lesson in perspective, though.
Legacy apps asummes a certain degree of reliability from the underlaying infrastructure. This assumption falls flat on its face in the cloud. Netflix wouldn't have needed to develop Chaos Monkey if this wasn't the case.
Secondly leap to cloud native never happens because no one wants to take the pain once it works even barely. Any issues can be pushed onto Infrastructure team. It's pure and simple risk avoidance.
Most applications are simply cloned from existing On-Premises Infrastructure because every project have a 2 weeks deadline and every single stakeholder just wants to stick it in. Patterns like Auto-Scaling etc is just a far fetched dream.
Supporting such Infrastructure where every server is a pet trying to survive in a Slaughter House is a deeply painful.