Architecture choices should follow the system, team and operating model. They should not follow fashion. Many companies hear that microservices are modern and monoliths are outdated, but the reality is more practical: a well-structured monolith can be easier to operate than a poorly designed distributed system.
The right question is not “monolith or microservices?” It is “which structure lets this system change safely, operate reliably and support the business?”
The monolith is not always the problem
A monolith is a single deployable application. That can be a problem if the codebase is tangled, deployment is risky and every change affects the whole system. But the monolith itself is not automatically wrong.
A modular monolith can be a sensible architecture when:
- the team is small;
- the domain is still evolving;
- deployment simplicity matters;
- operational capacity is limited;
- strong module boundaries can be maintained;
- the business does not need independent scaling of many components.
For many small and mid-sized companies, operational simplicity is a feature.
Microservices create new responsibilities
Microservices can help when parts of a system need independent deployment, scaling, ownership or technology choices. But they introduce complexity: service communication, network failure, data consistency, observability, deployment orchestration, testing and operational monitoring.
A company should not split a system into services unless it is ready to operate a distributed system.
Useful questions include:
- Does the team have the capacity to monitor multiple services?
- Are domain boundaries clear?
- Do services need independent release cycles?
- Is there a strong reason for separate scaling?
- Can the data ownership model be made explicit?
- Will the integration overhead be worth it?
Hybrid is common
Twoday’s testing strategy for hybrid monolithic/microservice applications points to a common reality: many modernisation efforts pass through a hybrid state. Part of the system remains in the monolith while selected capabilities move into separate services.
This can be a good transition path, but only if testing, feature toggles, data synchronisation and deployment are handled deliberately. A hybrid architecture can reduce risk when planned well. It can also create the worst of both worlds if responsibilities are unclear.
Use modernisation paths, not labels
Twoday’s application modernisation material references multiple routes such as rehosting, replatforming, rearchitecting, rebuilding and replacing. This is useful because it moves the conversation away from one architecture label.
A practical roadmap might include:
- stabilise deployment first;
- extract one high-change capability;
- improve test coverage around critical workflows;
- build an API layer;
- move reporting to a separate data pipeline;
- keep the core system as a modular monolith;
- replace a non-differentiating subsystem with a product.
Modernisation is not a single architectural ideology. It is a sequence of risk-reducing decisions.
The operating model decides
Architecture that cannot be operated responsibly is not modern. Before introducing more moving parts, review:
- deployment process;
- logging and monitoring;
- incident response;
- ownership;
- documentation;
- testing;
- backup and recovery;
- integration failure handling.
OpenTelemetry and SRE practices show why observability becomes more important as systems become distributed. More services mean more places where failure can happen.
Memory(One) perspective
Memory(One) should help companies choose architecture based on evidence: business workflow, change pressure, team capacity, data ownership and operational risk. Sometimes the right answer is a cleaner monolith. Sometimes it is a selective extraction. Sometimes it is a platform or integration layer. The goal is maintainable software, not fashionable architecture.
Sources and inspiration
- Twoday — Testing strategy for hybrid monolithic/microservice applications: https://www.twoday.com/blog/testing-strategy-for-hybrid-monolithic-microservice-applications
- Twoday — Modernization of applications: https://www.twoday.com/blog/modernization-of-applications
- Novicell — What is composable architecture?: https://www.novicell.com/uk/latest-thinking/what-is-composable-architecture/
- Microsoft Azure Architecture Center — Strangler Fig pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
- OpenTelemetry: https://opentelemetry.io/