Improving Microservice Architecture: A New Approach to Simplify Development and Testing

Microservices Pitfalls

Microservices have been a buzzword for quite some time now, and many organizations have already adopted this architecture pattern. However, there are still some concerns about the current approach to building microservices. In this blog post, we’ll take a closer look at what’s wrong with the current microservice adaptation and explore a new approach to building microservices that can help solve some of these issues.

What’s wrong with the current microservice adaptation?

The problem with the current approach to building microservices is that we’re not actually building microservices. Instead, we’re building module-services, which are services that perform a single task, such as a file service, email/communication service, cache service, or distributed session service. While this approach can help break down monolithic applications into smaller, more manageable components, it doesn’t address the issue of data synchronization.

Each app having its own database introduces complexity of data synchronization, which leads to latency, difficulty in testing, and longer development time. This is because syncing data across multiple databases takes time, and if there are any discrepancies in the data, it can cause problems down the line. Additionally, testing becomes more difficult because you have to test each app’s database separately, which can be time-consuming and expensive.

The new approach: Modular UI with Distributed API

To address these issues, a new approach to building microservices is emerging: Modular UI with Distributed API. This approach involves building a single, master database that all apps can access. The API server is distributed, so multiple copies can be generated on-demand to scale. Additionally, sessions are managed centrally on a Session Server, such as Redis, which makes it easy to scale the API server.

The API server can be built using Python, which makes development faster and easier.

Modular UI is another key component of this approach. Instead of each app having its own database, the UI is built modularly, with no database at all.

Benefits of the new approach

There are several benefits to using the Modular UI with Distributed API approach:

  • Only a single master database is required, which is the database we know and trust. There are no synchronization issues, and no migration or duplication of data is necessary.
  • The API server is distributed, so it’s easy to scale as needed. Additionally, sessions are managed centrally on a Session Server, making it easy to scale the API server.
  • The API server can be built using Python, which makes development faster and easier. A pilot implementation of this approach is already in use on live servers through the ecpy project.
  • The UI is built modularly, which means there are no databases to sync. This makes testing easier and less expensive, and it simplifies development.

Conclusion

While microservices are still an important architecture pattern, the current approach to building them has some limitations. The Modular UI with Distributed API approach offers a new way of building microservices that can help address some of these limitations. By using a single master database, a distributed API server, and a modular UI, developers can create microservices that are easier to develop, test, and maintain.

/by