14 ms·

It's not microservice or monolith; it's cognitive load

218 points by DevOpsy 3y ago

bobobob420 3y ago
How do you get to third on hn with 8 points and 0 comments in 2 hours?
- bobobob420 3y ago
  Now second
- simlevesque 3y ago
  By being the new post with the most points and comments in 2 hours. If another post would was more recent and had more points it would be higher. These posts get a temporary boost but if the points stay the same while being at the top, it'll disappear pretty soon.
  - quickthrower2 3y ago
    I suspect #points is the main factor. And the algorithm wants to surface fresh stuff, otherwise we'd still all be talking about Sam Altman. Glad we aren't :-) (nothing against Sam...)
  - bobobob420 3y ago
    Seems pretty easy to bot. Its also a personal blog which adds to suspicion. There is also a new trend which is trying to get on hackernews front page
- ldjkfkdsjnv 3y ago
  Someone at ycombinator boosts and deranks posts. I see it all the time.
quickthrower2 3y ago
Cognitive load is one good dimension to think about here. I like that it is a human concern. There are probably multiple. What I think is challenging is figuring out what the teams should be - this can be more complex than it appears. Do you have an "auth team" for example? How do you ensure the people in that team are happy that their CV is going to be "done auth for 2 years" when they next do their job. For small companies you might have micro teams, where there are 0.1 members on that team - I.e. it is at the point of part of someone's role. But treating it like it's own team (it get's own repo(s)) might make sense.
amw-zero 3y ago
We can’t measure cognitive load though. Or if we can, no one knows a way to apply that to software projects.
- mhh__ 3y ago
  You can't and shouldn't try to. We can however qualitatively try to see where the wind is blowing.
  - MichaelZuo 3y ago
    How does someone verify their understanding is correct then?
- aikiplayer 3y ago
  We might not be able to quantitatively measure it but we can run studies to evaluate what individuals and teams can handle. Human factors people do this and it’s a sub field in industrial engineering. The military runs these studies and I’d imagine air traffic controllers do them as well, etc. You sometimes get really surprising results.
  - lenerdenator 3y ago
    That's something I've noticed: the way we treat systems developed to work on data is _completely_ different from systems developed to work on, idk, oil. You can build data refineries (ETF) same as an oil refinery. The difference is, the engineers who build the oil refinery create manuals and standard operating procedures to operate the refinery, because if they don't, then the new board operator will press the wrong button and blow out every window in a five-mile radius. When you build a data refinery, no one documents _anything_ no matter how many times you ask engineers on the team to do it. Will it blow up in a massive fireball if you do it wrong? No, but it will corrupt data and have a business consequence. You can keep the 40 different microservices for the data refinery in your head though, right?
    - pixl97 3y ago
mikewarot 3y ago
I think a revisit of Conway's paper[1] might be appropriate. Between that, and the recent talk by Kevlin Henney about architecture[2], you'll be in far better shape to make such decisions. [1] https://www.melconway.com/Home/Committees_Paper.html https://www.melconway.com/Home/Committees_Paper.html [2] https://www.youtube.com/watch?v=aCK-Pu80EEs https://www.youtube.com/watch?v=aCK-Pu80EEs
3cats-in-a-coat 3y ago
The sad thing about these "monolith vs microservice" debates is that to this day we have programming languages which favor shared mutable state, so a program written like this is an absolute hell (or a very leaky abstraction) to distribute. And it doesn't have to be like this. Think about it. When your variable is a simple value, like a number or a string or a struct, we treat it as pass-by-copy (even if copy-on-write optimized), typically stack allocated. Remote IO is also pass-by-copy. But in-between those two levels, we have this intermediate pointer/handle hell of mutable shared state that the C family of languages promote, both procedural and OOP variety. The original OOP definition is closer to the Actor model which has by-copy messages, but the actual OOP languages we use, like C++, Java, C# all derive philosophically from the way C handles entities on the heap, as this big shared local space you have immediate access to, and can pass around pointers to. And that's where all our problems come from. This concept doesn't scale. Neither in terms of larger codebases. Nor in terms of distributing an application. It doesn't also scale cognitively, which the article mentions, but doesn't quite address in this context.
- alexalx666 3y ago
  The tradeoffs are great if you are mindful
  - 3cats-in-a-coat 3y ago
    Tradeoffs of?
- jiggawatts 3y ago
  Something I’ve wanted for a while now is a language / framework that behaves like networked micro services but without the network overheads. E.g.: the default hosting model might be to have all of the services in a single process with pass-by-copy messages. One could even have multiple instances of a service pinned to CPU cores, with hash-based load balancing so that L2 and L3 caches could be efficiently utilised. The “next tier” could be a multi-process host with shared memory. E.g.: there could be permanent “queue” and “cache” services coupled to ephemeral Web and API services. That way, each “app” could be independently deployed and restarts wouldn’t blow away terabytes of built up cache / state. One could even have different programming languages! Last but not least, scale out clusters ought to use RDMA instead of horrifically inefficient JSON-over-HTTPS. Ideally, the exact same code ought to scale to all three hosting paradigms without a rewrite (but perhaps a recompile). Some platforms almost-but-not-quite work this way, such as EJB hosts — they can short circuit networking for local calls. However they’re not truly polyglot as they don’t support non-JVM languages. Similarly Service Fabric has some local-host optimisations but they’re special cases. Kubernetes is polyglot but doesn’t use shared memory and has no single-process mode.
hmeh 3y ago
It’s hard to imagine worse advice. Software design principles lead you to good architecture. Focus on autonomy, proper partitioning, and sound design and you get what you get. If you target monoliths out of some misguided attempt to reduce cognitive load, you will only create unnecessary entanglement. If you try to target “microservices” with N services per team or other arbitrary target, you will end up missing boundaries you should realize or introducing ones you shouldn’t. There is no instant pudding.
- hmeh 3y ago
  Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.
  - dboreham 3y ago
    The entire purpose of microservices is to comply with Conway.
    - hmeh 3y ago
      This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.
      - guhcampos 3y ago
        I don't disagree completely with the comment, but I would possibly change it from "comply with Conway" tô "embrace Conway".
        hmeh 3y ago
        If you don't disagree, then I assume you have a strong understanding of structural design. I assume that you recognize that Conway's law is more of a curse, and a warning than it is something to embrace. I assume that you recognize that the only possible way to "embrace conway's law" and simultaneously recognize structural design would be to constantly be firing or otherwise disbanding entire teams as components get completed (components that likely won't need to be touched frequently because they were designed for a single reason to change). I assume all of that makes perfect sense to you. Yes?
ldjkfkdsjnv 3y ago
I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a professional. Technical debt more commonly comes from under abstraction rather than too much complexity/abstraction.
- imachine1980_ 3y ago
  i work in legacy code over abstraction gives more headaches than having to check manually when you need to change the software and the person who write it isn't in the company in the last five years, because the software is full of constrains that you don't known, and when you need to change something basic the whole software collapse(because of the interdependence of the componentes).
  - ldjkfkdsjnv 3y ago
    Right but thats just bad programming. If they had used no abstraction it would also be a nightmare.
    - teaearlgraycold 3y ago
      Rememeber: Having no abstraction is better than the wrong abstraction.
- jahewson 3y ago
  > Just design the software upfront We call that waterfall :)
  - ldjkfkdsjnv 3y ago
    No its called software engineering
  - 3y ago
dilawar 3y ago
Some decent pointers that one can keep in mind as rule of thumb. Would love to read some comments that says hey we tried exactly the same but...
mariodiana 3y ago
“[D]esign the software to fit the maximum team cognitive load.” I see. So, RAID drives, failover servers for redundancy, and generators (or at least UPS batteries) for power — but push your team to their maximum load.
- guhcampos 3y ago
  Might be a bit of a wording thing, because I think I got it very differently than you. To me, that sounds like "you can't design for a higher cognitive load than what your team can absorb" - and not "try to optimize the cognitive load dor the maximum your team can absorb".
  - slabity 3y ago
    It sounds like it should have been worded like, "Minimize cognitive load to maximize team effectiveness" The original wording sounds like could go both ways, so I understand why the person you're responding to sees it that way.
nateburke 3y ago
The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.
- ddejohn 3y ago
  This strikes me as overly cynical. My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that > cross team meetings and project management every time you want to ship a feature is somehow avoidable in tech?
  - irjustin 3y ago
    > This strikes me as overly cynical. > My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. > Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that This is overly cynical to you likely because you haven't experienced maintaining micro-services in the long term. Being able to "break away" with a common interface is literally the microservice tag line. It's completely true too. Standing up a service w/ an interface is incredibly fast, rewarding and watching it hum is beautiful. The problem starts when there's a bug that's upstream of your service. It's not too hard to get all 15+ services running on your laptop, but the problem is the other teams no longer let external members directly deploy the services they maintain (that one time someone from another team deployed a big bug). So now you've got to get PR approval and seemingly no one wants to review your bug. So you ask for time from the Product Owner and it gets forgotten because they're really busy too. So you go to an eng manager, etc etc... The above scenario plays out SO many times. I've been there in all various forms. As a blunt statement - any team under 30 members, monolith.
vvpan 3y ago
Whether it is a function, class, module, application or service I think there is one word for it - encapsulation.
- apantel 3y ago
  Yeah I would think that the solution to monolith vs microservices would be “neither should be followed because of dogma; encapsulate where it makes sense, when it makes sense”.
LASR 3y ago
The single-most important lesson I've learned building products as a founding engineer in a successfully exited startup: weighing tradeoffs and deciding which software architecture to use is the wrong place to dedicate mental energy. It's always the product. It comes first. Then the business. If you're lucky you may become a pawn in a larger battle among giants and you'll get acquired before you attempt to make any profit. If you end up in a place where your chosen architecture is no longer capable of supporting your scale - that's a happy place that very few teams get to experience. It means you've survived. Given that, whatever allows you to quickly get things in the hands of real customers (which depends quite heavily on what the actual product is) is the best architecture. We've hired some experienced engineers from giga-corp FAANG etc into tiny startups. The transition is hard, because there the opposite is true. You have a business already, and you have a well-defined goal you need to achieve with multi-year roadmaps etc. There, yeah you should probably decide on architecture first.
- solatic 3y ago
  Sad to see this isn't the top comment. Unless or until you have a built-in source of guaranteed demand - the only thing that matters is product agility in order to find customer demand. Without demand, you have no revenue, investors lose interest, the money runs out, and people stop paying you to work on that system. Then everything gets thrown out. And "demand" is not "we have paying customers" - it's having sufficient revenue, for whatever that means for that particular org.
- baby 3y ago
  I think we’ve been spoiled by move fast break things type of startups, and indeed if you’re in a competitive field you might have to fight for your survival. But truly successful projects are the ones that are worked on and improved for decades. Long-term work means that you will have to be conscious about being clean, and care about constant refactoring and simplification, and design decision that will prevent paralysis down the line. There’s a reason twitter did not change for like 10 years and apps like Instagram are able to adopt new trends super quickly. (Unrelated: since the Instagram team is behind Threads, I predict that Threads is going to evolve really really fast and be harsh competition to twitter over time)
hiddencost 3y ago
I've read a lot of these arguments. I dunno, I think software engineers have neglected soft skills for too long. "Philosophy X always leads to Y outcome." "Framework Z does Q." I bet a lot of software engineers are just bad with people. Coordinating a dozen teams takes work, but people do it all the time successfully. I don't think the frameworks are as important as figuring out an approach that works for the people involved.
- steve_adams_86 3y ago
  I'm pretty sure one of the things that keeps me employed in software is that I'm good at non-software stuff. So much so that I focus quite a bit less on the software now, and a lot more on the things software does, why, and for whom. That stuff seems a lot more important in the scheme of things; especially when money isn't free and people need software to be truly useful and very immediately. Maybe that's a typical progression in most software careers, but I wouldn't have believed I'd be here 10 years ago, or maybe even 5. I was always very technical (and I still love that side of things). Now I see the people side of things as far more important and interesting.
LarsDu88 3y ago
Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all. Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that. The principled approach is really to simply not do that, for the basic latency costs. I mean, did World of Warcraft, which is way more impressive than 99% of all the little django apps out there in corpo world run on a gajillion microservices? Fuck no
- c048 3y ago
  This is what you get when all you talk about it the positives, especially to new programmers or students. It's not about the why, but only if you do or do not. I'll die on this hill, but DDD can be put right up there with microservices as a solution to a certain type of problem being sold as THE solution.
  - FLT8 3y ago
    I'm interested to hear more about your views on DDD - especially if you have examples where DDD has been actively harmful. Usually my advice for anyone thinking about building a new piece of software for a particular business goal is to a) run an event storming workshop with a group of domain experts to help get a really good idea of events, actors, commands, information flow and clusters of behaviour, and then b) run a second pass where you think the domain through in terms of transactional boundaries and DDD aggregates, and then c) do a third pass where you think specifically about security constraints and how they can be met. It's an expensive exercise in terms of time taken up front, but having completed it, hopefully the team have gained enough of an insightful understanding of the domain that they won't make silly hard-to-reverse mistakes like needing transactions that span service boundaries, or building demonstrably distinct domains which share similar concepts into uber objects spanning those domains, or having one service depend on information from multiple other services in order to apply required security constraints. Anyway, TLDR is I have found DDD and DDD-adjacent methods extremely helpful for thinking through designs and making app architecture decisions.
- 3y ago
jauntywundrkind 3y ago
I feel like we are going to spend many years coping with Team Topologies, a book which idolizes a seeming infinite and vast independence of teams from each other in the name of 'spending things up' or some such. I love, respect, & cherish the ideas here. But the sound-bite ideas of the book vastly overweigh the practical complexities of development. Yeah, giving each team authority to do their thing is desperately necessary today; there's too much organizational confusion & unclear decision making processes. Teams need autonomy. Yes. But the book really seems to have so little to say about how to play together. It doesn't talk hardly at all about how to find concordance & to make decisions across teams. What are good common techs to adopt? Microservices as I'm everyone can pick whatever (Haskell for this, pho for that, & 12 varieties of node) is one organizational end, monolith is another end. The confusion and angst Team Topologies let's dwell and build is infinite, because it's pretense is that there are many parallel streams of development and that inter-team work is a negative. The books is so good and so important. Because so many orgs are fucked and doing things terribly. Cognitive load is massively over managed and it's impossible to do anything to escape the tar pit the shitty ancient overly established pretentious shitbag elders have dictated. But the result of what Team Topologies says is such an opposite and shitty fucked, where cognitive loads expand exponentially because every team is independent & fucking off into their own space, with only vague constraining behavior or nebulous "platform" teams that "support" or maybe dictate to these platforms teams. Never have I seen a book I both respect so highly & think so terrible & awful.
hooby 3y ago
Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordination, while monoliths automatically ensure that everyone always is perfectly the same page? Because by my personal experience, you totally can code a monolith in a strictly modular fashion, with clean interface-based API boundaries between the separate parts. And if you put those "modules" into separate packages, the dependencies between them end up being managed and documented as well. Just like you totally can setup microservices and surrounding procedures in a way that actually increases the feeling of product ownership in the teams, and reduces the hassle of inter-team coordination - especially in larger companies. Obviously there are ways to do monoliths right, and spectacularly wrong. And there are ways to do microservices right and wrong... I see so many arguments here, that do compare one method done wrong with the other method done right - and then imply that this is a strong reason for choosing that second method. I don't get it?
- nullandvoid 3y ago
  To borrow some monolith examples from Monolith to Microservices (https://www.goodreads.com/en/book/show/44144499 https://www.goodreads.com/en/book/show/44144499 - fantastic read) "Single Process" - Can be module based (Shopify), where multiple module's interact, but must be combined for deployment still, these module's can even extend to the DB's. Can still have multiple instances for performance "Distributed Monolith" - This is one to fear the most, we have multiple services, yet there is still shared DB's meaning we have to deploy things together. Both are monoliths but one is less susceptible to ball of mud. It's a sliding scale, with trade offs for each (and many variations still in between those listed). I think it's a lack of common terminology surrounding monolith / micro-service that creates this binary illusion.
- chronid 3y ago
  My 2c: you can get things right, but most of the time you won't, for many reasons - technical, logistical, cultural or merely political. Sometimes you don't control these reasons. So you are now left with managing risk. It's trade-offs all the way down.
zubairq 3y ago
I totally agree... the real question is how to reduce cognitive load. Try to get a system that can fit in your head, although I have totally failed to achieve this myself. But it is a goal!
- baby 3y ago
  Create self-contained frameworks and libraries by extracting code that starts becoming heavy and could be useful by its own. These are the useful abstractions. Constantly seek to specify, document, and simplify the protocols you implement. The clearer the ideas, the cleaner the implementation. Strive to use a single programming language. Organize your code like you would organize a city or a book.
  - zubairq 3y ago
    Thanks, good tips!
konschubert 3y ago
It’s hard to enforce api contracts between components of a monolith. And when performance tanks, it’s hard to pin the root cause to a component. Both of these could probably be fixed by tooling. Could be z as fun research project or maybe a company.
- karlmdavis 3y ago
  You and I must work in very different contexts, as these questions are so obvious that they first seemed like satire to me. You enforce API contracts in a monolith (or any codebase, really) via an at-least-modest amount of typing and a compiler. You diagnose performance issues via any number of tools, prominently including metrics and profilers. My context for this is a lot of years working with backend languages like Java, Rust, etc. though the same assurances and tooling are available for most every platform I’m aware of.
  - konschubert 3y ago
    Sure… and then the type of the return object if of API is ‘CustomerORMModel’… and now the api consumer can build n+1 query problems across components. You need a few more restrictions than that. But I agree it’s doable.
- baby 3y ago
  That’s why Meta has thrift and Google has grpc.
edandersen 3y ago
Lots of architects / tech leads read this instead as: "design the software to fit the maximum team cognitive load that you desire”. They actually over-complicate software builds in order to justify headcount later. "Oh whoops yes we now need a whole full time Ops team, don't worry I know just the guys".
- pluto_modadic 3y ago
  Kubernetes: because we have cloud engineers and they're not busy, right? it's not like they could be doing more important things if they weren't chasing fires.... wait why is my head count soaring...
qaq 3y ago
Mcroservices at the very least require very high investment into proper CI/CD and observability. If you are not willing to allocate resources to get those right things are going to go badly.
baby 3y ago
IMO: write everything in Rust. If a dependency is not in Rust, rewrite in Rust. Carmack has a rant about Meta’s stack for the Quest being in different languages and being a pain. Having worked in heavily-split stacks I don’t want to run into these again.
- TylerE 3y ago
  Never rewrite. Rewrites always fail.
will5421 3y ago
I’m sure that in every case, one or the other will be better for business for technical reasons.
- Sankozi 3y ago
  If only technical reasons would be important when choosing architecture then microservice architecture would not exists. Its killer feature is team independence and strict separation of responsibilities. Any technical advantages are dwarfed by technical problems it introduces.
hiAndrewQuinn 3y ago
I maintain that the only way to truly fight cognitive load is to outsource more of your design to long-term memory. That is as close to a silver bullet as you will ever get, and it explains way more of the tech landscape than you want to admit. In the ideal case, there exists a literal piece of mathematics you translate into code and work with from there. The upfront cost is extreme - but, once the math is internalized, the resulting product is sleek and elegant and can be understood rapidly at a bird's eye view by other people who also understand the underlying mathematics. Weaken this ideal case however appropriate to your business case, but no more than you have to!
lakomen 3y ago
Microservices = Cloud sales Cloud has money to pay for bullshit articles hyping Microservices. Ergo newbies believe the hype and hype Microservices. It's all stupid and HN with Reddit is the epicenter of stupid
antman 3y ago
Can anyone suggest a blog/book on how you manage cross communication across teams regarding evolving software interfaces? Change management foe Domain Driven Development? The way to minimise cognitive load is to have established amd clearly documented processes usually
dunfear 3y ago
Most system can have a single server today and it will basically always be more simple than N smaller ones. Everything is just faster if you just skip the TCP layer. Less configuration, less attack surfaces, less possible problems and issues. The CI/CD and backup is a lot easier as well. It is as another author wrote: It is a people problem. We programmers like the "do one thing" mantra so we tend to want to add it everywhere - even in places were the cost may outweigh the benefits.

218 points by DevOpsy 3y ago

bobobob420 3y ago

How do you get to third on hn with 8 points and 0 comments in 2 hours?

bobobob420 3y ago
Now second
simlevesque 3y ago
By being the new post with the most points and comments in 2 hours. If another post would was more recent and had more points it would be higher. These posts get a temporary boost but if the points stay the same while being at the top, it'll disappear pretty soon.
- quickthrower2 3y ago
  I suspect #points is the main factor. And the algorithm wants to surface fresh stuff, otherwise we'd still all be talking about Sam Altman. Glad we aren't :-) (nothing against Sam...)
- bobobob420 3y ago
  Seems pretty easy to bot. Its also a personal blog which adds to suspicion. There is also a new trend which is trying to get on hackernews front page
ldjkfkdsjnv 3y ago
Someone at ycombinator boosts and deranks posts. I see it all the time.

quickthrower2 3y ago

Cognitive load is one good dimension to think about here. I like that it is a human concern. There are probably multiple. What I think is challenging is figuring out what the teams should be - this can be more complex than it appears. Do you have an "auth team" for example? How do you ensure the people in that team are happy that their CV is going to be "done auth for 2 years" when they next do their job. For small companies you might have micro teams, where there are 0.1 members on that team - I.e. it is at the point of part of someone's role. But treating it like it's own team (it get's own repo(s)) might make sense.

amw-zero 3y ago

We can’t measure cognitive load though. Or if we can, no one knows a way to apply that to software projects.

mhh__ 3y ago
You can't and shouldn't try to. We can however qualitatively try to see where the wind is blowing.
- MichaelZuo 3y ago
  How does someone verify their understanding is correct then?
aikiplayer 3y ago
We might not be able to quantitatively measure it but we can run studies to evaluate what individuals and teams can handle. Human factors people do this and it’s a sub field in industrial engineering. The military runs these studies and I’d imagine air traffic controllers do them as well, etc. You sometimes get really surprising results.
- lenerdenator 3y ago
  That's something I've noticed: the way we treat systems developed to work on data is _completely_ different from systems developed to work on, idk, oil. You can build data refineries (ETF) same as an oil refinery. The difference is, the engineers who build the oil refinery create manuals and standard operating procedures to operate the refinery, because if they don't, then the new board operator will press the wrong button and blow out every window in a five-mile radius. When you build a data refinery, no one documents _anything_ no matter how many times you ask engineers on the team to do it. Will it blow up in a massive fireball if you do it wrong? No, but it will corrupt data and have a business consequence. You can keep the 40 different microservices for the data refinery in your head though, right?
  - pixl97 3y ago

mikewarot 3y ago

I think a revisit of Conway's paper[1] might be appropriate. Between that, and the recent talk by Kevlin Henney about architecture[2], you'll be in far better shape to make such decisions. [1] https://www.melconway.com/Home/Committees_Paper.html https://www.melconway.com/Home/Committees_Paper.html [2] https://www.youtube.com/watch?v=aCK-Pu80EEs https://www.youtube.com/watch?v=aCK-Pu80EEs

3cats-in-a-coat 3y ago

The sad thing about these "monolith vs microservice" debates is that to this day we have programming languages which favor shared mutable state, so a program written like this is an absolute hell (or a very leaky abstraction) to distribute. And it doesn't have to be like this. Think about it. When your variable is a simple value, like a number or a string or a struct, we treat it as pass-by-copy (even if copy-on-write optimized), typically stack allocated. Remote IO is also pass-by-copy. But in-between those two levels, we have this intermediate pointer/handle hell of mutable shared state that the C family of languages promote, both procedural and OOP variety. The original OOP definition is closer to the Actor model which has by-copy messages, but the actual OOP languages we use, like C++, Java, C# all derive philosophically from the way C handles entities on the heap, as this big shared local space you have immediate access to, and can pass around pointers to. And that's where all our problems come from. This concept doesn't scale. Neither in terms of larger codebases. Nor in terms of distributing an application. It doesn't also scale cognitively, which the article mentions, but doesn't quite address in this context.

alexalx666 3y ago
The tradeoffs are great if you are mindful
- 3cats-in-a-coat 3y ago
  Tradeoffs of?
jiggawatts 3y ago
Something I’ve wanted for a while now is a language / framework that behaves like networked micro services but without the network overheads. E.g.: the default hosting model might be to have all of the services in a single process with pass-by-copy messages. One could even have multiple instances of a service pinned to CPU cores, with hash-based load balancing so that L2 and L3 caches could be efficiently utilised. The “next tier” could be a multi-process host with shared memory. E.g.: there could be permanent “queue” and “cache” services coupled to ephemeral Web and API services. That way, each “app” could be independently deployed and restarts wouldn’t blow away terabytes of built up cache / state. One could even have different programming languages! Last but not least, scale out clusters ought to use RDMA instead of horrifically inefficient JSON-over-HTTPS. Ideally, the exact same code ought to scale to all three hosting paradigms without a rewrite (but perhaps a recompile). Some platforms almost-but-not-quite work this way, such as EJB hosts — they can short circuit networking for local calls. However they’re not truly polyglot as they don’t support non-JVM languages. Similarly Service Fabric has some local-host optimisations but they’re special cases. Kubernetes is polyglot but doesn’t use shared memory and has no single-process mode.

hmeh 3y ago

It’s hard to imagine worse advice. Software design principles lead you to good architecture. Focus on autonomy, proper partitioning, and sound design and you get what you get. If you target monoliths out of some misguided attempt to reduce cognitive load, you will only create unnecessary entanglement. If you try to target “microservices” with N services per team or other arbitrary target, you will end up missing boundaries you should realize or introducing ones you shouldn’t. There is no instant pudding.

hmeh 3y ago
Just read the author’s bio. This is a person that appears to have zero software design experience writing an article telling you to ignore software design and just respect your team configuration. I call this Conway’s Confusion.
- dboreham 3y ago
  The entire purpose of microservices is to comply with Conway.
  - hmeh 3y ago
    This is wrong. That's not how Conway's Law works. It’s also not how software design works. But please, by all means, continue to spread disinformation and keep us in the dark ages.
    - guhcampos 3y ago
      I don't disagree completely with the comment, but I would possibly change it from "comply with Conway" tô "embrace Conway".
      - hmeh 3y ago
        If you don't disagree, then I assume you have a strong understanding of structural design. I assume that you recognize that Conway's law is more of a curse, and a warning than it is something to embrace. I assume that you recognize that the only possible way to "embrace conway's law" and simultaneously recognize structural design would be to constantly be firing or otherwise disbanding entire teams as components get completed (components that likely won't need to be touched frequently because they were designed for a single reason to change). I assume all of that makes perfect sense to you. Yes?

ldjkfkdsjnv 3y ago

I used to complain about overly complex software, until I realized the problems themselves were very complex. There was/is no way around complexity, and pushing for early simplicity causes more problems than it solves. People need to accept that encoding 1,000 if else statements (software engineering) will be complex no matter how you spin it. Just design the software upfront for what you will need, like a professional. Technical debt more commonly comes from under abstraction rather than too much complexity/abstraction.

imachine1980_ 3y ago
i work in legacy code over abstraction gives more headaches than having to check manually when you need to change the software and the person who write it isn't in the company in the last five years, because the software is full of constrains that you don't known, and when you need to change something basic the whole software collapse(because of the interdependence of the componentes).
- ldjkfkdsjnv 3y ago
  Right but thats just bad programming. If they had used no abstraction it would also be a nightmare.
  - teaearlgraycold 3y ago
    Rememeber: Having no abstraction is better than the wrong abstraction.
jahewson 3y ago
> Just design the software upfront We call that waterfall :)
- ldjkfkdsjnv 3y ago
  No its called software engineering
- 3y ago

dilawar 3y ago

Some decent pointers that one can keep in mind as rule of thumb. Would love to read some comments that says hey we tried exactly the same but...

mariodiana 3y ago

“[D]esign the software to fit the maximum team cognitive load.” I see. So, RAID drives, failover servers for redundancy, and generators (or at least UPS batteries) for power — but push your team to their maximum load.

guhcampos 3y ago
Might be a bit of a wording thing, because I think I got it very differently than you. To me, that sounds like "you can't design for a higher cognitive load than what your team can absorb" - and not "try to optimize the cognitive load dor the maximum your team can absorb".
- slabity 3y ago
  It sounds like it should have been worded like, "Minimize cognitive load to maximize team effectiveness" The original wording sounds like could go both ways, so I understand why the person you're responding to sees it that way.

nateburke 3y ago

The moment you adopt service based teams with service based managers, say goodbye to engineers caring about working product. Say hello to cross team meetings and project management every time you want to ship a feature. It's pure vanity for a startup to think they will become the next AWS by adopting hard service-based contracts between teams.

ddejohn 3y ago
This strikes me as overly cynical. My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that > cross team meetings and project management every time you want to ship a feature is somehow avoidable in tech?
- irjustin 3y ago
  > This strikes me as overly cynical. > My current job is working with around 20 other engineers on an extremely bloated and coupled monolith. I'd love to be able to separate myself and my team from others by an agreed-upon interface. > Yes, "agreed-upon" is certainly doing some heavy lifting there, but I don't think it's realistic to expect that This is overly cynical to you likely because you haven't experienced maintaining micro-services in the long term. Being able to "break away" with a common interface is literally the microservice tag line. It's completely true too. Standing up a service w/ an interface is incredibly fast, rewarding and watching it hum is beautiful. The problem starts when there's a bug that's upstream of your service. It's not too hard to get all 15+ services running on your laptop, but the problem is the other teams no longer let external members directly deploy the services they maintain (that one time someone from another team deployed a big bug). So now you've got to get PR approval and seemingly no one wants to review your bug. So you ask for time from the Product Owner and it gets forgotten because they're really busy too. So you go to an eng manager, etc etc... The above scenario plays out SO many times. I've been there in all various forms. As a blunt statement - any team under 30 members, monolith.

vvpan 3y ago

Whether it is a function, class, module, application or service I think there is one word for it - encapsulation.

apantel 3y ago
Yeah I would think that the solution to monolith vs microservices would be “neither should be followed because of dogma; encapsulate where it makes sense, when it makes sense”.

LASR 3y ago

The single-most important lesson I've learned building products as a founding engineer in a successfully exited startup: weighing tradeoffs and deciding which software architecture to use is the wrong place to dedicate mental energy. It's always the product. It comes first. Then the business. If you're lucky you may become a pawn in a larger battle among giants and you'll get acquired before you attempt to make any profit. If you end up in a place where your chosen architecture is no longer capable of supporting your scale - that's a happy place that very few teams get to experience. It means you've survived. Given that, whatever allows you to quickly get things in the hands of real customers (which depends quite heavily on what the actual product is) is the best architecture. We've hired some experienced engineers from giga-corp FAANG etc into tiny startups. The transition is hard, because there the opposite is true. You have a business already, and you have a well-defined goal you need to achieve with multi-year roadmaps etc. There, yeah you should probably decide on architecture first.

solatic 3y ago
Sad to see this isn't the top comment. Unless or until you have a built-in source of guaranteed demand - the only thing that matters is product agility in order to find customer demand. Without demand, you have no revenue, investors lose interest, the money runs out, and people stop paying you to work on that system. Then everything gets thrown out. And "demand" is not "we have paying customers" - it's having sufficient revenue, for whatever that means for that particular org.
baby 3y ago
I think we’ve been spoiled by move fast break things type of startups, and indeed if you’re in a competitive field you might have to fight for your survival. But truly successful projects are the ones that are worked on and improved for decades. Long-term work means that you will have to be conscious about being clean, and care about constant refactoring and simplification, and design decision that will prevent paralysis down the line. There’s a reason twitter did not change for like 10 years and apps like Instagram are able to adopt new trends super quickly. (Unrelated: since the Instagram team is behind Threads, I predict that Threads is going to evolve really really fast and be harsh competition to twitter over time)

hiddencost 3y ago

I've read a lot of these arguments. I dunno, I think software engineers have neglected soft skills for too long. "Philosophy X always leads to Y outcome." "Framework Z does Q." I bet a lot of software engineers are just bad with people. Coordinating a dozen teams takes work, but people do it all the time successfully. I don't think the frameworks are as important as figuring out an approach that works for the people involved.

steve_adams_86 3y ago
I'm pretty sure one of the things that keeps me employed in software is that I'm good at non-software stuff. So much so that I focus quite a bit less on the software now, and a lot more on the things software does, why, and for whom. That stuff seems a lot more important in the scheme of things; especially when money isn't free and people need software to be truly useful and very immediately. Maybe that's a typical progression in most software careers, but I wouldn't have believed I'd be here 10 years ago, or maybe even 5. I was always very technical (and I still love that side of things). Now I see the people side of things as far more important and interesting.

LarsDu88 3y ago

Lets step back a second. If the rationale behind adopting microservices for everything is PURE orgitecture rather than software architecture, then that's not really a rationale at all. Instead of having one instance, you now have dozens of little service fiefdoms plus all the added network I/O overhead associated with that. The principled approach is really to simply not do that, for the basic latency costs. I mean, did World of Warcraft, which is way more impressive than 99% of all the little django apps out there in corpo world run on a gajillion microservices? Fuck no

c048 3y ago
This is what you get when all you talk about it the positives, especially to new programmers or students. It's not about the why, but only if you do or do not. I'll die on this hill, but DDD can be put right up there with microservices as a solution to a certain type of problem being sold as THE solution.
- FLT8 3y ago
  I'm interested to hear more about your views on DDD - especially if you have examples where DDD has been actively harmful. Usually my advice for anyone thinking about building a new piece of software for a particular business goal is to a) run an event storming workshop with a group of domain experts to help get a really good idea of events, actors, commands, information flow and clusters of behaviour, and then b) run a second pass where you think the domain through in terms of transactional boundaries and DDD aggregates, and then c) do a third pass where you think specifically about security constraints and how they can be met. It's an expensive exercise in terms of time taken up front, but having completed it, hopefully the team have gained enough of an insightful understanding of the domain that they won't make silly hard-to-reverse mistakes like needing transactions that span service boundaries, or building demonstrably distinct domains which share similar concepts into uber objects spanning those domains, or having one service depend on information from multiple other services in order to apply required security constraints. Anyway, TLDR is I have found DDD and DDD-adjacent methods extremely helpful for thinking through designs and making app architecture decisions.
3y ago

jauntywundrkind 3y ago

I feel like we are going to spend many years coping with Team Topologies, a book which idolizes a seeming infinite and vast independence of teams from each other in the name of 'spending things up' or some such. I love, respect, & cherish the ideas here. But the sound-bite ideas of the book vastly overweigh the practical complexities of development. Yeah, giving each team authority to do their thing is desperately necessary today; there's too much organizational confusion & unclear decision making processes. Teams need autonomy. Yes. But the book really seems to have so little to say about how to play together. It doesn't talk hardly at all about how to find concordance & to make decisions across teams. What are good common techs to adopt? Microservices as I'm everyone can pick whatever (Haskell for this, pho for that, & 12 varieties of node) is one organizational end, monolith is another end. The confusion and angst Team Topologies let's dwell and build is infinite, because it's pretense is that there are many parallel streams of development and that inter-team work is a negative. The books is so good and so important. Because so many orgs are fucked and doing things terribly. Cognitive load is massively over managed and it's impossible to do anything to escape the tar pit the shitty ancient overly established pretentious shitbag elders have dictated. But the result of what Team Topologies says is such an opposite and shitty fucked, where cognitive loads expand exponentially because every team is independent & fucking off into their own space, with only vague constraining behavior or nebulous "platform" teams that "support" or maybe dictate to these platforms teams. Never have I seen a book I both respect so highly & think so terrible & awful.

hooby 3y ago

Reading the responses/comments in here, a question arises... Are things really that black and white as people here paint them - with monoliths unavoidably and necessarily becoming a tangled mess of spaghetti, and micro-services being the singular, only way to achieve clean separation, autonomy and partition? With microservices inevitably being an organizational nightmare that leads to problems in inter-team coordination, while monoliths automatically ensure that everyone always is perfectly the same page? Because by my personal experience, you totally can code a monolith in a strictly modular fashion, with clean interface-based API boundaries between the separate parts. And if you put those "modules" into separate packages, the dependencies between them end up being managed and documented as well. Just like you totally can setup microservices and surrounding procedures in a way that actually increases the feeling of product ownership in the teams, and reduces the hassle of inter-team coordination - especially in larger companies. Obviously there are ways to do monoliths right, and spectacularly wrong. And there are ways to do microservices right and wrong... I see so many arguments here, that do compare one method done wrong with the other method done right - and then imply that this is a strong reason for choosing that second method. I don't get it?

nullandvoid 3y ago
To borrow some monolith examples from Monolith to Microservices (https://www.goodreads.com/en/book/show/44144499 https://www.goodreads.com/en/book/show/44144499 - fantastic read) "Single Process" - Can be module based (Shopify), where multiple module's interact, but must be combined for deployment still, these module's can even extend to the DB's. Can still have multiple instances for performance "Distributed Monolith" - This is one to fear the most, we have multiple services, yet there is still shared DB's meaning we have to deploy things together. Both are monoliths but one is less susceptible to ball of mud. It's a sliding scale, with trade offs for each (and many variations still in between those listed). I think it's a lack of common terminology surrounding monolith / micro-service that creates this binary illusion.
chronid 3y ago
My 2c: you can get things right, but most of the time you won't, for many reasons - technical, logistical, cultural or merely political. Sometimes you don't control these reasons. So you are now left with managing risk. It's trade-offs all the way down.

zubairq 3y ago

I totally agree... the real question is how to reduce cognitive load. Try to get a system that can fit in your head, although I have totally failed to achieve this myself. But it is a goal!

baby 3y ago
Create self-contained frameworks and libraries by extracting code that starts becoming heavy and could be useful by its own. These are the useful abstractions. Constantly seek to specify, document, and simplify the protocols you implement. The clearer the ideas, the cleaner the implementation. Strive to use a single programming language. Organize your code like you would organize a city or a book.
- zubairq 3y ago
  Thanks, good tips!

konschubert 3y ago

It’s hard to enforce api contracts between components of a monolith. And when performance tanks, it’s hard to pin the root cause to a component. Both of these could probably be fixed by tooling. Could be z as fun research project or maybe a company.

karlmdavis 3y ago
You and I must work in very different contexts, as these questions are so obvious that they first seemed like satire to me. You enforce API contracts in a monolith (or any codebase, really) via an at-least-modest amount of typing and a compiler. You diagnose performance issues via any number of tools, prominently including metrics and profilers. My context for this is a lot of years working with backend languages like Java, Rust, etc. though the same assurances and tooling are available for most every platform I’m aware of.
- konschubert 3y ago
  Sure… and then the type of the return object if of API is ‘CustomerORMModel’… and now the api consumer can build n+1 query problems across components. You need a few more restrictions than that. But I agree it’s doable.
baby 3y ago
That’s why Meta has thrift and Google has grpc.

edandersen 3y ago

Lots of architects / tech leads read this instead as: "design the software to fit the maximum team cognitive load that you desire”. They actually over-complicate software builds in order to justify headcount later. "Oh whoops yes we now need a whole full time Ops team, don't worry I know just the guys".

pluto_modadic 3y ago
Kubernetes: because we have cloud engineers and they're not busy, right? it's not like they could be doing more important things if they weren't chasing fires.... wait why is my head count soaring...

qaq 3y ago

Mcroservices at the very least require very high investment into proper CI/CD and observability. If you are not willing to allocate resources to get those right things are going to go badly.

baby 3y ago

IMO: write everything in Rust. If a dependency is not in Rust, rewrite in Rust. Carmack has a rant about Meta’s stack for the Quest being in different languages and being a pain. Having worked in heavily-split stacks I don’t want to run into these again.

TylerE 3y ago
Never rewrite. Rewrites always fail.

will5421 3y ago

I’m sure that in every case, one or the other will be better for business for technical reasons.

Sankozi 3y ago
If only technical reasons would be important when choosing architecture then microservice architecture would not exists. Its killer feature is team independence and strict separation of responsibilities. Any technical advantages are dwarfed by technical problems it introduces.

hiAndrewQuinn 3y ago

I maintain that the only way to truly fight cognitive load is to outsource more of your design to long-term memory. That is as close to a silver bullet as you will ever get, and it explains way more of the tech landscape than you want to admit. In the ideal case, there exists a literal piece of mathematics you translate into code and work with from there. The upfront cost is extreme - but, once the math is internalized, the resulting product is sleek and elegant and can be understood rapidly at a bird's eye view by other people who also understand the underlying mathematics. Weaken this ideal case however appropriate to your business case, but no more than you have to!

lakomen 3y ago

Microservices = Cloud sales Cloud has money to pay for bullshit articles hyping Microservices. Ergo newbies believe the hype and hype Microservices. It's all stupid and HN with Reddit is the epicenter of stupid

antman 3y ago

Can anyone suggest a blog/book on how you manage cross communication across teams regarding evolving software interfaces? Change management foe Domain Driven Development? The way to minimise cognitive load is to have established amd clearly documented processes usually

dunfear 3y ago

Most system can have a single server today and it will basically always be more simple than N smaller ones. Everything is just faster if you just skip the TCP layer. Less configuration, less attack surfaces, less possible problems and issues. The CI/CD and backup is a lot easier as well. It is as another author wrote: It is a people problem. We programmers like the "do one thing" mantra so we tend to want to add it everywhere - even in places were the cost may outweigh the benefits.