Hi folks, it's been a while since I last wrote about something in here. Well, I have been busy specially working and studying since then but, I finally found some spare time to wipe the spider web out of my keyboard and try to write something so, let's get to it.
Today, I got an invite in my email to watch a lecture about Microservices from TDC online conference. After the the video call, I felt like making a few comments about the lecture so I am getting back to it to do that. By the way, for those who don't know what it is, TDC is one of the popular tech events of Brazil held by a training company located in the city of São Paulo.
Frankly speaking, I did like a few information presented by the speaker and I also agree with him to a certain extent. However, I must disagree with the speaker for the most part. In fact, what has been spoken in the lecture can lead young developers to misunderstand Microservices. Anyways, I would write much more about that but, I decided not to do so for personal grounds and essence of time. I only want to make it public so others can come in here or find this information though google and get a different standpoint to better understand the core concepts about Microservices. So, I am going to write a very short essay with the two major points mentioned in the lecture. Let's cut to the chase.
First of all, he mentioned that the difference between microservices and services is microservices are atomic and generally, asynchronous and services are essentially synchronous. Honestly, I beg to differ on that, those assumptions are, in my opinion, totally mistaken, both services and microservices can take benefits from those communication mechanics, I mean, being either asynchronous or synchronous has nothing to do with their definition. It is just a communication technique or way of communication in which services of any nature can make use to communicate between them across machines. In addition to that, microservices can also be atomic by participating, whether or not, into database transactions with the ability to roll everything back when needed.
Second of all, I might have misunderstood what he said. However, I am under the impression he said that microservices is term hard to define and also he implied that the term itself does not mean much. Well, not really, I would say, and quite likely so do many others. The term microservices means a lot, I mean, it is self-explanatory, microservices are small, or should be, compared to traditional services. You build a microservice to solve a problem of the specific context, of course, try to keep it coherent to the domain being involved with just a single responsibility which has to be taken into account at that point. That's why it is a microservice, it only solves a specific problem and does a specific task to promote reusability. As being so specific, how could they be big? For instance:
cat text.txt | grep test
Above is an example of microservices, two services communicating with one another to solve a specific problem. As a matter of fact, we have been building microservices and designing microservice architecture for a very long time. Moreover, this concept likely stems from the Unix philosophy.
In conclusion, microservices are de facto a very good approach to build large and small systems as I encourage everyone to at least read a SOA book to have guidelines for developing such systems. I did not mean to offend or to take the speaker apart, I am only giving my standpoint and what I have in the back of my mind so that other readers can have a different angle of vision to better comprehend the terms and the philosophy behind the hood. Hope I made it clear enough.
That's all folks.
Kind regards.
