DEV Community: Sherdil Cloud

The Cloud Benefit That Never Makes It Into the Migration Plan

Sherdil Cloud — Tue, 22 Sep 2026 10:23:15 +0000

TL;DR: Most cloud migration plans budget for the boring, measurable stuff: uptime, unit cost, release cadence. The line item that almost never makes it onto the slide is that cloud removes the upfront infrastructure cost that used to make certain business models too risky to try, subscription products, API access, expansion into new markets without building anything there. That's not a performance improvement, it's a different set of things your engineering team is now capable of shipping.

Cloud migration business cases are usually built around three numbers: expected uptime, expected unit cost, expected release cadence. All real, all worth tracking, and all of them framed as improvements to the existing business. The category that gets left off the slide entirely is the one McKinsey's cloud-value research actually flags as the largest source of return: business models that weren't viable before because the upfront infrastructure cost made them too risky to try.

Migration and transformation are not the same line item

Migration: moving an app from your servers to a cloud provider. Transformation: the operational change that follows once that app can scale, recover, and ship on a schedule it couldn't manage before. You can complete the first and get almost none of the second, a lift-and-shift onto faster hardware still runs the same slow processes, just somewhere else. The gap between the two is where the return actually lives, and it's mostly not captured by "how's the uptime."

Five areas, ranked by how often they show up in a business case

Area	What changes	Shows up in the plan?
Time to market	New environments in minutes, release on demand	Usually
Customer experience	Auto-scaling, multi-region keeps services online	Usually
Decision-making	Managed data/AI services on tap	Sometimes
Cost model	CapEx → usage-based OpEx	Always
New business models	Subscription, platform, API products become viable	Rarely

The last row is the one worth dwelling on, because it's structurally different from the other four. Rows 1-4 make the existing business faster, cheaper, or more reliable. Row 5 makes things possible that weren't on the roadmap at all, a software vendor offering its product as a subscription instead of a license, a company exposing an internal capability as a metered API, a local business serving another country's customers without building anything there. None of that requires new engineering talent. It requires the upfront cost barrier to disappear, which cloud does automatically, and almost nobody puts a line for it in the business case.

The metric nobody tracks for this

If your team is only tracking uptime and unit cost, you're measuring rows 1 and 4 and missing row 5 entirely, because "revenue from a product that didn't exist before the migration" isn't a metric anyone thinks to add to the dashboard until after it's already generating revenue. Worth adding deliberately: track whether any internal capability gets flagged as "this could be its own product" during the post-migration retro. That conversation happens more often than teams expect once the infrastructure cost of trying is gone.

The common worries, briefly

Worry	The reality	What to do
"Our data won't be secure"	Providers out-invest most companies on security; shared-responsibility splits the work clearly	Access controls, encryption, monitoring from day one
"It'll cost more than on-prem"	Can, without management, with right-sizing and budgets, most orgs cut cost while gaining flexibility	Adopt FinOps, track a unit-cost metric from the start
"We'll be locked into one vendor"	Multi-cloud/hybrid design keeps options open	Open standards, infrastructure as code for portability

None of these three block row 5 specifically, they're about the migration itself, which is exactly why "new business models" gets left off the risk register too. It's not a risk anyone's weighing against; it's an upside nobody's counting.

Proof, briefly

A Sharjah retail group rebuilding for peak-demand reliability (auto-scaling storefront, real-time inventory, CI/CD) didn't set out to launch a new business line, they set out to stop crashing on sale days. The infrastructure work alone drove online revenue up 38% in two quarters, purely from the site staying up and converting the traffic it already had. That's rows 1-4 working. Row 5, an actual new product or revenue line, wasn't even the goal of that engagement, which is itself the point: most teams don't budget for row 5 because they don't go looking for it.

FAQ

Is "new business models" really a cloud benefit, or is that just good product strategy?
Both, cloud removes a specific blocker (upfront infrastructure cost) that used to make certain product ideas too risky to greenlight. The product strategy still has to be good; cloud just changes which ideas clear the risk bar.

How do we know if we have a row-5 opportunity hiding in our stack?
Ask whether any internal-only capability (an API, a data pipeline, an admin tool) would be useful to someone outside the company. If yes, the cost of finding out is now low enough to actually test it.

Does this only apply to software companies?
No, a manufacturer selling data through an API, a logistics firm selling tracking access, anyone running software has capabilities worth checking for this. The starting point differs by industry, the mechanism doesn't.

Originally published on the Sherdil Cloud blog, the full piece (with the complete five-area breakdown and the Sharjah retail case study in full) is here. For the migration path itself, see legacy system modernization; for turning an internal capability into revenue specifically, turning IT into a profit center.

About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps infrastructure for enterprises across Pakistan, the UAE, and the United States since 2014.

How to Actually Vet a Cloud Services Partner (Not Take Their Word For It)

Sherdil Cloud — Tue, 15 Sep 2026 16:42:19 +0000

TL;DR: Picking a cloud partner shapes your cost, security, and delivery speed for years, so "trust us" isn't a good enough answer. Here's a 6-point checklist you can independently verify for any cloud partner, not just ours, covering partner status, engineer certifications, local + global reach, compliance-by-design, service breadth, and whether the model creates lock-in or actual independence. Applied transparently below using how we do it at Sherdil Cloud, since the whole point is that you shouldn't have to take a vendor's word for it.

Cloud partner pages are usually a wall of adjectives, "trusted," "experienced," "world-class", with nothing a buyer can independently check. That's backwards. A trustworthy partner should hand you a checklist you can verify yourself, for them or for anyone else you're evaluating. Here's the one we think actually matters, with each point tied to something you can go confirm right now, not take on faith.

The 6-point checklist

#	What to check	Why it's verifiable, not a claim
1	Recognized cloud partnerships	Provider directories list this publicly, check yourself, don't take a badge on a website at face value
2	Certified, experienced engineers	Certifications are checkable credentials, not a vibe
3	Local presence + global reach	Ask for reference clients in your specific region/industry
4	Compliance built in, not bolted on	Ask when in the project compliance controls get designed, not just whether they exist
5	End-to-end services	One partner across strategy → migration → DevOps → security → FinOps means no finger-pointing when something breaks
6	The delivery model itself	Does the engagement leave your team able to run the system alone, or does it quietly create a consultant dependency?

Point 1 is the one most buyers skip because it's the easiest to fake with a logo on a homepage, but AWS and Alibaba Cloud both maintain public partner directories. If a claimed partnership doesn't show up there, that's your answer.

Point 6 is the one that actually differentiates providers

Points 1-5 are table stakes any competent shop should clear. Point 6, the delivery model, is where providers genuinely diverge, and it's worth interrogating directly: does the engagement pair your engineers with theirs throughout the build, so your team owns and can run what gets built once it ends? Or does the system stay comprehensible only to the consultant, which is lock-in by a different name?

At Sherdil Cloud we run this as a co-build model specifically because the alternative, a system only we understand, creates a dependency that's good for us and bad for the client. A partner optimizing for your independence rather than your ongoing need for them is one worth trusting on the rest of the checklist too.

How we score against our own checklist

