
Ask HN: Is this microservices madness? - throwaway3265
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&#x27;s somewhat chaotic.<p>I am the front-end person in a team doing a single product. Besides me, there&#x27;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.<p>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&#x27;s no single process or workflow that works smoothly.<p>How common&#x2F;rare is this about microservices? What would you recommend me doing (besides jumping ship)?
======
wmf
4-6 people (the two pizza rule) per microservice makes sense, so you're only
off by two orders of magnitude.

~~~
throwaway3265
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...

------
hluska
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?

~~~
throwaway3265
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.

~~~
hluska
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.

------
smt88
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.

~~~
thisone
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.

------
franzwong
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).

------
bjourne
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](https://news.ycombinator.com/item?id=17585936)

