The technology world loves a trend. A bandwagon. The “in” thing. A fashionable choice.

Partly that’s a defense mechanism, it’s tough to be unique when you want community support later - Stack Overflow isn’t going to be filled with answers to questions only your company has.

It can also help with a problem we’ll write about another time, where the number of options available to solve most problems has reached astronomical levels and frankly going with the crowd is probably easier than making an objective choice.

Follow the crowd?

Where the crowd is going right now is the land of Microservices, just next to the Single Page Application (SPA) river. But we don’t think you should follow them, not unless you really understand what you’re getting into.

The problem with Microservices, and the Javascript powered SPA, is that of complexity.

Where you previously ran your whole web application server-side, now a fair proportion of it runs in the browser. So now you have to think about not only your technology choice, but that of all of your customers too.

The challenges

Where your application code previously called methods or functions to retrieve back information from another part of your database, it may now be retrieving that information from another service over the network. So that means you’ll now have to deal with the additional latency that will bring.

Where you once ran a set of servers and optimised your application to run at it’s best, you might now have to run 100 applications and get them all to talk to each other without causing too much network overload. That’s before you worry about keeping them all up to date, or count how many database servers you’ll need to keep data segregated.

There are solutions for these problems of course. There’s no shortage of containerisation and orchestration models, messaging and queuing systems, caching tools, packaging and deployment techniques or even ways to run part of your SPA on the server.

But if you’re a small development company, is that the best use of your time? How many systems engineers are you going to hire to set all that up for you and keep it all running? Instead of adding customer value through new features, are you prepared for the additional engineering effort required to just make all of this hang together?

And that’s the trap. You’ve designed your application for a mythical future where it’s used by the whole world, rather than the 12 customers you really have.

Why so popular?

If you’re Facebook or Google or Amazon, where these ideas have been popularised, that’s not really going be a problem for you. If you have 10,000 developers, splitting your codebase into hundreds or thousands of individual services is probably necessary just to get any forward momentum at all. It would be incredibly difficult to have that many developers all working on a single application.

But you’re probably not Facebook.

It’s understandable why these ideas become popular. Those companies write their own blog posts about them, and they get shared across the Internet because others in the technical field want to know how they manage to run a service that deals with that many users on a daily basis. That Amazon choose this as a way to run their development may make it seem like a good solution to your own problems.

But once again, you’re probably not Amazon.

Pragmatic choices

This is why it’s important to not follow trends, but instead making pragmatic choices based on your own situation. That’s just a good lesson for life generally.

Now this doesn’t mean we should design our application as a monolith that can never be broken apart. It doesn’t mean that some applications wouldn’t benefit from having part of it run in the browser. It doesn’t mean that an API on Lambda can’t be the right choice for your project. Nor does it mean that server-generated HTML is the answer to every problem. Of course not. This is not the land of extremes.

But Microservices are a premature optimisation, something Donald Knuth described as the root of all evil. They shouldn’t be the starting point that you hang everything else on. Unless you really do have 1,000 developers, or if you just don’t believe technology designs from 20 years ago still work just fine.

Contact us if you want to talk more about the right design decisions for your development project.

Photo by JJ Ying on Unsplash