{"id":4885,"date":"2018-03-27T07:27:51","date_gmt":"2018-03-27T14:27:51","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=4885"},"modified":"2023-06-13T05:30:35","modified_gmt":"2023-06-13T12:30:35","slug":"condemn-microservices-architecture-fail-even-start","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/condemn-microservices-architecture-fail-even-start\/","title":{"rendered":"How to Condemn Your Microservices Architecture to Fail Before You Even Start"},"content":{"rendered":"

A lot has already been said about microservices over the last few years, but I commonly see new distributed systems being developed with the old mindset of monoliths. The side effect of building something new without the understanding of some key concepts is that you will end up with more problems than before, which is definitely not the goal you had in mind.<\/span><\/p>\n

In this article, I would like to tackle some concepts that we historically take for granted and which might lead to poor architecture when applied to microservices:<\/span><\/p>\n

 <\/p>\n

Make Synchronous Calls Only<\/b><\/h2>\n

In a monolith architecture, we are used to All-Or-Nothing availability, we can always call any service anytime. However, in a microservices world, there are no guarantees that a service on which we depend will be online. It could be even worse, as a slow service can potentially slow down the whole system as each thread will be locked for a certain amount of time while waiting for the response of the external service.<\/span><\/p>\n

\"\"

How locked\/slow threads eventually consumes your entire thread pool<\/p><\/div>\n

We are still learning how to properly implement communications between services, but the rule of thumb is to <\/span>make everything asynchronous<\/i><\/b>, and that is where one of the first challenges emerges, because historically we haven\u2019t exercised enough our ability to transform a synchronous flow into asynchronous. <\/span><\/p>\n

Hopefully, most of the use cases can be implemented asynchronously with the right amount of effort. Amazon, for instance, implemented its whole order system that way, and you barely feel<\/strong><\/em> it. They will almost certainly let you place an order successfully, but if there is any problem with the payment or if the product is out of stock, you will receive an email notification a few minutes or hours later telling you about it and which actions need to be taken. The advantage of this approach is clear; even if the payment or stock service is down, it won\u2019t block users from placing an order. That is the beauty of asynchronous communication.<\/span><\/p>\n

Of course, not everything in your system can be async, and to deal with the common problems of synchronous calls like network instability, high latency or temporary unavailability of services, we had to come up with a set of patterns to avoid cascading failures such as local caches, timeouts, retries, circuit breakers, bulkheads, etc. There are many frameworks out there implementing those concepts, but the <\/span>Netflix Hystrix<\/span><\/a> is currently the most well-known library.<\/span><\/p>\n

There is nothing essentially wrong with this approach;\u00a0it works pretty well for several companies. The only downside is that we are pushing an extra responsibility for each service, which makes your microservice even less \u201cmicro\u201d. Some options have been proposed in the last two years to address this issue. The Service Mesh pattern, for instance, tries to externalize this complexity in a form of a sidecar container :\u00a0<\/span><\/p>\n

\"\"<\/p>\n

I personally like this approach, especially because it is language agnostic, which means that It will work for all of your microservices regardless of the language in which it is written. Another advantage is the standardized metrics, as different libraries\/frameworks might use a slightly different algorithm for retries, timeouts, circuit breaks, etc. Those small differences might impact significantly the generated metrics, making impossible to have a reliable vision of the system’s behavior.\u00a0<\/span><\/p>\n

UPDATE:<\/strong>\u00a0\u00a0If you want to read more about the Service Mesh pattern, check out this excellent presentation<\/a>.<\/p>\n

\"\"<\/p>\n

In Summary, thinking about how services will communicate with each other is essential for a successful architecture, and should be planned ahead to avoid a chain of dependencies. The less the services know about each other, the better the architecture is.<\/span><\/p>\n

 <\/p>\n

Just Use RDBMS for Everything<\/b><\/h2>\n

 <\/p>\n

After a 30-year monopoly of RDBMS, it is understandable why many people still think that way. However, nowadays, virtually every day a new database is born (and <\/span>two JavaScript frameworks<\/span><\/a>). If in the old days, picking a database was a matter of choosing one among five, today, the same task demands much more attention. <\/span><\/p>\n

\"\"

Source: db-engines.com – initial release dates<\/p><\/div>\n

As <\/span>Martin Fowler said<\/span><\/a> 12 years ago, there are a lot of benefits on choosing a specialized storage, such as: higher performance, lower cost, etc. I won\u2019t spend your time going through all the downsides of RDBMS (slow reads, sparse data, impedance mismatch, joins, etc). Rather, I would just like to highlight again how the database plays a major role in the overall performance of the system, and an inappropriate choice will eventually cost you much more money.<\/span><\/p>\n