Hacker News Reader

So much this. Same goes with all the Kafka usage, making development literally Kafkaesque. The data eventually flows through your microservice landscape, being eventually consistent and performance issues become a whole different nightmare. Yea, maybe I just didn't read enough of the documentation but maybe your 1500 users per month web-app doesn't need 7 microservices and Kafka as single source of truth, all hold together by 8 developers.

It's astonishing how many teams want to use cool tech instead of create a great tool for users or how many teams think that technology will solve bad management.

So much this! As someone that regularly deals with data platforms and data engineering issues this nails it.

Today’s desire to make everything event driven and “real-time” boggles the mind. Solutions are contorted to fit the Kafka operating model.

The inevitable result is blog posts about how “we solved our self inflicted problems that would have never existed if we chose a sane design for our real problem. “

Oh and never forget that no senior stake holder ever really checks their info/dashboards in real time. Never mind actually making decisions in real time based on it.

Same! My dataengineering team wants everything to be moved from batch oriented to 'stream oriented'. We are replacing our batch workflows to flink/spark streaming. But no one has been able to answer me what business use cases need streaming or what if any problem is being solved by this added level of complexity.

Sometimes, streaming makes sense. When I was at a FAANG, we had a sampled streaming database with nice plots (kinda, ugly but functional).

This was incredibly useful as it allowed teams to figure out what had happened in prod without needing to wait for the next day's batch jobs.

OTOH, most companies don't need something this complicated, and I'd imagine you could do the same with MySQL/Postgres if you're not at FAANG scale.

I agree. When it is the right solution to the problem at hand there is nothing better than a good streaming solution.

It goes for pretty much all technology, that you need to choose the right tool for the job. For some reason the marketing just gets most people all worked up and ready to fit problems into technology that was never designed for their problems.

I migrated a unmaintainable over engineered java spring application consisting of around 20 micro services using Kafka all over the place to one single Rust application. A relief for anyone in the company.

One reason this can be doable is that working in the 20 microservice environment is so unproductive that the original app probably did very little.

Exactly. Making sure those services work in production, and the constant troubleshooting in local environments as well would easily be most of the developers' days.

Just you alone? Do others in the company know Rust?

I really like the idea of Rust I just worry about how things shake out In The Real World(tm).

I have no doubt Rust is here to stay for a while so I think it’s pretty solid play when appropriate.

What happened to the people who worked on those 20 microservices. What do they do now?

A few walked away. They did not agree with the move. But the company was really in the need for a radical change since development was stuck in complexity and maintainance.

Are you saying you rewrote not just the Spring application but all of the micro services as well?

I understood it as a distributed spring application.

Note the relationship between the size of the team and the ability to manage a monolith.

A team that grows larger quickly needs some way to manage the complexity within the codebase and the difficulty of knowing whom to talk to. In theory, it is possible to build a modular monolith with clear ownership boundaries. In practice, this requires strong technical leadership.

Kelsey Hightower, a core Kubernetes engineer, once said that microservices were created because teams didn't want to talk to each other. One problem - they still have to talk to each other.

Its a question of how much they need to talk together.

My current company has a code base which, if we want to avoid falling into technical bankruptcy, teams will need to spend 35 hours per week talking to other teams. The goal of well-defined interfaces is to reduce that to 2-5 hours per week.

Saying “microservices” is a concise yet oversimplified way to describe what is actually needed: well-defined modules with clearly-visible boundaries.

> Kelsey Hightower, a core Kubernetes engineer,

Not sure what you mean by 'core' but my impression was that he was more of an evangelist and a community manager.

My understanding of his role is vague, but my point is more that, even as an "evangelist" of K8S, he is not going to suggest that you use it because Google does.

Yup, papito is absolutely correct; microservices are just Conway's law. They're not for scaling the software, they're for scaling the organisation.

Which is why I wish there was a meaningful term like “pizza-sized services” as a way to say “these don’t need to be tiny, but they do need to be small enough that a 4-8 person team can handle the mental load of managing them.”

It always surprise me why startups want to grow in amount of people.

I see this picture quite often. There is a small team that managed to create a great product. Then they get investmens, grow in size, hired a few starts that worked before in FAANG like companies and now trying to adopt microservices. The initial team spirit is gone, people who worked there from the leaving

Sometimes it's done for smoke and mirrors more than anything else. There's suddenly a ton of money pushing in your door,so people decide to start adding random titles to the payroll,even though it's probably still those 5-10 guys that making it all tick.

Because they need to grow users and build a moat against competitors. If your product was made in 6 months by 5 engineers then a competitor can (and will) do the same. Users will generally want new features or capabilities or other such things. Boring but time consuming work not matter how well engineered your product is. This type of work is very different from a green field new product so it'd be odd if many people didn't leave during the shift.

I'm generally in your camp (having been through 3 monolith-to-microservices migrations), but to be fair, at least two of your examples are pretty massive outliers:

* Instagram barely had any features when it was acquired - the entire API was like 3-4 endpoints, and all the web version did was literally _show a single photo_

* Whatsapp was extremely brilliant in its implementation/choice of language (erlang) - they beat competition's headcount 10:1 for the same scale due to that, but hiring Erlang engineers is no easy feat

Facebook is also famous for its monolith approach, so I wouldn't necessarily put Google and Facebook on the same page when it comes to the CS Gods they worship (-:

One shouldn't use outliers and one off examples to guide one's behaviors. Most startups will fail miserably. Most of the ones that don't and do eventually succeed will grow over time to a decently large size before exiting. So you should expect that trajectory and not a lucky exit before you hit 50 employees.

True, but existence proofs are useful if you don’t extrapolate too much from them. Ie you _can_ be a unicorn with a monolith.

I think it’s not so useful to look at 30-person monoliths though, as you say. I’m sure there are 30-person startups that are jumping the gun and building microservice architectures? Don’t do that. First build the monolith.

But I think what you are getting at in the latter part, and I agree: the question is whether there are 100, or 1000 employee-company monoliths. I don’t know of any, I’d guess there are some examples, but I’d be comfortable wagering that they are much rarer the bigger you get.

Instagram is still a monolith. They started breaking out some high-load things for sure, but only once it makes data-driven sense.

https://instagram-engineering.com/static-analysis-at-scale-a...

> you _can_ be a unicorn with a monolith

Even if another company can do it...that does not mean that you can. Know thyself.

Jocko Willink can lead a team effectively on 5 hours of sleep a night. If I try to do that, I lose my grip on the fabric reality and the meanings of words.

Know thyself.

I agree, I think what is unsaid, but assumed, in the article is that the owners of the business want to maximize profit. Other types of organizations (for example hackers organizing around Linux kernel development) do not share that goal and don't have this type of problem.

> Instagram? Monolith. 12 people when sold to Facebook.

So your metric for succes is acquisition size, not good software design?

Companies sell working product and large, active user bases - not "good software design", a metric subjective at best. What you may call good design, I may call "unnecessary and wasteful over-engineering".

Yes, I was planning to edit my comment to add a better description of what I meant (and move from writing on mobile, to typing on my computer), but then I completely forgot about it.

So yes, agreed: 'good software' is absolutely subjective.

My point about 'good software' was about creating non-bloated, modular software - software that is well documented and easy for others to collaborate on, contribute to, or take over.