Reason	What backs it up
Recognized cloud partnerships	AWS Advanced Partner, Official Alibaba Cloud Partner, check the AWS Partner Network and Alibaba Cloud Partner Network directly
Certified, experienced engineers	AWS, Kubernetes (CKA), and Alibaba Cloud certifications, 10+ years building cloud/DevOps systems
Local presence, global reach	Teams in Pakistan, the UAE, and the US since 2014
Compliance built in	SBP, NESA, TDRA, PCI DSS, ISO 27001 designed in at architecture time, not retrofitted
End-to-end services	Strategy → migration → DevOps → security → FinOps, one accountable partner
The co-build model	Client engineers pair with ours throughout; you own and run what's built after we leave

The honest caveat on numbers

Since 2014, across three regions, holding two major cloud partnerships, with a typical TCO reduction in the 25-30% range across engagements, these are representative ranges from real work, not a promise of identical results for your specific environment. Any honest partner should say the same thing: the right figure for you comes from an actual assessment of your setup, not a number lifted from someone else's case study.

How an engagement actually starts

Step	What happens	Typical timeline
Free consultation	Discuss goals, constraints, current setup	1 session
Assessment	Review the environment, map quick wins and risks	1-3 weeks
Proposal	Scope, timeline, expected outcomes	Within days of the assessment
Co-build delivery	Build alongside your team, hand over ownership	Per agreed scope

The first step being small and low-risk is deliberate, it's the fairest way to judge any partner on evidence (is the advice specific? honest? useful?) before committing to anything bigger.

FAQ

What actually makes a cloud partner trustworthy, in one sentence?
Everything they claim should be something you can verify independently, partner directories, certification registries, reference clients, not something you take on faith from their own marketing.

Why does the delivery model matter as much as technical skill?
Because a technically excellent team that builds something only they can maintain has built you a dependency, not a solution. The model determines whether you're more capable after the engagement or just as reliant on the vendor as before.

Is a bigger TCO-reduction number always the better partner?
Not by itself, it depends entirely on your starting point. Be skeptical of any number presented without "here's how we'd measure yours specifically" attached to it.

Originally published on the Sherdil Cloud blog, the full piece is here. For how we approach compliance specifically, see cloud compliance in 2026; for the migration side, smooth, secure, smart cloud migration.

Wrapping a Monolith in Docker Isn't Containerization

Sherdil Cloud — Sat, 12 Sep 2026 12:22:14 +0000

TL;DR: docker build on a monolith and calling it "containerized" gets you a portable monolith, which still scales and fails as one block, and gains almost none of what containers actually offer. Real containerization pays off through five specific benefits: portability, independent scaling, self-healing, resource efficiency, and consistency, and most of them require splitting the app first. A real food-delivery platform proved this by containerizing after splitting into services: server cost down 41%, deploy time from 2 days to 20 minutes, zero crashes at dinner-time peak.

The most common containerization mistake isn't technical, it's sequencing: teams wrap one large application in a container as-is, expecting the benefits to show up automatically. They don't. A monolith in a container still scales as a single unit, still fails as a single unit, and still ships as one big risky deploy, you've changed the packaging, not the architecture. The benefits below only show up once services are actually separated.

Containers vs VMs, for anyone who still confuses them

Aspect	Containers	Virtual machines
What's virtualized	OS is shared	Full hardware + OS copied
Size	Megabytes	Gigabytes
Startup time	Seconds	Minutes
Density per server	Many per host	Far fewer per host
Best for	Microservices, scaling, fast delivery	Strong isolation, mixed OSes

Neither wins universally, most production systems run containers on top of VMs, getting both layers. But the density/speed numbers explain why containers, not VMs, are the default unit for anything you want to scale or ship fast.

The five benefits, and which ones need splitting first

#	Benefit	What it provides	Requires splitting the app?
1	Portability	Build once, run on any cloud	No
2	Independent scaling	Scale one service without scaling the rest	Yes
3	Self-healing	Failed containers restart automatically	No (needs orchestration)
4	Resource efficiency	More workloads per server than VMs	Partially
5	Consistency	Same image dev → production	No

This is the table that explains why "wrap the monolith" underdelivers: benefit 2, arguably the biggest one, is architecturally unavailable to a single-container monolith. You can containerize a monolith and get portability and consistency (real wins, not nothing), but independent scaling, the thing that turns a traffic spike from an incident into a shrug, requires the app to actually be decomposed into services first.

Docker builds it, Kubernetes runs it

Docker is where you build and run individual containers, most people start here. It stops being enough once you have more than a handful of containers to manage by hand. Kubernetes is the orchestrator: it schedules containers across servers, scales them, restarts failed ones, and routes traffic to healthy replicas. Docker packages the application; Kubernetes is what makes benefits 2 and 3 (independent scaling, self-healing) actually happen at runtime instead of staying theoretical.

The four pitfalls, and the one that undoes everything else

Pitfall	Why it backfires	The fix
Containerizing a monolith as-is	Wrapping one big app gains little of the benefit	Split into services where it pays off, then containerize
No orchestration	Manual scaling/restarts don't hold at scale	Use Kubernetes or a managed equivalent
Ignoring image security	Vulnerable base images ship straight to production	Minimal trusted bases, scan every image in the pipeline
Storing data inside containers	Data vanishes on restart	Keep state in managed databases or volumes

The first row is the one that makes the other three moot if you skip it, there's no orchestration strategy that fixes a system that's architecturally one block.

Case study: split first, then containerize

A Dubai food-delivery platform's single large application strained every evening under dinner-time demand, because the whole app scaled as one block, it was slow to react to the surge and expensive to run the rest of the day. Deployments were risky, so new features shipped rarely. Five-month co-build: split into services, then containerized on Kubernetes.

Problem	What we built	Outcome
Crashes at dinner peak	Split into services, scaled independently on Kubernetes	Peak handled with zero crashes
Risky, rare deploys	Container images shipped through CI/CD	Deploy time: 2 days → 20 minutes
High server cost	Higher container density, autoscaling off-peak	Server cost down 41%
Slow recovery from failures	Self-healing + rolling updates	Recovery now automatic

The lesson the team took away, verbatim from the engagement: the gains came from splitting the app first, then containerizing, not the reverse. Once each service could scale and recover independently, the nightly dinner rush stopped being a fire drill and became routine.

FAQ

Should we containerize our existing monolith?
Often yes, but rarely as-is. Wrapping it changes nothing about how it scales or fails. The bigger win comes from splitting it into services where that pays off, then containerizing those, an assessment of what to split usually comes first.

What's the actual difference between Docker and Kubernetes?
Docker builds and runs individual containers. Kubernetes orchestrates many of them across servers, scaling, restarting, routing traffic. Docker packages; Kubernetes runs it reliably at scale. Most production systems need both.

Does containerization inherently improve resilience?
Only under an orchestrator. A bare container that crashes just... stays crashed. Self-healing (automatic restart, moving workloads off a failed server) is a Kubernetes-layer behavior, not a property of containers alone.

Originally published on the Sherdil Cloud blog, the full piece (with the complete five-benefit breakdown and four-stage build) is here. For the orchestration layer specifically, see Kubernetes for beginners; for the delivery pipeline on top of it, CI/CD from scratch.

The 6-Point Checklist for an E-Commerce Stack That Survives Black Friday

