Skip to main content





Understanding microservices

  • Edit
    Collaborate with us
    Edit this page on GitHub
  • Microservices (also known as the microservices architecture), according to James Lewis and Martin Fowler:

    is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

    With the hype of microservices and the fall of monoliths, it became clear that as the constituent services are small, they can be built by one or more small teams from the beginning, separated by service boundaries. All in all, this makes it easier to scale up the development effort.

    Microservices have many benefits... ...but come with additional burdens
    Strong Module Boundaries
    Microservices reinforce modular structure, which is particularly important for larger teams. The structure of a software system mirrors the communication structure of the organization that built it.
    Inter-process communication
    Dealing with network latency and hiccups, data marshalling
    Multiple transactions
    Handling and coordinating multiple independent commits
    Independent Deployment
    Simple services are easier to deploy, and since they're autonomous, are less likely to cause system failures when they go wrong. Continuous delivery becomes a must, as the organizations that do this can respond quickly to market changes and introduce new features faster than their competition.
    Fault tolerance
    Recovering from and handling communication errors and service consistency
    Limited data mashup
    Executed in memory and limited to APIs
    Access management and authentication
    Technology Diversity
    With microservices, you can mix multiple languages, development frameworks and data-storage technologies.
    Debugging & troubleshooting
    Drilldown to the root cause, because it may be inside of the chain of services
    Monitor & logging
    Need to centralize effective monitoring & logging

    As you can see, all the initial benefits create additional burdens. What was promised to speed up the process has now become a huge complexity problem.

    Monoliths and microservices aren't a simple binary choice, and you must not forget that there are systems out there that don't quite fit into either category.

    That said, the normal assumption is that, because of the cost of microservices on productivity, they can only be made up for in more complex systems, but this isn't absolutely true.

    OutSystems already solves some of these burdens by:

    1. Adopting a single stack

    OutSystems provides you with built-in capabilities that handle:
    Debugging and troubleshooting
    * Monitor and logging
    2. Exposing a query model

    By exposing a query model, data mashup is now possible, as you can query entities directly to read data and use APIs to write data.
    * Limited data mashup

    With this initial context in mind, it's now time to ask the question: when should you adopt a domain architecture (and therefore a microservices architecture) in OutSystems? Let’s dig into it!

    • Was this article helpful?