25 ms·

The costs of microservices (2020)

• jihadjihad 3y ago
  Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too seem very confusing to grug https://grugbrain.dev/#grug-on-microservices https://grugbrain.dev/#grug-on-microservices
  • sethammons 3y ago
    grug not experience large teams stepping on each other's domains and data models, locking in a given implementation and requiring large, organizational efforts to to get features out at the team level. Team velocity is empowered via microservices and controlling their own data stores. "We want to modernize how we access our FOO_TABLE for SCALE_REASONS by moving it to DynamoDB out of MySQL - unfortunately, 32 of our 59 teams are directly accessing the FOO_TABLE or directly accessing private methods on our classes. Due to competing priorities, those teams cannot do the work to move to using our FOO_SERVICE and they can't change their query method to use a sharded table. To scale our FOO_TABLE will now be a multi-quarter effort providing the ability for teams to slow roll their update. After a year or two, we should be able to retire the old method that is on fire right now. In the meanwhile, enjoy oncall." Compare this to a microservice: Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. Users of the API report that it is now much faster.
    • jjtheblunt 3y ago
      > Team velocity is empowered via microservices and controlling their own data stores. Bologna. Choosing clear abstractions is an enabler of focus, but that doesn’t necessarily imply those abstractions are a network call away.
      • sethammons 3y ago
        our team of 300 - we _can't_ enforce the clear abstractions. New dev gets hired, team feels pressured to deliver despite leadership saying to prioritize quality, they are not aware of all the access controls, they push a PR, it gets merged. We have an org wide push to get more linting and more checks in place. The damage is done and now we have a multi-quarter effort to re-organize all our code. This _can_ be enforced via well designed modules. I've just not seen that succeed. Anywhere. Microservices are a pain for smaller teams and you have to have CI and observability and your pains shift and are different. But for stepping on eachother? I've found microservices to be a super power for velocity in these cases. Can microservices be a shitshow? Absolutely, esp. when they share data stores or have circular dependencies. They also allow teams to be uncoupled assuming they don't break their API.
        • ChrisMarshallNY 3y ago
          > leadership saying to prioritize quality Well, that's different. My experience is that "leadership" often finds quality to be expensive and unnecessary overhead. That's one reason that I stayed at a company that took Quality seriously. It introduced many issues that folks, hereabouts would find unbearable, but they consistently shipped some of the highest-Quality (and expensive) kit in the world. Quality is not cheap, and it is not easy. It is also not really the path to riches, so it is often actively discouraged by managers.
        • nicoburns 3y ago
          > They also allow teams to be uncoupled assuming they don't break their API. Presumably you would still need tooling to enforce teams not breaking their API, and also to prevent people just modifying services to expose private internals that should not be part of the public API?
        • jacquesm 3y ago
          You can't really retrofit culture and behavior, you can only very gradually move towards a particular goal and usually that's a multi-year effort, if it can be done at all.
        • 3y ago
    • simonw 3y ago
      > Team realizes their table wont scale, but their data is provided via API. They plan and execute the migration next sprint. ... followed by howls of anguish from the rest of the business when it turns out they were relying on reports generated from a data warehouse which incorporated a copy of that MySQL database and was being populated by an undocumented, not-in-version-control cron script running on a PC under a long-departed team member's desk. (I'm not saying this is good, but it's not an unlikely scenario.)
      • sethammons 3y ago
        another reason why you provide data only over API - don't reach into my tables and lock me into an implementation.
        • simonw 3y ago
          An approach I like better than "only access my data via API" is this: The team that maintains the service is also responsible for how that service is represented in the data warehouse. The data warehouse tables - effectively denormalized copies of the data that the service stores - are treated as another API contract - they are clearly documented and tested as such. If the team refactors, they also update the scripts that populate the data warehouse. If that results in specific columns etc becoming invalid they document that in their release notes, and ideally notify other affected teams.
          • hermanradtke 3y ago
            This same thing can be applied to contracts when firing events, etc. I point people to https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying https://engineering.linkedin.com/distributed-systems/log-wha... and use the same approach to ownership.
            • simonw 3y ago
              Yeah, having a documented stream of published events in Kafka is a similar API contract the team can be responsible for - it might even double as the channel through which the data warehouse is populated.
    • shadowgovt 3y ago
      As with so many software solutions, the success of microservices is predicated upon having sufficient prognostication about how the system will be used to recognize where the cut-points are. When I hear success stories like that, I have to ask "Is there some inherent benefit to the abstraction or did you get lucky in picking your cleave-points?"
      • esafak 3y ago
        That comes with experience, but you can let time be the judge if you factor your monolith early enough. If the factorization proves stable, proceed with carving it into microservices.
    • charcircuit 3y ago
      Other teams can access your data directly even if it's in your own separate database.
    • sally_glance 3y ago
      This applies to performance optimizations which leave the interface untouched, but there are other scenarios, for example: - Performance optimizations which can't be realized without changing the interface model. For example, FOO_TABLE should actually be BAR and BAZ with different update patterns to allow for efficient caching and querying. - Domain model updates, adding/updating/removing new properties or entities. This kind of update will still require the 32 consumers to upgrade. The API-based approach has benefits in terms of the migration process and backwards-compatibility though (a HTTP API is much easier to version than a DB schema, although you can also do this on the DB level by only allowing queries on views).
    • crabbone 3y ago
      Found the author of CISCO / Java Spring documentation. I honestly expected people used passive-aggressive corpo-slang only for work / ironically. But this reads intentionally obfuscated. But, to answer to the substance: you for some reason assumed that whoever designed first solution was an idiot and whoever designed the second was, at least clairvoyant. The problem you describe isn't a result of inevitable design decisions. You just described a situation where someone screwed up doing something and didn't screw up doing something else. And that led you to believe that whatever that something else is, it's easier to design. The reality of the situation is, unfortunately, the reverse. Upgrading microservices is much harder than replacing components in monolithic systems because it's easier to discover all users of the feature. There are, in general, fewer components in monolithic systems, so less things will need to change. Deployment of a monolithic system will be much more likely to discover problems created by incorrectly implemented upgrade. In my experience of dealing with both worlds, microservices tend to create a maze-like system where nobody can be sure if any change will not adversely affect some other part of the system due to the distributed and highly fragmented nature of such systems. So, your ideas about upgrades are uncorroborated by practice. If you want to be able to update with more ease, you should choose a smaller, more cohesive system.
      • perrylaj 3y ago
        I think I view the situation in a similar fashion as you. There's absolutely nothing preventing a well architected modular monolith from establishing domain/module-specific persistence that is accessible only through APIs and connectable only through the owning domain/module. To accomplish that requires a decent application designer/architect, and yes, it needs to be considered ahead of time, but it's 100% doable and scalable across teams if needed. There are definitely reasons why a microservice architecture could make sense for an organization, but "we don't have good application engineers/architects" should not be one of them. Going to a distributed microservice model because your teams aren't good enough to manage a modular monolith sounds like a recipe for disaster.
    • nijave 3y ago
      Microservices don't magically fix shared schema headaches. Getting abstraction and APIs right is the solution regardless of whether it's in-memory or over the network. Instead of microservices, you could add a static analysis build step that checks if code in packages is calling private or protected interfaces in different packages. That would also help enforce service boundaries without introducing the network as the boundary.
      • tubthumper8 3y ago
        I guess I'm confused by the suggestion - doesn't that static analysis step to check that code isn't calling private interfaces already exist, and is called a "compiler"?
    • com2kid 3y ago
      Or how about "we want to update a 3rd party library due to a critical security issue, but we can't because that library is used in 500 different parts of the code and no way in hell can we stop development across the entire org for multiple weeks". With microservices, you deploy the updates to public facing services first, write any learnings down, pass it along to the next most vulnerable tier. Heck on multiple occasions I've been part of projects where just updating the build system for a monolithic codebase was a year+ long effort involving dozens of engineers trying to work around commits from everyone else. Compare this to a microservice model where you just declare all new services get the new build tools. If the new tools come with a large enough carrot (e.g. new version of typescript) teams may very well update their own build tooling to the latest stuff without anyone even asking them to!
    • danmaz74 3y ago
      Team size is probably the most important factor that should influence the choice about microservices. Unfortunately, there was a period when it looked like every project and every team had to adopt them or be declared a dinosaur.
  • agumonkey 3y ago
    new role: lead grug
  • insanitybit 3y ago
    Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. Isolation is not anything to scoff at, it's one of the most powerful features you can encode into your software. Isolation can improve performance, it can create fault boundaries, it can provide security boundaries, etc. This is the same foundational concept behind the actor model - instead of two components being able to share and mutate one another's memory, you have two isolated systems (actors, microservices) that can only communicate over a defined protocol.
    • nicoburns 3y ago
      > Network calls are a powerful thing to introduce. It means that you have an impassable boundary, one that is actually physically enforced - your two services have to treat each other as if they are isolated. That is not too true at all. I've seen "microservice" setups where one microservice depends on the state within another microservice. And even cases where service A calls into service B which calls back into service A, relying on the state from the initial call being present. Isolation is good, but microservices are neither necessary nor sufficient to enforce it.
      • insanitybit 3y ago
        Well, I'd say you've seen SoA setups that do that, maybe. But those don't sound like microservices :) Perhaps that's not a strong point though. Let me be a bit clearer on my point because I was wrong to say that you have to treat a service as being totally isolated, what I should have said that they are isolated, whether you treat them that way or not. There is a physical boundary between two computers. You can try to ignore that boundary, you can implement distributed transactions, etc, but the boundary is there - if you do the extra work to try to pretend it isn't, that's a lot of extra work to do the wrong thing. Concretely, you can write: rpc_call(&mut my_state) But under the hood what has to happen, physically, is that your state has to be copied to the other service, the service can return a new state (or an update), and the caller can then mutate the state locally. There is no way for you to actually transfer a mutable reference to your own memory to another computer (and a service should be treated as if it may be on another computer, even if it is colocated) without obscene shenanigans. You can try to abstract around that isolation to give the appearance of shared mutable state but it is just an abstraction, it is effectively impossible to implement that directly. But shared mutable state is trivial without the process boundary. It's just... every function call. Any module can take a mutable pointer and modify it. And that's great for lots of things, of course, you give up isolation sometimes when you need to.
  • manicennui 3y ago
    I just wanted to note that static typing isn't required for autocomplete. JetBrains has IDEs for languages like Ruby and Python that can do it. If you open the REPL in a recent version of Ruby you get much of what you expect from an IDE with a statically typed language (with regards to autocomplete and syntax checking).
    • manicennui 3y ago
      Also, DRY is not about repeated code. This drives me crazy. Ruby developers love to make code worse by trying to "DRY it up".
      • Capricorn2481 3y ago
        What are you replying to? The article is about how Dry shouldn't be over applied. Dry is literally "Don't Repeat Yourself" and is definitely pushed for cleaning up redundant code, so it's not unreasonable for people to think that's what about. It's only recently that people have pointed out that there's a difference between Duplicated code and Repeated code.
        • manicennui 3y ago
          Redundant code is not code that looks the same. It's only reasonable for people to believe it is about code that looks the same if they have never bothered to learn what it means.
          • Capricorn2481 3y ago
            That's what I said, yes. There's a difference between duplicated logic and redundant code. And it's clear the Grug article agrees with that.
    • 998244353 3y ago
      You are correct, but static typing does make it a lot easier. Working with Rider feels like working with an IDE that fully understands the code, at least structurally. Working with PyCharm feels like working with an IDE that makes intelligent guesses.
