Featured
Incube8 · 2021–2022
Zero-downtime EC2 to EKS cutover with weighted traffic shifting
Problem Revenue-critical workloads had to move from legacy EC2 to Kubernetes (EKS) with zero downtime, and there was no safe way to prove the new platform under real production traffic before committing to it.
Approach Placed both the EC2 and EKS backends behind a single load balancer as two weighted target groups, then shifted live traffic in small, reversible steps from 0 to 10 to 20 percent. At 20 percent we detected a CoreDNS fault and immediately returned the weight to 0 to protect production, resuming the ramp only after the fix was in. We then held EKS at 50 percent for several days to validate it under real load, before stepping through 60, 70, 80 and finally 100 percent and decommissioning the legacy EC2 instances.
Result A fully controlled, zero-downtime migration with instant rollback at the first warning sign. The CoreDNS issue was contained before it reached users, the EKS workloads were proven under production traffic, and the legacy EC2 footprint was cleanly retired.
Featured
Incube8 · 2022
Re-architecting a legacy application into a cloud-native workload
Problem The application was not built for the cloud. It leaned on local state, ran expensive work inline on every request, and sent all database traffic to a single primary, which capped its reliability and performance as load grew.
Approach Partnered closely with the development team to reshape the application for cloud-native operation. Moved all static objects and uploaded files into S3 so instances stayed stateless, and added a caching layer where it mattered to take load off the hot API paths. Shifted expensive work to background processing by queuing request payloads on Redis and SQS. Split database access into separate writer and reader endpoints so read traffic moved off the primary, then scaled the Amazon Aurora read replicas to match demand.
Result A genuinely cloud-native application with high reliability and performance. It now runs independently inside the EKS cluster at better than 99 percent SLA, holding steady over time with no further feature or code changes.
Incube8 · 2021–2022
EC2 to Kubernetes platform migration
Problem 5+ revenue-critical applications on hand-managed EC2 with inconsistent, unauditable releases.
Approach Re-engineered Ansible deployment pipelines into Helm releases on EKS, with hardened base images and policy gates in CI.
Result 10 to 20 deploys per week, rollback in 15 minutes, and a single audit trail across environments.
Incube8 · 2022
Observability & reliability programme
Problem Incidents surfaced by users before monitoring, with no agreed service objectives.
Approach Unified Datadog, Prometheus/Grafana, ELK and CloudWatch; built endpoint-level monitoring; defined SLIs/SLOs and alert routing per tier.
Result MTTD down 50%, MTTR down 40%, and 2 repeat incidents eliminated.
Incube8 · 2024
Pipeline & runtime security hardening
Problem Inconsistent base images and long-lived IAM credentials across 15 services, with findings surfacing only in production.
Approach Set golden base images, moved scanning left into CI, extended CrowdStrike runtime coverage, and replaced static IAM users with scoped service roles.
Result Critical image findings down 50%, static credentials retired across 12 IAM accounts, least-privilege across 15 services.
Incube8 · 2025–2026
AWS Security Hub remediation programme
Problem A large backlog of high and critical Security Hub findings across workload accounts, with no owner or triage process.
Approach Triaged by severity and control, grouped into repeatable remediation patterns, drove fixes with owning teams, and folded controls into account baselines.
Result 1,000+ high and critical findings closed across multiple accounts, with a sustained remediation cadence.
Incube8
Safe large-table updates without locking production
Problem Running a single update across a table of millions of rows locked the table and risked out-of-memory errors, which could stall or disrupt the production system.
Approach Worked with the developers to replace bulk single-query updates with a chunked loop that reads and updates 500 to 1,000 records at a time, so each small batch commits quickly, the table is never held under a long lock, and memory stays bounded.
Result Developers gained practical knowledge for handling large data sets, and we can now run patches and update queries against production tables with no downtime or locking.
Incube8
Shared library for handling read-replica replication delay
Problem Reading from the reader replica could return stale data because of a few milliseconds of replication lag behind the primary, so an application reading a record right after writing it might not see the latest value.
Approach Built a shared library so teams could handle replication delay consistently, with a few strategies to choose from. One retries the read against the replica after a short wait. Another falls back to the primary when fresh data is required. A third writes the value to a Redis or Memcached cache key and serves later reads from the cache instead of the database. Each application picked the approach that matched its consistency and performance needs.
Result A reusable, tested way to handle read-after-write consistency across services, so teams kept the reader-scaling benefits without stale-read bugs and no one had to reinvent the fix.