Sherdil Cloud — Mon, 07 Sep 2026 07:26:32 +0000

TL;DR: In e-commerce, performance is revenue, a slow page loses shoppers, a sale-day crash loses sales and trust in the same hour. Six building blocks decide whether a store survives its peak: auto-scaling compute, a CDN/caching layer, a database built to scale, stateless architecture, Core Web Vitals discipline, and load testing before the day arrives. A real US DTC brand went from Black Friday crashes to handling a 30x spike with zero downtime and its best sales day on record.

Sale-day traffic isn't steady load with a bump, it's 10-30x normal traffic arriving in a window measured in hours, sometimes minutes. A stack sized for an average day doesn't degrade gracefully under that; it falls over exactly when every visitor is worth the most. The fix isn't "buy bigger servers." It's a specific set of architecture decisions that most crashes trace back to skipping.

The 6 building blocks, in order of how often they get skipped

#	Building block	What it does
1	Auto-scaling compute	Adds/removes servers as traffic changes, so peak isn't a guess
2	CDN + caching	Serves most requests without touching origin servers at all
3	A database built to scale	Read replicas + query caching so the DB isn't the bottleneck compute isn't
4	Stateless architecture	Any server handles any request, no session tied to one machine
5	Core Web Vitals discipline	Page speed directly drives conversion and search ranking
6	Load testing + observability	Finds the weak point before real shoppers do

Building block 4 is the one that silently breaks building block 1. You can wire up auto-scaling perfectly, but if sessions are pinned to specific servers, adding capacity doesn't help, shoppers already routed to an overloaded server stay stuck there. Statelessness is what makes horizontal scaling actually work, not just exist on paper.

Horizontal vs vertical: why this isn't really a choice anymore

Vertical scaling (bigger server) has a ceiling and usually needs downtime to apply. Horizontal scaling (more servers behind a load balancer) scales close to unbounded without taking anything offline, paired with auto-scaling, it turns a 10x sale-day surge into a routine scale-out instead of an incident. Modern e-commerce architecture assumes horizontal scaling as the default; the six building blocks above are really just "what horizontal scaling requires to actually work."

Where sale-day disasters actually come from

Mistake	Why it backfires	The fix
Sizing for the average day	Store crashes on its busiest, most valuable day	Auto-scale for the peak, not the average
Sticky, server-bound sessions	Can't add servers, so scaling fails silently	Stateless app + shared session store
No CDN or caching	Pages are slow, origin overloads under load	CDN for static assets, cache for common queries
Never load testing	The weak point gets found by real shoppers	Load test to expected peak, well ahead of time

Every one of these is discoverable in a load test before the actual event, which is exactly why block 6 isn't optional. A store that's never been pushed to its limit in a test has no idea which of the other five blocks is actually load-bearing until it's live traffic finding out.

Case study: 30x traffic, zero downtime, best Black Friday on record

A US direct-to-consumer brand's store buckled every Black Friday, fixed servers sized for normal traffic met a surge that made up a disproportionate share of annual revenue, and every year meant slow pages, timeouts, and lost sales at the worst possible moment. Four-month rebuild, run as a co-build so the team could operate it through every future peak:

Problem	What we built	Outcome
Crashes at peak	Stateless app on auto-scaling containers	Handled 30x traffic, zero downtime
Slow pages	CDN, caching, Core Web Vitals work	Page load: 4.1s → 1.3s
Database bottleneck	Read replicas + query cache	Checkout stayed fast under load
Untested before the day	Load testing to the expected peak	Conversion +18%, cart abandonment −22%

The number worth sitting with: scaling kept the store up, but the 1.3s page load is what actually grew revenue. Auto-scaling let the traffic through; speed is what converted more of it. Both mattered, and neither alone would've produced the best Black Friday on record.

FAQ

Is cloud scalability expensive for a smaller store?
Usually the opposite, you pay for extra capacity only while a surge lasts, instead of running servers sized for a peak that happens a few days a year, year-round.

What's the single most commonly missed building block?
Stateless architecture. Teams wire up auto-scaling and assume it'll work, then discover sticky sessions are quietly capping how much of that new capacity actually helps.

Does page speed really move conversion, or is that overstated?
It's understated if anything, Core Web Vitals affect both conversion directly (shoppers abandon slow pages) and search ranking (Google uses them as a ranking signal), so the win compounds.

Originally published on the Sherdil Cloud blog, the full piece (with the complete six-block breakdown and four-stage build) is here. For the uptime side specifically, see resilient cloud infrastructure; for keeping the cost of that auto-scaling in check, right-sizing your cloud.

Why Your Team Ships Fewer Experiments Than It Should

Sherdil Cloud — Thu, 03 Sep 2026 09:43:28 +0000

TL;DR: Most teams don't lack ideas, they lack a cheap way to test them. Four blockers inflate the cost of trying: manual environment setup, big rare releases, idle-hardware cost from failed tests, and no safe way to undo a change. Fix all four with on-demand environments, automated delivery, and feature-flagged rollouts, and a real SaaS team went from 3 experiments a quarter to 19, lead time 9 days to 3 hours, infra cost per experiment down 82%.

If standing up a test environment takes a week and a failed experiment leaves a server running that someone has to remember to kill, people stop proposing experiments. Not because they ran out of ideas, because the cost of finding out if an idea works got too high. That cost is the actual constraint on innovation speed, and it's an infrastructure problem, not a creativity problem.

Why DevOps and cloud fix different halves of the same wall

DevOps alone hits a hardware ceiling: you can automate a release perfectly and still wait weeks for a new environment to get racked. Cloud alone hits the opposite problem: you can spin up a server in seconds, but if releases are still manual and risky, that speed goes unused. Each one removes the other's limit, which is why teams running both pull ahead of teams running either alone.

The five capabilities that actually move the needle

#	Capability	Effect
1	On-demand environments	No waiting weeks to try an idea
2	Infrastructure as code	Copy a working setup instead of rebuilding it
3	Managed building blocks (DB, queues, AI)	Build on parts instead of from scratch
4	Automated delivery pipeline	Release many times a day without fear
5	Feature flags + staged rollouts	Test on real traffic, undo in seconds

Capability 5 is the one that changes team psychology, not just infrastructure: when a bad idea can be switched off in seconds instead of requiring a redeploy, people propose riskier, more interesting experiments, because the downside stopped being scary.

Four blockers, and what actually fixes each one

Blocker	Why it slows innovation	The fix
Manual environment setup	Every experiment waits days/weeks for a place to run	Define environments as code; create and destroy on demand
Big, rare releases	Each release is risky, so teams batch changes and ship less	Automate delivery so small changes ship safely, many times a day
Cost of a failed test	Idle hardware from abandoned ideas discourages new ones	On-demand resources that cost nothing once shut down
No safe way to undo	Fear of breaking prod stops teams from trying bold changes	Feature flags + staged rollouts with instant rollback

Notice these aren't tooling gaps you buy your way out of, they're process defaults that compound. Manual setup makes releases scarier (batch more into each one), which makes rollback harder (nobody wants to touch it), which makes the next idea feel riskier to propose. Fixing one blocker without the others gets you partial relief; fixing all four is what changes the actual experiment rate.

Speed and safety aren't a trade-off (the data backs this)

