DEV Community: Sherdil Cloud

A Cloud Audit Isn't a Cleanup Sprint, It's a Pipeline

Sherdil Cloud — Wed, 14 Oct 2026 08:44:11 +0000

TL;DR: Most teams treat a cloud audit as a one-time cleanup: find the waste, delete it, move on. Run it instead as a four-stage pipeline, discover, analyze, act, govern, and the two stages that matter most for whether the savings last are the bookends: automated tagging/inventory at the start, automated budgets and alerts at the end. The middle two stages (analyze, act) are where the dollar amounts live, but the bookends are where the durability lives. A real six-week audit on a US SaaS company's cloud footprint cut the monthly bill 38%, and the line item nobody expects, data transfer, was a hidden top-five cost until the pipeline's analyze stage mapped it.

A cloud audit run as a cleanup sprint has a predictable failure mode: someone finds $50k/year of waste, deletes it, the bill drops, everyone moves on, and six months later the bill has quietly crept most of the way back. That's not because the cleanup was wrong, it's because a sprint has a start and an end, and waste doesn't. Run the same audit as a pipeline instead, with discovery and governance as permanent, automated stages rather than a kickoff meeting and a final report, and the savings behave differently.

The pipeline, stage by stage

Stage	What it does	Automatable?
Discover	Inventory every resource, tag what's untagged, map where spend goes	Yes, run continuously
Analyze	Score savings opportunities across five technical areas by effort and impact	Partially, tooling surfaces candidates, a human prioritizes
Act	Apply right-sizing, deletions, and commitments, safest first	No, each change needs a human sign-off
Govern	Budgets, alerts, and a review rhythm that catch drift	Yes, run continuously

Notice the shape: discover and govern are the two stages you can fully automate and leave running, while analyze and act are inherently a human-in-the-loop exercise, you don't want a script auto-deleting a disk or auto-buying a three-year commitment. The practical implication: build discover and govern as always-on tooling from day one, and treat analyze/act as a recurring but bounded project that tooling feeds into.

The five technical areas analyze actually scans

#	Area	What it checks	Where the tooling gap usually is
1	Right-sizing	Real CPU/memory vs. provisioned size	Usually covered by the provider's own recommender
2	Idle/orphaned resources	Disks, snapshots, IPs nothing depends on	Needs a dependency graph, not just a resource list
3	Pricing and commitments	On-demand vs. reserved/savings-plan/spot fit	Needs usage predictability scoring, not just usage volume
4	Storage tiers and data transfer	Lifecycle rules, cross-region/egress traffic	Most commonly missed, see below
5	Architecture and licensing	Autoscaling vs. fixed fleet, managed vs. self-managed, unused seats	Rarely automated at all, needs architectural judgment

Area 4 deserves the callout. Right-sizing and idle-resource tooling are mature, most providers ship a version of it. Data transfer is different: it's billed per gigabyte across a path (cross-region call, egress to the internet) rather than per resource, so a resource-centric audit tool simply doesn't see it as a line item to flag. It shows up only when something explicitly traces where data actually flows, and because almost no team builds that tracing by default, it routinely turns out to be a top-five cost that nobody budgeted for.

Case study: the audit that mapped data flow and found the untagged 71%

A US B2B SaaS company's cloud bill had outgrown its revenue, and the team suspected waste but couldn't act on the suspicion, resources were untagged, so there was no owner to call about any specific dollar. We ran the pipeline's discover and analyze stages across all five areas over six weeks, then act over three months:

Finding	Pipeline stage that caught it	Outcome
Oversized fleet	Analyze (area 1)	29% off compute
Idle/orphaned resources	Analyze (area 2), tooling-driven	$0.21M/yr of pure waste removed
Everything on-demand	Analyze (area 3)	Commitment coverage 9% → 71%
No cost ownership	Discover (tagging) + Govern (budgets/alerts)	Waste stays visible and owned going forward

Monthly bill down 38%. The detail worth isolating for an engineering audience specifically: the 9%-to-71% commitment-coverage jump and the $0.21M in deleted waste are one-time, project-shaped wins, exactly the kind a cleanup sprint also would have found. What a sprint wouldn't have left behind is the discover/govern automation, the tagging that makes next quarter's drift visible the moment it happens instead of at the next scheduled audit.

FAQ

If our provider already has a cost recommender, do we still need a separate audit?
A recommender covers right-sizing well (area 1) and sometimes idle resources (area 2). It won't touch data transfer mapping, commitment-fit scoring, or architecture-level changes, areas 3-5 need a broader pass, usually annually or when the environment changes significantly.

What's the single highest-leverage thing to automate first if we're starting from nothing?
Tagging enforcement at resource-creation time (policy that blocks untagged resources from deploying). It's the discover-stage piece that every later stage, including governance, depends on, and it's useless to add after the fact since you'd still have to backfill the existing untagged fleet.

Is data transfer really worth a dedicated tracing effort, or is it a minor line item?
In this case study it was a hidden top-five cost, and that's typical, not exceptional, because almost nobody traces it by default. A basic version (checking for cross-region traffic between tightly coupled services) catches most of the easy wins without building full network-flow tooling.

