Microservices and the New Holy Grail of Scalability
Microservices and the New Holy Grail of Scalability
In this article, we will talk a little about the significant problem of the Holy Grail with microservices.
Join the DZone community and get the full member experience.Join For Free
The Holy Grail is a treasure that serves as an essential motif in Arthurian literature, in addition to great films like Indiana Jones. In some versions of the legend, a holy vessel is responsible for curing all diseases and problems. The Holy Grail has also become synonymous with an object or relic sacred to some areas or the solution of all issues.
In the IT area, we also have this Holy Grail that seeks the performance and scalability of an application with a single solution that we call the silver bullet. This silver bullet has been changing techniques for generations, and the current one is microservices. Did we finally find the Holy Grail of IT with microservices? In this article, we will talk a little about the significant problem of the Holy Grail with microservices.
The dream of performance and scalability has always been an intense desire among computer architects. And many of them start using microservices for the sake of performance. And as we know in computing since 1960:
Premature optimization is the root of all evil.
The Holy Grail Generations (No Clue Generation)
Indeed, I don't have decades of practice; however, in that period, I could see some generations of the Holy Grail, or I simply have a performance problem, and here comes the typical “no clue” solution like a silver bullet. What I call “no clue,” basically, is based on the answer that comes out of an architect's sleeve as the solution to all possible problems. Throughout my journey, I could see these Holy Grail solutions change over time; however, their basic concept is not, a quick solution, without much analysis of the current architecture:
- Increase the memory of the JVM: the problem of the application is undoubtedly to increase the mind of the application;
- Put cache for the database: the problem is in the database, so we need to put a cache;
- Change the relational database to NoSQL: the database needs to be scalable, soon I will put a solution with NoSQL as Cassandra;
- Switch to microservices: I need to create the scalability of the application, so I need to divide the application.
The Problems of Microservices
There are several problems that lectures or workshops do not address, the real-world software architecture:
- Hardware complexity: since the new architecture will deal with new machines, it is essential to note that in addition to creating it is important to maintain these services, that is, databases need more backup operations.
- Security: security is important, and ensuring access between machines is trivial. For example, it is important to ensure that financial sector servers access financial sector databases and that other machines do not.
- Every application needs testing, and with microservices it will not decrease, on the contrary, these tests need to increase since it is necessary to test integration, not to mention, which needs to verify when such services are not available Circuit Break.
- An application with difficulty logging will become even more complicated with microservices; it is vital to have even more infrastructure and machines to centralize the logs and have an open trace id to follow the log among the services available in the application.
The Most Common Errors With Microservices
It is widespread to have the most current list of errors that all software has, especially when there is a paradigm shift. For example, when there was a migration to NoSQL databases, certainly, the mistake was to think of relationships in databases that do not support relationships like Cassandra. The following list presents the most common errors that we find in microservices:
- Domain break: DDD brought several benefits, mainly, bringing the code closer to the business with ubiquitous language. Within the DDD, we have the concept of domains, and when we move to microservices, it is very normal to break the business in the domain in the wrong way. Speaking of performance, the most efficient way to communicate between domains is memory or not reinventing the wheel, for example, instead of orchestrating services, we can simply join and search for the necessary information.
- Do not automate: one of the best practices existing when it comes to microservices, certainly, is CI / CD. These techniques are fundamental, especially since there are a lot of machines to be managed
- Diversity of languages: this decision is certainly the most intriguing for me. So far I do not know a single project whose goal is to display something on the console; however, it is ubiquitous to hear a programmer's decision based on the number of lines inside a "Hello World". It is essential to be very careful with this type of arrangement.
- Your application is not big enough to become a microservice: not every large application will need to be a microservice, and it is essential to admit that.
- One of the great arguments for choosing microservices is the possibility of selecting to scale a component individually. However, here comes the question: does it make sense to climb a part independently?
- Microservices need information, and like any distributed database, they face the CAP theory. Performing several updates on each service, it is necessary to add a new layer and complexity in the application, such as the SAGA standard, and this layer, given its complexity, generally causes even more impact on the consistency in the data of all the services involved.
- Starting the project now as microservices tends to be a big mistake, mainly, in the instability in the definition of domains an error in the break causes a significant dependence and coupling between services so that many orchestrations as good practice would be joins for relational or subdocuments thinking about a NoSQL database store, like MongoDB.
Another significant point, use microservices only because large companies use this type of architecture. In the world of software architecture, a decision should not be made just by the popularity of the solution. As Edson Yanaga says in his book:
"Certainly, we always read great things about the microservices architectures implemented by companies like Netflix or Amazon. So let me ask a question: how many companies in the world can be Netflix and Amazon?"
Microservices like any architectural decision without its advantages and disadvantages as Martin Fowler says:
"Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single transaction. Microservices require multiple resources to update, and distributed transactions are frowned on (for good reason). So now, developers need to be aware of consistency issues, and figure out how to detect when things are out of sync before doing anything the code will regret."
The pursuit of the Holy Grail in computing is still one of the biggest myths within the world of computing. Microservices, like any architectural decision, have benefits and disadvantages like any other solution. Microservices were not the first and will not be the last silver bullet of performance that I affectionately call “no clue generation.” As engineers and architects, we must carefully analyze such decisions.
It is worth remembering that despite the great glamorization of microservices in lectures, articles, and some books, their explanations are often restricted to the creation and not to maintenance and trade-offs. Since conception, in general, is the most natural part of the software. It is always essential when choosing architecture to check the advantages and disadvantages of a solution and be very afraid when they only tell you about the benefits, after all, it is more content in search of the holy grail.
Opinions expressed by DZone contributors are their own.