Pros, Cons & When Not To

A good mechanic will occasionally tell you the repair costs more than the car. It is the sentence that earns every other sentence they say, because it proves the advice is about your problem and not their invoice. A cloud engineer needs the same sentence, and this class is where you learn to say it.

The previous two classes made the case for moving. They were true. But a case made only in one direction is a sales pitch, and the market is thick with people who will tell you every workload belongs in the cloud — usually people who are paid when it does. The professionals are the ones holding the list of exceptions, because the exceptions are where the expensive mistakes live.

Start with the misconception that funds most of those mistakes: that the cloud makes a system better. It does not. It changes where the system runs and how it is billed. A badly designed application, moved unchanged, becomes a badly designed application that now bills by the hour — and the failure of a "lift and shift" is almost always that the shifting happened and the lifting of the design did not.¹

Data gravity

The tendency of a large dataset to pull applications and services toward wherever it already lives, because moving the data is slower and costlier than moving the code that uses it.

Data gravity is the single most underestimated force in a migration. It is easy to move a stateless web tier and feel that the project is going well. The database, the years of images, the analytics archive — those resist, and they resist in a way that shows up on an invoice rather than in an error log. Most of this class is really about the places data gravity, physics and the law each say slow down.

Watch how the trap springs on a real migration. A team lifts Campux's web tier to Azure in a weekend, and it goes perfectly — stateless, small, easy to move — so everyone declares the migration low-risk and schedules the rest for next month. But the web tier was the light half. The order history, the product images, years of clickstream the analytics team refuses to part with — that is the heavy half, and it did not move, so now the application in Azure reaches back across the internet to a database still sitting in the closet, on every single request. The project did not get easier after the easy part; it got harder, because the part that was left is the part that resists. A plan that front-loads the movable and calls it progress is measuring the wrong thing.

Here is the asymmetry that catches out more first migrations than any other. Putting data into Azure is free and unlimited. Taking data back out — to the public internet, to your office, to another provider — is metered and charged. The door is free to enter and costs money to leave.

Egress

Data transferred out of the provider's network. Ingress (data in) is free; egress past a small monthly allowance is billed per gigabyte, and the rate rises the further the data has to travel.

The current numbers, for the regions Campux would use, look like this. Read the free rows as carefully as the priced ones — they are the reason small tests never reveal the problem.² One caution before you lean on the table: these are Zone 1 rates — Azure groups regions into pricing zones for bandwidth, and the same gigabyte leaving a region in, say, Asia or South America bills at a noticeably higher rate.

Data enters free and pays to leave.

Put a number on it in Campux's world. Suppose the finance team refuses to move its reporting warehouse off-premises, so every night a five-terabyte extract is pulled from Azure down to the office. That is roughly 150 terabytes a month across the boundary; run it through the tiers in Table 1 and it bills around $11,000 a month, on the order of $135,000 a year — for a design choice that appears nowhere on the architecture diagram and produces not one new feature. The storage the data sits on costs a fraction of that. The movement is the expense.

This is why architecture that respects data gravity keeps computation next to the data instead of hauling the data to the computation, and why a plan that quietly assumes free data movement is not a cheaper plan — it is the same plan with a bill hidden in a footnote. When you review a migration design, the first question worth asking is always: what crosses the boundary, how often, and in which direction?

Light travels about three hundred kilometres in a millisecond — closer to two hundred in the glass fibre a network actually runs through, and the reply must make the same trip back — and no datacentre, no SLA and no amount of money changes that. When a workload must respond faster than the round trip to the nearest region allows, the cloud is not slow because it is badly built — it is slow because the region is four hundred kilometres away and physics is charging you for the distance.

Most web applications never notice; a hundred milliseconds is invisible to someone browsing a storefront. But the exceptions are real and worth recognising on sight: industrial control loops that must react in single-digit milliseconds, high-frequency trading, live audio processing, a factory robot that cannot pause to consult a server in another country. These belong at the edge or on the premises, close to the thing they control, and the correct engineering answer is to say so rather than to promise a latency the map forbids.

Campux has a smaller version of this. When the storefront had its nine-hour outage in Class One, the in-store point-of-sale tills kept taking card payments, because they were designed to work whether or not a distant server was reachable. That property — degrading locally rather than failing globally — is one you keep deliberately, and it is a reason some of the store systems will stay partly on-premises long after the website is entirely in Azure.

Put rough numbers on the wall so the limit stops being abstract. A region four hundred kilometres away is about two milliseconds of light each way through fibre, call it four for the round trip once you add the switches and the software in between — fine for a web page, invisible to a shopper. But a control loop that must react in one millisecond has already lost before the request leaves the building, and a system that makes ten dependent round trips to render one screen turns that four milliseconds into forty the user actually feels. The failure is not the cloud being slow; it is distance being charged at the speed of light, ten times over, on a workload that never should have crossed the room. The fix is architectural — move the latency-critical piece close to the thing it serves — and recognising which piece that is, before you deploy it four hundred kilometres away, is the judgment this section is training.

