Let’s Take Our Conversations about Microservices to the Next Level

It’s interesting to read the discussions that are going around lately on the “go-to” architectural approach and what your services sizing should be — should be a nanoservice, microservice, macroservice, right-sized-service or a monolith? So much has been written about these different architectural approaches.

We are already behind this comparison of “good” vs. “bad” discussions. This is good timing to approach it in a different way and I truly believe that this conversation should be changed completely. We should talk further about what comes with any of these approaches and that, no matter what you choose, if you build it right you can always change, select an approach or just mix between them.

If you follow that topic closely, you can hear more leaders in the industry talk about “macroservices” as companies start to realize that adopting “microservices” might sound great but it arrives with a cost that they didn’t consider while building their systems. There are so many great advantages in building systems in a microservices architecture but it’s not always the right fit for any type of organization. It depends on so many factors and that’s why you hear that more teams are starting to be conservative in their decisions and consolidate their services.

I’m not that old but it’s interesting to look back and point my finger on any timeframe and see how trends come and go in our industry. These days it became very popular to talk about the cool trendy stuff that the technology giants implement. The “buzz” around them brings you into a mindset that choosing such an architectural approach will solve all your problems, and in the end if Google chose them, why shouldn’t you?

This is the kind of feeling that very likely can lead you to do it wrong — you are feeling this is the “Holy Grail” and what you were always dreaming of — you will scale easily, be resilient, deploy faster and so on. Obviously, we as engineers love being on the edge and implement new stuff. The reality is very different.

Finally, these days bring an amazing opportunity for us engineers. As we develop more of cloud native applications, we get lots of power in our hands — you can easily spin up any service that you build, deploy it on your own, use any cutting-edge infrastructure that you ever dreamed of, but it always come with a cost  — “with great power there must also come great responsibility.”

I attended QCon London 2020 — just as a side note it is unbelievable that it was not so far and today we are in a totally different world with many of the challenges that COVID-19 brings — it was great to see how the industry has grown up and there were many talks that were around cloud native “lessons learned.” One of the inspiring talks was given by “Building Microservices” author Sam Newman. “Microservices guru warns devs that trendy architecture shouldn’t be the default for every app, but ‘a last resort,’” is how The Register summarized it, and honestly I can’t express that better than that.

Newman also wrote that  microservices are “an architectural approach, not the architectural approach.”  If you follow this topic closely, you might be aware of the debate that is going on lately between some of the technology leaders in the industry around it — just one of them is this debate between Kesley Hightower and Ben Sigelman on The New Stack Context podcast.

I’m very happy to see that finally, the conversation is changing as we grow up along with the maturity of these approaches in architecting our cloud native applications.

If I can influence the conversation, I would like to see how we focus more on the following:

• The cost  that comes with each approach and if your company is really ready to pay that cost while developing its products to deliver value to their customers. As in everything we choose (at least in technology), there is always a cost and you should consider if it fits well with your goals. There are many posts that compare microservices versus monoliths, how you should migrate from monoliths to microservices and there are even posts that claim you should build nano services just because great technology companies do that (just name one and you will probably find a post on that). The problem is that much less talk about the challenges that come with microservices architecture and their lessons learned. No matter what the architectural approach that you choose in that spectrum of nano-to-mono or a “mix,” you should make sure that your software is designed in such a way that it will always be maintainable and, as you scale, it can grow with you.
• Services structure: It doesn’t really matter what the size of your service, but you should ask yourself (and be honest): is it built well? Is your service built around a well-defined domain, is it really decoupled with its own logic and can evolve with your business to bring value to your customers fast? If you read Martin Fowler and Eric Evans articles it’s obviously a good time to explore these areas.

credit: Lightstep

Just as an example, if we pick one of your services, what’s the chain of calls it has to make in order to complete your request successfully? What it takes to add a new functionality, do you need to refactor the whole module or just develop an additional layer and you are done? All these questions should be considered well while choosing your next architectural approach. This is what we may need to discuss while making our decision and be honest if it really works for us. Can we really deliver better software or do we pay much more to fix the challenges that have been created by us? As you quickly can get, it doesn’t really matter what the architecture approach that you choose, it first depends on how your software is built and then you can always pick the right approach now and change it later on while you grow and face new challenges.

• Implementation retrospective :  What are your pain points today and if you already implemented one or more of the architectural approaches, what are the lessons learned as you scaled along with the maturity of your product? What changes have you done to fit it right in your company and most importantly what did not work for you? Sometimes companies choose one of the approaches because they think that it’s going to solve all their problems. As they start to scale, the company quickly realizes that there are many new problems that they did not take into account while choosing this approach and that are hard to solve in the situation that they are in now  —  for example, the team doesn’t have the necessary skills. One of the new challenges that they might realize is how to troubleshoot a cloud native application which can negatively impact the software delivery processes. There are many other questions that are interesting to discuss, such as: how did you solve your teams dependency, how does it impact your SLAs, who maintains this service end-to-end ? These questions lead us directly into the last area that I think we should explore .
• Can your company structure support these engineering decisions? Are you a small startup company (with one engineering team) or do you have many teams that are going to touch each other’s lines of code while developing a feature or fixing a bug? Did you build the right environment to support your engineers in being independent? And so on. All these questions have to be further discussed and as said earlier, the community should contribute to these conversations in order to prevent other companies from doing the mistakes that they have done or at least understand the best practices that they followed to succeed in that journey.

It’s very important that our conversation around the different architectural approaches in developing cloud native applications will be changed from into an insightful discussion that highlight the benefits but will also show what didn’t work. I just raised here some of the areas that can be interesting to explore.

I truly believe that microservices bring many advantages. We build microservices in our company as well but we try to invest the time thinking if this new functionality is really worth another service of its own or it can be a good fit in one of the services that already built around this domain. It is important for us to invest the time to think because we understand the challenges that new services bring with them.

Let’s take our conversations on this topic to the next level in order to contribute to the evolution of these cloud native architectural approaches.

Happy coding!