The answer is one word, absolutely! Is there any difference between them? Again, absolutely! Microservice architecture is inspired by SOA. Their architecture seems like SOA, but there are differences that make microservice a more polished and organized version of SOA. In SOA also, problems are broken into services, and typically, they all used SOAP as a messaging language for communication. There are many consumers connected with many services through the service bus. Consumers can invoke any service by sending a message over the Enterprise Service Bus (ESB). Like in microservice, in SOA also, these services can be in the same language or a different language. SOA doesn't mention the bounded context of these services. Although these are not strict rules in microservices, microservice architecture gives some bounded context about these services in terms of SRP. The database in SOA is typically shared between the services, while in microservices, each service should have its own database and no other service can deal with that directly. SOA believes in the principle of sharing as much as possible, so SOA promotes sharing resources such as databases among different services, which actually increases the coupling between services. This contradicts with the microservice architecture. Microservice believes in the principle of sharing as little as possible. This changes the fundamental approach of designing any service in architecture.

Communication layer ESB, the middleware, in SOA becomes the single point of failure. In the case of failure in ESB, none of the services can work, consume any data, or talk to each other. Microservice deals with this problem with the failure in isolation principle. Typically, microservices talk over RESTful, and it eliminates the need for any heavy middleware communication channel. Another implication of SOA is service contracts. As there is no notion of bounded context in SOA, the same service can make changes in a different data model, which actually leads it to shared data model. This data model can have hierarchy or complex data types. Changes in any of this data model, even with a single field can result in changing the interface in all services and deploying the whole application. The following figure is showing the typical architecture of SOA Application:

Some of the problems mentioned above earlier with SOA can be handled by implementing the architecture in an efficient way, but not all the problems can be solved. SOA is a very broad term, and microservices can be a subset of SOA, which has some more fine- grained rule around the service- oriented design. There is a famous quote about Microservices, that is "Microservices are, SOA done in better way".

One major edge that microservice architecture has over monolithic applications is the speed to production environment. Microservices are getting popular not only in small startups but also in big companies. One of the biggest goals they achieve is shorter Time to Market (TTM). With dynamic and ever-changing requirements, TTM has become critical; product requirements change daily based on market reaction. Microservice architecture perfectly fits in this situation--speed, build, test, and ship. The market is very competitive these days and is evolving around customer feedback. The cycle is build, test, and ship, get the feedback from the market, build it again, test it again, and ship it again. If any product can be shipped to market in a shorter time with new features or upgraded with feedback from the market, then it will definitely have an edge over the competitior. Achieving the same in a monolithic environment is not easy; the whole application has to ship again even for a small feature.