3 ms·

"So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny... 2. Any communication between tea

"So, can we agree on these architectural principals, except in edge cases: 1. A team must be in control of its own destiny... 2. Any communication between teams must be done by... an interface such that changes between teams are made obvious." Sure. You'll get no argument from me on these points... "it comes back to my original point: The architecture is the function of number of people in the system." ...or on this one. I will grant that a division of code along the same lines as the division of labor is both sensible and inevitable. I will also grant that 100 or 250 or 2500 or more people are sometimes needed for a firm to achieve its objectives. Will you grant that sometimes, they aren't? That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? That sometimes, adding more people to a slow project just makes it slower? I ask these questions because in my world, micro-services have typically been narrowly defined as network servers in Java, Python, or Rust, each interacting with a database (sometimes, the same database) through an ORM, and a rigid adherence to this orthodoxy has padded resource budgets both in terms of compute and people and has sapped performance both in terms of compute and people.

ebiester 2y ago
Will you grant that sometimes, they aren't? It depends. Let's take a SaaS engineering department, for example. If your customer base is tripling year over year based in the need of the market, you can end up with feature requests that would take decades even with an engineering team ten times the size. Those are often from sales on the backs of failed deals because the product didn't yet meet the client need. If the goal is to keep the lights on and meet current customer need, you need a fraction of the total engineering team. However, we're on the message board of a venture capital site, so we can take an assumption of hypergrowth, as is the goal of a startup. So, then, I'd argue that in growth scenarios, these people are required. That doesn't mean that they are being used the most efficiently, of course. I think this would be a main point of our disagreement. That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? I agree. And some of that is the ZIRF culture as well. And I think we agree with the rest as well. However, I think I am sensing a separate point where I don't know if we agree or disagree. Our field has not created the tools to scale from 10 to 100 or 100 to 250 well. The best tools that have been created to date have taken microservices as part of the orthodoxy. I don't think this is the only way to do it - Robert Martin has a good article here from a decade ago: https://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html https://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServic... However, everyone escaped the java ecosystem (because Oracle and because Spring, more than the language itself IMO) and solutions such as rails plugins didn't develop the rest of the ecosystem around it like AWS did with microservices. And don't get me wrong - I'm currently living in nanoservice hell. We agree more than we disagree. However, I think we are looking at different constraints. Were I a director of engineering at a seed funding company that was starting to feel the pain of a monolith, I'd take one engineer and create a plugin architecture that enforces APIs, and build a pseudo-schema enforced by peer review and linting - and performance exceptions must go through views (or stored procedures for creates and updates). It's painful to rename a table, but much less than moving it to another microservice. Then, I'd keep things in a monorepo as long as possible, at least until 100 people, with the rule that all things in main must be behind feature flags first and any database migrations must be independent of code changes. But I take for granted that growing projects will usually need more people and more quickly than the architecture can easily accommodate, and I think we disagree there.
- dventimi 2y ago
  I'm having a hard time following you. All I'm saying is, I believe that all other things being equal, a more simple architecture with fewer tiers, layers, network servers, and moving parts will tend to require fewer people than a less simple architecture with more tiers, layers, network servers, and moving parts. If you're saying that isn't true in a hyper-growth startup then I guess I'll have to take your word for it as I've never worked in a hyper-growth startup (only in glacial-growth non-startups).

ebiester 2y ago

Will you grant that sometimes, they aren't? It depends. Let's take a SaaS engineering department, for example. If your customer base is tripling year over year based in the need of the market, you can end up with feature requests that would take decades even with an engineering team ten times the size. Those are often from sales on the backs of failed deals because the product didn't yet meet the client need. If the goal is to keep the lights on and meet current customer need, you need a fraction of the total engineering team. However, we're on the message board of a venture capital site, so we can take an assumption of hypergrowth, as is the goal of a startup. So, then, I'd argue that in growth scenarios, these people are required. That doesn't mean that they are being used the most efficiently, of course. I think this would be a main point of our disagreement. That sometimes, the tail wags the dog and the staff and its culture determine the architecture rather than the reverse? I agree. And some of that is the ZIRF culture as well. And I think we agree with the rest as well. However, I think I am sensing a separate point where I don't know if we agree or disagree. Our field has not created the tools to scale from 10 to 100 or 100 to 250 well. The best tools that have been created to date have taken microservices as part of the orthodoxy. I don't think this is the only way to do it - Robert Martin has a good article here from a decade ago: https://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServicesAndJars.html https://blog.cleancoder.com/uncle-bob/2014/09/19/MicroServic... However, everyone escaped the java ecosystem (because Oracle and because Spring, more than the language itself IMO) and solutions such as rails plugins didn't develop the rest of the ecosystem around it like AWS did with microservices. And don't get me wrong - I'm currently living in nanoservice hell. We agree more than we disagree. However, I think we are looking at different constraints. Were I a director of engineering at a seed funding company that was starting to feel the pain of a monolith, I'd take one engineer and create a plugin architecture that enforces APIs, and build a pseudo-schema enforced by peer review and linting - and performance exceptions must go through views (or stored procedures for creates and updates). It's painful to rename a table, but much less than moving it to another microservice. Then, I'd keep things in a monorepo as long as possible, at least until 100 people, with the rule that all things in main must be behind feature flags first and any database migrations must be independent of code changes. But I take for granted that growing projects will usually need more people and more quickly than the architecture can easily accommodate, and I think we disagree there.

dventimi 2y ago
I'm having a hard time following you. All I'm saying is, I believe that all other things being equal, a more simple architecture with fewer tiers, layers, network servers, and moving parts will tend to require fewer people than a less simple architecture with more tiers, layers, network servers, and moving parts. If you're saying that isn't true in a hyper-growth startup then I guess I'll have to take your word for it as I've never worked in a hyper-growth startup (only in glacial-growth non-startups).