As Head of Technology in JAM’s Asia office, I oversee modernisation projects for partners in Singapore and beyond. And in today’s modernisation landscape, this means I’m working largely with platforms benefiting from the savings, efficiencies and security improvements that come with loosely-coupled cloud application designs.
But, in my own experience, and from my wider involvement with Singapore’s technology sector, I do see a recurring theme in the discussions that take place during the middle stages of these modernisations, when services begin to be decoupled:
- Costs are too high
- We’re delivering features slower – not faster
- Our governance is becoming too complex
Our own cloud architecture design services and existing application modernisations are built with this in mind. We both educate in the discovery phase and mitigate to the extent we can during the build.
In this post, however, I want to address the Singapore cloud-native community beyond our partners, and offer some guidance on both how to communicate these issues and soften their impact.
Rising cloud costs
Why this occurs during decoupling
During the transition phase, the legacy monolith and its new microservices may run side-by-side.
Each new service will have its own baseline CPU, memory, logging and security stack. In addition, you now have inter-service calls, cross-zone and data-transfer fees (cross-zone egress is charged on AWS and GCP, but is typically free inside a single Azure region).
These temporary overlaps make the monthly invoice look worse before it gets better.
How to address the concern pre-project
Engage stakeholders early on. Often, forecasting an expected cost spike (within a generous range for error) and a projected saving once the period of concurrence ends can prevent friction down the line.
How to minimise the impact mid-project
Autoscale/scale-to-zero on all new services (where workload type allows) – pay only for their partial-traffic moments while the monolith still handles the rest.
Tag every duplicated resource and publish a live “overlap spend” dashboard – real-time visibility lets each squad prune costs sprint-by-sprint.
The strangler fig pattern – just like how a strangler fig tree grows around a host tree and eventually replaces it: identify the most resource-intensive modules in the legacy system that can be replaced.
Set and enforce retirement dates for each legacy module – use feature flags to disable a legacy module the moment its replacement has proved stable, and then scale down the resources for the legacy system accordingly.
Ultimate benefit
After overlap, every service carries only the capacity it needs. Unused resources disappear automatically. This turns cloud spend into a direct, predictable reflection of real traffic and removes the blanket over-provisioning costs of the legacy stack. This will free up budget for new features.
Slower delivery velocity
Why this occurs during decoupling
The monolith’s single codebase often becomes several repositories, pipelines and review flows. Teams spend more time wiring build steps and coordinating merges. This is time that could go into feature release. Hence, it appears to the team that modernisation has slowed rather than accelerated their schedule.
How to address the concern pre-project
Forecast an initial dip in release frequency on a velocity chart and agree a rebound milestone; framing the slowdown as expected allows this period to be planned for by the client.
How to minimise the impact mid-project
Generate a “service starter kit” – roll out a one-command scaffold that creates repo, CI pipeline and basic monitoring for any new service, cutting setup to minutes.
Introduce a shared release dashboard – show live pipeline status for all services so teams can spot blockers without extra meetings.
Bundle low-change code together temporarily – if two slices always change together, keep them in one repo and pipeline until traffic or ownership justifies a split, treating the bundle as a stepping stone toward full independence.
Use feature flags – feature flags allow independent microservices to be deployed without exposing the new features until dependent services are ready. This ensures deployments are uninterrupted technical operations while feature release becomes a business decision.
Ultimate benefit
Once tooling stabilises, each service can be released on its own schedule: smaller, safer changes ship faster and incidents affect only one domain.
Governance burden
Why this occurs during decoupling
Each new microservice has its own security, compliance, and change-management concerns. While in the monolithic architecture, one approval gate sufficed, there are now dozens of endpoints, policies, and audit artifacts. This added work can make the entire project feel heavy, especially when added to the pre-existing governance need the team is still dealing with.
How to address the concern pre-project
Flag that governance tasks will briefly double while old and new stacks overlap, and agree up-front who owns each review and which controls can be shared; this keeps the extra load visible and time-boxed. Remind your team that this is only a temporary pain for a long-term gain of significantly improved security.
How to minimise the impact mid-project
Centralise controls in an API gateway/service mesh – while legacy and microservices coexist, one gateway enforces auth, TLS and rate-limits across north-south traffic and microservice east-west calls; monolith internal calls remain inside its own process, so reviewers approve a single layer not dozens; retire or slim it once the monolith is gone.
Adopt policy-as-code templates in CI – during overlap, new pipelines trigger manual checks; OPA rules let compliant builds auto-pass, leaving only real exceptions for auditors and avoiding dual-stack release queues.
Publish a self-service compliance checklist – teams on either stack complete a short questionnaire mapped to current controls, giving auditors needed evidence without extra meetings; scope it to the overlap window, then fold into routine pipeline gates later.
Ultimate benefit
With controls codified once and inherited everywhere, review cycles shrink and audits trace policy to implementation in minutes. Security posture strengthens while teams regain the agility promised at the project’s outset.
How we can help
I hope this allows others in Singapore’s cloud-native community to better navigate the difficult middle phase of modernisation, where overlapping microservice and monolithic functions can make it seem as though the initial project goals are being delivered in reverse.
At Just After Midnight, we’ve helped teams in Singapore and around the world achieve their goal of a decoupled, modern architecture while minimising and planning for the difficult mid-project periods.
If you’re facing similar challenges or planning a modernisation project, we’d love to talk. Drop us a line and we’ll get back to you in no time.