The third place the answer is "not like that" is not technical at all. Some data is bound by law or contract to live in a particular country, to stay in the custody of vetted personnel and cleared infrastructure rather than an ordinary support engineer, or to never sit on hardware shared with anyone else. These constraints do not care how elegant your architecture is.

Data residency

A requirement that data be stored, and sometimes processed, within a defined geography — a country or economic region — to satisfy a law, a regulator, or a contract.

The cloud has real answers here: Azure offers regions in dozens of countries, lets you pin resources to a chosen geography, and operates sovereign and government clouds for the strictest cases. But every one of those answers is something you must choose and configure on purpose. Nothing about the cloud keeps regulated data in-country by default; a resource created in the wrong region is a compliance incident that no amount of encryption undoes. The obligation to know where the data physically rests sits squarely above the line you drew in Class One — it is yours.

Notice the pattern across §2 to §4: the hard limits are money, physics and law, in that order of how often you will meet them. You will argue about egress every month, about latency occasionally, and about residency rarely but with a lawyer in the room. None of the three is a reason to distrust the cloud. Each is a reason to design for it deliberately.

The two cons that arrive in year two

Two more costs belong on the list before you leave it, and both are quiet because neither shows up on the calculator that approved the migration. They surface a year later, when the business case has already been signed on year one's numbers.

Vendor lock-in is the price of convenience compounding. Every managed service you build on — a proprietary database, a serverless runtime, a message bus with its own dialect — saves you real effort today and stitches you a little more tightly to one provider. None of them is a trap on its own; together they mean that leaving is no longer a matter of copying files but of rewriting the parts of the application that learned to speak the platform's private language. And the egress meter from §2 is the toll booth standing on that exit: the very act of moving your data to a competitor is billed per gigabyte, so the platform charges you to leave at precisely the moment you have decided to. Lock-in is rarely a reason not to use a managed service — the productivity is genuine — but it is a reason to know which of your dependencies are replaceable and which are load-bearing, and to spend your portability budget where a future migration would actually hurt. Class Five weighs this properly when it takes portability and multi-cloud apart.

The skills gap is the other, and it is the one leadership underestimates most. The cloud does not run itself; it runs on people who understand it, and a team that has spent a decade racking servers holds none of that knowledge by default. Hand them a portal and no training and you have not removed the outages, only moved them from the failed disk to the misconfiguration — and the misconfiguration, as Class One argued, is the failure mode the provider will never catch for you. Real, budgeted retraining is part of the migration's cost, not a courtesy after it. The half of the responsibility line that is yours cannot be held by people who were never taught where it runs.

Repatriation — moving a workload out of the cloud and back onto owned hardware — is the word the marketing never uses and the honest engineer keeps ready. It is not an admission of failure; it is what happens when a workload's shape stops matching the model. The candidate is nearly always the same: something large, steady and predictable, running hot around the clock with no peak to amortise and no idle trough to save on.

That is the mirror image of Campux's storefront. The store site has a sharp November peak and a dead January — the exact profile consumption pricing rewards. A workload that runs flat at ninety percent every hour of every day gets none of that benefit and pays the cloud's convenience premium on every one of those hours. For a few companies at a certain scale, buying the hardware back is simply the cheaper arithmetic, and a few have said so publicly.³

Put Campux's two shapes side by side and keep capex and opex apart, or the arithmetic lies to you. The storefront needs three units of compute most months and ten in November, so scaling with demand costs it roughly $6,450 a year — against the roughly $18,000 it would cost, paid once, to buy servers sized for the November peak and leave them mostly idle the other eleven months. That gap, a yearly bill smaller than a single purchase, is the saving Class Two banked. Now take a workload with the opposite shape: an analytics job that grinds at ten units every hour of every day, month in and month out. It has no trough to release and no peak to amortise, so metered pricing bills all ten units, every month, forever — on the order of $18,000 a year, not once. Buy the same ten units of hardware outright instead and that $18,000 is spent a single time; the box then keeps working for however many years it lasts, while the cloud bill for the same workload keeps repeating. That is the arithmetic behind repatriation, and it holds only if you also count what a server room costs beyond the hardware — power, space, a refresh cycle, the people who rack and patch it. Add those in before you trust the comparison. Leave them out and you have only shown that the cloud is not free, which nobody claimed. Elasticity you cannot use is a discount you cannot claim; a bill that repeats every year is a different thing from a purchase that does not, and that difference, not a vague sense that owning is cheaper, is what sends a flat, steady workload back on-premises.