Ask HN: Is this microservices madness? | Hacker News Reader

Ask HN: Is this microservices madness?

A bit of background: I work in a small finance company in Tokyo with ~20 people in IT. The structure of this department is everyone responds straight to the CTO so it's somewhat chaotic.

I am the front-end person in a team doing a single product. Besides me, there's only the back-end guy (our direct boss is the CTO). As per our CTO instructions, the back-end is structured with microservices in go. So 1 developer is designing, launching and maintaining something like 8-10 microservices. Things also change quite frequently from our CTO random recommendations.

I feel this is madness, and our main back-end guy works very long hours and is visibly burned. I am worried both for him and for the quality (or even launch) of the product. There's no single process or workflow that works smoothly.

How common/rare is this about microservices? What would you recommend me doing (besides jumping ship)?

View on HN

4-6 people (the two pizza rule) per microservice makes sense, so you're only off by two orders of magnitude.

They wanted the back-end guy to be only 50% of his time in this project and the other 50% in another project initially! Luckily they understood it didn't make any kind of sense at some point. Not that now it makes more sense, but...

The unfortunate thing is that this kind of stuff happens in our industry, regardless of architecture choices. Many developers are overworked through a combination of being short staffed and poorly managed.

The odds of being able to change this company are quite low. So, you'll need to make a choice. Do you want to stay until it starts to hurt your health, or do you want to leave and risk long term unemployment?

If you want to stick it out, you might need to take control of the team. In that case, I'd start by figuring out why the developer is having problems maintaining 10 microservices. Is it death by agile, is Go the wrong tool, or is it a case of massive technical debt? Or, was the whole project built by a burned out developer?

Once you figure out what's going on, you'll have to be open and honest with your CTO. Maybe your CTO needs to back off? Maybe your CTO needs to get more involved and start writing code? Maybe the other developer just isn't cut out for the company?

Oh, I am great now. While it's not fulfilling, I have a fairly relaxed timeline (since it's the same deadline as the back-end) so I've done some learning, refactoring, cleanup, and extensive testing without any overwork.

The project is new, so he has to create those 10 microservices from scratch. Someone is helping out managing the infra, but still there's quite a big burden on the dev.

I think some optimal solutions might be to put a manager/dev lead in the middle to help out, let the team self-organize properly (cannot do that though since it's finance) or hire more devs. All of those would take months probably.

First, I hope that you stay great. You've got compassion for the other developer, plus a good sense of what's wrong in an engineering culture. It would be upsetting for our industry to lose that to burnout or worse.

In your CTO's defense, assuming we define microservices in roughly the same way, I think a single developer should be able to handle 10 microservices. If a developer couldn't, I'd want to look at contributing factors like death by agile, technical debt and a shitty stack. If none of those are the case, is the developer burned out? Or does she have the skill/demeanour to even do the work in that company?

And sadly, you likely don't have time to ship the project and lobby for a major organizational change. I think you either need to be that manager in the middle (you're definitely capable, Manager), or alternately, how is your Go???

Good luck - I'll be thinking about you.

That many microservices from the beginning is premature optimization. I'm not really convinced it would ever be an optimization, honestly.

It sounds like your manager sucks and work culture isn't great. Why not apply for other jobs while you're there? It doesn't hurt to have options.

Maybe when my Japanese gets better (I'm learning!) and I've been here a bit longer (don't want to seem a job-hopper, specially in Japan).

we know nothing about what this system is doing. Being finance there could be a lot of out of band requirements that mean SOA/microservice architecture is the correct paradigm, and that the number of services is the least they need right now.

But without actually knowing what the system is doing and what it's constraints are, there is no blanked too-many, not-enough, they're-doing-it-wrong.

I think the backend guy should raise the problem to CTO. If he doesn't do it, either he is fine for that or he is not brave to say it out. (Is he a Japanese?)

I am also working in Tokyo but I resigned yesterday. I think frontend developer is easier to get a job than backend developer (me).

There was a similar thread on HN a few days ago. Tl;dr: Likely some incredibly dumb architecture choices were made in your situation.

https://news.ycombinator.com/item?id=17585936

Reply on news.ycombinator.com