6 ms·

> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transforma

> I often help engineering organizations that are in the midst of a transformation. This is typically both a technology transformation and a cultural transformation. For example, these organizations might be attempting to break a core monolithic system into microservices, so that they can have independent teams and adopt a DevOps approach. It's amazing this fad of microservices still hasn't subsided yet. It is the bane of every company that isn't a FAANG but has management who wants to pretend they might someday have FAANG-level scaling/development problems.

bradlys 6y ago
They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo. I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!
- marshmellman 6y ago
  I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.
  - yeswecatan 6y ago
    Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.
    - aserafini 6y ago
      But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices). But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.
      - yeswecatan 6y ago
        I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.
        aserafini 6y ago
        It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline. In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).
      - vasco 6y ago
        > But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation? 3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time. 4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability. Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).
  - nmfisher 6y ago
    The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team. Probably some truth to that.
    - marshmellman 6y ago
      Well said. I think a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.
  - dgellow 6y ago
    Something to consider: when you then realize that the boundary isn’t the correct one or the environment evolved enough that it isn’t meaningful anymore, that’s really painful and expensive to change.
- onethought 6y ago
  Microservices and monorepos are unrelated to each other. You can have 100 micro services from a single repo, and the services are just different folders. Microservices help people have bounded context when they are develop and they leak their abstractions less into the next one. Monoliths (admittedly I've only seen them in Python, Ruby and .Net) start reaching into each others pieces and adding to tech debt in subtle ways. You are of course right, discipline is required in both architectures, but there are different emphasis in both.
jonno123 6y ago
I haven't found many articles from respected sources that will convince management that microservices are a bad idea. There's https://martinfowler.com/bliki/MicroservicePrerequisites.html https://martinfowler.com/bliki/MicroservicePrerequisites.htm... , but this won't convince them.
- knowhy 6y ago
  Here is my non complete list: - Who’s at the Helm? [0] - Microservices, hard as 1, 2, 3 - You can move it but complexity is still here [1] - Microservices — architecture nihilism in minimalism's clothes [2] - Do I Really Need Kubernetes? [3] - Your team might not need Kubernetes [4] I doubt that any of those articles could convince higher management. I don't know what a "respected source" actually means. I general I believe that advice from consulting agency and cloud providers should be taken with a grain of salt. If you drew the same conclusion from the "Who’s at the Helm?" article than I, there is only one way out which is a curated container catalog. VMware's Tanzu Application Catalog [5] is the only product in that space I'm aware of. I have quoted the price tag on HN, I think it was removed since that, so I won't repeat it here again. In any way it was magnitudes higher than the EKS base price which already seen as a showstopper by many small shops. Bottom line is: it is really hard and really expensive to operate containers in a secure manner. Probably too hard and too expensive that it would be a good idea to start with it before you actually need it. 0: https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1 https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1 1: https://medium.com/@danielpetisme/microservices-hard-as-1-2-3-af4e33899af4 https://medium.com/@danielpetisme/microservices-hard-as-1-2-... 2: https://vlfig.me/posts/microservices https://vlfig.me/posts/microservices 3: https://thenewstack.io/do-i-really-need-kubernetes/ https://thenewstack.io/do-i-really-need-kubernetes/ 4: https://medium.com/faun/your-team-might-not-need-kubernetes-57240e8d554a https://medium.com/faun/your-team-might-not-need-kubernetes-... 5: https://tanzu.vmware.com/application-catalog https://tanzu.vmware.com/application-catalog
- disgruntledphd2 6y ago
  What I really don't get about microservices is the performance aspect. Like cache << memory << disk << network in terms of time needed to read/write, and it seems to me that microservices are particularly prone to this by often using HTTP calls. Sure, you can run them on the same box, but it's very easy not to, and I imagine that this will absolutely crater performance (at least in the DS/ML stuff I do).
kevsim 6y ago
1 year into my startup and I'm super happy to have kept everything a well-organized monolith. Every once in a while a thing pops up where some voice in my brain (remnants from previous jobs) says "just break it into its own service" but I've thus far resisted. Our deployments are trivial. Our local dev setup is trivial. Maybe some day we'll have a few small services broken off, but today is not that day.
playing_colours 6y ago
While I agree with you on unreasonable rush for microservices in many cases, I do not think a company must be on the FAANG-level scaling to justify microservices infrastructure. Modularisation is an efficient tool to address growing complexity of software. The code is organised in closed subsystems - modules - that work together via communication with each other over defined interfaces: functions, REST endpoints, messaging system. Modules can be done in monolith by enforcing boundaries and policies: namespaces, packages, agreements on communicating only via "service" classes, isolating database entities, no foreign keys between entities belonging to different modules, etc. It is so called "modular monolith", and I believe it's an efficient way to progress for organisations before jumping on microservices train. Microservices are the next step of modularisation and isolation. By introducing independent deployment of the modules and isolated runtime for each module (different machine, VM, containers) they enable independent CI/CD for the teams that helps to scale up the organisation and they help with isolating different pieces of software that have different technical requirements (traditional Web API with database calls, stream and batch data processing, etc.), different stability and change frequency. While bringing a lot of additional concerns, requiring education and discipline, microservices are critical enablers for many companies to further grow their products and scale up the technical department.
Tehnix 6y ago
As both an IC and Manager, I've now been on a lot of teams using monoliths and teams using microservices, and I would always choose microservices going forward. Let's be straight, both have pros and cons, but I value the following pros of microservices a lot more than any of the cons: - Enforces separations that are important for: - Maximum parallelization of work. - Scalability of each service. Never share database. - Reusability of the service from other services. The trick is to learn how to cut microservices though. Establish an interface that it exposes, like GraphQL or RPC. Don't try to split too fine-grained, but find a balance that works for you. I promise you, when it comes to scalability, you'll be glad you don't have to scale one massive database just because one part of your application is seeing more activity. This also allows you to pivot quicker to a different database suddenly, or a different programming language, if requirements change. E.g. Node.js -> Rust if your service is found to be on the hotpath of everything, and you need correctness and performance. I fundamentally view the difference the same way I would choose Rust over Clojure: - Monoliths: Rely on discipline of the team to do it right (like Clojure won't catch your dynamic mistakes) - Microservices: The most important parts you need are built-in and enforced by the concept itself (like the Rust compiler guides you towards the correct approach).

