Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It’s 100% a question of scale. And I don’t mean throughput, I mean domain and business logic complexity that requires an army of engineers.

Just as it’s foolish to create dozens of services if you have a 10-person team, you don’t really get much out of a service mesh if you only have a handful of services and not feeling the pain with your traditional tooling.

But once you get to large scale with convoluted business logic that is hard to reason about because so many teams are involved, the search for scalable abstractions begin. Service mesh then becomes useful because it is completely orthogonal to biz logic and you can now add engineers 100% focused on tooling and operations, and product engineers can think a lot less about certain classes of reliability and security concerns.

Of course in todays era of resume driven development, and the huge comp paid by FAANGs, you are going to get a ton of young devs pushing for service mesh way before it makes sense. I can’t say I blame them, but keep your wits about you!



If you can convince your business folks to run shit on the command-line then there is basically no need for services ever. I know it sounds insane but its how it was done in the old days and there really is only a false barrier to doing it again.


Place I worked had support staff copy-pasting mongo queries from google docs -- worked in the early days but eventually you have to start building an admin interface for more complicated processes

When it was just mongo installs are easy since they only needed a mongo desktop client


Terminal can handle auth.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: