DevOps in 2026 looks different from DevOps in 2018. Some things we used to preach have become table-stakes, others have quietly fallen away. Here's what's still worth doing.
Security and Compliance Get Harder, Not Easier
Cloud platforms have excellent default security, which is different from your usage being secure. Misconfigurations — open S3 buckets, overly permissive IAM roles, security groups with 0.0.0.0/0 — are the single biggest cause of cloud security incidents. Platform features that would catch these exist. Most teams don't enable them until after a close call.
For regulated workloads, there's additional paperwork: shared responsibility documentation, DPA agreements, residency commitments. The big three clouds have all of this. Smaller providers may not. Don't find out after signing a contract.
Cost Isn't What You Think It Is
Cloud bills surprise people in two directions. One: you end up paying more than the on-prem alternative, usually because you didn't right-size or didn't reserve capacity. Two: a single misconfiguration in an auto-scaler or a data transfer pattern creates a spike that would pay a junior engineer's salary for a year.
The discipline around cloud cost is real work. Tools help — Cost Explorer, CloudHealth, third-party FinOps platforms — but the actual savings come from having someone whose job includes weekly cost review and action on what they find.
The Decision Most Teams Make Too Casually
Cloud platform choice and cloud architecture are decisions you live with for years. And yet, we see teams make them based on what their senior engineer happened to use at their previous company. Sometimes that turns out fine. Sometimes it doesn't.
A little discipline up front pays for itself. Write down your actual requirements. Compare realistic scenarios, not marketing comparisons. Factor in the talent market for your region. Factor in the ecosystem of tools and integrations. Then decide.
The FinOps Discipline
Cloud bills are famously variable. Without discipline, they drift upward quarter over quarter as engineers spin up resources faster than anyone tracks them. The teams that keep costs under control treat cost as a first-class operational concern, not a monthly finance problem.
Concrete practices that work: weekly cost review meetings with at least one senior engineer present, tagging policies that actually get enforced, alerts on unusual spend within 24 hours, and a named person whose job includes cost optimisation. None of this is hard. All of it gets dropped when everyone is busy shipping features. Related read: our post on AWS migration checklist covers the flip side of this.
What We Tell Teams New to Cloud
Start simpler than you think. A small EC2 instance or a managed container platform will get you further than you expect. Add complexity when a specific problem justifies it, not because a conference talk made it sound exciting. Most teams that run Kubernetes probably shouldn't. Most teams that run twenty microservices could ship faster with three.
The cloud rewards discipline, not complexity. The teams we see doing best are unglamorous ones: clean Terraform, boring infrastructure, and a clear list of things they'd explicitly chosen not to do yet.
The Mistake of Migrating Without Rebuilding Some Things
Lift-and-shift to the cloud, by itself, is rarely the optimisation that pays off. You're usually running the same architecture, just at higher cost in a different data centre. The savings come from rebuilding parts of the workload to use cloud-native patterns: managed databases instead of self-hosted, queues and events instead of polling, auto-scaling instead of over-provisioning.
The usual rhythm is: lift-and-shift to get off the old infrastructure and out of the contract. Then, over the following six to eighteen months, rebuild the parts that benefit most from cloud-native redesign. The mistake is treating step one as the end state.
Reliability Patterns That Survive Contact with Reality
Every cloud architecture diagram looks reliable. The reality of reliability is harder. Real outages come from surprising places: DNS resolution failures in specific regions, hitting account-level quotas during traffic spikes, cascading failures when a dependency you forgot about goes down.
The patterns we rely on: everything critical has a second path (backup region, alternative service), timeouts and circuit breakers on every network call, chaos testing at least quarterly, and runbooks for the failure modes you've actually seen. Reliability is a practice, not an architecture.
The Cloud Landscape in 2026
Cloud maturity has reached a specific point where the conversations have shifted. Pure cost arbitrage versus on-premise is usually settled — most net-new workloads go cloud-native, period. The interesting conversations now are about optimisation within cloud: FinOps practices, architectural patterns that avoid over-spend, choosing between serverless and containers based on specific workload characteristics.
The big three cloud providers (AWS, Azure, GCP) continue their parallel evolution with slightly different centres of gravity. AWS remains the broadest. Azure continues to win Microsoft-centric enterprises. GCP's data and AI tooling continues to lead on specific dimensions. The multi-cloud debate has mostly settled — most companies run primarily on one with occasional workloads on others.
What's changing most is the edge of the cloud experience. Cloudflare Workers and similar edge platforms are moving real application code closer to users. Hybrid patterns — some workloads on the primary cloud, some at the edge — are becoming standard for performance-sensitive applications. Choosing where each piece of your workload runs is now a meaningful architectural decision in its own right.
A Few Cloud Myths to Dispel
One: 'cloud is always cheaper'. Not always. Without optimisation discipline, cloud bills can exceed equivalent on-premise costs. Done well, cloud is cheaper; done poorly, it isn't.
Two: 'we need multi-cloud for resilience'. Usually overkill. Multi-cloud adds significant operational complexity that most businesses don't need. A single primary cloud with proper multi-region setup is resilient enough for the vast majority of use cases.
Three: 'we need Kubernetes'. Probably not, unless you've specifically identified a need it uniquely solves. Simpler compute options (managed containers, serverless) cover most real workloads with less operational burden.
A Migration We Learned a Lot From
In mid-2025 we migrated a financial services client from a colocated data centre to AWS. About 40 servers, a mix of application, database, and reporting workloads. Eighteen-year-old infrastructure, accumulated customisation, documentation that was 60% accurate on a good day.
The migration took seven months. Not because the technology was hard — AWS tooling for this is genuinely excellent. It took that long because discovering what the systems actually did, as opposed to what the docs said, required actual archaeology. We found services that hadn't been restarted in years, running on hardware that had outlived two sysadmins.
Lesson we took forward: the estimate for any legacy migration needs a chunky factor for discovery that nobody wants to talk about up front. If someone quotes you a timeline without a significant discovery phase, they haven't done this before.
The Short Checklist
If you take nothing else from this post, take this checklist. It's what we'd hand to someone just starting out in this area. None of it is revolutionary. All of it is worth doing. The compound effect of consistently doing these things, even without any other clever moves, is meaningful over a year or two. We'd rather see a team do the checklist competently than chase the latest trend while skipping the fundamentals.
- Tag every cloud resource with owner, project, and environment. Untagged resources become untracked costs.
- Set up budget alerts in your cloud console. Actually configure them, not just create them.
- Review IAM policies quarterly. Trim the cruft.
- Use managed services for stateful things (databases, queues) unless you have a specific reason not to.
- Keep production infrastructure in code (Terraform or equivalent). No clicky-click changes.
- Practice restoring from backups on a cadence. An untested backup is theatre.
- Tag every cloud resource with owner and project. Untagged resources become untracked costs.
- Enable MFA on the root/owner account and store those credentials in a locked vault.
- Set budget alerts at 50%, 80%, and 100% of expected spend. One alert at 100% is too late.
- Document disaster recovery steps. Don't assume the person who built the system will be around to recover it.
The rhythm we've settled on with every client is the same: get the fundamentals in place, then iterate. Every quarter we sit down with them and look at what's improved, what hasn't, and what should change. Not every quarter produces headline results. Every quarter produces learning. That's the thing that compounds over years. The work we're doing today with clients who've been with us for three or four years looks dramatically different from where we started together, because each quarter of iteration moved the bar a little. That's the right way to think about any of this. Not as a project with a defined end, but as a practice that gets better over time. Start. Measure. Adjust. Repeat.
Thanks for reading all the way to the end. If this was useful, the next most useful thing is usually to pick one concrete action from it and actually do it this week. Insight without action is just entertainment, and we suspect you've got better things to do than be entertained by a technology blog.
Frequently Asked Questions
Is 'DevOps team' a valid structure in 2026?
It's falling out of favour. Platform engineering (building internal developer platforms that product teams use self-service) is replacing the idea of a DevOps team that bottlenecks deployments. The outcome is similar but the structure is different — infrastructure-as-product rather than infrastructure-as-service.
How often should we be deploying?
High-performing teams deploy multiple times per day. Low-performing teams deploy monthly or less. Deployment frequency is the single strongest predictor of DORA metrics. If you're deploying less than weekly, there's something in your process that needs attention — even if the cadence itself isn't the problem, it's a symptom.
Do we really need CI/CD from day one?
For anything production, yes. The cost of setting up basic CI/CD is a few days. The cost of not having it is measured in production incidents, rollback drama, and engineer frustration. GitHub Actions with a basic workflow is the minimum bar. Fancier pipelines can come later.
What's the first DevOps improvement a small team should make?
Make deployments boring. That means automated, repeatable, reversible, and without drama. Once deployment stops being a stress event, everything else gets easier. Your cadence increases naturally. Your engineers stop fearing Friday afternoons. Your incidents resolve faster because rollback is a non-event.
Need help with your project?
Orange Essence Technologies builds e-commerce, software, mobile apps and AI solutions for clients across India and around the world. If any of this is relevant to what you're working on, we'd love to chat.
Get in touch →
