Why Organisations Move to the Cloud, and Where It Disappoints

Concept

Cloud adoption is a business decision before it is a technical one. If you can only recite the benefits, you will lose the argument to anyone who has been billed for them. This note gives both sides.

Why it is used

Architecture: what changes and what does not

Owned data centre                 Cloud
-----------------                 -----
Buy capacity for peak      ->     Rent capacity for now
Change takes weeks         ->     Change takes minutes
Fixed location             ->     Choose a location per workload
Your team patches all      ->     Provider patches below your layer
Failure = your spares      ->     Failure = replace the instance
-----------------------------------------------------
Your application code, your data model, your security
decisions and your operational discipline are unchanged.

The last line is the one people skip. Moving a badly designed system into a cloud gives you a badly designed system with a monthly invoice.

Important terminology

Where the cloud disappoints

• Cost, when nothing is switched off. Idle resources bill exactly like busy ones. Most overspend is forgotten resources, oversized instances and data transfer, not the headline prices.
• Lock in, when you use the convenient parts. A virtual machine moves easily. A workflow built from one provider queues, functions and event buses does not.
• Latency you cannot remove. Physics still applies. If your users are in one city and your servers are on another continent, no configuration fixes the round trip.
• Compliance and data residency. Some data is legally required to remain in a particular country. That constrains region choice before any technical discussion starts.
• A steeper skills requirement. The platform removed the hardware and added identity, networking, automation and cost management to your job.
• Shared fate during a provider incident. When a region has a bad day, you and thousands of others have a bad day together, and you cannot walk into the building.

Real world example

A logistics company moves twelve applications by lift and shift and expects a saving. The bill rises by eighteen per cent. Investigation finds:

• Every server was sized to match the old hardware, which had itself been sized for peak load in 2019.
• Development and test environments run continuously, including weekends.
• Backups are written to another region, so every backup pays egress.

Right sizing, a nightly shutdown schedule for non production, and keeping backups in the same region cut the bill by well over a third. The lesson is that cloud savings are earned by operating differently, not granted by arriving.

Commands

Latency is the limitation you can measure yourself, so measure it before you argue about it.

# Round trip time to a host, five probes then stop
ping -c 5 YOUR_DOMAIN

# Where the delay appears along the path
traceroute YOUR_DOMAIN

# Split one HTTPS request into its phases
curl -s -o /dev/null -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}" https://YOUR_DOMAIN

Hands on lab

1. Choose two websites: one you believe is hosted near you and one you believe is hosted far away.
2. Run the curl -w phase breakdown against both.
3. Compare time_connect. That value is dominated by distance and is the number you cannot configure away.
4. Compare time_starttransfer minus time_appconnect. That gap is the server thinking, and that part is yours to improve.

Expected output

Nearby service:
dns=0.011 connect=0.024 tls=0.061 first_byte=0.098 total=0.104

Distant service:
dns=0.013 connect=0.187 tls=0.402 first_byte=0.488 total=0.501

The distant service is not running slower software. It is four thousand kilometres away, and the TLS handshake pays the round trip more than once.

Common mistakes

• Comparing a cloud bill to hardware price alone. The honest comparison includes power, cooling, rack space, network links, spares, staff time and the cost of capacity you bought but never used.
• Assuming managed means unmanaged by you. A managed database still needs correct sizing, indexes, backups you have actually tested, and a connection limit that matches your application.
• Treating lock in as binary. It is a spectrum with a price. Decide how much portability is worth, then choose deliberately.

Troubleshooting the business case

Security considerations

• Moving to cloud widens the number of people who can create infrastructure. Permissions must be tightened at the same time, not afterwards.
• Data residency rules are a security requirement, not a preference. Confirm them before selecting a region.

Best practices

• Write down the specific outcome you expect - faster releases, lower peak cost, a second site - and measure it afterwards.
• Move one small, low risk workload first and learn on it.
• Budget for the operating change, not only the migration.
• Assume every resource is billable until proven otherwise.

Interview questions

1. Give three genuine benefits of cloud adoption and three genuine limitations.
2. What is vendor lock in, and how would you reduce it without giving up managed services entirely?
3. A team moved to cloud and costs increased. List the first four things you would investigate.
4. Why can a cloud migration make an application slower?

Mini assignment

Write a one page recommendation for a fictional company with a seasonal workload. State the expected benefits, the two limitations that most apply to them, one measurement you would take before the move, and the same measurement after.

Conclusion

Cloud adoption buys speed and flexibility, and charges you in cost discipline, skills and portability. Engineers who can argue both sides are the ones trusted with the decision.