Google's DORA research, tracking engineering teams for over a decade, consistently finds the teams shipping most often also have the lowest change-failure rates. Elite performers deploy on demand and recover in under an hour; low performers deploy monthly and take days. The lever for innovation specifically is lead time, commit to running in front of users, because a short lead time is what lets a team learn from one experiment and move to the next before the idea goes stale.

Case study: 3 experiments a quarter to 19

An Islamabad SaaS team wanted to ship faster but kept stalling on the same wall: environment setup took over a week, releases happened roughly monthly, and a failed experiment left orphaned servers someone had to remember to kill. They had the ideas. They didn't have a cheap way to test them.

Blocker	What we built	Outcome
Week-long environment setup	Environments defined in Terraform, created on demand	New environment in under 10 minutes
Monthly releases	CI/CD pipeline with automated tests and rollback	Lead time: 9 days → 3 hours
Costly failed tests	On-demand resources, auto-shutdown of idle environments	Infra cost per experiment down 82%
No safe rollout	Feature flags, staged rollout to user segments	Experiments per quarter: 3 → 19

Five months, kickoff to full rollout. The team didn't get more creative, they got a lower cost of finding out if an idea worked, and the number of things worth trying went up on its own once that cost dropped.

FAQ

Does shipping more often mean shipping worse code?
No, DORA data shows the opposite. Teams that ship most often also have the lowest change-failure rates, because small frequent releases are easier to test and undo than large rare ones.

Do we need both DevOps and cloud, or does one cover it?
Each limits the other alone. DevOps on your own hardware still waits weeks for a new environment. Cloud without DevOps gives you fast infrastructure and slow, risky releases. Pairing them removes both ceilings at once.

What's the single highest-leverage fix to start with?
On-demand environments, usually, it's the blocker that makes every other experiment wait, and it's typically the fastest to fix with infrastructure as code.

Originally published on the Sherdil Cloud blog, the full piece (with the complete five-capability breakdown and four-stage build) is here. For the delivery-pipeline foundation, see CI/CD from scratch; for keeping cheap experiments cheap, cloud cost optimization strategies.

The 5 Cloud Migration Mistakes That Actually Cause Outages

Sherdil Cloud — Fri, 28 Aug 2026 11:27:00 +0000

TL;DR: Migrations that go wrong almost always fail the same five ways: no dependency mapping, a big-bang cutover, lift-and-shift applied blindly to everything, security bolted on after the move, and no cost guardrails before go-live. None of these are exotic failure modes, they're predictable, which means they're avoidable. A real 7-month phased migration (40+ workloads, sensitive regulated data) shipped with under 2 hours of total cutover downtime and zero compliance gaps by avoiding exactly these five.

Cloud migration has a reputation for being risky, and the reputation is earned, but not because migration is inherently dangerous. It's because most failures trace back to the same five mistakes, made in roughly the same order, on roughly every project that skips them. Fix these five and a migration stops being a leap of faith and starts being boring, in the best sense.

The four phases, in order (skipping one causes the next one's failure)

Phase	What happens	Skip it and...
1. Assess	Inventory workloads, map every dependency	Hidden dependencies break at cutover
2. Plan	Sequence into waves, pick a strategy per workload, define rollback	You improvise mid-migration
3. Migrate	Move in waves, test, then cut over	Untested waves fail in production
4. Optimize	Right-size, harden security, add cost controls	You inherit a migrated-but-unmanaged mess

The order matters more than any individual step. A team that rushes past assessment doesn't skip that work, it just does it during cutover, under pressure, in front of users.

The five mistakes that actually cause outages

#	Mistake	What breaks	The fix
1	Skipping dependency mapping	Hidden shared DBs / internal APIs break when only one side moves	Map every dependency before anything moves
2	Big-bang cutover	One failure takes down the whole business at once	Migrate in small, reversible waves
3	Lift-and-shift everything	You inherit old problems at cloud prices	Pick a strategy per workload (the 7 Rs)
4	Security bolted on after	Gaps and compliance failures surface late, expensive to retrofit	Build encryption, least-privilege, and compliance checks into every wave
5	No cost guardrails	The first full bill is a shock	Tag, budget, and right-size before go-live, as part of the plan

Two of these deserve a closer look, because they're the ones teams underestimate specifically because they feel optional.

Why "just lift-and-shift it" is a trap

A pure lift-and-shift is the fastest way to get something running in the cloud, and applied to everything, it's the fastest way to pay cloud rates for the same problems you had on-prem. The fix isn't "never lift-and-shift," it's choosing per workload, using the well-known 7 Rs (rehost, replat form, refactor, repurchase, retire, retain, relocate). Some apps genuinely just need to move as-is. Others are wasting money staying architecturally frozen. The mistake is applying one strategy to a portfolio that needs several.

Why the cutover strategy matters more than the migration tooling

Big-bang cutovers concentrate every risk into a single weekend. Wave-based migration does the opposite: start with low-risk, non-production workloads, prove the process works, and only touch critical systems once you've built confidence through repetition. Each wave is small enough to be reversible, which means a wrong call costs you an hour of investigation, not an incident review.

Migrating securely (not securing it afterward)

Security added post-migration is a retrofit, and retrofits are slow and leaky. The teams that get this right decide three things before anything moves: data travels over a private connection (not the public internet) for sensitive workloads, everything is encrypted in transit and at rest, and migration tooling gets least-privilege access, nothing broader. Each workload gets validated against its compliance rules before cutover, not assumed to have carried over. For jurisdictions with real residency rules (NESA, TDRA, SBP, or similar), that validation includes confirming data landed in the right region, not just that the app is running.

Case study: 40+ workloads, under 2 hours of total downtime

A Dubai insurance group needed to move off an aging on-prem data center while holding sensitive policyholder data under NESA and TDRA rules, meaning a big-bang move wasn't an option and neither was cutting corners on compliance. Seven-month phased migration, client engineers pairing throughout so they'd own the platform afterward:

Risk	What we did	Outcome
Unknown dependencies	Full discovery and dependency mapping first	Zero cutover-day surprises
Downtime fear	40+ workloads migrated in small waves	Under 2 hours total cutover downtime
Sensitive data + compliance	Encrypted transfer, least privilege, residency by design	NESA + TDRA cleared, zero data loss
Runaway cost	Right-sizing and FinOps built into the optimize phase	Run cost 24% below the old data center

The number that mattered wasn't any single stat, it's that all four came out of the same seven months, because none of the five common mistakes got made. Confidence didn't come from a big reveal at the end; it came from every small wave working, which is what made the final critical cutover feel routine instead of terrifying.

FAQ

What's the single biggest predictor of a bad migration?
Skipping dependency mapping. Almost every cutover-day surprise traces back to a dependency nobody documented before the move started.

Is lift-and-shift always the wrong call?
No, it's the wrong default. Some workloads genuinely just need to move as-is. The mistake is applying it to every workload instead of choosing a strategy (one of the 7 Rs) per app.

How do you migrate regulated data without a compliance gap?
Validate each workload against its compliance rules before cutover, not after, and build encryption, least-privilege access, and residency checks into every wave rather than adding them once everything's already moved.

Originally published on the Sherdil Cloud blog, the full piece (with the complete four-phase framework and secure-migration checklist) is here. For choosing a strategy per workload, see legacy system modernization; for the cost-guardrails side, cloud cost optimization strategies.

Right-Sizing Your Cloud Isn't Just a Cost Cut, It's a Two-Way Fix

Sherdil Cloud — Wed, 26 Aug 2026 13:02:14 +0000

Most teams hear "right-sizing" and think "make it smaller." That's half the story. The other half is the resources quietly starved of capacity, throttling under load while nobody notices. Fix both directions in the same pass and you don't trade cost for performance, you usually get both.

Executive summary: Organizations waste roughly a third of their cloud spend (Flexera 2025), mostly on resources sized for a peak that rarely happens. Right-sizing matches every resource to what it actually needs, which cuts cost on the oversized half and improves performance on the undersized half. This guide covers the five-step process, the free tools that do the analysis, the mistakes that turn it into a risk, and a real engagement where shrinking one service and growing another delivered a 36% cost cut and a 45% latency drop from the same exercise.

Right-sizing has a branding problem. It gets filed under "cost cutting," which makes it sound like a trade-off, save money, accept some risk to performance. In practice it's closer to bug-fixing: some resources are wrong in one direction (oversized, wasting money), others are wrong in the other direction (undersized, wasting your users' patience), and the fix for both is the same exercise. You're not choosing between cheaper and faster. You're removing a mismatch, and which way it resolves depends on which way the mismatch pointed.

