Monoliths, Microservices, Nanoservices, Serverless and Macroservices – so many architectural styles to choose from. Some are considered outdated, some are considered cutting edge. None of these styles are inherently good or bad, as it all really depends on the context. Still, every time an architectural style emerges and receives the limelight, we have a tendency to jump right in and treat it as an architectural absolute. When something new surfaces, the old must go!

Instead of asking how this will benefit the business, we dive into strange discussions. For example, how big should a Microservice be? Some answers to this question have been helpful over the years, such as a single business capability or responsibility. Others have been not larger than what I can read on one screen!

At an architecture non-conference in 2014, I found myself part of a group discussing Microservices. Everyone was very curious about what Microservices were, their benefits and challenges, what solution they could be, and to what problem. During this discussion a peer architect proudly announced that his business (a bank) already was running 1400 microservices! There might have been a valid reason for so many Microservices, but I do still to this day wonder what pain they solved by introducing so many Microservices – and at what cost.

The takeaway from that event and a long stretch of time after that was that monoliths now were considered something to avoid. Microservices were the new goal architecture.

We go too far like this over and over. A hangover with Microservices is imminent. The serverless hangover is a little further out on the horizon. Macroservices to the rescue!

Dave has a point. It is time to realize that it does not work in our favor to let ourselves be so easily swayed into throwing our current knowledge and architecture design out the window. Remember, there are businesses out there that thrive on, if not inventing new concepts, then at least pushing them intensely and selling consultancy services and conferences.

Again, I want to stress- Monoliths, Microservices, Nanoservices and Macroservices – none of these are necessarily bad or wrong. In fact, it is good to have a well equipped toolbox. The problem is the overzealous march towards the new while disbanding the old without thought.

What is the alternative?

Well first, based on my own experience, which I will dive into shortly, I urge you to step back and decide not to drink the Kool-Aid. Be more relaxed about your architectural style. Yes. It. Really. Does. Depend. That is not just an industry joke. Have your strong opinions, but hold them loosely, as they say. It does not need to be black and white, one or the other, good versus evil. Monoliths can be good, Monoliths, microservices and serverless functions can co-exist in the same architecture, if your needs have evolved this way. They should, barring a real and concrete need to rewrite an entire solution, at most be considered an addition to the existing architectural toolbox.

Second, I urge you to focus on making Stellar software, figuratively and literally. Figuratively, in the sense that you focus on the business needs at hand and try to solve them as best a you can, with architectural styles that fit. As for literally, let us walk through a real example.

Stellar software example

When we started Position Green, there existed nothing but a monolith. This monolith contained all functionality and fulfilled the needs at the time.

We then gained a new client. They selected us for our existing feature set, but also wanted to add their own functionality. We promised them that this was possible. However, we decided against adding their special needs to the monolith. Instead, we wanted to add it as a separate sub-system (Microservice, perhaps?). But before we could do that, we needed a Single Sign-On solution to cover both and future sub-systems (and APIs). The authentication functionality was carved out and the Login sub-system was born.

After Login was added, we could add the clients specific functionality. This was an exciting and rather large addition. By adding it as a separate sub-system we avoided cluttering our standard system with client specific code. Of course, we also gained some complexity, but overall it was worth it.

Later on we needed to be able to store client specific extensions to our system. We opted to make use of a platform that could host these extensions as serverless functions. Again, we added to our architecture.

As the software evolved and as time passed, it was clear that the monolith would not disappear any time soon. That was okay. Even some new features were best placed with the monolith, but with proper modular separation, following the principles of Domain-Driven Design.

The interesting part of this is how our architecture evolved. The monolith had gravity, both in terms of existing functionality and also in decisions when considering a “home” for new functionality. We had a discussion and made a decision every time something new was to be added. We had no Microservice rule. In many ways our architecture acted like a solar system, with one central star (monolith) and several planets (sub-systems) that manifested when needed. It was a Stellar software architecture, figuratively and literally!

For the sceptic

The sceptic in you might ask if this evolution was not portended by the existence of the monolith early on? Maybe, but let me add here that I have been part of a very large greenfield Microservice-first project, and even here the services were naturally different in size. There were different classes of services, the largest being the one that solved the primary needs in the domain. In other words, it was more balanced, but there was definitely a similar pattern.

In conclusion, I urge you to leave the religious and toxic battles on Monoliths vs Microservices vs Macroservices vs serverless behind and choose purely from what you know is needed at a given time.