• nevinera 3y ago
  The right time to extract something into a separate service is when there's a problem that you can't tractably solve without doing so. Increasing architectural complexity to enforce boundaries is never a solution to a lack of organizational discipline, but midsize tech companies _incessantly_ treat it like one. If you're having trouble because your domains lack good boundaries, then extracting services _is not going to go well_.
  • avelis 3y ago
    Sounds like a SISP (solution in search of a problem). Or throwing a solution at a problem not understanding the root issue of it.
  • jeffbee 3y ago
    I find it odd that there is this widespread meme—on HN, not in the industry—that microservices are never justified. I think everyone recognizes that it makes sense that domain name resolution is performed by an external service, and very few people are out there integrating a recursive DNS resolver and cache into their monolith. And yet, this long-standing division of responsibility never seems to count as an example.
    • pjc50 3y ago
      DNS resolution is genuninely reusable, though. Perhaps that's the test: is this something that could concievably be used by others, as a product in itself, or is it tied very heavily to the business and the rest of the "microservices"? Remember this is how AWS was born, as a set of "microservices" which could start being sold to external customers, like "storage".
      • jeffbee 3y ago
        What about a mailer that's divided into the SMTP server and the local delivery agent?
        • pjc50 3y ago
• avelis 3y ago
  > Once the monolith is well matured and growing pains start to rise, then you can start to peel off one microservice at a time from it. Curious what is considered a growing pain of the monolith vs tech debt that hasn't been tackled. If the issue is the monolith can't scale in performance then a services oriented architecture doesn't necessarily give you that automatically unless you know where the bottleneck of your monolith is.
