Why mWtech wrote this
Most teams mWtech works with have cloud-native development well in hand; the productivity story is real and not in question. Where architects and dev leads keep hitting friction is the boundary between new services and the systems of record that still run the business. This press release is mWtech's practical, architecture-level view on designing that boundary – so a cloud-native programme scales instead of collapsing into a distributed monolith.
Cloud-native development is the default now. A React front end, a set of Node.js or Java services, a PostgreSQL or MongoDB data store, packaged in containers and orchestrated with Kubernetes – this stack lets teams build, ship and scale faster than any previous architecture allowed. For new applications the components are mature, well understood and the productivity gains are real.
What trips up established enterprises is rarely the build itself. It is the collision between the new services and the core systems – databases, transaction platforms, mainframe and Adabas applications – that still hold the data and run the business. A React dashboard backed by a PostgreSQL read store is only as useful as the data feeding it, and in most South African enterprises, the most valuable data does not live in the cloud. It lives in systems of record that were never designed to be called by a fleet of containers.
Where cloud programmes stall
The pattern is familiar. The first cloud-native services ship quickly and demo beautifully. Then the second wave needs real data from the core, and the team reaches back the quickest way it can – a direct database call here, an overnight extract there, a point-to-point connection per service. It works at first. Then the connections multiply, load on the core climbs, data consistency drifts and the elegant micro-service architecture is quietly coupled to the very monolith it was meant to move beyond.
The cloud-native part was never the problem. The problem is that nobody designed the layer in between – the part that lets fast-moving services talk to mission-critical ones safely and repeatedly.
What enterprise-grade cloud-native really needs
Doing this properly is less about the cloud platform you choose and more about four disciplines that decide whether a programme scales or seizes up:
- An anti-corruption layer, not point-to-point calls. Core systems should sit behind governed, re-usable APIs and event streams that isolate new code from the data model of the source. An anti-corruption layer keeps mainframe and Adabas semantics from leaking into your micro-services, so a Node.js or Spring Boot service consumes a clean contract rather than binding to a legacy schema.
- Event-driven, with change data capture. Polling a busy core synchronously does not scale. Capturing changes off the source and streaming them onto a log lets services react to events and decouples read paths from the system of record. A PostgreSQL or MongoDB read model is then kept current from that stream rather than querying the core directly – fast reads for the React layer, no extra load on the core.
- Resilience and distributed-transaction discipline. Containers are disposable and networks fail by default. Timeouts, retries with backoff, circuit breakers and bulkheads are table stakes – and where a business process spans services and the core, sagas with compensating actions matter more than pretending a distributed two-phase commit will hold.
- Security and observability as first-class concerns. Authentication and authorisation (JWT and OAuth2/OpenID Connect), proper secrets handling and end-to-end tracing belong in the design, not a later hardening sprint. The service-to-core boundary is usually where the hard latency and failure modes hide, so it is the part most worth instrumenting from day one.
Build for where you are, not where the demo is
The cloud-native success stories that circulate are usually greenfield – a start-up with no legacy and nothing to integrate. Established enterprises are not greenfield and lifting that playbook wholesale is how good architecture decays into a distributed monolith. The more honest pattern is incremental: a strangler approach that stands new cloud-native services in front of the core and migrates capability behind a stable interface, rather than a big-bang rewrite that bets the business on one cut-over. Cloud-native development and core integration are one design problem, owned together – not two backlogs that meet for the first time at the integration test.
How mWtech helps
This is the seam mWtech works in. For over a decade, the company has connected modern applications to the core systems that run South Africa's largest enterprises – and it architects and builds cloud-native services with that integration reality designed in, not bolted on afterwards. mWtech's engineers work the full stack: React on the front end, Node.js and Java with Spring Boot for services, PostgreSQL and MongoDB for data, containerised and orchestrated on Kubernetes – on one side; and mission-critical databases, transaction systems and Adabas and Natural estates on the other. That means the API, event and anti-corruption layers between them are designed deliberately rather than discovered under load.
mWtech's professional services cover the full path: target-architecture and reference design, the integration and event backbone, and hands-on build alongside your teams – whether you are standing up a cloud-native programme, scaling one that has begun to strain, or exposing a core system to new services for the first time. Speak to mWtech about a cloud-native architecture built for your enterprise as it is.
Share
Editorial contacts