Earlier quoted context omitted.
With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. And worse still you can't even see a lot of the complexity easily as it's hidden in how the distributed system is configured. A normal system design, derisively called a monolith by some, is much clearer and explicit. It's less code. It'…
> With a lot of systems, the business system design is complex enough in the first place that if you add a distributed system design to it as well you just end up with a colossal mess. The goals of system design are a) a system actually works, b) the system is not a colossal mess. In a similar manner, the challenge of any engineering field is to not allow things to become overly complex. > A normal system design, der…
What we talk about when we talk about system design
11–20 of 37 posts
Re: What we talk about when we talk about system design
#12Except that as a developer when I hear "solution Y is just X with one change", I know that this is BS and that there won't be just that change which will be annoying because I'll have to refactor later..
Re: What we talk about when we talk about system design
#13To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going system design process - especially when it comes to the software part, and they’re often not very good at the non-software part either.
I find myself a little bit stuck doing hands-on software engineering for companies who’ve gotten themselves into a system design hole. Companies are willing to throw tremendous resources at paying for system design mistakes, but not at avoiding them, or correcting them.
I don’t really know how to profitably find my way upward, except for becoming a manager or a consultant.
Re: What we talk about when we talk about system design
#14Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…
This is a huge claim. If true, then the way to profitably find your way upward is similar to what the linked article itself is doing:
Write about it, in a credible way, build your reputation as a person that can drive change leading to results, and then become a consultant.
Re: What we talk about when we talk about system design
#15Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…
> To me, it’s clear that designing systems is the way to maximum ongoing profit This is a huge claim. If true, then the way to profitably find your way upward is similar to what the linked article itself is doing: Write about it, in a credible way, build your reputation as a person that can drive change leading to results, and then become a consultant.
Re: What we talk about when we talk about system design
#16Re: What we talk about when we talk about system design
#17I'm relatively new in this and recently I've been reading and hearing a lot about how distributed systems are overused and usually a monolith can do a better job etc. I'm working at a company serving millions of customers and distributed systems are utilized, most of my experience as a software engineer was built around this to the point that I was never around a codebase that is 10/20k+ lines of code. I feel like I…
https://google.github.io/building-secure-and-reliable-system...
> hearing a lot about how distributed systems are overused and usually a monolith can do a better job etc
> improve my understanding of monolith vs microservices, when to use each, and the tradeoff of preferring one over the other
A lot of this will depend on where you're working. Where I'm at, the preference is for single tasks up to somewhere in the neighborhood of 200 gigs of RAM and commensurate CPU. Our individual servers have just stupid amounts of RAM and CPU on them, and our deployment stack has..... nontrivial amounts of overhead for.... reasons.
But if you're e.g. deploying on AWS, the price optimization point is gonna be different. And if you're deploying while working at Amazon it'll be yet a different tradeoff (cynically, having more to do with pager duty boundaries)
Re: What we talk about when we talk about system design
#18Over the years I’ve found myself more and more interested in designing systems than paying for existing system design mistakes - I want to help people learn to avoid them. (Coming at this from software engineer). To me, it’s clear that designing systems is the way to maximum ongoing profit. Yet no-one I’ve come across in the world of business (still clinging on to hope) seems interested in an intentional, on-going sy…
Re: What we talk about when we talk about system design
#19Any good resources on how to properly define the design space? What makes it a space more than a list of requirements?