Microservices vs. Monoliths – In the scope of small teams

I regularly read and talked about microservices versus monoliths in software landscape solutions in the past weeks. Statements like "Microservices cannot be recommended for teams below 50 developers" or "There is too much overhead and too little benefit to migrating to microservices." Often heard about a widespread assumption that a single microservice must be maintained by a designated team for its own.

The following article will explain my view on this topic, why I prefer modern composable architecture like #MACH over #monoliths, and why this modern approach works for smaller to medium-sized companies very well.??

There is no versus - understanding composable architecture.

While the microservice and monolithic approaches are both basically standalone patterns, both can be deployed and fulfill their purposes independently. But modern solution architectures don't try to have a single standalone unit anymore; the key for modern flexibility, scalability, and fast-paced development lies in the composition of the most suitable technologies available, not just a single piece of technology. So to speak, today's demand is to have "the best of breed" in place for specific requirements.

In a composable architecture, the idea is to slice down the business- and technology domains into bounded contexts and smaller modules to assign isolated and specific services to fulfill roles. Microservices are first-class citizens for this approach but externally provided headless SaaS solutions can also be implemented to fill such positions.

In a nutshell, #MACH, which means?Microservices, API-First, Cloud-Native SaaS,?and?Headless, represents the ideal composition already by its very definition. A basic approach decouples the backend from the frontend, while an API exposes all functionality. In addition, cloud-native SaaS can also be implemented through API and outsource entire subdomains of your solution while you still control your system.

All services expose headlessly and have no UI or frontend; instead, multiple clients, frontends, apps, or IoT devices can communicate via API with the service layer.

Original: https://adrianstanek.dev/post/microservices-vs-monoliths-how-to-migrate-to-a-modern-architecture

Legacy monoliths can stay - at least for a while

During legacy system migration to modern architecture, keeping the established solution as part of the composition is still advisable to avoid significant overhead in costs and effort when tackling the complete solution at once.

In most cases, the complexity is aligned to the companies complexity, and it's recommendable to think about migration step-by-step by building up a MACH landscape around legacy and substituting the old system service-by-service.?

You should never lose the focus out of mind: The application is a solution for a problem; it should not become a problem because of too-tight development conditions and timelines.

A real-world example - How we approach?

In the last 15 years, we have built many monolithic eProcurement and eCommerce solutions for B2B customers. However, we have faced significant problems in the applications' performance and development process in the past three years. The applications became sluggish, and the codebase started to get way too large, so new features took way too long to implement. In addition, it was hard to onboard new developers, and existing team members started having their own niches in the codebase. Since we had a pretty small 2-pizza-team, it became a real problem for our company's future; at first, we thought about classically re-building the solutions but concluded that this approach would only lead to the same issues later.

We started to look into microservices and PWA and learned about the advantages of separating front- and backend. And this was the beginning of our future. As we realized that taking small steps by separating the concerns of our solutions into smaller pieces and starting to see those isolated, we gained speed in the development process again.

Keeping the legacy solution in place

The key for our small team was not to think holistic about our application anymore. Instead, we sliced our solutions down into small modules and started to develop on microservices and a combination of PWA and microfrontends, which were then deployed beside the legacy solution. A General-Purpose-API provided a secure communication layer between all moving parts and connected to the new landscape with the existing solution.?

So we started with new features by adding them in separate services. Later we began to migrate legacy functionality in microservices. So, finally, we've started to renew our solution landscape; there was light at the end of the tunnel again.

We were surprised at how fast we progressed after the fundamentals like container orchestration and lean CI/CD pipelines were in place. Of course, getting rid of legacy solutions is a long-term goal and is not done yet. But we already could tackle many pain points, which really made life hard for us. Those steps seemed to be impossible before microservices.

Problems gone, speed gained.

There were no new developer niches, performance bottlenecks, or onboarding problems since we use standardized frameworks, for instance, NestJs or NextJs. Furthermore, a single microservice will most likely stay clean and understandable since the isolation of the other pieces prevents overlapping dependencies, which later could lead to problems again. It's still isolated even with time advancing and a codebase in a single microservice that gets older than others. We stay free in our decision to upgrade a single service or migrate its functionality into SaaS, for instance.

There is no end - A new continuous journey began.

There is a goal to obliterate the legacy system, but this isn't a final goal. We already know that our solution will not become a legacy with the MACH in mind. Of course, we will progressively work on new features and substitute others. But the overall solution will never be a sluggish one again, and an upgrade of the system will never feel like a marathon again.

So our real goal was to establish a new way of developing our solutions progressively and continuously, without running into a dead end after some time again. For us, this is was a significant ingredient for keeping an agile development process.

Thank you for reading and your interest.