Yes, right: What happened to Microservices?
Microservices were previously heralded as the wave of the future of software development, promising enhanced scalability, flexibility, and resilience. However, the enthusiasm for microservices has died down in recent years, and the emphasis appears to remain on monolithic architecture. What occurred? Is this owing to the introduction of new trends and technologies, or is it the result of microservices themselves reflecting on lessons learned?
Microservices are not a panacea, and they, like any other technology, come with their own set of expenses. Before getting into microservices, think about the exact results you want to achieve. Inquire, "Is there anything within the system that is scaling at a different rate than the rest of the system?" as well as "Is there any part of the system that requires more frequent deployments than the rest of the system?" Once you've determined the answers to these questions, you may do a cost-benefit analysis to see if microservices are genuinely essential for you.
Martin Fowler, a well-known advocate in the microservices community, says that using microservices to start a new project is not the ideal method. According to Fowler, virtually all successful microservice tales began with a monolith that became too large and was broken apart. As a result, before going to microservices, it's advisable to start with a monolith and figure out what the correct boundaries are.
Monolithic is still scalable.
Microservices proponents frequently assert that monolithic design cannot grow well beyond a certain point, yet this is not always the case. Shopify, for example, has been developing its application as a monolith since 2006, amassing over 2.8 million lines of Ruby code and over 500,000 changes. They only chose a Modular Monolith strategy in 2016 when they realised how difficult it was to design and test new features. Shopify's strategy enables them to reap the benefits of both monolithic and microservices systems while minimising their disadvantages.
Distributed systems are difficult to manage.
Because microservices are fundamentally a method of designing distributed systems, they are not immune to the inherent problems of such systems. Conducting transactions across numerous services is one of the most difficult challenges. Although there are various approaches for handling dispersed transactions, none of them can give the same level of ease that developers enjoy in a monolithic design with a transaction-capable database.
Serverless computing is a competitor to microservices, however, it is more of a development of the microservices design than a replacement. Both techniques aim to deconstruct complicated systems into smaller, more manageable components. Serverless computing, on the other hand, abstracts away infrastructure issues to give a more automated method of designing and deploying microservices.
In conclusion, microservices are still a valuable approach for certain scenarios, but they are not a one-size-fits-all solution. It's important to consider the specific outcomes you hope to achieve and perform a cost-benefit analysis before deciding to adopt microservices. Moreover, the emergence of new trends and technologies, such as serverless computing, also provides alternative approaches to building distributed systems. The key is to keep an open mind and evaluate each approach based on its merits and suitability for your specific use case.
Thank you 🙌🏻 for taking the time to read this conversation. I hope that I was able to provide useful information and insights. If you have any further questions or concerns, please do not hesitate to ask in comments 👇🏻👇🏻