On Discipline

I recently had a colleague send me an article entitled Microservices, Please don’t in which the author identifies several “falacies” that are surrounding the microservices craze. I don’t take issue with the topic or even any of the “falacies” the author outlines in the article. What I do take issue with is the (I assume) intentional mis-titling of the article, which misleads the user into thinking the author is going to present convincing reasons not to use microservices. Instead, the article points out common cultural misconceptions about how microservices will solve all their problems and then vaguely sums up with “[before you use microservices, simply understand] the domain you’re working in…”.

The article is no better than click bait really, which I won’t bother to rant about as I’m sure others have done so.

My response to my colleage:

The article seems to talk more about cultural problems than engineering.
Complexity is complexity, regardless of your architecture, either approach
can be taken to the extreme (to dire consequence). This kind of rhetoric is
akin to “PHP, please don’t”. PHP can be wielded as wonderfully or terribly as
any other language. It’s not the tool or pattern that is as important as the
team that is wielding it.

Discipline

I guess what I really wanted to write about in this post was the topic of discpline, or the lack thereof. The article speaks to a lack of discipline more than an engineering problem, just as someone criticizing the use of PHP is really pointing out their inability to use the language effectively, not because of a lack of features, but because of a lack of discipline.

Same goes for perl.

Same goes for java.

Same goes for microservices.

Final thoughts

Use microservices or don’t. Use the monolith or don’t. It doesn’t really matter. What does matter is that your team understands the approch they’re taking and the tools they’re using, through debate, experimentation, and failure. There is no “one true way”. There is no “one true light”. Put your teams and their conversations over your tools and your patterns.

Did you fail? Good. Talk about it, don’t blame. I don’t know of any organization where success is guaranteed every time. But every organization I know that banks all their success on their first (and only) implementation fails, and subsequently creates a culture of blame, either for the “old guard” developers, past employees, or someone else on the team.

Set yourself up for success by practicing failure

Discuss, argue, agree, experiment, repeat. Do this with discipline. This is the only way you’re going to find the “magic recipe” that actually works for your organization, be it microservices, or the monolith.