Improving Wetware

Because technology is never the issue

Microservices, the Cloud and Us

Posted by Pete McBreen 24 Aug 2021 at 21:04

In a presentation on Modular Monoliths Simon Brown had a great comment on Microservices

If you can’t build a modular monolith, what makes you think microservices is the answer?

Or as Architect Clippy said it

I see you have a poorly structured monolith. Would you like me to convert it into a poorly structured set of microservices?

Marcus Ranum has had similar thoughts

I love it when software developers say “How hard can it be?!” and decide to build their own complete replacement system. The results are usually about as bad as the first system, for the same reason. To be fair, this stuff is really hard to write – which is all the more reason to be skeptical when someone says they’ll just put together a modular cloud-based version of their own. You should always ask “why do you believe you will get right the things that everyone else got wrong? Because the reasons that they got it wrong apply to you, as well.”

Overall it seems that although the cloud and microservices are seen as synonymous, microservices bring with them a lot of extra complexity and interdependencies that cost time and effort to resolve and work around. Justin Etheredge has written that it is all about scale

The problems I’ve dealt with are not at the scale of Google, Facebook, or Uber.

Few organizations have to deal with the problem of how to coordinate more than 100 developers. Yes, Spotify and Amazon have that sort of problem, but most of us do not. So it is therefore very likely that the solutions that work for their scale of problem might not be the best ones for the rest of us.

An example that I have seen recently is that of a web application that was moved from the old style LAMP stack to an Angular single page application front end supported by a REST API at the backend. So now a change to the requirements meant that the release of the typescript changes to the angular pages had to be coordinated with the release of the REST API changes (which needed to be versioned in case there were old clients using the prior version of the service).

Revisiting "Applying the Lessons of eXtreme Programming"

Posted by Pete McBreen 11 Aug 2021 at 17:37

Way back in 2000 for the TOOLS34 conference I wrote an article Applying the Lessons of eXtreme Programming and it was interesting to look back at it to see how things have worked out since then.

  • Applying JUnit – the unit test frameworks as not as widely utilized as I expected, but now all modern programming languages ship with a flavor of unit testing built in
  • Be intolerant of process variations and working off process – many teams have not learned this lesson and have problems arising from this
  • Use a coach to keep the team on process and improve individual skills – this does not seem to have caught on, even in teams that use Scrum, the scrum master role does not always enforce process
  • Apply the Quality First Strategy – I still see to many teams that allow code to be merged without adequate tests that later prove to contain incorrect code
  • Continuous Integration is the only way to avoid Integration Hell – I’d soften this to a way to avoid, and many teams still have problems making this work
  • Tired humans produce lousy software – still true, and even agile teams sometimes forget this
  • Incremental Development requires Incremental Requirements Capture – still true, some teams are getting good at this
  • Simple Designs are easier to maintain and evolve – in the era of microservices, we seem to be forgetting this lesson. Yes the microservices themselves are simple, but the interaction between multiple microservices are really hard to maintain for a lot of teams
  • Adjust your development process slowly and measure the effects of the change – I still think this is a good lesson from XP, but all too many teams are not very good at this
  • Many projects would benefit from a good dose of Reality Therapy – still true unfortunately