Originally published on the Sherdil Cloud blog, the full piece (with the complete audit areas table and four-stage process) is here. For the pricing-commitment side in depth, see right-sizing your cloud; for the ROI framing this feeds into, maximizing cloud ROI.

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.

Compliance Isn't a PDF Checklist: It's a CI Gate

Sherdil Cloud — Mon, 05 Oct 2026 11:12:46 +0000

TL;DR: Most compliance programs are still a once-a-year document-gathering sprint, screenshots, spreadsheets, manual evidence collection. That model breaks the moment you're juggling more than one framework (GDPR, SOC 2, ISO 27001, PCI DSS, HIPAA, regional rules like NESA/SBP) at once, which most real businesses are. Compliance-as-code treats the rules as machine-readable policy that runs on every change, the same way a test suite does, a non-compliant config gets caught the day it's introduced, not during the audit. A real healthtech engagement cut audit prep from 5 weeks to 4 days doing exactly this.

Security and compliance get conflated constantly, and the distinction actually matters for how you build: security stops attacks, compliance proves, with evidence, that you meet a defined standard. You can be secure without being compliant (no paper trail) and compliant on paper without being genuinely secure. The engineering implication is that compliance isn't a security control, it's an evidence problem, and evidence problems are exactly the kind of thing you can automate into a pipeline instead of reconstructing manually once a year.

The frameworks that actually trigger this

Framework	Who it applies to	Main focus
GDPR	Anyone handling EU personal data	Privacy, data rights, residency
SOC 2	SaaS and service providers	Security and availability controls
ISO 27001	Any organization	Information security management
PCI DSS	Anyone handling card payments	Payment data protection
HIPAA	US healthcare data	Patient data privacy and security
NESA / TDRA	UAE organizations	National cyber security, data handling
SBP rules	Pakistan financial institutions	Data residency, outsourcing controls

Most real businesses face several of these simultaneously, a UAE fintech serving European customers needs GDPR, PCI DSS, and NESA together. Manual, per-framework evidence gathering doesn't scale linearly with the number of frameworks; it scales worse, because the same underlying control (say, encryption at rest) has to be documented three different ways for three different auditors unless the control itself is defined once, in code.

Compliance-as-code, mechanically

The pattern is the same shape as a test suite, applied to policy instead of application logic:

Define the rule as machine-readable policy (OPA/Rego, AWS Config rules, or equivalent) instead of a paragraph in a document.
Run it on every change, a Terraform plan, a new resource, a config update, the same way you'd run unit tests in CI.
Fail the build, not the audit. A non-compliant configuration gets caught the moment it's introduced, when it's a code review comment, not six months later when an auditor finds it.
Emit evidence automatically. The same check that blocked (or passed) the change produces the log entry an auditor eventually wants to see, you're not reconstructing history, you're exporting it.

The practical effect: instead of "gather evidence for the audit" being a project, it becomes a report export, because the evidence was being generated continuously the whole time.

Five practices, condensed

Map which rules actually apply, based on data held, industry, customer locations. Card data → PCI DSS. Health data → HIPAA. EU customers → GDPR. Get this wrong early and you discover a missing requirement mid-audit, which is the expensive way to find out.
Build compliance in by design, residency, encryption, and access controls set to match obligations before workloads go live, not retrofitted.
Automate with compliance-as-code, the pattern above.
Keep audit-ready evidence, access logs, config-change logs, kept in a tamper-resistant store automatically, not assembled on request.
Stay future-ready, new rules (2026 brought real movement on AI and data use) become an adjustment to existing policy-as-code, not a new program from scratch.

Case study: 5 weeks to 4 days

A US healthtech company needed SOC 2 Type II and HIPAA readiness to close enterprise deals, but their compliance process was entirely manual, every audit meant weeks of gathering screenshots and spreadsheets, with gaps surfacing late enough to threaten deals already in motion. Six-month program, run as a co-build:

Problem	What we did	Outcome
Unclear obligations	Mapped SOC 2 and HIPAA controls to the platform	A clear, owned control set
Manual, fragile compliance	Compliance-as-code with continuous checks	Gaps caught the day they appear
Slow audit prep	Automated evidence collection and trails	Audit prep: 5 weeks → 4 days
Patient data protection	Encryption, least privilege, access logging	SOC 2 Type II + HIPAA readiness, zero findings

The sales team stopped losing deals to security questionnaires once "can you prove it?" became a report export instead of a scramble, which is the actual business case for treating compliance as a pipeline problem instead of a paperwork problem.

FAQ

Does compliance-as-code replace the need for an actual audit?
No, you still need the external audit. What changes is the prep: evidence that was being generated continuously means exporting a report instead of weeks of reconstruction.

What's the first thing to automate if we're starting from manual compliance?
Access logging and config-change tracking, the evidence-collection side pays off immediately regardless of which framework you're targeting, and it's usually the slowest part of any audit.

Does this only work for one framework at a time?
The opposite, it scales better with more frameworks, because the underlying controls (encryption, access control, residency) get defined once in code and mapped to multiple frameworks' requirements, instead of being re-documented from scratch for each one.

