Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
Microservices architectures are very popular today. In this article, we take a look at how microservices architectures are different from Service Oriented Architectures (SOA).
This is the last article in a series of five articles on cloud and microservices. The previous four can be found here:
You have distributed applications (from different vendors running on variety of platforms) integrated with middleware infrastructure. Applications interact with each other in a traditional/synchronous way by sending messages over the Enterprise Service Bus (ESB)/Broker to get the job done.
The synchronous infrastructure is causing delays leading to unproductive wait times and dissatisfaction from the users. There is a need for applications to propagate information (state changes and interesting events) to other interested applications asynchronously without knowing the details about their identity.
Microservices are one of the biggest buzzwords of recent years. However, it turns out that it is a bit like teenage sex: everyone talks about it, but nobody really knows how to do it. What does it take to make good use of this architecture? What conditions do we have to meet so that it’s something more than just an item on your CV? Read the article to find out.
Several years ago, conferences were all about Service Oriented Architecture. In a nutshell, it consists of building large systems with many logically divided services integrated with each other. The idea was to eliminate the main problems related to monolithic architecture. Most SOA implementations were based on, or shifted over time toward, the Enterprise Service Bus. The bus was responsible for communication routing, document mapping, handling different types of endpoints, auditing, and security. The idea was noble, but the versatility of the solution turned out to be a double-edged sword. After some time, the bus turned into another monolith. Centralization, bottlenecks, both in terms of development and efficiency, and a single point of failure contributed to the growing criticism of the solution. I know cases where a 60-80-person team working on the bus turned out to be insufficient and a part of the communication had to be point-to-point so as not to block business projects.