It is a fact that Microservices are a tendency nowadays within the Software Development Industry. It has changed, not only the way we architect and write software, but how our teams are structured. Among many other benefits, having some technology independence between services, dedicated teams for specific business domain areas, scale and deployment independence make Microservices such as a great choice when architecting complex systems – even when architecting the simple ones.
Nonetheless, there is always a tendency to named things in a particular form just to pretend to be up-to-date or fancy. This is something that use to happen a lot with Agile methodologies – for instance, some people and companies use to claim they are agile just for having a kamban board or having scrum meetings.
Something similar can happen with Microservices. Let’s take a look at this example:
Suppose that we are talking about a retail company. They offer a delivery service for purchases made on its web site. For this matter, the company has an agreement with an external delivery service company. Hence, the retail company needs to inform the delivery company about any new purchase that must be shipped.
The retail company’s system has the following components:
So far, so good. However, as Bob Martin says: “The devil is in the implementation details“. Taking a close look into the Payment and Delivery service code, we notice the following algorithm:
- Payment sends order details to Delivery through a queue system.
- Delivery picks up the order, save required data into its storage and returns a shipment number.
- Payment sends a delivery confirmation email to the customer and sends and email to the Delivery company with order details.
At this point, it is extremely clear that there is something wrong here. Payment service sends email details about the delivery. That is not OK. Even worst, this is coming from a real scenario I have seen over my experience. The retail company was so proud about its Microservice architecture, though.
The main problem here is not specific to Microservices, it is about Software Development principles: Separation of Concerns and Single Responsibility Principle. The delivery service must be in charge of everything related to delivery, such as sending confirmation emails, etc. Plus, changes over the delivery business case may require changes in both the Payment and Deliver services due to how developers split the code and responsibilities.
Let’s recall that a Microservice must be focus in one particular business domain subject. In addition, it should act as a plugin component, that is: it could be added or removed without affecting the rest of the system – or at least, affecting as little as possible. Finally, a Microservice must be independent to deploy – in above scenario, changes on Payment and Delivery services may imply deploying both, hence some unnecessary dependency.
My thought is instead of focusing on naming or using fancy-trend names, it is wide much better to truly understand the Software Development foundations and the new approach – in this case Microservice – in depth, so we can take the most of both. As a result, our Software products will be designed and implemented with best practices and will deliver business value over time. At the end, that is why we get payed for.
Vicluar Daniel Merchan 