9 ms·

It's not about microservices or not, it's about domain boundaries, application architecture, coupling. Whether it runs in a service or in a monolith isn't the d

• globular-toast 6y ago
  Yeah. One thing I've noticed is that people are really bad at working towards high-level, nebulous goals like "code quality, right abstractions, decoupling, cohesion". Keeping these goals in mind requires constant thought, analysis and decision making as each case is different and there's no universal solution. So people jump at simple, single-faceted goals like "normalise the database", "spin out microservices", "don't use HTML tables", "rewrite using Rust" etc. These involve no further thought, no continuous evaluation of nebulous targets like quality, no keeping up with moving goals. It explains quite a lot of problems with politics too. Choose from red or blue. No further thinking required. If even that's too difficult, just pick the one your parents/friends picked. Easy!
• konschubert 6y ago
  Yea. Once you have good domain boundaries you can use microservices to make the split more visible for less thoughtful devs and use the associated tooling (contract testing, ... ) to reduce operational coupling around deployments and tests. But aside from that, anything you can do with microservices you can also do in monoliths.
  • pydry 6y ago
    Some people think that if you start creating micro services you will magically just "get" those boundaries.
    • kenniskrag 6y ago
      and magically get the problem of distributed transactions. :)
      • heavenlyblue 6y ago
        I am yet to see a single monolith that doesn't deal with exactly the same issue itself.
        • pc86 6y ago
          Aren't monoliths by definition not distributed?
          • caogecym 6y ago
            monolithic source code can be deployed across multiple servers.
          • heavenlyblue 6y ago
            A true monolith is like a true function - it's absolutely useless because everything it does is pure and therefore it can't interact with reality at all. In less metaphorical terms: you still need to sync external APIs, sync filesystem with the database, deploy to S3 as you don't want to saturate your web workers, or have conflicts in your parallel red-blue deployments. If your monolith doesn't do anything I had just described then you probably aren't doing anything exciting anyway so it's quite unlikely that you've got a lot to say about software architecture.
    • konschubert 6y ago
      Oh, you don't know how true this is.
  • tsss 6y ago
    > But aside from that, anything you can do with microservices you can also do in monoliths. Microservices can give you some things that a modular monolith can't provide: independent deployments, different tech stacks, independent scaling and better resiliency.
  • chris_j 6y ago
    I'd be interested to hear about the sorts of systems that you've worked on and how anything you can do with microservices you can do with a monolith. Some problems that I've had to solve in recent years: - Urgently deploying a fix in one part of the system without having to deploy the _whole_ system. - Updating the framework or the language (my favourite: updating from Java 8 to Java 11, which broke a lot of things and which we would have hated to have to do all in one go, if we'd had a monolith). - Scaling different parts of the system independently (both in terms of running different services on different numbers of nodes and in terms of using different hardware for application nodes and DBs). - Load testing different parts of the system independently. - Trialling a new language or framework in a small part of the system without affecting the rest of the system. I personally wasn't aware of how much of a big deal some of these problems would have been until our system grew to the size that it is now, with a dozen or so development teams working on at least as many services. I personally have no idea how you could solve these problems on a system this size without splitting it into independently deployable services, without incurring a massive cost.
• pjmlp 6y ago
  Indeed, if the team is not able to write modular code, it is not putting a network in the middle that it will sort it out, the outcome is just spaghetti network calls.
  • collyw 6y ago
    I always found the "microservices make things simpler" argument to be suspicious. At the end of the day it is just a monolith with unreliable network connections between components. Each microservice may be less complex, but you have just pushed complexity from the application layer to the devops layer. In a well written monlith the components shouldn't need to be any more complex than a microservice component.
    • anthonypasq 6y ago
      thats because the main advantages of microservices have nothing to do with writing code. as an example, the PathofExile.com website goes down every time the game servers restart because they share infrastructure. This should be avoided.
      • aserafini 6y ago
        But you can avoid this quite easily without resorting to microservices.
      • pjmlp 6y ago
        Someone forgot to use a load balancer with red/blue deployments.
• eternalban 6y ago
  From a technical point of view, we're on the same page. But then there is the reality of modern software development. A few years ago, the new CTO of a Union Square Ventures' investment tapped me as technical advisor to review this startups efforts to expand their software to new verticals. He came in as part of a reshuffle. He had brought his Director of Engineering from his previous (well known) company, and there was even a Star CEO (which is the reason I signed up!) with a monumentally impressive CV. As compensation, I was billing lawyer hourly rates. After two months of reviewing their existing architecture, and picking the brains of the dev, support, and sales team the new verticals, I came with an architectural solution to their immediate and long-term needs. I gave them exactly what they said they wanted. What then happened is that, for one, the Star CEO turned out to be an echo chamber of "growth growth growth" and entirely disappointing as a leader of a software company. And this was a SV veteran from both HW and SW side of SV. Huge disappointment. The CTO, who was entirely clueless, apparently gave in to back channel efforts of his DoE to disregard my work product. A few days later I walk into an all hands meeting where the "next generation" was announced to be "a ball of mud" of "microservices". This same CTO later took me aside and basically offered to give me hush money ("will you be my personal advisor?") to keep quiet, while getting the same (insanely high) hourly rate for the remainder of my contract. So this is the reality of modern software development. Architecture is simply not valued at extremities of tech orgnizations: the bottom ranks are young developers who simply don't know enough to appreciate thoughtful design. And the management is facing incentives that simply do NOT align with thoughtful design and development.
  • pc86 6y ago
    And yet not a single name or identifying piece of information that people can take action on, so these borderline frauds will continue drawing huge paychecks and hampering development for years to come.
    • eternalban 6y ago
      The CEO was not a fraud and given the genuine fully-established and world class credentials of his technical reports in previous engagements, entirely unlikely that he could have faked it with that crowd. No. It seems he had adjusted per prevailing and current norms of SV. Beyond that clarification, I think it irresponsible to name names. This wasn't a case of "fraud" - Peter Principle ruled the day. Both CTO and DoE had in fact lead a successful very large scale internet product company, which is the reason they were tapped. It just happens that this domain was far more nuanced and complex than the domain of their previous victory tour. Also, as expected, they (including the super enthusiastic junior engineers that kept pushing for "microservices") have all moved on. This is just how the industry works.
• NicoJuicy 6y ago
  In short: DDD - Domain Driven Design That's also the most useful thing i learned with doing microservices at work. Note many good articles/videos about practical domain boundaries/designing AggregateRoot though. Does anyone have any tips? I feel that i'm lacking somewhat in designing them.
• collyw 6y ago
  This is something that is totally underappreciated in software. I guess it's difficult to do and takes experience to get right. And probably more difficult to explain how to do to others. Having worked on enough crap code in the past (and right now) my primary thoughts are to try and make things understandable for the next dev that needs to pick it up after me.
• fatnoah 6y ago
  >it's about domain boundaries, application architecture, coupling. Thank you! As a service consumer, if I need to call the same 3 other services for EVERY OPERATION, then we've achieved microservice hell. >monolith with 500.0000 lines of code could be very well designed... As someone who was part of a "de-monolith" effort, the first step of our process was to create internal service facades that grouped things according to the logical domains that aligned well with our required functionality, data storage, and availability requirements. Once those were functional, decoupled, and comprehensible, we actually had an easy to maintain, clean monolithic code base that exposed a small handful of services that were de/loosely coupled and conformed to workflows we need to support via web services.