A few years ago I was in a leads meeting; all engineering leads and higher go to it, so it also included managers, directors, the VP, even the CTO. My team had asked me about getting more whiteboard space, so I wanted to bring it up. Oddly enough, it became one of the most frustrating experiences in my career, yeah... all because of a whiteboard.
It was for a well funded and successful startup, we spent loads of money on more frivolous things like parties; I didn't think I'd find any objections. I was wrong. It became a discussion about how we already had some, and there's more down the hall – a lot of solutioning, which isn't a bad thing in itself, but it was 30 plus minutes of this. My shock and frustration aside, I was talking to another lead in the hall after and I said: "you know, how expensive was that conversation?". I did some quick math and it was easily over $500.
It would have been cheaper to just buy the whiteboard.
So what do whiteboards have to do with microservices? Well... a lot. As employees, our goal is to add value, and as engineers, our value add is often pretty easily measurable. It's great we are smart enough to solve the great whiteboard shortage of 2019, but sometimes it's not worth the cost, and being too aggressive about microservices has that same cost.
I was trying to explain this to a bartender the other day. I was getting some dinner and she asked me what challenges my job has. I immediately thought of microservices. All of the drinking glasses sit above her head, she can just slide one out, where she stands, and start pouring. I asked: "what if the glasses were in the other room?". A bit of an odd question... but in development, it's ideal that everything has its own dedicated space. There could be an awesome storage setup, where the glasses are dispensed to her, automatically even. But she would have to go to the other room, constantly, so how ideal is it? I often feel this way about microservices, as well. If I have to change between multiple projects and do releases (and wait for them!), I think something is wrong.
We all know the upsides to microservices, but I've spent thousands and thousands of dollars waiting for builds and releases, and I don't feel good about that. I want to be productive, the customer and the business wins when I am. I love the phrase:
no abstraction > a bad abstraction.
And it totally applies here. It's great everything is infinitely scalable, but if we can't change the code quickly, everyone is losing.
So here is my proposal: microservices should be better thought out. Start by breaking up everything internally in your code, into logical modules and services. If you later find one part of the code needs to scale, pull it out, and do it. It shouldn't take a lot of effort, because you already have a decent abstraction. Things that are critical and unlikely to change much over time, you can go ahead and break it out, if you have the resources to do so. These would be things like a service that sends emails or logs events. And lastly, it makes sense to do this for your frameworks, if (big if) you have a team that's dedicated to supporting it.
In closing, I just want to build things that customers love and make my company money, so I can put food on my table. I don't want to spend my time waiting for builds or arguing over a $100 whiteboard. I challenge everyone who reads this to think about valuable their time is, and to not rely on an "all or nothing" attitude, to look at the things they spend the most time on, and see if they can shave off a few minutes from those tasks. It really does add up over time.