Building robust enterprise solutions requires thinking differently. For many, service oriented architecture is the way to go. But recently, the influx of microservices challenges the idea that there's only one way to skin the proverbial Information Technology cat. As Torsten Winterberg puts it, “Microservices are the kind of SOA we have been talking about for the last decade. Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. Classic SOA is more platform driven, so microservices offer more choices in all dimensions.”
I have always been of the mind that service oriented architecture (SOA) represents an architectural pattern for software design where application components provide services to other components via a communications protocol, typically over the internetwork. Today, many embrace the idea of micro services -- in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. Now, this seems to be splitting hairs, but in practice the concept of microservices might be hard to distinguish from SOA principles. Think of it this way: With SOA, one could write business logic to query a dataset to GetPaymentsAndCustomerInformationAndPurchaseHistoryDataAPI and AuthenticateUsersAPI. The approach from a microservices pattern would simply be to deconstruct those two APIs into much smaller units (GetCustomer; SubmitPassword). The net result is of course the same transactional processing and data traversing the wire, but in smaller increments. And new uses for the multiple APIs could be found, perhaps.
Perhaps the biggest gains in taking a microservices approach resides in cloud-deployed applications. Monolithic applications are sometimes wholesale moved to the cloud, but every time a rev is made, even to a small part of the app, the entire solution to be rebuilt, tested and deployed. With the alternative, smaller units are revised with agility, and downtime is reduced or eliminated.