• lcfcjs 3y ago
  Interesting article. Although one point I'd like to contest is the first "pro" which is you can use a different language for each service. We tried this approach and it failed fantastically. You're right about the cons, it becomes un-maintable. We had 3 microservices that we maintained on our team, one in Java, one in Ruby and one in Node. We very quickly realized we needed to stick to one, in order to share code, stop the context switching, logging issues, etc. The communication piece is something that solid monoliths should practice as well (as is it touched on in the article). Calling an 3rd party API without a timeout is not a great idea (to be it lightly), monolith or microservice. Thought-provoking nevertheless, thank you for sharing.
  • codesnik 3y ago
    lemme guess, you all converged to Java?
• jeffbee 3y ago
  The article sees to take for granted that your development org is completely broken and out of control. They can't decide what to work on during sprints, they furtively introduce third party libraries and unknown languages, they silently ship incompatible changes to prod, etc. I guess microservices are easier if your developers aren't bozos.
  • alt227 3y ago
    Unfortunately there are very often bozos in your team or complete teams of bozos working on the same project as you. Im sure Microservices are easier if you work in a development team of smart, competent, intelligent developers. However Im sure everything would be easier then!
  • simonw 3y ago
    Every developer is a bozo for their first few months in a new job, simply because it takes time to absorb all of the information needed to understand how the existing systems work.
    • jeffbee 3y ago
      Acculturating new developers is one of the main tasks of an organization. I don't think it's very difficult to communicate that some company uses language[s] X[, Y and Z] only.
      • simonw 3y ago
        That depends on the culture of each specific organization. Are there top-down engineering decisions? Is there a push for more team autonomy? My experience is that many organizations have something of a pendulum swinging between those two positions, so the current state of that balance may change over time. Also: many new developers, when they hear "microservices", will jump straight to "that means I can use any language I want, right?" (Maybe that's less true in 2023)
    • novia 3y ago
      In my experience the bozos were absolutely not the newbies. Maybe you work in a job that is dedicated to engineering only, but what happens is that often in a company of non-engineers, some kinda reorg happens where a person ends up on your team who never studied programming in their life, with the assumption that the person is a go-getter who will be able to pick all this stuff up. The experiment is never called a failure when they consistently fail to learn. 2 years later the same underwhelming "engineer" will still be there getting other people to do their work while desperately trying to introduce bugs into production.
• harry_ord 3y ago
  My current job hasn't been a great experience with microservices. It's a industry where I've worked with a monolith that did a lot more but having everything split between like 17 different services makes managing anything not so fun. The other big blocker is small team and only one of us met the original staff who designed this.
• ThinkBeat 3y ago
  Side issue: What software is used to make those diagrams?
  • FL410 3y ago
    Looks like Excalidraw
    • ThinkBeat 3y ago
      thank you kindly
• timwaagh 3y ago
  I liked this well balanced approach. What I think is necessary is more capability to have hard modularisation within a monolith, so decoupling is not a reason to introduce microservices. Performance should be the main/only reason to do it. It's a shame few languages support this.
  • esafak 3y ago
    You mean like namespacing? What language did you have in mind?
• ranting-moth 3y ago
  The article mentions Development Experience, but doesn't mention what I think is an overlooked huge cost. Bad Development Experience results in unhappy and/or frustrated developer. Unhappy and/or frustrated developer is usually performing considerably worse than his happier self would.
• lr4444lr 3y ago
  Don't disagree with the article, but to play Devil's Advocate, here are some examples of when IME the cost IS worth it: 1) there are old 3rd party dependency incompatibilities that you can spin off and let live separately instead of doing a painful refactor, rebuilding in house, or kludgy gluing 2) there are deploy limitations on mission critical high available systems that should not hold up other systems deployment that have different priorities/sensitive business hours time windows 3) system design decisions that cannot be abstracted away are at the mercy of some large clients of the company that are unable or unwilling to change their way of doing things - you can silo the pain. And to be clear, it's not that these things are "cost free". It's just a cost that is worth paying to protect the simpler monolith from becoming crap encrusted, disrupted with risky deploys, or constrained by business partners with worse tech stacks.
  • eterevsky 3y ago
    1) Why is it better than wrapping it in an interface with a clear API without extracting it into a separate service?
    • paulddraper 3y ago
      Those dependencies might cross language boundaries, or interfere with your other dependencies running in the same process.
      • bingemaker 3y ago
        On the contrary, when they fail silently, it is hard debug "dependent" services
        • mark_undoio 3y ago
          In the Java world, we've developed record/replay across microservice boundaries, so it's effectively possible to step from a failure in one microservice and into the service that sent it bad data. https://docs.undo.io/java/Microservices.html https://docs.undo.io/java/Microservices.html [Edit: for which, by the way, any feedback is welcome - it's technically quite promising but real world experience is worth a lot!]
• agumonkey 3y ago
  Has anyone approached microservices with good old brookes modularization perspective ? when and how to split your app into modules / services whatever.
• abound 3y ago
  I'm as much of a "build a monolith until you can't" person as any, but one motivation for using microservices that I haven't seen mentioned here is differing resource/infra requirements + usage patterns. Throw the request/response-oriented API with bursty traffic on something serverless, run the big async background tasks on beefy VMs (maybe with GPUs!) and scale those down when you're done. Run the payments infra on something not internet-facing, etc. Deploying all those use cases as one binary/service means you've dramatically over-provisioned/underutilized some resources, and your attack service is larger than it should be.
  • charcircuit 3y ago
    A load balancer can make this work with a monolith. Requests for expensive services can be routed to a separate tier of servers for example.
• dfilppi 3y ago
  [dead]
• Symmetry 3y ago
  In the robotics world it's pretty common to have something that looks a lot like microservices as an organizing principle. ROS[1] would probably the robotics framework that everybody cuts their teeth on and in that you have a number of processes communicating over a pub/sub network. Some of the reasons for organizing this way would be familiar to someone doing websites, but you also have factors like vendors for sensors you need providing libraries that will occasionally segfault, and needing to be able to recover from that. [1]https://en.wikipedia.org/wiki/Robot_Operating_System https://en.wikipedia.org/wiki/Robot_Operating_System
• eterevsky 3y ago
  In my experience, if a piece of code is stateful and is called from several different services, then it should be its own service. Otherwise it is usually better off as a library.
• sorokod 3y ago
  eventual consistency A bit of tangent but one must admire the optimistic attitude reflected by this name. "Most of the time inconsistent" says the same thing but is not great for marketing.
