Go to content
Microservices arkitektur rød header

Solution Architecture

Building a Dynamic IT Landscape with Microservice 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.

What are microservices?

Microservices are small, standalone pieces of software with a single goal of executing code. Unlike a software monolith, the execution of processes is broken down into small independent pieces of software, each with full autonomy over its own process and a clear delineation of the purpose of that specific process.

Advantages of microservice architecture

  • a logic map and a pen icon

    Best practice software regardless of technology

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

  • a raising chart icon

    Continuous system replacement

    Build your architecture to be able to replace systems continuously and at different paces.

  • Budget

    Robustness - one failure doesn't bring everything down

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

  • a taking off airplane icon

    Performance optimisation and scalability

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

  • a file with a speed watch icon

    Time to market

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

  • people connections icon

    Greater efficiency

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

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 | 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.


2 | Redirect calls to the new microservice

Once you have ensured that the service satisfactorily solves a specific task in the monolith, you can redirect relevant calls in the facade from the legacy software and execute production calls to the new service instead.


3 | Continue establishing independent microservices

And that's how you proceed. One process at a time, moving out of your legacy software and establishing it as an independent microservice.