Microservices: Creationism versus Evolutionism

This morning a friend (@vgrgic) tweeted the following quote from Martin Fowler:

“So if you can keep your system simple enough to avoid the need for microservices: do.”

This is absolutely true I think, microservices are far from the silver bullet some people want you to believe. They do have a place in software architecture obviously, but there is always a ‘it depends’.


A lot of microservices ‘experts’ I’ve met are creationists. When they start designing an application (the last two years), they break the requirements down into pieces. Once they start coding they instantly create small services and connect them. But in my experience, this has a major drawback. When doing this, you’ll need to make quite a lot of assumptions upfront on what the future of the service will hold and how it will grow. Once you’ve created small services they have very strong boundaries, those boundaries really dictate and limit how your application can and will grow. This can work well, only if all your assumptions turn out to be true, but really, how often does that happen?


I’ve labelled myself as a design evolutionist. Always start with a monolith. Properly separate the concerns in your code, keep it really clean and tidy. Always be aware of what each piece of code does and if it belongs where you just wrote it. In the best scenario, you’ll end up with a simple, well build, working monolith! This is also what Martin Fowler describes in his piece on MicroservicePremium. There is a point where the monolith becomes a burden to manage. Once you reach that point, and you’ve payed proper attention to the separation of concerns, it should be trivial to cut loose a well defined microservice from your code.

Rant about the hype

Warning: The following paragraph is full of nonsense.

Until recently I couldn’t understand the microservices hype. Why is it suddenly this popular? But recently I’ve seen the light. I now know why so many people like it. Microservices has a wide appeal for many wrong reasons.

  1. Architects (like me) like it because it solves one kind of problem really well, managing and maintaining a huge application.
  2. The DevOps community likes it because they have a lot to do when you have heaps of services.
  3. Large SOA/ESB companies like it, they almost went bankrupt and out of fashion, but now they can sell their crappy tooling again as it ‘enables microservices’.
  4. The OSGi community likes it, they too can use the term microservices to sell OSGi tooling and knowledge.
  5. Application servers like it because they can create tooling to enable microservices.
  6. Monitoring companies found a new gap in the market, they can now sell microservices monitoring tools…
  7. Etc etc et fucking cetera!