Microservices


I want to start with a popular phrase that’s being quoted in the article: “not every problem is a nail and not every solution a hammer”. The reason to start with it is because when people know something, we tend to find a solution that fits into something we know or recently learned.

So, quoting Martin Fowler on a later article1 he wrote in 2015: “So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith.”

Also, Fowler says on that same article1 “is a microservice architecture a good choice for the system you're working on? It depends…”

Throughout the original article, Fowler mentions the cases that would be the appropriate to adopt the microservices model. For many years, a lot of systems were developed and envisioned as monolithic structures that were hard to deploy, especially in large enterprise systems, that often had the problem of intertwined code, that when modified incorrectly, could lead up to a bunch of problems for the development team or the system’s functionality. Trying to develop new features could become difficult on those monolithic systems.

At the time that he wrote the article in 2014, microservices were relatively new and he only saw microservices as a promising way to develop systems. Since the article was written, microservices have become more popular, given the context of cloud applications being more adopted.

So, in conclusion, you could say that microservices could be a real solution, but the premise for any system, monolithic or not, is to have well written code. Cleaning up your application and refactoring could save a lot of trouble before transforming a monolithic system into microservices. As I said in the beginning, not all solutions work best for all problems, it actually depends on the problem that you’re trying to solve…

Don’t turn microservices into the hammer that will always try to find a nail.


1.     https://martinfowler.com/bliki/MicroservicePremium.html

Comments

Post a Comment

Popular posts from this blog

Image
So, this is a little about me... I am Omar Zamora... I was studying in college 20 years ago, but I had to leave school for several reasons, and actually Ariel was my teacher back then. Since then I have been working, first as an Software Project Leader in Costco and afterwards in Buying and Logistics. I stayed in Costco for 17 years and after that went to other companies. Right now I'm working on the SCT as the Information and Communications Technology Director in the SCT. I love music, I'm a drummer and right now I play guitar and sing in a band.
Read more

Is Design Dead?

In this long article by Martin Fowler, he talks about software design and its applicability. This article was written in 2000, with its final revision on 2004. Still, the concepts he talks about are still applicable up until this day. He talks about the main styles of software design, which are planned and evolutionary. As he states, the main problem with planned design is that is really difficult to foresee the changing requirements of a system as it keeps growing and evolving. So that can become a problem, as sometimes the issues that come up can become more difficult to handle on the original design approach. On evolutionary design, the design keeps changing as the project is developing and becomes part of the programming processes. The issue is that it becomes messy and hard to track down the in the long term, making the code harder to maintain and more prone to bugs. When Fowler talks about how design applies to Extreme Programming (XP), he also sa
Read more

Who needs an architect?

It’s hard to have people agree on any subject, and this could be talking about politics, religion but also software design. Even in the software community people can’t agree the definition of a software architect, let alone if they are actually necessary or useful for a project. In this article by Martin Fowler, he talks about this, he actually tries to define both, the concept of architecture and also the software architect. He defines software architecture as a shared understanding the expert developers working on a project of the system design. So, this means that the architecture of a system depends on the vision and involvement of the developers, to fully understand how a system should work. But it’s also telling us that it needs consensual agreement by the group, which sometimes can be hard to reach, especially when the system become too large or too complex. But as the author also says, everything depends on what the developers thinks is importan
Read more