What right-sizing actually means

Right-sizing is adjusting the size and type of a cloud resource to match what its workload really uses, not just picking a smaller instance. Three ways a resource can be wrong, only one of which is "too big":

Situation	The problem	The fix
Over-provisioned	Paying for capacity that sits idle	Shrink to fit real usage
Under-provisioned	Slow, throttled, or crashing under load	Grow it, or change the type
Wrong instance family	CPU/memory balance doesn't match the app (e.g., a memory-heavy app on a compute-optimized box)	Switch families, not just sizes

That third row is the one most teams skip. A smaller instance in the wrong family is still waste, it's just cheaper waste.

The five-step process

#	Step	What it involves
1	Measure real usage	Track CPU, memory, network over a full business cycle, including peak days, not a quiet week
2	Find both kinds of mismatch	Flag over-provisioned and under-provisioned resources, most audits only look for the first
3	Choose the right type	Pick family, size, and generation together; a size change alone can leave the real mismatch untouched
4	Apply changes safely	Test in staging or on a slice of traffic first, roll out with a clear rollback
5	Make it continuous	Workloads drift, so a review that happens once decays back into waste within months

Step 2 is where the "it's just a cost cut" framing breaks down: hunting only for oversized resources means you catch the money leak and miss the performance leak sitting right next to it.

The tools that do the analysis for you

You don't need to eyeball CloudWatch graphs by hand, every major provider ships a free recommender:

Tool	Provider	What it does
AWS Compute Optimizer	AWS	Flags over- and under-provisioned resources with a specific target size
Azure Advisor	Azure	Recommends resizing or shutting down underused VMs
GCP machine type recommendations	Google Cloud	Suggests right-sized machine types from usage history

None of these know about a launch next week or a campaign about to 10x your traffic, they only read the past. Treat every recommendation as a draft a human signs off on, not an auto-apply button.

Where right-sizing goes wrong

Mistake	Why it backfires	The fix
Sizing on a quiet week	You undersize, then crash at the next real peak	Measure across a full cycle, busy periods included
Only ever shrinking	You miss the under-provisioned performance wins entirely	Look both ways, up as well as down
Ignoring instance family	A smaller size in the wrong family still wastes money	Match the family to the workload's actual profile
Treating it as a one-time project	The fit drifts and waste creeps back within months	Make it a recurring review, not a cleanup sprint

Case study: shrinking one service, growing another, at the same time

A Karachi gaming studio came to us with a cloud bill that was too high and a matchmaking service that was too slow, the textbook case for why "right-sizing = shrinking" is the wrong mental model. Their game servers sat on oversized instances, half-idle between match peaks. Their matchmaking service ran undersized, so players queued too long and sometimes timed out entirely.

Problem	What we did	Outcome
Oversized game servers	Right-sized the instances, added autoscaling between peaks	Compute cost down 36%
Undersized matchmaking	Moved to a compute-optimized family and grew it	Match latency down 45%
Wrong database family	Switched to a memory-optimized instance type	Faster queries, lower cost
One-off tuning	Set up continuous right-sizing with alerts	Fit holds as the player base grows

Four months from kickoff to full rollout. The number worth sitting with isn't the 36% or the 45% individually, it's that both came out of the same engagement. Nothing about fixing the cost problem competed with fixing the performance problem; they were the same mismatch pointing in opposite directions.

Frequently asked questions

Is right-sizing risky for production workloads?

Low-risk if done in order: test in staging or on a slice of traffic, then roll out with a clear rollback path. Because each change is reversible, a wrong guess costs minutes, not an outage.

How often should we right-size?

Treat it as a recurring habit, not a one-time cleanup, a deeper review each quarter, backed by automated recommendations and alerts in between. Workloads drift, so a review done once starts decaying immediately.

Can right-sizing actually improve performance, not just cut cost?

Yes, that's the half most guides skip. An undersized resource throttles or crashes under load; growing it or moving it to a better-fitting family fixes that directly, in the same pass as the cost-side fixes.

Originally published at sherdilcloud.com.

Cloud Hit $900B in 2026, Here's What Actually Changed for Engineering Teams

Sherdil Cloud — Tue, 25 Aug 2026 12:25:07 +0000

TL;DR: Global cloud spend crossed $900B in 2026, public cloud specifically is at $850B (+21.3% YoY, Gartner), 94% of enterprises run cloud in some form, and 87% run multi-cloud (Flexera 2025). Adoption isn't the interesting question anymore, it's settled. What separates teams now is architecture: compliance designed in at build time instead of retrofitted, FinOps treated as an engineering discipline, and region/provider chosen for data residency up front. A real dual-jurisdiction build below shows what that looks like.

If your team is still debating whether to be on cloud, that debate is over industry-wide, 45% of IT budget now goes to cloud infrastructure, up from under 17% in 2021 (IDC). The teams pulling ahead aren't the ones who adopted earliest; they're the ones who stopped treating cloud as a lift-and-shift target and started treating it as the platform their compliance, cost, and reliability decisions get made in.

What cloud actually replaced, reason by reason

Old model	Cloud model	Typical impact
Capacity bought for peak, idle the rest of the time	Pay for what you use, scale on demand	20-30% lower TCO vs on-prem
Manual capacity planning for traffic spikes	Auto-scaling absorbs spikes without a pager going off	No over- or under-provisioning
AI/ML as a separate, bolted-on project	Managed AI services in the same platform (SageMaker, Vertex AI, Azure AI, PAI)	66% YoY adoption growth
Security owned entirely in-house	Shared-responsibility model, hyperscaler-grade controls (SOC 2, ISO 27001, PCI DSS, NESA P1)	Fewer gaps than most in-house stacks
DR as a separate, expensive project	Multi-region replication and failover as a platform feature	Sub-second RPO, minutes RTO

None of this is news if you've shipped on any major provider. What's changed is that these are now table-stakes defaults, not things you have to architect from zero.

