Service Oriented Architectures versus microservices
When a developer encounters microservices and they know the Service Oriented Architecture (SOA) style of software design, the first question they ask themselves is whether SOA and microservices are the same thing or whether they are related, and the answer is a little bit controversial; depending on who you ask, the answer will be different.
According to Martin Fowler, SOA focuses on integrating monolithic applications between themselves, and it uses an Enterprise Service Bus (ESB) to achieve this.
When the SOA architectures began to appear, these ones tried to connect different components between themselves, and this is one of the characteristics of microservices, but the problem with SOA was that it needed many things surrounding the architecture to work properly, such as ESB, Business process management (BPM), service repositories, register, and more things, so it made it more difficult to develop. Also, in order to change some parts of a code, it was necessary to agree with the other development teams before doing it.
All these things made the maintenance and code evolution difficult, and the time to market long; in other words, this architecture was not the best for applications that often needed to make changes live.
There are other opinions regarding SOA. Some say that SOA and microservices are the same, but SOA is the theory and microservices is a good implementation. The need to use an ESB or communicate using WSDL or WADL was not a must, but it was defined as the SOA standard. As you can see on the next picture, your architecture using SOA and ESB will look like this:
The requests arrive via different ways; this is the same way microservices work, but all the requests reach the ESB and it knows where it should call to get the data.