So you just made it to a new development team filled with brilliant people, that was faced with a challenge of building a solution which would change the world. After hearing the needs and the goals on planning meetings, pumped up and excited, you and your team get deep into discussions to design this save-the-world-make-your-client-happy new platform. These design meetings are filled up with passion and different perspectives, ending up with one of the developers saying: We really should consider microservices!. The whole discussion changed its course, and now the whole room is going around the benefits, patterns, languages and/or related to microservices, and here it’s when i think everything starts going on a weird path. tools Tech Hypes There’s nothing more exciting for a developer (at least for me it is!), to find new technologies, discover new problem-solving patterns and be aware of what’s going on with . It’s like a shot of adrenaline to discover new topics and the feel of starts to intensify while digging deeper. So, more often than not, you would hear one of your teammates (or even yourself!) during discussions say technology “oh!, i need to implement this…” “I know we can solve this problem with (insert here any new tool of framework with a lot of fuzz)” or “i’ve seen (insert big company name here) have solved this problem with X”. I’ve personally seen this situation happen, and also have seen people defend with dreaded passion why the project needs the solution that is being talked so much in the community these days, and there are valid arguments, but lots of the arguments i’ve heard fall into patterns like: Why should we reinvent the wheel? If this is how someone is doing it, why shouldn’t we? Who are we to criticize what a tech giant is doing? They have spent tons of resources to achieve a solution, why should we question it? And even though, in certain contexts, those arguments are valid, doesn’t mean they are applicable for the reality of all projects. Hearing what are the trends and what the community has to say about any topic is a smart move, but following it blindly would take you and your project through the wrong path (probably), or at least not the best one. Is it microservices what you really need? The microservices architectural pattern is being outside for quite now, but lately, it has gained a lot of attention. Tools and frameworks are being worked on, and hundreds of companies have them as the very base pillars that support their platforms. Tech giants like Netflix are not only using microservices, but creating a complete tool set to work with, which have turn them in reference solutions for other developers, and for a good reason. They scale, support heavy loads, grow and run a steady business which is a reality thanks to their platform. All these qualities are what you want for your to-be-built platform, and even more, your client was very insistent that to run a good business he would need all that. So, at that point, you are thinking, Well, no!. this just feels like a perfect match, isn’t it?… The real objective is about business not about technology This single sentence basically resumes all the key points of this post, and in many other conversations i’ve had with other developers it can generate a lot of discussions. For me, it means that at some stages of a project, it’s extremely important to focus on what drives the business, and what do we need to deliver in order to gain some value. Microservices give a lot of benefits, but with those benefits comes a lot of complexity, and this kind of complexity would drive you off the road of focusing on the business, which at the end is what really matters. Distribution, communication, discovery, isolation, health, are some of the topics that come hand in hand with this approach, and every each of them is its own monster to control. Getting into that would make you spend some time before you can show some value to the business. Monoliths are not always a bad thing All the fuzz can bring up some noise, and all the goodness can be eventually transformed on statements that not always be true. Some of my favorites are Monoliths are evil and they need to be gone for good You cannot scale if you have a monolith The first argument is oriented (i think) to functional segregation. Which honestly is a great thing about microservices, but it doesn’t mean you cannot achieve it on a monolith. This topic goes outside the architectural pattern and enters into just regular development best practices. Having an application with a clear segregation, where you can breathe high cohesion and low coupling will allow you to take the decision to move to microservices afterwards. And even better, you get to choose which parts of your application actually needs to be “evolved” to a separate service by itself. Cool, huh? If we get deeper into the second argument, there are a lot of points of debate. My take on this one is that even that it’s true, doesn’t mean that you can’t scale up a monolith. Again, with good practices in place in your application, you don’t get to scale up separate parts of it, but you can scale your single “big service” using all the modern greatness built for that end. We all need to walk before start to run Stop the tech giant fallacy. Facebook, Google, Netflix, or any other started small, they grow day by day with their needs, and they didn’t just jump into a solution because it was good, they evaluated solutions based on their requirements. It’s key to understand possible paths to take and learn from mistakes others already made, but always keep in mind that they walked a long path to be there, spending a lot of resources and precious engineering-time, which are limited. An efficient investment of those resources is key for the success of your project. I really love microservices and all the technology that has been created with it or around this pattern. But it’s important to always think twice, and more importantly see what are the needs of your project and how this pattern would help to leverage it. Think about the business and tackle the needs with tech, not the other way around. PS: Special thanks to my lovely wife Olga, my friend Daniel V. and my friend Aleja who were kind and patient to go through the whole thing and review my first blog post :)
