Technology is subject to fads, fashions, and buzzword-of-the-day just like most other things. Recently, a colleague of mine asked me for my opinion of microservices. It took me a moment to diplomatically answer along the lines of, “A microservice is just a small Web service function — nothing more.”
I remember when Service Oriented Architecture first appeared in the early 2000s. It seemed exotic and mysterious. In SOA you create a Web service that can accept a query from an application, for example http: //mywebservice.com/adder?x=3&y=5. The service could do something, like perhaps add x=3 and y=5, and return the sum of 8 (probably in XML or JSON format) to the application.
One of the original design goals of SOA was to create a technology where all kinds of different systems could talk to each other. For example, if a large company had Linux systems and Window systems and mainframe systems, you could put a Web service on top of each system.
The universal technology-glue scenario is pretty powerful. Additionally, Web services are useful to fetch proprietary data, or to perform processing on a very powerful machine.
I took a look at creating a microservice on top of Microsoft’s Azure platform. It was pretty slick — significantly faster and easier than spinning up a Web service from scratch (which I’ve done many times), but of course there’s the expense of having to explicitly pay for Azure.
OK, so what does all this have to do with the latest and greatest microservices? Well, someone thought that it’d be cool to slap a new name around SOA. If you search the Internet for “microservices vs. SOA” you’ll find all kinds of nonsense where self-proclaimed experts try to create ideas where none exist.
The moral: a microservice is just a small SOA function. I’m waiting for someone to come up with the notion of a “miniservice” and a “macroservice” and a “metaservice” and who knows what else, and sell training classes on how to understand them. (I hope you sense the sarcasm here).