The four trends that actually touch your stack

Trend	What it means day-to-day	2026 stat
Hybrid + multi-cloud	Workload placement is a design decision, not a lock-in accident	72% of enterprises run hybrid
Edge computing	Latency-sensitive workloads move closer to the source	58% YoY growth (IDC)
Sovereign cloud	Region/provider chosen for residency, not just latency or price	$80B market (Gartner)
Cloud-native by default	Containers, microservices, serverless are the assumption, not the exception	95% of new workloads

The one worth pausing on is sovereign cloud, because it's the one most teams still treat as a compliance afterthought instead of an architecture input.

Compliance is an architecture decision, not a retrofit

Retrofitting data residency after a system is built is expensive and audit-risky, you're moving live data and re-proving controls under time pressure. Deciding it up front costs nothing extra at runtime. If your users span jurisdictions with real residency rules (UAE NESA, Pakistan SBP, or similar), the provider and region get picked at design time, not after the first audit finding.

Case study: dual-jurisdiction, one ops stack

A Karachi-headquartered fintech we worked with served customers in both Pakistan and the UAE, meaning Pakistani customer data had to satisfy SBP residency, UAE customer data had to satisfy NESA P1 and TDRA, and both had to run under a single operational stack instead of two disconnected ones.

Decision	Architecture	Outcome
Pakistan customer data + core banking	Karachi private cloud, DR replication to Lahore	SBP residency satisfied; cleared audit on first pass
UAE customer data + core banking	Alibaba Cloud Dubai (NESA P1 certified)	NESA + TDRA met at the architecture level
Analytics, ML, reporting	AWS Bahrain, cross-region data minimization	31% lower analytics TCO vs all-on-prem baseline
Shared services (CI/CD, observability, IAM)	GitHub Actions + Datadog + federated AWS IAM	One ops stack across three environments

Year-one numbers: −31% TCO vs the on-prem baseline, 99.97% uptime across both jurisdictions, zero findings across both the SBP and NESA audits, and deployment frequency went from once every two weeks to four times a week. The uptime and cost numbers are nice; the audit result is the one that mattered most to the client, it's what happens when residency is a day-one architecture constraint instead of a compliance team's last-minute ask.

FAQ

Is cloud adoption still an open question for most companies?
No, 94% of enterprises already run cloud in some form and 87% run multi-cloud (Flexera 2025). The open question now is architecture, not adoption.

Does multi-jurisdiction compliance mean running separate stacks per region?
Not necessarily. The case study above runs three regions (Pakistan private cloud, UAE, Bahrain analytics) under one CI/CD, observability, and IAM layer, separate data planes, shared operational tooling.

Is cloud actually cheaper, or does it just feel that way?
Only with active management. Without FinOps and right-sizing, cloud spend can exceed on-prem. Managed well, most organizations see 20-30% lower infrastructure cost than equivalent on-prem setups.

Originally published on the Sherdil Cloud blog, the full piece (including the five-reason and four-trend breakdowns in more depth) is here. For the residency side specifically, see our enterprise cloud security guide; for the cost side, cloud cost optimization strategies.

5 Cloud Cost Quick Wins You Can Ship This Week (Zero Performance Hit)

Sherdil Cloud — Wed, 19 Aug 2026 07:10:13 +0000

TL;DR: Organizations waste roughly a third of cloud spend (Flexera 2025), and most of it sits in capacity nobody is using, not in customer-facing resources. That's why you can cut 20-30% off the monthly bill in the first 90 days with zero performance impact. Five quick wins: right-size, delete idle/orphaned resources, schedule non-prod off-hours, commit to your baseline, and tier cold data.

The fear that stops most teams from cutting cloud cost is that it'll slow something down. Usually it won't, because the waste isn't in your production capacity, it's in the stuff running that no one asked for. Oversized instances, dev environments idling at 3 AM, disks from servers you deleted months ago. Here are five changes you can ship this week, in rough order of effort-to-payoff.

1. Right-size oversized instances, 20-50% per instance

Most instances are sized for a peak projection that never happens. Pull real utilization (AWS Compute Optimizer gives safe recommendations from actual usage) and size to demand, not fear. Dropping a consistently-underutilized instance one class typically saves 20-50% on it, and if it was genuinely underutilized, performance doesn't move.

2. Delete idle and orphaned resources, pure waste, zero risk

Every account accumulates ghosts: disks from terminated servers, old snapshots, unattached reserved IPs, idle load balancers. None of them serve traffic; all of them bill. This is the zero-risk win, you're deleting things nothing depends on. Use your provider's cost tooling to list unused resources and clear them.

3. Schedule non-production to switch off, up to 65%

Dev, test, and staging almost never need to run 24/7. An automated schedule that stops them outside business hours cuts their cost by up to 65%, and production is completely untouched. Setup is an afternoon.

4. Commit to savings plans for your baseline, 60-72%

For the workloads that genuinely run around the clock, Savings Plans or Reserved Instances give you the same resources at a lower rate, up to 60-72% off. The one discipline: commit only to your steady baseline, not your peaks. Everything above baseline stays on-demand, so you never over-commit.

5. Tier cold data to cheaper storage, 40-70%

Set lifecycle rules that auto-move rarely-accessed data to colder, cheaper tiers. Hot data stays hot; cold data drifts down automatically. 40-70% off the data you move, no manual shuffling, no impact on anything live.

The point: these target waste, not capacity

Here's a real example that makes the "no trade-off" claim concrete. A Karachi e-commerce startup had a bill outgrowing revenue and was scared that cutting cost would hurt the store. Three-week quick-win sprint:

Quick win	Action	Result
Right-sizing	Shrank over-provisioned web/worker nodes	−14% compute
Idle cleanup	Removed orphaned disks, snapshots, IPs	Pure waste gone
Non-prod scheduling	Shut dev/staging after hours	−61% on those environments
Commitments + tiering	Committed baseline; tiered order data	Lower rate + cheaper storage

Outcome: −29% on the monthly bill, 0% performance drop, in three weeks. They'd feared a trade-off that didn't exist, because all five wins targeted waste, the store ran exactly as fast as before.

Then stop it creeping back

Quick wins are step one; without guardrails the waste returns. Four cheap habits keep it gone: tag every resource by team/project, set a monthly budget per team, wire spend-anomaly alerts, and do a monthly cost review. Native tools (AWS Budgets, Cost Anomaly Detection) cover most of it.

FAQ

Can you really cut cloud cost without hurting performance?
Yes, usually easily, because most waste sits in capacity nobody uses.

What's the single fastest win?
Delete idle resources, then right-size. Both are quick and risk-free, with results in weeks.

Are savings plans risky?
Low-risk if you commit only to your steady baseline; anything above stays on-demand.

Originally published on the Sherdil Cloud blog. For the deeper version, see the 10-strategy cloud cost optimization guide; the full quick-wins piece is here.

About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, cutting AWS, Azure, and GCP bills for enterprises across Pakistan, the UAE, and the United States since 2014.

Serverless DevOps: When It Wins, When It Doesn't, and How to Run It

Sherdil Cloud — Sat, 15 Aug 2026 11:12:44 +0000

