Solution Architecture

Does the architecture lock down the business?

With an evolutionary approach to IT architecture, you can gradually integrate new systems, whether it's systems that need replacement due to obsolescence or new systems required as your setup requirements change. For example, the need for a Product Information Management (PIM) system may arise as your e-commerce business matures.

How often do you deploy new code in the form of products, features, or systems in your IT setup?

Once a year? Once a month? Or once an hour? If you don't know, you can probably imagine that there is a difference between releasing a year's worth of work at once or doing it continuously, perhaps even multiple times an hour. This difference applies to potential errors and troubleshooting, as well as development lead time. There is no doubt that most companies prefer continuous progress and early iterations that can be quality-tested and business-tested with users early in the process.

Advantages of microservice architecture

Best practice software regardless of technology

Microservices allow for technology diversity and the use of best practice software regardless of the technology.
Continuous system replacement

Build your architecture to be able to replace systems continuously and at different paces.
Robustness - one failure doesn't bring everything down

Through clearly defined interfaces, an error can be isolated from the rest of the services.
Performance optimisation and scalability

Unlike a software monolith, the performance of microservices can be optimized down to the individual service.
Time to market

Rapid deployment of new code and features. With microservices, you can deploy each service independently.
Greater efficiency

With microservices, you can naturally divide responsibilities among teams, allowing smaller teams to individually handle tasks from development to deployment.

Learn more about how we help companies with transition processes/digital roadmaps for solution architecture.

How do you phase out legacy software with microservices?

There are several variations of the method described below, but to keep the explanation simple, let's stick to the general principle of replacing a service or a piece of software.

1

1 | Build a facade

The first step in the strangler fig method is to build a facade that can receive and direct calls to services behind it. Initially, most calls will go to the monolith, which will then execute the call. By establishing a facade instead of directly calling the service, there can be two or more parallel services that can receive calls. The software monolith now becomes the "host" around which you can start building a strangler fig architecture, for now, sticking to the symbolism.