Microservices == Microhell

Microservices, a word that has been buzzing around a lot, every one is writting, speaking and developing under the microservices mindset, but it is never that simple, just splitting a service into small pieces and having them interacting over the wire can cause a great mess.

Not having a good planning on how the service will interact, can cause an auto DDoS, because all the services are too chattie and then overload the network, so essentially, you performed an DDoS attack just by trying to run your system, congratulations.

So, what to do?
Now that the naive solution (http) is discarted, how can you interact in a system where everything is logically separeted? Many solutions have evolved throught out the years, one of the best solutions, specially if you need one way communication, is using a queue service, where messages can be posted and they can be received from the other end of the queue to be proccessed.

RPCs (Remote Procedure Calls), this method of executing actions is sometimes slow, depending on the level of concistency been used, two-phase commit is very costly but is very effective.

During the 80's and 90's, a paper was show, called SAGAS, which described long running transaccions on databases, and how to utilize them to make long queries work efficently, now it had evolved into Distributed SAGAS, a pattern where each microservice is a task, and a sequence of tasks is transaccional, so when an update occurs, every service that needs to be updated will receive the info. Also I really like the idea of a "pipeline" for this kind of situations, for example, maybe a reservation site allows you to book a flight, pay your hotel and rent a car on the same website, at the same time, so then, based on your task priorities, the SAGAS can be reorganized to make the most important task first, for instance, booking a fligth, because without a fligth, no trip can be made, so is cheaper to wait for the fligth booking service to answer, than to book a hotel and then cancel it.

Conclusion
I really like the last approach, having a way to think about the problem is great, and having the freedom to implement it as you wish is also a good idea, but it can be really bad, because not just one, any one can do what they pleased to do with your service, and our job is to prevent that from happening.