bradlys 6y ago

They're doing microservices because they can't make a good monolithic codebase. For some reason, CTOs are very happy to start doing microservices with high level of documentation and rigorous interfaces but completely unwilling to have a well documented and rigorously defined monolith. I don't fucking get it. It's like one layer of abstraction on top of folders. Instead of breaking up ownership by folders or whatever bullshit - they decide to breakup ownership by github repo. I'd love to be sold on it otherwise but that's what I've been told directly as the reason for the move to microservices by many companies and what I've seen at my own. Can't do a good job because your business practices suck? Fuck it - microservices, baby!

marshmellman 6y ago
I think a big reason is that microservice architecture forces teams to establish clear boundaries rather than leave it to team diligence. For less centralized organizations, I think it can be a useful forcing function.
- yeswecatan 6y ago
  Clear boundaries on multiple levels as well. I believe a _very_ big part of why people feel they need microservices is because of poor architecture and a lack of boundaries in a monolith. Every single monolith I've come across has had issues with circular dependencies and no real contracts between "apps" (as they are called in Django). I believe people see ORMs such as Django's as a way to perform one big query as opposed to many small queries. The big query spans 3 apps and 8 models. You have these things sprinkled throughout the codebase and you end up with a big ball of mud.
  - aserafini 6y ago
    But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? This situation is a necessary conceptual step before decoupled micro services and far far easier (because it introduces none of the ops problems of microservices). But that never seems to happen. I think it’s because codebase discipline rules are harder for management to ‘see’ than API rules.
    - yeswecatan 6y ago
      I agree though I'd have to think a bit more about the exact way for apps to speak to each other. My guess would be each app could have an api file with a bunch of functions. I wonder how that would work in a situation where you have 3 apps, each with a single model, and the dependencies are A -> B -> C. You could still run into situations where B isn't supposed to know anything about A yet nothing stops B from importing A's api.
      - aserafini 6y ago
        It’s still possible to have circular dependencies in microservices. There is normally nothing stopping service A calling B and B calling A except common sense and discipline. In fact I would say it’s MORE difficult to prevent circular microservice dependency programmatically than in code (where you can hook into module level imports).
    - vasco 6y ago
      > But then why not just introduce a rule: Django ‘apps’ can only talk to each other via pure Python dicts like an interface? (rather than sharing models)? 1. One person or group needs to decide on what the rule should be, what the boundaries are and how to enforce those boundaries. This is usually not an easy process, ymmv. 2. After a decision is made, you'll have to decide on how to put the rule in place. Are you going to stop everything and make sure all code paths are working according to the new rule? Are you going to do it incrementally? New features = new rule, old features = common sense? Another variation? 3. You then start running your new rule and maybe you enforce it with some custom static checks, and when that fails you hope your code reviewers will always catch this every time. 4. You still need that one person or group to make sure this actually gets done and to assess if it actually has a positive impact on velocity and reliability. Or you can put in an implicit "rule" that new code happens in a separate repository, where you don't need to care. A developer that has to do an API call because they simply cannot "import" another module or "query" someone else's data has no choice but to do the right thing - though many opportunities to do a lot of other wrong things too, this is not a panacea. But when we're talking about more than ~5-6 teams, the coordination effort of making sure everyone is aligned on a monolith can be much tougher than to go to multiple services (hopefully not micro).
- nmfisher 6y ago
  The corollary being that the technical problem of a microservice architecture is easier to solve than the management problem of leading a single large team. Probably some truth to that.
  - marshmellman 6y ago
    Well said. I think a microservices architecture exchanges an organizational expense for a technical expense. For certain organizations, it can be the right call.
- dgellow 6y ago
  Something to consider: when you then realize that the boundary isn’t the correct one or the environment evolved enough that it isn’t meaningful anymore, that’s really painful and expensive to change.