• spott 3y ago
  "Microservices" has always been weird to me. People argue for them from two different, drastically different, points of view: * Microservices become necessary at some point because they allow you to independently scale different parts of the application depending on load. * Microservices become necessary at some point because they allow you to create hard team boundaries to enforce code boundaries. Personal opinion: micro services are always thrown out there as a solution to the second problem because it is easier to split a service out of a monolith than it is to put the genie of bad code boundaries back in the box. An application goes through a few stages of growth: 1) When it starts, good boundaries are really hard to define because no-one knows what the application looks like. So whatever boundaries are defined are constantly violated because they were bad abstraction layers in the first place. 2) After a while, when the institutional knowledge is available to figure out what the boundaries are, it would require significant rewrites/refactoring to enforce them. 3) Since a rewrite/major refactor is necessary either way, everyone pushes to go to micro services because they are a good resume builder for leadership, and "we might need the ability to scale", or people think it will be easier ("we can splinter off this service!", ignoring the fact that they can splinter it off within the monolith without having to deal with networks and REST overhead). Unfortunately, this means that everyone has this idea that micro services are necessary for code boundaries because so many teams with good code boundaries are using micro services.
  • soco 3y ago
    Granular performance and team boundaries are both valid points. But, I haven't seen yet (around me) monolith applications so complex to have more teams working on them. I've seen instead applications developed by two persons where some higher-ups requested splitting them into microservices just because (no, scaling wasn't needed).
• paulddraper 3y ago
  > The term micro can be misleading, though - there doesn’t have to be anything micro about the services. In fact, I would argue that if a service doesn’t do much, it just creates more operational toll than benefits. A more appropriate name for this architecture is service-oriented architecture, but unfortunately, that name comes with some old baggage as well. What baggage is that? Because in my experience 90% of the argument revolves around the word "micro." If "micro" is indeed irrelevant to "microservices," let's name things better, yes?
  • wholesomepotato 3y ago
    https://www.service-architecture.com/articles/web-services/soap.html https://www.service-architecture.com/articles/web-services/s... After enough people retire that remember how big of a mess this was, we can probably re-use "Service Oriented".
    • paulddraper 3y ago
      You linked to Simple Object Access Protocol. I don't follow the point.
• fwungy 3y ago
  Just use Rust. Rust solves all of this.
• deleted 3y ago
  [deleted]
• ashu1461 3y ago
  If your company has a microservice architecture but doesn't have proper knowledge on how should they communicate, how should they share code etc then it is the worst thing possible.
• astonex 3y ago
  There's a spectrum between each function is a separate service, to everything is in one binary. The engineering part is finding the happy medium.
• exabrial 3y ago
  > Getting the boundaries right between the services is challenging - it’s much easier to move them around within a monolith until you find a sweet spot. Once the monolith is well matured and growing pains start to rise, then you can start to peel off one microservice at a time from it. I couldn't agree more. "Do not optimize your code" applies here.
• resters 3y ago
  There should be a distinction between doing a migration of a "monolithic" system to "microservices" vs adding functionality to a monolithic system by implementing a "microservice" that will be consumed by the monolithic system. In some cases, microservices are helpful for separation of concerns and encapsulation. But teams often get the idea that their monolithic system should be rewritten using "microservice" patterns. It's important to question whether the monolithic system is using the correct abstractions and whether spllitting it into different services is the only way to approach the deficiencies of the system. In most systems there are bits that can (and probably should) be quite decoupled from the rest of the system. Understanding this is a more fundamental aspect of system design and does not apply only to monolithic or microservice approaches.
• aleksiy123 3y ago
  I recently had some discussions and did some research on this topic and I feel like there is a lot people don't talk about in these articles. Here are some more considerations between micro services and monolothic tradeoffs. Its also important to consider these two things as a scale and not a binary decision. 1. Isolation. Failure in on service doesn't fail the whole system. Smaller services have better isolation. 2. Capacity management. Its easier to estimate the resource usage of a smaller service because it has less responsibilities. This can result in efficiency gains. Extended to this is you can also give optimized resources to specific services. A prediction service can use GPU while web server can use CPU only. A monolothic may need to use compute with both which could result in less optimized resources. 3. Dev Ops Overhead. In general monolothic services have less management overhead because you only need to manage/deploy one or few services over many. 4. Authorization/Permissions. Smaller services can be given a smaller scope permissions. 5. Locality. Monolothic can share memory and therefore have better data locality. Small services use networks and have higher overhead. 6. Ownership. Smaller services can have more granular ownership. Its easier to transfer ownership. 7. Iteration. Smaller services can move independently of one another and can release at seperate cadences.
  • tazard 3y ago
    1. Isolation With a well built monolith, a failure on a service won't fail the whole system. For poorly built microservices, a failure on a service absolutely does being down the whole system. Not sure I am convinced that by adopting microservices, your code automatically gets better isolation
    • aleksiy123 3y ago
      Its not automatic but it has the potential for more isolation by definition. If your service has memory leak, crash it only takes down the service. It is still up to your system to handle such a failure gracefully. If such a service is a critical dependency then your system fails. But if it is not then your service can still partially function. If your monolith has memory leak, or crash it takes down the whole monolith.
    • scurvy_steve 3y ago
• js8 3y ago
  I think people get the modularity wrong. Modularity is important, but I came to conclusion there is another important architectural principle, which I call "single vortex principle". First, a vortex in a software system is any loop in a data flow. For example, if we send data somewhere, and then we get them back processed, or are in any way influenced by them, we have a vortex. A mutable variable is an example of a really small vortex. Now, the single vortex principle states that there ideally should be only one vortex in the software system, or, restated, every component should know which way its vortex is going. The rationale is when we have two vortices, and we want to compose the modules that form them into a single whole. If the vortices are correctly oriented, composition is easy. If they have opposite orientation, the composition is tricky and requires decision on how the new vortex is oriented. Therefore, it is best if all the vortices in all the modules have the same orientation, and thus form a single vortex. This principle is a generalization of ideas such as Flux pattern, CQRS, event sourcing, and immutability.
  • salvadormon 3y ago
    I find this vortex concept interesting. Do you have any books or online sources that I could use to study this?
    • js8 3y ago
      No, I made it all up. I wish I had time and interest to formalize it.
    • ahoka 3y ago
      It’s called engineering. /s
  • Freebytes 3y ago
    This is a very good point, and you could probably write quite a few articles about this particular subject. You may even have a service A that calls service B that calls service C that calls service A. Then you have a problem. Or, you have C get blocked by something happening in A that was unexpected. Ideally, you only have parents calling children without relying on the parents whatsoever, and if you fail in this, you have failed in your architecture.
• nightowl_games 3y ago
  I tried to use an eBPF sampling profiler to produce a flame graph/marker chart of our c/c++ desktop application. I struggled to get it going, seems like the existing tools are for kernel level profiling and more complicated stuff. Anyone recommend a simple technique to produce a quality profiler report for profiling a desktop application? Honestly the chrome/firefox profiler is so great that I do wasm builds and use those. Ideally Id like a native profiler that can output .json that chrome/ff can open in it's profile analyzer.
• sazz 3y ago
  Speaking from a Release Management point of view going from a monolith to microservices is often done for the wrong reasons. The only valid reason for actual doing the change seems to be for scaling reasons due to performance bottlenecks. Everything else is just shifting complexity from software development to system maintenance. Of course, developers will be happy that they have that huge "alignment with other teams" burden off their shoulders. But the clarity when and how a feature is implemented, properly tested across microservices and then activated and hypercared on production will be much harder to reach if the communication between the development teams is not mature enough (which is often the actual reason from breaking up the monolith).
  • altairTF 3y ago
    This is the sole reason we're considering breaking this out into a separate component of our app. It's become too large to maintain effectively. The rest of the app will remain unchanged
  • buster 3y ago
    There are many valid reasons (and many wrong reasons). I would say: If you have multiple stakeholders, evoling business needs and many ( > 10) developers, there might be a good reason to have independent deployable, testable and releaseable units. Having few developers with a well defined context working on multiple microservices is a pain, though. Regarding "Everything else is just shifting complexity from software development to system maintenance.": This sounds reasonable if your software is actively developed. Development is expensive. It may very well be, that the costs of maintaining a distributed system is lower then the cost of developing a very large monolith with a large team. In the end, it depends.
    • sazz 3y ago
      "There might be a good reason to have independent deployable, testable and releaseable units" Of course this is the bottom line. But everything you define in the sentence can be achieved with a proper pipeline and repository architecture based on a monolith as well. For example teams could use a branch setup where they own their own team branches capable of merging to master and deploying. Each team could then define their own testing strategy and Definition of Done on their "team master". Having the ability to release independently is actually a social problem, not a technical one. But the symptom of that social misalignment often shows up as a technical problem (dropping release KPIs, etc.) So changing from a monolith to microservice will most likely only fight the symptom, not the root cause.
• holoduke 3y ago
  I think that chunking up your application layer into smaller parts is always a good idea. But when do you say its a microservice? When its completely isolated, with its own database etc. Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices?
  • never_inline 3y ago
    > Are many small applications running as seperate binaries/processes/on different ports talking to one database endpoint also microservices? One database endpoint as in ? You can use different schemas and have no relations between tables used by different services, or on the other extreme have services which write to same table. I have read in a book that the most important criteria is independent deployability. I forget the name of the book.
    • esafak 3y ago
      https://samnewman.io/books/building_microservices_2nd_edition/ https://samnewman.io/books/building_microservices_2nd_editio... ?
      • never_inline 3y ago
        Yep this book.
• avandekleut 3y ago
  We started with a microservices architecture in a greenfield project. In retrospect we really should have started with a monolith. Every 2-3 days we have to deal with breaking changes to API schemas. Since we’re still pre-production it doesn’t make sense to have a dozen major versions up side-by-side, so we’re just sucking up the pain for now. It’s definitely a headache though. We also are running on AWS API Gateway + lambda so the availability and scalability are the same regardless of monolith or not…
• wnolens 3y ago
  If a monolith is well-factored, what is the difference between it and co-located microservices? Probably just the interface - function calls become RPC. You accept some overhead for some benefits of treating components individually (patching!) What is the difference between distributed microservices v.s. co-located microservices? Deployment is more complex, but you get to intelligently assign processes to more optimal hardware. Number of failure modes increases, but you get to be more fault tolerant. There's no blanket answer here. If you need the benefits, you pay the costs. I think a lot of these microservice v.s. monolith arguments come from poor application of one pattern or the other, or using inadequate tooling to make your life easier, or mostly - if your software system is 10 years old and you haven't been refactoring and re-architecting as you go, it sucks to work on no matter the initial architecture.
  • marcosdumay 3y ago
    From the developer POV, the difference is on the interface. And while we have all kinds of tools to help us keeping a monolith in sync and correct, the few tools we have to help with IPC can not do static evaluations and are absolutely not interactive. From the ops POV, "deploy is more complex" is a large understatement. Each package is one thing that must be managed, with its own specific quirks and issues.
  • hu3 3y ago
    > Probably just the interface - function calls become RPC. Network calls introduce new failure modes and challenges which require more plumbing. Can I retry this RPC call safely? How about exponential backoff? Is my API load-balancer doing its thing correctly? We'll need to monitor it. How about tracing between microservices? Now we need OpenTelemetry or something like that. How harder is it to debug with breakpoints in a microservice architecture? How can I undo a database transaction between 2 microservices? Suddenly your simple function call just became a lot more problematic.
    • wnolens 3y ago
      My first Q was re: monolith on one host to many services on one host. And yes, when going off-host, you'll have these issues. One should not employ network hops unnecessarily. Engineering is hard. Doesn't make it not worth doing.
• dec0dedab0de 3y ago
  Modern micro services are ridiculous, with few exceptions. IIRC the original idea of micro-services was that each team in a large company should provide a documented API for the rest of the company to use instead of just a web page or a manual process. this is in contrast to their being only one development team that decides what gets worked on. Which allows individual employees to automate bigger processes that include steps outside of their own department. Somehow that changed to people spinning up containers for things that could be a function.
• jedberg 3y ago
  Last time I did a survey of my peers, companies that were all in on microservices in the cloud spent about 25% of their engineering time on the support systems for microservices. That number is probably a bit lower now since there are some pretty good tools to handle a lot of the basics. And the author sums up the advice I've been giving for a long time perfectly: > Splitting an application into services adds a lot of complexity to the overall system. Because of that, it’s generally best to start with a monolith and split it up only when there is a good reason to do so. And usually that good reason is that you need to optimize a particular part of the system (which often manifests as using another language) or your organization has grown such that the overhead of microservices is cheaper than the management overhead. But some of the things in this article are not quite right. > Nothing forbids the use of different languages, libraries, and datastores for each microservice - but doing so transforms the application into an unmaintainable mess. You build a sidecar in a specific language, and any library you produce for others to consume is for that language/sidecar. Then you can write your service in any language you want. Chances are it will be one of a few languages anyway that have a preferred onramp (as mentioned in the article), and if it's not, then there is probably a good reason another language was chosen, assuming you have strong technical leadership. > Unlike with a monolith, it’s much more expensive to staff each team responsible for a service with its own operations team. As a result, the team that develops a service is typically also on-call for it. This creates friction between development work and operational toll as the team needs to decide what to prioritize during each sprint. A well run platform removes most of the ops responsibility from the team. The only thing they really have to worry about is if they have built their system in a way to handle failures well (chaos engineering to the rescue!) and if they have any runaway algorithms. Otherwise it's a good thing that they take on that ops load, because it helps them prioritize fixing things that break a lot.
  • nijave 3y ago
    >A well run platform removes most of the ops responsibility from the team It might remove most of the responsibility from the original team but it transfers it somewhere else. Making sure the new "platform team" is well staffed is something I don't see mentioned/discussed very often in the context of microservices
• bob1029 3y ago
  > And think of the sheer number of libraries - one for each language adopted - that need to be supported to provide common functionality that all services need, like logging. This is the #1 reason we quit the microservices game. It is simply a complete waste of mental bandwidth to worry about with the kind of tooling we have in 2023 (pure cloud native / infiniscale FaaS), especially when you have a customer base (e.g. banks & financial instutitions) who will rake you over hot coals for every single 3rd party dependency you bring. We currently operate with one monolithic .NET binary distribution which is around 250 megs (gzipped). Not even the slightest hint of cracks forming. So, if you are sitting there with a 10~100 meg SaaS distribution starting to get nervous about pedantic things like "my exe doesnt fit in L2 anymore", then rest assured - Your monolithic software journey hasn't even begun yet. God forbid you find yourself with a need to rewrite one of these shitpiles. Wouldn't it be a hell of a lot easier if it was all in one place where each commit is globally consistent?
  • _a_a_a_ 3y ago
    Word. BTDT, all services getting out of sync etc. Not worth it.
  • tsss 3y ago
    No one says you can't have all of your microservices use the same language...
    • bob1029 3y ago
      Absolutely. This is how we operated when we were at the peak of our tech showmanship phase. We had ~12 different services, all .NET 4.x the exact same way. This sounds like it could work, but then you start to wonder about how you'd get common code into those 12 services. Our answer at the time was nugets, but we operate in a sensitive domain with proprietary code, so public nuget services were a no go. So, we stood up our own goddamn nuget server just so we could distribute our own stuff to ourselves in the most complicated way possible. Even if you are using all the same language and patterns everywhere, it still will not spare you from all of the accidental complexity that otherwise becomes essential if you break the solution into arbitrary piles.
• rvrs 3y ago
  I feel like this article conflates monoliths with monorepos. You can have a more flexible (though not as "flexible" as microservices, perhaps for the better) engineering by just following the "libraries" pattern mentioned in the article and splitting each of the libraries into their own repos, and then having version bumps of these libraries as part of the release process for the main application server. Doing it this way gets you codebase simplicity, release schedule predictability, and makes boundaries a bit more sane. This should get you a lot farther than the strawmanned "one giant repo with a spaghetti mess of code" model that the author posits.
• 0xbadcafebee 3y ago
  So where's "the costs of monoliths" post? They don't show up here, because everyone is out there cluelessly implementing microservices and only sees those problems. If everyone were out there cluelessly implementing monoliths, we'd see a lot of "monoliths bad" posts. People don't understand that these systems lead to the same amount of problems. It's like asking an elephant to do a task, or asking 1000 mice. Guess what? Both are going to have problems performing the task - they're just different problems. But you're not going to get away from having to deal with problems. You can't just pick one or the other and expect your problems to go away. You will have problems either way. You just need to pick one and provide solutions. If 'what kind of architecture' is your biggest hurdle, please let me work there.
  • yCombLinks 3y ago
    The 8 trillion monolith bad posts are why we are now over inundated with microservices. This is the blowback when people are realizing the cost benefit didn't work for them
• wg0 3y ago
  "Monolith first." Also, call stack can go pretty deep. You can't go deep with microservices. Everything has to be first hop or you risk adding latency. Also, transactional functionalities become lot more challenging to implement across services and databases because it's blasphemous to share database among Microservices.
• DerekBickerton 3y ago
  Separation of Concerns as a Service
• Sohcahtoa82 3y ago
  I've found that microservices are fine. In fact, they're pretty damn neat! But what isn't fine are nanoservices, where a service is basically just a single function. Imagine creating a website where you have a RegisterService, LoginService, ForgotPasswordService, ChangePasswordService, Add2FAService, etc. While I haven't seen it THAT bad, I've seen things pretty close to it. It becomes a nightmare because the infra becomes far more complex than it needs to be, and there ends up being so much repeated boilerplate. Also, obligatory: https://youtu.be/y8OnoxKotPQ https://youtu.be/y8OnoxKotPQ
• deleted 3y ago
  [deleted]
• mattbillenstein 3y ago
  I think most organizations should take a stab at scaling out with in-process services first - ie, instead of an rpc it's a function call, instead of a process, it's a module, etc. In a well-factored app, stepping on one another's toes should be the exception, not the rule. Unfortunately, I think modern web frameworks don't do a good job of enabling this. They often encourage "God object" patterns and having code/data very tightly coupled.
• mrinterweb 3y ago
  A bit over a decade ago, I was sold on the concept of microservices. After implementing, maintaining, and integrating many microservices; I have realized how incredibly exhausting it is. Sure microservices have their place, but understanding the often higher costs associated with microservices should be considered when developing a new service. Focus on the costs that are less tangible: siloed knowledge, integration costs, devops costs, coordinating releases, cross-team communication, testing, contract versioning, shared tooling. I could go on, but that's just a sample of some of the less obvious costs. I feel that the collective opinion of microservices has shifted towards being trepidatious of microservices as many have experienced the pains associated with microservcies.
• andersrs 3y ago
  Goldilocks went inside the Git Hut. First she inspected the git repo of the great, huge bear, and that was 2TB which was far too large and monolithic for her. And then she tasted the 281 repos of the middle bear, and they were far too small and numerous for her. And then she went to the 10 repos of the little, small wee bear, and checked out those repos. And they were neither too large nor too small and numerous, but just right; each had it's own reason to be and she liked it so well, that she sat down and cloned it all.
• parentheses 3y ago
  The biggest negative of Microservices is that it creates hard ownership boundaries. This affects planning - more effort is needed to understand boundaries that need adjustment or crossing. This affects execution - needing to cross a boundary comes with inefficiencies and an automatic need to move with synchronization. This affects future projects - service boundary clarity works against flexibility.
• PedroBatista 3y ago
  Similarly with frontend devs thinking a "modern web-app" can only be built with frontend frameworks/libs like React/Vue/Svelte, etc, lately I feel there's an idea floating around that "monolith" equals running that scary big black ball of tar as a single instance and therefore "it doesn't scale", which is insane. Another observation is the overall amount of code is much bigger and most of these services are ~20% business/domain code and ~80% having to deal with sending and receiving messages from other process over the network. You can hide it all you want, but at the end of the day it's there and you'll have to deal with the network in one way of another. Just like the frontend madness, this microservice cult will only end once the economy goes to crap and there's no money to support all these Babel Towers of Doom. PS: microservices have a place, which is inside a select few of companies that get something out of it more than the cost they pay.
  • superfrank 3y ago
    I think the thing people normally miss about microservices is that the goal of microservices is usually to solve organization and people problems and not technological ones. There's some tech benefits like allowing services to scale independently, but the biggest benefit is clear ownership boundaries and preventing code from becoming overly coupled where it doesn't need to be. If you're a team small team working on a single product you probably don't need microservices since you likely don't have the type of organizational problems that microservices solve. Microservices are likely premature optimization and you're paying the price to solve problems you don't yet have.
    • koliber 3y ago
      Yep. There are situations where microservices genuinely add net value. In discussions like this one, people make valid points for microservices and for monoliths. Often, words like “large” and “many” are used without providing a sense of scale. Hers is a heuristic. It’s not a hard rule. There are likely good counter examples. It does sketch a boundary for the for/against equation for microservices. Would love to hear feedback about whether “100” is that number or a different heuristic would be more accurate. Engineering departments with fewer than 100 engineers should favor monoliths and seriously question efforts to embrace microservices. Above that, there’s an increasing chance the microservices could provide value, but teams should stick to a monolith as long as possible.
• highspeedbus 3y ago
  Monoliths are like heavy trucks. Microservices are like motorcycles. Surely you can delivery 15 metric tons of wood with either of them. You will just need a lot of motorcycles to match capacity. Somehow a big part of industry became convinced that of course that approach is better, since motorcycles are cheaper*, easier to scale*, and solve some managerial problems*. * They don't, IMHO. >its components become increasingly coupled over time >The codebase becomes complex enough that nobody fully understands every part of it >if a change introduces a bug - like a memory leak - the entire service can potentially be affected by it. I believe the only real solution to those challenges is Competency, or Programmer Professionalism. Uncle Bob had some great points on this topic. https://www.youtube.com/watch?v=BSaAMQVq01E https://www.youtube.com/watch?v=BSaAMQVq01E
  • ysleepy 3y ago
    Was with you until you mentioned Robert Martin. I have no respect for that shill.
• kgeist 3y ago
  >As each team dictates its own release schedule and has complete control over its codebase, less cross-team communication is required, and therefore decisions can be taken in less time. In my experience, it's the opposite. When a feature spans several microservices (and most of them do), there's much more communication to coordinate the effort between several isolated teams.
• ph4evers 3y ago
  I still don’t fully understand what makes something a monolith. For example, I have a big app which is serving 90% of the API traffic. I also have three separate services, one for a camera, one to run ML inference, and one to drive a laser welding process. They are split up because they all need specific hardware and preferably a separate process (one per gpu for example). Is this a monolothic app or a micro service architecture?
  • flakes 3y ago
    I would call that a micro-service architecture using a mono-repo. I think a lot of people here are conflating mono-repo/poly-repo with a mono-deployment. You can easily add in extra entrypoint executables to a single mono-repo. That allows initiating parts of the system on different machines, allowing scaling for skewed API rates across your different request handlers. Similarly, you can create a monolith application building from a poly-repo set of dependencies. This can be easier depending on you version control system, as I find git starts to perform really poorly when you enter multi-million SLOC. At my job we have a custom build system for poly-repos that analyzes dependencies and rebuilds higher level leaf packages for lower level changes. Failing a dependency rebuild gets your version rejected, keeping the overall set of packages green.
  • stavros 3y ago
    > Is this a monolothic app or a micro service architecture? Yes. To be less facetious, the continuum goes from "all the code in a single process" to "every line of code is a separate service". It's not either-or.
  • SanderNL 3y ago
    I tend to call these things “distributed monoliths” assuming the camera, ML and laser driver are integral to the functionality of the system. There is no hard rule that I know of but my heuristic is something like “can I bring instances up and down randomly without affecting operations (too much)”. If so, I’d call that a microservice(ish) architecture. The waters have been muddied though. Microservices were IMO once associated with Netflix-like scalability, bringing up and down bunches up “instances” without trouble. But nowadays what used to be good old service-oriented architecture (SOA) tend to be also called microservices. SOA can also be about scalability, but it tended to focus more on how to partition the system on (business) boundaries. I guess like you did. It’s all a bit muddy in my experience.
• Aerbil313 3y ago
  Looking at the “costs” section and considering the recent developments, it seems better tooling will increasingly be helpful in running a software company. See for example Nix Flakes. You can now have instant and performant declaratively defined identical environments in production and development, and across teams. IMHO widespread use of such technologies (as opposed to heavyweight ones like Docker) could relieve one of the biggest costs of microservices: They are expensive to run.
• john-tells-all 3y ago
  Monoliths are so much easier to test and deploy! Even if one service needs to be developed separately, it can still live in the monolith. For dev, it's easier to test. For production, deploy the same monolith but have it only handle a single service, depending on how it's deployed. You get all the benefits of a monolith while a little benefit of separate services. Microservices are okay, but "kick up" a lot of issues that can be slow/awkward to solve. Testing being the big one. If the business decides it's worth the exponential complexity then that's fine.
• Gluber 3y ago
  Every company i have advised jumped on the microservice bandwagon some time ago.... Here is what I tell them: 1. Microservices are a great tool... IF you have a genuine need for them 2. Decoupling in and on itself with services it not a goal 3. Developers who are bad at writing proper modular code in a monolithic setting will not magically write better code in a Microservice environment.. Rather it will get even worse since APIS ( be it GRPC, Restful or whatever ) are even harder to design 4. Most developers have NO clue about consistency or how to achieve certrain gurantees in a microservice setting ( Fun fact: My first question to developers in that area is: Define your notion of consistency, before be get to the fun stuff like RAFT or PAXOS) 5. You don't have the problems where microservices shine ( e.g banks with a few thounsands RPS ) 6. Your communication overhead will dramatically increase 7. Application A that does not genuinly need microservices will be much cheaper as a monolith with proper code seperation Right now we have generation of developers and managers who don'T know any better, and just do what everybody else seems to be doing: Microservices and Scrum ... and then wonder why their costs explode.
• camgunz 3y ago
  People really underestimate the eventual consistency thing. It's 100% the case your app will behave weirdly while it's processing some sort of change event. The options for dealing with this are real awkward, because the options for implementing transactions on top of microservices are real awkward. Product will absolutely hate this, and there won't really be anything you can do about it. Also fun fact: this scales in reverse, as in the bigger and better your company gets, the worse this problem becomes, because more services = more brains = more latency. Relatedly, you can't really do joins. Like, let's say you have an organizations service and a people service. You might want to know what people are in which organizations, and paginate results. Welcome to a couple of unpalatable options: - Make some real slow API calls to both services (also implement all the filters and ordering, etc). - Pull all the data you need into this new 3rd service, and justify it by saying you're robust in the face of your dependency services failing, but also be aware you're adding yet another layer of eventual consistency here too. This is the simplest this problem can be. Imagine needing data from 3 or 13 services. Imagine needing to to synchronize UUIDs from one service to 20 others. Imagine needing to also delete a user/organization from the 30 other services that have "cached" it. Etc etc. I used to think microservices were an adaptation to Conway's law, but now I really think it's a response to the old days when we didn't have databases that scaled horizontally. But we do now (Cockroach, Big Query, etc) so we really should just move on.
  • fullspectrumdev 3y ago
    The joins problem is fucking killing me in some personal projects that will need a total rewrite at this point
• tantaman 3y ago
  Really doesn't make sense to me that people jump to microservices rather than creating module boundaries in their monolith.
• aimon1 3y ago
  Microservices are necessary and the best way to architect something new that is going to be used at scale. In my experience working with monolithic architecture with 20+ teams at a large Tech company, I have found it takes multiple years to convert to microservices. Rebuilding generally is possible in half as much and gives you the opportunity to hire good talent, motivate existing employees and use the latest tech. thoughts?
• bullen 3y ago
  Microservices don't cost as much if you deploy them everywhere so you get both vertical and horizontal scaling without lookup cost. Of course then you need the same stack which allows multiple apps deployed everywhere.
• shoelessone 3y ago
  Anytime these discussions come up I always wonder if there are any great examples in the form of a deep technical analysis of microservice architecture? I've built things that I've called microservices, but generally have failed to do a complete job or always left with something that feels more like a monolith with a few bits broken out to match scaling patterns. I know there are talks and papers by Netflix for example, but if anybody knows if any smaller scale, easier to grok talks or papers that go into common pitfalls and solve them for real (vs giving a handwavey solution that sounds good but isn't concrete) I'd love to check it out.
  • screamingninja 3y ago
    This is my gold reference: https://microservices.io/ https://microservices.io/ Most issues I have seen around microservices circle around bad design decisions or poor implementations. Both are also major issues for monoliths, but since those issues do not surface early on, it is easier to start developing a monolith and take on the technical debt to be dealt with later on. Microservices architecture takes time and effort, but pays huge dividends in the long run.
• benreesman 3y ago
  I’ve always thought the monolith vs. micro service debate to miss the point. Taking an RPC call has costs. But sometimes you need to. Maybe the computation doesn’t fit on any of your SKUs, maybe it is best done by a combination of different SKUs, maybe you need to be able to retry if an instance goes down. There are countless reasons that justify taking the overhead of an RPC. So, do you have any of those reasons? If yes, take the RPC overhead in both compute and version management and stuff. If no, don’t. Why is this so contentious?
• qudat 3y ago
  Having an API gateway sounds nice, but that’s not how I’ve seen it. Usually the FE has to query and synchronize multiple API endpoints (eg auth, product, billing). In this case microservices really just means "let the front-end handle the complexity of synchronizing multiple API endpoints." And then we wonder why the FE is so complex: https://bower.sh/front-end-complexity https://bower.sh/front-end-complexity
• deleted 3y ago
  [deleted]
• pkulak 3y ago
  I look forward to 2030 when microservices are all the rage. Anyone who avoids the temptation to tear down and rebuild their entire org as a monolith will be way ahead of the curve.
• totallywrong 3y ago
  As a contractor, having worked with a lot of teams, I get the feeling that the kubernetes and microservices hype a few years ago resulted in a lot of unnecessary refactors. It can make sense, of course, but often doesn't, and running a monolith on k8s is perfectly fine.
• dogcomplex 3y ago
  Can we just build our localized monolith systems in a modular way so they can easily be decomposed into decentralized microservices at any sensible division when the need arises..? Must we always have this debate against an idea that is stupid on its face - sending remote requests for every single service..?
• nijave 3y ago
  The article touches on it a bit, but in my experience microservices multiply operational problems (especially at startups where you don't have big, dedicated infrastructure teams). All of a sudden you have 5-10x things getting built in CI and deployed. You need some way to debug issues so usually distributed tracing comes up. Now that you have 10x as many of everything, you obviously want to try to centralize things like networking, authn/z, service discovery so you introduce some platforms to help with that... but someone has to run and maintain all that. That's fine if you want platform/infrastructure teams to maintain these but many startups only have a very small handful of people (10% or less of eng) handling CI/infra/release/performance/observability/networking/traffic mgmt with some title like "SRE" or "devops"
  • nine_k 3y ago
    A typical startup with 20k DAU: "We need scale, microservices, k8s, CDNs, etc!". Stackoverflow: "We run a single .NET-based multi-tenant web app running across just nine web servers, at 5% to 10% of capacity" [1]. Hacker News: "HN still runs on one core, at least the part that serves logged-in requests, and yes this will all get better someday...it kills me that this isn't done yet but one day you will all see." [2]. HN had ~12M MAU by the end of 2022. [1]: https://www.datacenterdynamics.com/en/news/stack-overflow-still-on-prem-runs-qa-platform-off-just-nine-servers/ https://www.datacenterdynamics.com/en/news/stack-overflow-st... [2]: https://news.ycombinator.com/item?id=35157344 https://news.ycombinator.com/item?id=35157344
    • rospaya 3y ago
      Does HN have the SLA and uptime that the startup signed with their clients and will half an hour of downtime sink HN?
      • nine_k 3y ago
        No. A number of startups don't either. I hazard to say that even giants like Tinder or Uber likely can have a 30 min outage and lose some revenue and goodwill, but not be hit by some exorbitant liabilities. Also, microservices add both resilience (by running many copies) and fragility (many loosely coupled moving parts). Which effect prevails, depends on many factors.
• IceMichael 3y ago
  Testing hugely via expensive integration tests or E2E is needed no matter which software you have. And you could easily fall into doing that for microservice architectures. However, a common way is rather having contract tests. Google Fowler's article for it
• swingingFlyFish 3y ago
  "And if a change introduces a bug - like a memory leak -" I had no idea web applications could cause memory leaks.
• deterministic 3y ago
  > As the number of feature teams contributing to the same codebase increases, its components become increasingly coupled over time. Nope. Not automatically true. Unless your development team is incompetent. And if your development team is incompetent, switching to micro-services will be even worse. 30+ years of experience here working on very large scale software composed of libraries from many teams. I never ever had the kind of monolith problems described in the article. What I have seen though is a 30+ years old micro-services system that generates more WTF comments per day than most software gets per month. It is literally the worst written software I have ever seen or heard about. 150+ micro-services all failing in new random ways every single day. Solving a problem that monoliths I have worked on solved way better.