Monoliths, Monoliths, Monoliths…

  • They started with micro-services and are continuing to develop;
  • They started with a monolith and are continuing to develop;
  • They are breaking out a monolith into micro-services;

Specific Micro-service Technology Problems

Some of the examples of technology problems I’ve seen in teams adopting the micro-service approach include:

  • Focusing solely on synchronous communication and ignoring asynchronous communication entirely. This means broken business processes because of downstream failures in services;
  • Not understanding when choreography and orchestration should be used to support business processes;
  • Slicing things way too thinly meaning you end up with 50/60 micro-services to manage with associated database(s), deployment pipelines, monitoring, security concerns etc… etc…
  • Completely ignoring the amount of effort required to package, deploy and monitor your services in the production environment — especially if you’re working with a multi-repo rather than mono-repo approach.

Team Challenges

There are several challenges with teams starting out with the micro-service approach over a monolith:

  • Micro-services technical and operations experience — most people are doing this for the first time and learning on the job;
  • Domain experience and constructing appropriate bounded contexts — most people end up slicing way too thin;
  • Resource constraints around developers and devops — lots of startups are working on the 5–10 people in tech with possibly 1–2 people managing the operational side;
  • Somebody-read-about-something-on-medium and wants to implement micro-services, but doesn’t really know what they’re doing.

The Micro-service Startup Trap

If you’re running a startup and think that micro-services is the right approach then highly suggest you reconsider your choice, or at the very-least tread very carefully with the decision, or speak to a consultant who has been through this pain before with a team. It could mean:

  • Longer time to market, potentially a frustrated business who don’t understand “why building it is taking so long”;
  • A higher bar required in terms of technical skills required and longer time to do hiring;
  • Increased operational costs on Azure, AWS, GCP due to the number of services you need to deploy as EC2 containers, ECS tasks etc…., the increased number of database instances, monitoring etc… etc…;

Monoliths Aren’t Perfect

Monoliths aren’t perfect — don’t get me wrong. Consider the big monolithic Java application with hungry resource requirements (big heap, long GC etc…). If one thing blows up, it all blows up. However, most startups won’t necessarily have a huge fully blown application with 150 features until several years in.

  • An application that has hundreds of users generating PDF’s;
  • An application that generates image thumbnails;

In Conclusion

I’m an interim and fractional CTO working with startups, scale-ups and bigger companies on product and technology challenges. A lot of the problems here I’ve seen first hand as an engineer, manager and architect with businesses and had to solve. You can talk to me, hire me here:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store