Originally published on the Sherdil Cloud blog, the full piece (with the complete frameworks table and four-stage compliance build) is here. For the security foundation this builds on, see cloud security 2026 best practices; for the pipeline this plugs into, CI/CD in 2026.

Follow One Request From the Browser to the Database (And Every Check It Should Hit)

Sherdil Cloud — Fri, 25 Sep 2026 11:20:49 +0000

TL;DR: A secure web architecture isn't one control, it's the path a request travels: edge (CDN, WAF, DDoS), load balancer (TLS, health checks), stateless app tier (least-privilege roles, input validation), private data tier (encryption, backups), and an identity layer verifying everything. The data tier sits deepest so an attacker has to defeat every layer in front of it first. A Lahore EdTech platform rebuilt this way handled 22x exam-day traffic with zero downtime and zero critical findings in a security review, reliability, scale, and security came from the same architecture, not three separate projects.

The most useful way to think about web security isn't a checklist of controls, it's a request's journey. A user's click travels inward through layers, and each layer's job is to check, filter, or scale something before passing it on. Get the layering right and performance and protection come together; get it wrong and you bolt security on afterward and pay for it in latency and gaps.

The path, layer by layer

Layer	Its job	Key controls
Edge / CDN	Serve content fast, absorb attacks	CDN, WAF, DDoS protection, rate limiting
Load balancer	Spread traffic across healthy servers	TLS termination, health checks
Application tier	Run the app logic	Stateless services, least-privilege roles, input validation
Data tier	Store and serve data	Private subnets, encryption at rest, backups
Identity	Control who can do what	Zero trust, MFA, least privilege

The design property worth internalizing: data sits deepest. A request passes the edge, the load balancer, and the application before it ever touches the database, and each step checks and filters it. Because the data tier never faces the public internet directly, an attacker can't reach it without first defeating everything in front, which is why "public database" and "open bucket" show up at the top of every breach post-mortem.

Five principles that make the layers work

#	Principle	What it does
1	Defense in depth at the edge	Filters and absorbs attacks before they reach the app
2	Encrypt everything	TLS on every connection, encryption at rest by default
3	Zero-trust identity	Verify every request, grant least privilege
4	Scalability by design	Stateless services scale out under load
5	Reliability by design	Redundancy and failover keep it online

Two of these deserve a note for engineers. On principle 1: the edge isn't just a performance layer, a WAF blocking OWASP Top 10 patterns means your application servers only ever process clean traffic, which is a security win and a capacity win. On principle 4: keeping the app tier stateless (no session pinned to one server) is what makes the load balancer and autoscaler actually useful, and it's the same property that lets a traffic spike become a routine scale-out instead of a crash. Security and scalability share this one architectural decision.

Four mistakes behind most web breaches

Mistake	Why it's dangerous	The fix
Public databases or open buckets	Data exposed directly to the internet	Private subnets; deny public access by default
No web application firewall	App-layer attacks reach code directly	Add a WAF, address the OWASP Top 10
Over-permissive access	One stolen account reaches everything	Least privilege + zero-trust verification
Missing/weak TLS and insecure config	Data intercepted; servers ship insecure defaults	TLS everywhere; harden with CIS Benchmarks

Note that TLS is effectively free now (Let's Encrypt and managed certificate services with auto-renewal), so treating unencrypted data anywhere as a defect to fix rather than a trade-off to weigh is the right default.

Case study: exam-day traffic, 22x

A Lahore EdTech platform ran online exams for schools. Twice a term, on exam day, traffic jumped more than twentyfold and the site slowed or crashed exactly when it mattered most. It also held sensitive student data with no firewall at the edge and some services running with far too much access. They needed reliability, scale, and security at once. Five-month co-build:

Problem	What we built	Outcome
Crashes on exam day	Stateless app tier, load balancing, autoscaling	Handled 22x traffic, no downtime
No edge protection	CDN, WAF, DDoS protection at the edge	Attacks blocked before the app
Exposed data, broad access	Private subnets, encryption, least-privilege roles	Passed security review, zero critical findings
Partial, weak TLS	TLS on every connection, auto-renewed certs	100% of connections encrypted

The lesson the team took away: reliability, scale, and security weren't three projects. Because they were built into the same layered architecture, the platform sailed through exam day and the security review at once.

FAQ

Is a WAF enough on its own?
No, it's one layer. A WAF blocks common app-layer attacks, but it doesn't replace private data tiers, least-privilege roles, or encryption. Defense in depth means each layer assumes the one in front of it might fail.

Why is statelessness a security topic and not just a scaling one?
Because the same property that lets any server handle any request also lets you replace a compromised or unhealthy server without losing session state, it makes both scale-out and incident response easier.

Where do most teams get the layering wrong?
Putting the database somewhere reachable from the public internet "temporarily" and never moving it. Data tier in private subnets from day one is the cheapest control on this list.

Originally published on the Sherdil Cloud blog, the full piece (with the complete layer and principle breakdown and the four-stage build) is here. For the reliability layer, see resilient cloud infrastructure; for the container layer that keeps the app tier elastic, containerization.

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.

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.