TL;DR: Serverless DevOps = running code on services that manage the servers for you, wired into CI/CD. It shines for bursty, event-driven, unpredictable traffic (pay-per-execution, auto-scaling, single-function rollbacks) and is a bad fit for steady high-volume or long/heavy jobs (where containers cost less and don't hit runtime limits). Most real systems are hybrid. Here's the honest breakdown plus the five practices that make it work.

Serverless gets pitched as a universal upgrade. It isn't, it's a workload-shaped tool. Get the shape right and it turns your worst scaling headache into a non-issue while slashing idle cost. Get it wrong and you're paying per-execution premiums for a steady workload that a container would've run cheaper. Let's be precise about which is which.

What "serverless DevOps" actually means

Servers still exist, they're just invisible to you. You upload code as functions; the provider handles capacity, patching, and scaling. Serverless DevOps is that plus the usual pipeline discipline: automated testing, IaC, and CI/CD. You remove two kinds of overhead at once, server management and manual release steps.

When serverless wins

The sweet spot is spiky, unpredictable, event-driven work:

Pay-per-execution: idle functions cost nothing, so experimentation is cheap and nobody has to justify spend before trying an idea.
Automatic scaling: traffic spikes are absorbed with no manual intervention (the case study below took a 50× spike with zero downtime).
Small deploy units: you can roll back a single function instead of a whole service.
Built-in availability: high uptime without standing up redundant infrastructure.

When serverless doesn't win

This is the part vendors skip. Serverless is the wrong call when:

Trade-off	Why it happens	What to do instead
Cold starts	Idle functions need spin-up time	Provisioned concurrency on latency-sensitive paths (checkout, real-time APIs)
Vendor lock-in	Function APIs tie you to one provider	Keep business logic separate; use open frameworks
Long/heavy jobs	Runtime and memory limits exist	Run on containers instead
Predictable high volume	Per-use billing exceeds reserved cost	Compare pricing before committing

The honest strategy most teams land on: hybrid. Bursty, event-driven work on serverless; steady or heavy workloads on containers. Match the architecture to the workload, not to the trend.

The five practices that make it work

#	Practice	Tools
1	Event-driven functions	AWS Lambda, Azure Functions, Function Compute
2	Managed building blocks	DynamoDB, S3, managed queues
3	Infrastructure as code	Terraform, AWS SAM, Serverless Framework
4	Automated CI/CD	GitHub Actions, GitLab CI
5	Observability + cost tracking	CloudWatch, OpenTelemetry, Datadog

Two of these deserve emphasis for serverless specifically:

Keep functions focused. Event-driven functions trigger, run once, and stop. The discipline that keeps this clean is one function, one job, sprawling functions entangle your system fast.
Track cost per function, not just per month. Per-execution billing means a single hot function can quietly dominate the bill. Observability here isn't just tracing across function hops (though you need that too), it's per-function cost visibility. The cloud cost optimization mindset applies directly.

What it looks like in production

A Dubai event-ticketing platform had the textbook serverless-shaped problem: brutal on-sale traffic spikes, expensive idle time between events, and slow feature delivery.

Challenge	What we built	Result
Crashes during on-sale	Event-driven functions with auto-scaling	Handled a 50× traffic spike, zero downtime
Idle-time cost	Pay-per-execution + managed datastore	−64% off-peak infrastructure spend
Slow delivery	CI/CD with per-function deployment	Feature lead time 3 weeks → 4 days
Production blind spots	Function tracing + per-function cost view	Issue detection hours → minutes

Four months, kickoff to full rollout. The lesson: matching architecture to workload characteristics turned the platform's biggest weakness (bursty traffic) into a non-issue and cut idle cost. That only worked because the workload was actually serverless-shaped, which is the whole point.

FAQ

Does serverless save money?
Conditionally. Bursty/unpredictable traffic → significant savings. Steady high-volume → per-execution billing can exceed reserved container costs. Compare both against your actual traffic before committing.

What's a cold start and does it matter?
The delay when an idle function spins up on first call. Negligible for background jobs; a real problem for latency-sensitive paths, fix it with provisioned concurrency.

When should we NOT use serverless?
Long-running or compute-heavy jobs that exceed function limits, and steady high-volume workloads where containers cost less. Most production systems end up hybrid.

Originally published on the Sherdil Cloud blog, the full guide (including the four-stage build and compliance coverage) is here. For the pipeline side, see CI/CD from scratch; for the serverless-vs-containers decision, the hybrid vs multi-cloud strategy guide helps.

About the author: Muhammad Usman is Head of DevOps at Sherdil Cloud, AWS DevOps Engineer Professional, Certified Kubernetes Administrator (CKA), and Alibaba Cloud Certified, building cloud and DevOps platforms for enterprises across Pakistan, the UAE, and the United States since 2014.

The 5 Shifts Redefining Cloud Infrastructure in 2026

Sherdil Cloud — Thu, 06 Aug 2026 09:41:12 +0000

TL;DR: Worldwide public cloud spending hits $723B in 2026 and 89% of orgs run multi-cloud, adoption is a solved problem. What separates teams now is how they assemble infrastructure. Five shifts define the next phase: AI moving into the platform layer, sovereign/regional cloud, platform engineering replacing ad-hoc ops, FinOps as a default discipline, and energy efficiency as a design constraint.

The interesting question about cloud infrastructure in 2026 isn't "should we adopt it"; that's settled. Spending is at $723B (Gartner), 89% of organizations run multi-cloud (Flexera 2025), and Kubernetes is the default deployment target at most companies (CNCF 2024). The gap between teams now comes from assembly, not availability. Here are the five shifts driving that gap.

1. AI moves into the platform layer

GPU scheduling, model serving, and vector databases are becoming base platform components, not bolt-ons. That changes how you plan: training and inference workloads are spiky and expensive, so capacity planning and data governance have to be designed in up front, not discovered when the bill arrives. If your platform team doesn't own a story for how GPUs get scheduled and how model data is governed, that gap surfaces fast.

2. Sovereign and regional cloud

Data residency stopped being a policy paragraph and became an architecture rule. UAE workloads under NESA need specific controls and often in-country residency; Pakistani financial data under State Bank of Pakistan rules must stay in-country for regulated records. The practical consequence: your provider and region are decided at design time (Alibaba Cloud Dubai, AWS Bahrain, in-country private cloud), because retrofitting residency later is expensive and audit-risky. This is the same reasoning behind enterprise cloud security, controls belong in the architecture, not on top of it.

3. Platform engineering replaces ad-hoc ops

The pattern that's winning: a small internal team builds paved roads, standard deployment, database provisioning, logging, observability, and developers self-serve instead of filing tickets. CNCF surveys show platform teams are now common at mid-size and large companies. The payoff isn't just speed; it's that security and cost rules apply everywhere by default because everyone travels the same road. If your deploys depend on one or two people, or every team wires infrastructure differently, this is the shift to make first.

4. FinOps becomes a default discipline

Cloud cost is now an engineering responsibility, not a finance afterthought. The FinOps Foundation reports reducing waste and managing commitments as the top priorities year after year. The teams that avoid surprise bills do three unglamorous things from day one: tag on the first deploy, set per-team budgets, and track unit-cost metrics (cost per customer/transaction). Bolted on later, FinOps is a cleanup project; built in, it's just how the platform works, the mechanics are in our cloud cost optimization guide.

5. Energy efficiency becomes a design constraint

The IEA projects data-center electricity demand roughly doubles by 2030. That's starting to affect capacity availability in some regions, which means right-sizing instances and choosing efficient regions is no longer only a sustainability nicety, it's an availability and cost concern. Conveniently, the efficient choice is almost always the cheaper one too.

The part people skip: it's collaborative by design

None of this is a thing you buy and drop in. Cloud runs on a shared-responsibility model — the provider secures hardware, network, and hypervisor; your team secures applications, data, and access, and neither side can replace the other. The same is true of build partners: the ones who leave behind unexplained systems fail long-term. Real success is when your team learned the platform during the build, owns the runbooks, and can extend it without daily support. It's the open-source ethos (Kubernetes, Terraform, Prometheus are all maintained by people who never meet) applied to your own stack.

What it looks like in practice

A Dubai logistics platform had a single overloaded ops team bottlenecking every deploy, new features waited weeks for environments. Client engineers paired with us throughout the build:

Problem	What we built	Outcome
Deployment bottleneck	GitHub Actions golden-path pipeline; developer self-deploy	+41% faster releases by month four
Data residency	Alibaba Cloud Dubai; Terraform-enforced residency rules	TDRA + NESA alignment at design time
Unmanaged cost	Tagging policy, per-team budgets, idle-env shutdown	−27% monthly run cost
Knowledge transfer	Client engineers paired on every component	Team runs the platform independently

Eighteen-month results: +41% faster release cycle, −27% monthly cloud cost, deployment-bottleneck engineers 2 → 0, 100% of runbooks owned in-house. The most durable outcome wasn't the cost saving, it was that the team could run and extend the platform after we left.

FAQ's

What are the biggest infrastructure shifts for 2026?
AI moving into the base platform, sovereign/regional cloud driven by residency, platform engineering replacing ad-hoc ops, FinOps as a default engineering discipline, and energy efficiency as a design constraint.

What is platform engineering and do we need it?
A small internal team builds self-service paths (deployment, DB provisioning, logging) that developers use instead of filing tickets. You need it if deploys depend on one or two people or teams build infrastructure inconsistently.

Why is data residency such a big factor in the UAE and Pakistan?
NESA (UAE) needs specific controls and often in-country residency; SBP (Pakistan) requires regulated customer records stay in-country. Both decide region/provider at design time, they belong in the architecture, not added later.

Originally published on the Sherdil Cloud blog. The full essay: including the collaborative build model and the four-stage engagement, is here. If you're standing up a platform team, Sherdil Cloud's infrastructure and DevOps practice co-builds them.

Cloud Security for Engineers: The Controls You Actually Configure

Sherdil Cloud — Fri, 24 Jul 2026 15:12:20 +0000

TL;DR: Most cloud breaches aren't sophisticated, they're misconfigurations. The controls that actually prevent them are things engineers configure, not things security buys: least-privilege IAM with MFA, encryption with real key management, default-deny networking with zero-trust internal traffic, policy-as-code that blocks bad resources before they deploy, and automated threat detection you actually watch. Here's the engineer's version.

Security tooling gets sold in dashboards, but breaches happen in config files. A public S3 bucket, an overly permissive IAM policy, an open security group, these are the things that leak data, and they're all fixable in the same place you write the rest of your infrastructure. This is the hands-on version of cloud security: the controls you own.

Start where the breaches actually come from

Three threat categories, and the first one dominates:

Threat category	Common causes	How to catch it
Misconfiguration	Public S3 buckets, permissive IAM, unencrypted DBs, open security groups	Automated scanning: AWS Config, Azure Policy, GCP Security Command Center
Identity-based	Phishing, credential stuffing, stolen access keys	Login anomaly detection, impossible-travel alerts
Supply chain	Compromised images, malicious packages	Image scanning, SBOM analysis, dependency monitoring

Misconfiguration is the majority of cloud data exposures, and it's the category most directly in your hands.

IAM: least privilege is a config discipline, not a policy PDF

Scope every identity to its function. A deploy role reads logs and ships code; it does not touch IAM or networking. Review quarterly with AWS IAM Access Analyzer (it literally tells you which permissions go unused).
MFA on every human user. It blocks 99.9% of credential-based attacks. Non-negotiable.
Kill long-lived keys. Use STS AssumeRole or managed identities for short-lived credentials instead of access keys that live forever and leak into git history.

Networking: default-deny, then zero-trust internally

Segment with VPCs and purpose-specific subnets. Load balancers and gateways in public subnets; app servers and databases in private subnets with no direct internet route.
Security groups are allow-lists. Default-deny, permit only required flows, document each rule with its owner, and review monthly.
Don't trust your own VPC. Encrypt internal traffic with mTLS and authenticate every service-to-service call. Zero-trust is what stops one compromised instance from becoming lateral movement across your whole estate.

Data: encryption that survives a stolen dataset

Encrypt at rest (AWS KMS / Azure Key Vault / GCP Cloud KMS, customer-managed keys for PII, financial, health), encrypt in transit (TLS 1.2+ external, mTLS internal), and classify data into tiers so "we encrypt everything" becomes a defensible position. Encryption doesn't stop the breach, it decides whether the stolen data is a catastrophe or a shrug.

Policy-as-code: block the mistake before it ships

This is the highest-leverage control an engineer can add. AWS Config Rules, Azure Policy, and Open Policy Agent evaluate every resource against your baseline and flag or auto-remediate. The rules that pay for themselves immediately:

No S3 bucket may be publicly accessible
No security group may allow unrestricted inbound
All databases must have encryption enabled

Wire these into the pipeline and misconfigurations stop being a 258-day discovery problem, they never merge.

Detection: automated, and actually watched

Centralize logs (CloudTrail / Azure Activity Log / GCP Audit Logs) into a SIEM, then turn on native detection:

Cloud	Native detection	Catches
AWS	GuardDuty	Account compromise, crypto mining, exfiltration, recon
Azure	Defender for Cloud	Same + configuration risk scoring
GCP	Security Command Center	Same + posture management

The catch nobody mentions: automated detection only works if a human is watching the alerts. A GuardDuty finding that pages a monitored on-call is the difference between a 4-hour containment and a 258-day headline. For one financial-services client, that setup cost under $1,000/month and contained a stolen-key incident in four hours flat.

The three controls that do most of the work

If you do nothing else, do these, they prevent over 80% of cloud breaches:

Least-privilege IAM + mandatory MFA
Encryption at rest and in transit with centralized key management
Automated threat detection with centralized logging

Everything else: compliance frameworks, audits, asset inventory, is scaffolding around those three.

Originally published on the Sherdil Cloud blog. The full six-domain framework, including compliance (ISO 27001, SOC 2, GDPR, HIPAA, PCI-DSS) and governance, is in the Sherdil Cloud enterprise guide.

About the author: Muhammad Usman is Head of Cloud Security at Sherdil Cloud, CISSP, AWS Certified Security Specialty, Azure Security Engineer Associate, and Google Cloud Professional Cloud Security Engineer — who has led cloud security architecture and incident response across Pakistan, the UAE, and the United States since 2014.