Microservices in the age of AI

A common argument today is that microservices (and micro-frontends) are becoming less relevant because AI systems need full context to generate reliable code. Splitting an application into many services can make it harder for an AI agent to understand and modify the system as a whole.

There is some truth to this, but the problem is often misunderstood.

The real issue is not microservices themselves. It’s that most AI agents don’t have access to a complete, runnable environment. AI coding agents currently write code based on static context: files, prompts and partial views of a repository. They can’t run the full system, interact with real services, or validate changes end-to-end. That’s where things break down.

A different approach

Instead of adapting your architecture to fit AI limitations, a better approach is to give AI agents access to real environments. In this way, they can run the system, test changes across services, and validate behavior against real dependencies, exactly as a developer would.

That’s the problem GetWebstack was built to solve. One command spins up a full production-like environment for your application including all services and databases. Each environment is isolated and fully functional, whether it’s used by a developer or an AI agent iterating on a feature.

Microservices aren’t the problem. Blind agents are.

Definitions, principles, and how they can help you

Intro

Technical startups, by definition, aim to grow fast. The start is usually very accelerated and the focus is on product features, not on the quality of the code base. We can compare this phenomenon with fast food. They have the same urge to be ready and delicious to please all the clients in the shortest time possible. In the long run, this speed can become unhealthy. Successful projects grow fast and clients demand more and more functionalities. Developers’ focus is on implementing new features as fast as possible. That’s the recipe for creating a monolithic, dinosaur project. It becomes too slow for the user experience and too big to improve in a competitive amount of time.

Tech teams and founders can avoid this problem with a good start. Consider from the beginning all the possible parts or components of the application. Even though the business plan is long-term, it helps structure the technical part so it has a good base for future features. This means using technologies like containers, serverless applications, and Kubernetes. The architectural choices are essential. Such a choice represents structuring the technical product in micro-apps, micro-services, and micro-frontends.

In this article, we’ll talk about these concepts and you’ll see how they change the game of software development.

1. Microservices

This is an architectural approach that became popular in the last couple of years. The concept is to break the big and complex applications, known as monoliths, into small and independent services. From the outside, they are black boxes that hide all the unnecessary information and implementation details.

One microservice encapsulates one business functionality. Then it makes it accessible to other services via network endpoints. Microservices communicate and send messages using APIs, event triggers, or other channels. Being completely independent, we can change and release a microservice all alone. It needs to assure backward compatibility and not affect the current consumers.

Let’s see a list of 4 key concepts of microservices as we can find them in “Building microservices” by Sam Newmann.

a. Independent deployability

A change in a microservice should not depend on or impact any other microservice. A microservice can be changed, deployed, and released every time is required. It’s a key that assures that the microservices are loosely coupled.

b. Built around a business logic

As said earlier, a microservice solves a single business scope. We prioritize the business scope over the technical one. It helps to recombine the microservices in different ways to deliver new functionality. In practice, it means moving from the 3-layer architecture (frontend, backend, and database team) to multiple independent microservices teams. Each of them takes care of a different business feature.

c. Owning their own state

It means avoiding or eliminating shared databases. Each microservice has full access to its database. In case it needs data from another microservice’s database it needs to request it explicitly. The reason behind this is to completely separate the data that can be shared from the data that cannot. It also reduces the need for backward-incompatible changes.

d. Size

There is no physical size recommended for microservices. Even though the name contains the term “micro”, it was not meant to impose any size restriction. The recommendation is to be easily understood and as small as possible.

There are 2 numbers that you can think of:

• how many microservices you can handle
• how strict you want to be in terms of their boundaries without letting them be too coupled

2. Micro-frontends

The same as microservices, micro-frontends represent an architectural concept recently developed. Before that, the norm was to build a single-page monolithic application that interacts with a set of microservices. To avoid code conflicts, usually, one single team was in charge of the development. Unfortunately, this type of architecture cannot be easily improved in the long term. Especially, it is not for products built to be used for many years with frequent releases made by distributed teams.

The new trend is to offer the best user experience and to provide an easy path to do what the users want to do—all without losing the quality of the services.

Micro-frontends break the monolithic frontend into separate frontend applications. These applications are owned by independent teams who take care of a single business aspect. The micro-frontend architecture follows the same principles as microservices. On top of that we can add 2 more:

a. The automation

A strong culture of automation eliminates a lot of problems. Each micro-frontend is a separate project that has hundreds of different parts. We need to assure continuous integration and deployment and fast response to feedback. The automation requires a lot of time but doing it from the beginning of the project it saves time later.

b. Decentralized governance

Each team working on a micro-frontend has the decision power over that micro-frontend. It allows them to choose which technologies and tools to use to do the job. The tech leadership can always offer the guidelines that align teams, but they should not be a blocker in the decision-making process. This approach empowers the teams and becomes essential for introducing new successful practicing.

3. Micro-apps

Putting together microservices and micro-frontends, we end up having the final concept of micro-apps.

A micro-app is a specialized application meant to serve a single, well-defined business task. It follows the principle of single responsibility that reduces the complexity of old fashion monolithic applications. A micro-app can include a frontend, a backend, or other services that serve a single scope.

Benefits

All three concepts follow one main principle of breaking down the big and complex applications. The scope is to make software applications easier to develop, maintain and scale.

The separation of code into micro projects splits the development across teams. It empowers them to take ownership of the project and to choose the right tools. It allows the automation of testing and individual releases without creating code dependencies.

We can also add the reuse of the same functionality in different places. Think of how you need a blog app added to each of your projects. You create a micro-app for the blog and reuse it in all projects.