onethought 6y ago
Microservices and monorepos are unrelated to each other. You can have 100 micro services from a single repo, and the services are just different folders. Microservices help people have bounded context when they are develop and they leak their abstractions less into the next one. Monoliths (admittedly I've only seen them in Python, Ruby and .Net) start reaching into each others pieces and adding to tech debt in subtle ways. You are of course right, discipline is required in both architectures, but there are different emphasis in both.

jonno123 6y ago

I haven't found many articles from respected sources that will convince management that microservices are a bad idea. There's https://martinfowler.com/bliki/MicroservicePrerequisites.html https://martinfowler.com/bliki/MicroservicePrerequisites.htm... , but this won't convince them.

knowhy 6y ago
Here is my non complete list: - Who’s at the Helm? [0] - Microservices, hard as 1, 2, 3 - You can move it but complexity is still here [1] - Microservices — architecture nihilism in minimalism's clothes [2] - Do I Really Need Kubernetes? [3] - Your team might not need Kubernetes [4] I doubt that any of those articles could convince higher management. I don't know what a "respected source" actually means. I general I believe that advice from consulting agency and cloud providers should be taken with a grain of salt. If you drew the same conclusion from the "Who’s at the Helm?" article than I, there is only one way out which is a curated container catalog. VMware's Tanzu Application Catalog [5] is the only product in that space I'm aware of. I have quoted the price tag on HN, I think it was removed since that, so I won't repeat it here again. In any way it was magnitudes higher than the EKS base price which already seen as a showstopper by many small shops. Bottom line is: it is really hard and really expensive to operate containers in a secure manner. Probably too hard and too expensive that it would be a good idea to start with it before you actually need it. 0: https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1 https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1 1: https://medium.com/@danielpetisme/microservices-hard-as-1-2-3-af4e33899af4 https://medium.com/@danielpetisme/microservices-hard-as-1-2-... 2: https://vlfig.me/posts/microservices https://vlfig.me/posts/microservices 3: https://thenewstack.io/do-i-really-need-kubernetes/ https://thenewstack.io/do-i-really-need-kubernetes/ 4: https://medium.com/faun/your-team-might-not-need-kubernetes-57240e8d554a https://medium.com/faun/your-team-might-not-need-kubernetes-... 5: https://tanzu.vmware.com/application-catalog https://tanzu.vmware.com/application-catalog
disgruntledphd2 6y ago
What I really don't get about microservices is the performance aspect. Like cache << memory << disk << network in terms of time needed to read/write, and it seems to me that microservices are particularly prone to this by often using HTTP calls. Sure, you can run them on the same box, but it's very easy not to, and I imagine that this will absolutely crater performance (at least in the DS/ML stuff I do).

kevsim 6y ago

1 year into my startup and I'm super happy to have kept everything a well-organized monolith. Every once in a while a thing pops up where some voice in my brain (remnants from previous jobs) says "just break it into its own service" but I've thus far resisted. Our deployments are trivial. Our local dev setup is trivial. Maybe some day we'll have a few small services broken off, but today is not that day.

playing_colours 6y ago

While I agree with you on unreasonable rush for microservices in many cases, I do not think a company must be on the FAANG-level scaling to justify microservices infrastructure. Modularisation is an efficient tool to address growing complexity of software. The code is organised in closed subsystems - modules - that work together via communication with each other over defined interfaces: functions, REST endpoints, messaging system. Modules can be done in monolith by enforcing boundaries and policies: namespaces, packages, agreements on communicating only via "service" classes, isolating database entities, no foreign keys between entities belonging to different modules, etc. It is so called "modular monolith", and I believe it's an efficient way to progress for organisations before jumping on microservices train. Microservices are the next step of modularisation and isolation. By introducing independent deployment of the modules and isolated runtime for each module (different machine, VM, containers) they enable independent CI/CD for the teams that helps to scale up the organisation and they help with isolating different pieces of software that have different technical requirements (traditional Web API with database calls, stream and batch data processing, etc.), different stability and change frequency. While bringing a lot of additional concerns, requiring education and discipline, microservices are critical enablers for many companies to further grow their products and scale up the technical department.

Tehnix 6y ago

As both an IC and Manager, I've now been on a lot of teams using monoliths and teams using microservices, and I would always choose microservices going forward. Let's be straight, both have pros and cons, but I value the following pros of microservices a lot more than any of the cons: - Enforces separations that are important for: - Maximum parallelization of work. - Scalability of each service. Never share database. - Reusability of the service from other services. The trick is to learn how to cut microservices though. Establish an interface that it exposes, like GraphQL or RPC. Don't try to split too fine-grained, but find a balance that works for you. I promise you, when it comes to scalability, you'll be glad you don't have to scale one massive database just because one part of your application is seeing more activity. This also allows you to pivot quicker to a different database suddenly, or a different programming language, if requirements change. E.g. Node.js -> Rust if your service is found to be on the hotpath of everything, and you need correctness and performance. I fundamentally view the difference the same way I would choose Rust over Clojure: - Monoliths: Rely on discipline of the team to do it right (like Clojure won't catch your dynamic mistakes) - Microservices: The most important parts you need are built-in and enforced by the concept itself (like the Rust compiler guides you towards the correct approach).