Monolith to Microservices

It is the gradual decomposition of a larger application into smaller services that own clear business capabilities and can be developed, deployed and operated independently.
The goal is not simply to create more applications.
The goal is to reduce unnecessary coupling so teams can change important parts of the system with less coordination and risk.

No.
Microservices introduce network communication, distributed data, observability, deployment and operational complexity.
A well-designed modular monolith can be the better architecture when the application does not need independent scaling, deployment or team ownership.
Thoughtworks specifically recommends modular monoliths in situations where the domain is still evolving or the additional operating complexity of microservices is not justified.
We recommend decomposition only where the expected business or engineering benefit is greater than that added complexity.

We start with the business domain rather than technical layers.
Domain-driven design helps identify bounded contexts such as orders, pricing, invoicing or customer management. We then examine code dependencies, data ownership, release cadence, scaling needs and team structure.
A good boundary allows a service to change and deploy independently.
If two proposed services constantly call each other or always have to be released together, the boundary is probably wrong. Microsoft uses exactly these tests in its current microservice-boundary guidance.

The Strangler Fig pattern modernizes an application gradually.
A routing or abstraction layer directs some requests to the existing monolith and others to newly extracted services. As more functionality moves, the responsibilities of the monolith become smaller.
After the old functionality has no remaining dependencies, it can be retired.
AWS and Microsoft both recommend this pattern for reducing the risk of large brownfield modernization programs.

This is often one of the hardest parts of the program.
Microservices should ideally own their domain data, but splitting a shared database too early can create difficult consistency and migration problems.
We first identify data ownership and access patterns. Depending on the situation, services may temporarily share existing data, use APIs around it or move domain data gradually using replication and change data capture.
Microsoft explicitly treats data ownership, schema decomposition, joins and integrity as major considerations during monolith decomposition.

No.
Microservices are an architecture style, not a Kubernetes requirement.
Services can run on Kubernetes, container platforms, serverless services, virtual machines or other runtimes.
Kubernetes can be useful when many independently deployable services need consistent scheduling, scaling and operational controls, but the runtime should follow the workload and operating model rather than define the architecture.

Independent services need a reliable path to production.
That normally includes CI/CD, environment provisioning, identity, secrets, monitoring, logging, security controls and a clear production support model.
Without these shared capabilities, application decomposition can create operational fragmentation.
This is directly supported by your SIXT engagement: the monolith-to-microservices program required a shared Kubernetes runtime, common CI/CD, monitoring and security architecture so extracted services had a consistent production platform.

We normally choose a capability with a clear business boundary, manageable dependencies and enough value to prove the modernization approach.
Edge capabilities with fewer dependencies can be good first candidates.
Microsoft recommends starting with such services because they are easier to separate and allow teams to validate the architecture and operating model before tackling deeply coupled domains.
The first extraction should prove more than code decomposition. It should prove deployment, monitoring, data handling, support and coexistence with the monolith.