A good CI/CD pipeline is invisible. Code goes in, working software comes out. A bad one is a constant source of friction. The difference is mostly setup discipline.
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.
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.
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.
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. Related read: our post on Kubernetes introduction covers the flip side of this.
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.
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.
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.
None of this is rocket science. It's the accumulation of small good decisions, made consistently, over time. The teams that win at this aren't the ones with the cleverest tactics. They're the ones that keep showing up, doing the fundamentals, and improving a bit each quarter. That's the whole secret, and it's also why so few actually do it. The temptation to chase the novel and the exciting is real. The discipline to keep doing the boring work that actually produces results is rare. If you've read this far, you probably have the temperament to be one of the ones who makes this work. Start with one thing from the checklist above, ship it this week, and build from there.
Closing thought: everything we've written here comes out of actual client work, not theory. If you try something based on this post and it doesn't work the way we described, that's a useful data point — both for you and for us. We'd be curious to hear what happened, either way.
Frequently Asked Questions
Should I use GitHub Actions or GitLab CI or something else?
Use what matches your code host. If you're on GitHub, GitHub Actions. GitLab, GitLab CI. Both are excellent in 2026 and the feature parity is high. The friction of using a different CI from your code host is rarely worth the marginal feature differences. Switching costs money and time.
How fast should our CI pipeline be?
Under 10 minutes is excellent. Under 20 minutes is acceptable. Above 30 minutes starts hurting developer flow significantly. Long pipelines reduce how often developers run them locally, increase context-switching, and slow down the fix-deploy cycle when things break. Invest in making CI fast.
Should we automatically deploy to production?
For mature teams with good test coverage and observability, yes. For teams without those foundations, gate production deploys with manual approval. The right answer depends on your confidence in catching issues before they reach users, not on dogma. The goal is fast safe deployment, not automation for its own sake.
What security practices matter most in CI/CD?
Pin actions or plugins to specific commit SHAs not tags (tags can be moved). Use OIDC for cloud authentication instead of long-lived credentials. Enable dependency scanning with Dependabot or Snyk. Scan container images before production. Branch protection requiring status checks before merge. Start with these five and you'll cover most real risks.
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 →
