5 ms·

You know what the path of high performance teams is? Not growing that fast. The children of Google, Facebook, and other Giants dispersed across the lands, beget

by papito 5y ago

You know what the path of high performance teams is? Not growing that fast. The children of Google, Facebook, and other Giants dispersed across the lands, begetting many an offspring, who worshipped their lord, Complexity, solving problems they don't have. Don't solve problems you don't have. Most companies think they need microservices, for example. It is an extremely expensive proposition. Debugging anything becomes a nightmare and developer ergonomics are shot to hell. There is a reason why we stayed away from distributed services in the past. What, you think I could not have stitched together 20 different Python services on my machine in 2009 and put my productivity into paralysis? Don't fool yourself about things like Docker making things easier. It doesn't help people reason about distributed systems. Instagram? Monolith. 12 people when sold to Facebook. WhatsApp? Monolith. 32 people when sold to Facebook. StackOverflow. Monolith, with a lite SQL ORM for highly optimized queries. Look at that - all those things we did in 2004, still work like a charm. But heyo, go ahead and spend a few months learning Kubernetes while the lean companies laugh at you in the rear-view mirror.

vasergen 5y ago
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
- cosmodisk 5y ago
  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.
- marcinzm 5y ago
  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.
deleted 5y ago
[deleted]
afarrell 5y ago
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.
- papito 5y ago
  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.
  - afarrell 5y ago
    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.
  - dominotw 5y ago
    > 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.
    - papito 5y ago
      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.
- pjc50 5y ago
  Yup, papito is absolutely correct; microservices are just Conway's law. They're not for scaling the software, they're for scaling the organisation.
tonyjstark 5y ago
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.
- holoduke 5y ago
  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.
  - leetrout 5y ago
    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.
  - sk5t 5y ago
    Are you saying you rewrote not just the Spring application but all of the micro services as well?
    - dopidopHN 5y ago
      I understood it as a distributed spring application.
  - dominotw 5y ago
    What happened to the people who worked on those 20 microservices. What do they do now?
js8 5y ago
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.
beckman466 5y ago
> Instagram? Monolith. 12 people when sold to Facebook. So your metric for succes is acquisition size, not good software design?
- papito 5y ago
  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".
  - deleted 5y ago
    [deleted]
  - beckman466 5y ago
    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.
marcinzm 5y ago
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.
- theptip 5y ago
  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.
  - papito 5y ago
    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-an-instagram-story-8f498ab71a0c https://instagram-engineering.com/static-analysis-at-scale-a...
  - afarrell 5y ago
    > 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.
herval 5y ago
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 (-:

by papito 5y ago

vasergen 5y ago

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

cosmodisk 5y ago
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.
marcinzm 5y ago
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.

deleted 5y ago

[deleted]

afarrell 5y ago

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.

papito 5y ago
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.
- afarrell 5y ago
  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.
- dominotw 5y ago
  > 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.
  - papito 5y ago
    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.
pjc50 5y ago
Yup, papito is absolutely correct; microservices are just Conway's law. They're not for scaling the software, they're for scaling the organisation.

tonyjstark 5y ago

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.

holoduke 5y ago
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.
- leetrout 5y ago
  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.
- sk5t 5y ago
  Are you saying you rewrote not just the Spring application but all of the micro services as well?
  - dopidopHN 5y ago
    I understood it as a distributed spring application.
- dominotw 5y ago
  What happened to the people who worked on those 20 microservices. What do they do now?

js8 5y ago

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.

beckman466 5y ago

> Instagram? Monolith. 12 people when sold to Facebook. So your metric for succes is acquisition size, not good software design?

papito 5y ago
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".
- deleted 5y ago
  [deleted]
- beckman466 5y ago
  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.

marcinzm 5y ago

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.

theptip 5y ago
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.
- papito 5y ago
  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-an-instagram-story-8f498ab71a0c https://instagram-engineering.com/static-analysis-at-scale-a...
- afarrell 5y ago
  > 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.

herval 5y ago

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 (-: