Drawbacks of microservices

It's not very easy to build an MSA. First of all, you need to invest in people skills. In addition, you must adopt methodologies such as Agile and DevOps to create a full-stack team that is able to obtain the following:

• Service replication: One of the benefits of MSA is that it is easy to scale up. But to do this, you need an infrastructure that enables this feature using a standard mechanism based on, for example, metadata. Platform as a Service (PaaS) is the ideal environment but to use it, your teams should have or obtain competencies in this area and your applications must be cloud ready or cloud-native. Therefore, you need to heavily invest in people and resources.

• Service discovery: In a microservice ecosystem, services are distributed to guarantee load balancing and failover into immutable infrastructure provided by, for example, containers in a PaaS or immutable VM images using the major virtualization providers. Services scale up and down based on certain predefined metrics. In this scenario, it is difficult to know the exact address of a service until it is deployed and ready to be used. The exact service endpoint address is usually mapped by service registration and service discovery. Developers and operational people need to write code and maintain infrastructure that makes it easy to do so. The architectural design phase is different from the past. Therefore, you need to refactor the existing applications or design new ones in a different manner using these new actors.
• Service monitoring: In a distributed environment, it is essential to monitor services and log information. This enables you to take proactive action if, for example, a service is consuming unexpected resources (such as CPU, memory, or threads) or has some issues (such as resource leak, memory leak, or a database connection leak). It's extremely important to create a system that is able to aggregate logs from different microservices, visualizing them in an easy way for operation teams, developers, and business users. If you don't build this infrastructure, you could encounter some difficulties in the production environment since you will not able to debug the application and react to an issue in an effective way.

• Resiliency: Usually, a full business workflow is built by the invocation of multiple services being distributed in different environments—for this reason, it is easy to predict that one of these services could fail, independent of the hard work made by the development team to test it. For this reason, developers should try to avoid the failure by automatically implementing corrective actions to guarantee that the system's workflow continues to operate properly. It's not very easy to predict failure, so your team must contain highly skilled senior staff that can help design this type of software.

• DevOps: There is no microservice without automation. CI/CD are essential for microservice-based applications to succeed. You need to identify bad software quality, performance issues, runtime execution exceptions, and so on, at the earliest opportunity via well-automated unit testing, performance testing, static code analysis, and deployment pipelines. It's extremely hard to build and maintain this type of automation in a source and infrastructure life cycle.

• Resource and network overhead: A full suite, which is needed to implement a complex business domain, is built by multiple microservices. This means that a great number of applications require more resources to run than traditional monolith applications. You need to build this type of infrastructure or learn to use a cloud-native platform in all core development areas—Infrastructure as a Service (IaaS), PaaS, Software as a Service (SaaS), and so on. Do you have all of the necessary skills to choose, develop, and maintain these platforms?

Another important consideration is the as-is infrastructure. Maybe, in your organization, there are great monoliths or SOA applications that work great. Should you abandon them or completely rewrite them? If neither, how can you migrate them to a cloud-oriented infrastructure?

Another aspect that is difficult to manage is the consistency of the data—how can you preserve it in a system that is distributed and heterogeneous in terms of the implementation of technologies?

So, after the collection of all points, positive and negative, the challenge is deciding when it makes sense to use an MSA.

For those who have built enterprise applications over the past 10-15 years, concepts such as services, isolation, and data ownership bring to mind another architectural model that has been the foundation of enterprise applications—SOA.

So what are the differences between MSA and SOA?  Let's take a look at them in the next section.