I read this article around when it originally was posted and while I'm not a fan of DHH in general, I do generally agree with his take on the ever-ballooning-complexity we see in this industry...
I read this article around when it originally was posted and while I'm not a fan of DHH in general, I do generally agree with his take on the ever-ballooning-complexity we see in this industry with each passing year.
But I don't know what the solution is. What I find is that when you propose not using something like K8S, or "the cloud", microservices, etc etc, you get a lot of push back from most other devs. Even if what you're building doesn't really warrant this complexity. Like, when you know that you're only targeting internal users now and into the future, and the number of users is predictable, and so the load is also predictable. But you inevitably get other devs talking about scaling and endless other "what if" scenarios. And it's just this crazy battle to get devs to consider other simpler solutions that were commonplace just 10 years ago. But we gotta instead use whatever FAD is "in" today because devs on the team want it (who will undoubtedly leave in the next 1-2 years and so will never have to maintain what they build).
I'm actually not even against Docker or containerization in general, but I disagree oh-so-strongly that everything needs to be architected as some microservices spiderweb of complexity (which often times just devolves into a "distributed monolith" anyway) and that we need to deploy into AWS or Azure. I guess if you don't have servers on-premises already maybe there's some important considerations there, but the places I'm thinking of as I'm writing this post are places that already had existing physical data centers (which were not going away any time soon).
My perhaps overly cynical take on this is that I think many devs today are, consciously or not, practicing a form of "resume-driven-development." So-and-so tech firm is using XYZ stack, so I better too, so when the next project starts, or maybe even during this one, I'll push for us to use XYZ as well. And the justification? Well, FAANG is doing it, so we should do. Ugh. Just ugh.
I think this is very much part of the problem. I've joined some internal projects that had 24 "microservices" (distributed monolith) with advanced kubernetes configs (with way too much dev time...
I think many devs today are, consciously or not, practicing a form of "resume-driven-development."
I think this is very much part of the problem. I've joined some internal projects that had 24 "microservices" (distributed monolith) with advanced kubernetes configs (with way too much dev time spent maintaining it) for maybe a few hundred infrequent internal users.
It's ridiculous. Keep it simple until you need complexity I say. I actually think that dockerising projects is part of making things simpler. A simple "docker-compose up" and you have a lovely little dev environment that's consistent on everyone's machine. If it builds on your machine it'll build when it's deployed. It's super simple and cheap to deploy the images to AWS app runner or GCP cloud run.
The projects I've been involved in have now all been monoliths with a pg database and a frontend. Easy. If over time we see a real need for complexity then we can split things out and manage it nicely using the lessons learned so far.
It might not be as standout on the CV, but building things which are performant, satisfy user needs, and are delivered ahead of schedule and under budget can only be good for the CV.
It's a sad state of affairs where building something simple, performant, and maintainable that satisfies the business's needs on schedule and under budget does not stand out on a CV. ;-) And the...
It's a sad state of affairs where building something simple, performant, and maintainable that satisfies the business's needs on schedule and under budget does not stand out on a CV. ;-) And the sad part is that I know you're 100% correct.
I totally agree with you re: docker-compose by the way. I really think that's kind of the sweet spot that has emerged out of the past 8-10-ish years of infrastructure and deployment tools. Sometimes you don't need it, but when you do it (can be) damned simple to get going and provide a consistent environment with.
I'm not in dev, but in my IT workplace I see the same sort of behavior, but I think it's more motivated by hyper-nerddom than anything else. People who really think xyz thing would be cool, and...
I'm not in dev, but in my IT workplace I see the same sort of behavior, but I think it's more motivated by hyper-nerddom than anything else. People who really think xyz thing would be cool, and are so focused on how cool and fun it would be to build that it's hard to talk them down and get them to think about the business case. Like okay, that'd be neat, but how valuable is spending 40 hours building it? Does automating that really save any time? Would that idea actually work in the context of our actual environment, or would this be better suited for a home lab?
I think at least in my case part of the issue is that a lot of these people are on the younger side, and haven't had many, if any professional jobs before. They're coming out of school and are in their first environment where you can't just mess around with whatever you want, and getting people to learn that for the first time is not easy.
Though don't get me started on "well FAANG is doing it". That comes from our executives, and it makes me want to beat my face into my cubicle lol.
I think this is a really good point. And it's a almost a shame to me, because such a person is obviously really enthusiastic about something. On different teams I've been on over the years,...
but I think it's more motivated by hyper-nerddom than anything else
I think this is a really good point. And it's a almost a shame to me, because such a person is obviously really enthusiastic about something. On different teams I've been on over the years, sometimes I feel like building up that enthusiasm in some co-workers is half the battle! But yeah, it's just people going way too far down the rabbit hole in these cases we're talking about here. I agree with you too about it seeming to be mostly younger folks getting caught in these types of traps. I definitely notice this too.
It really is insane how much time some people will spend working on building automation. I've also been on teams where I've seen people throw way too much time into something that just isn't needed. A company I was at several years ago, one developer on one of the other teams spent way too much time building up a complex set of tools to dynamically build Kubernetes YAML files from a custom DSL he built specifically for this tool. When you looked at the Kubernetes scripts they ended up deploying ... it was just super simple Deployment, Service and ConfigMap resources. Nothing complex. Not even a lot of them, only 2-3 as I recall. Just totally over-engineered for the task at hand. Appropriately, the tool he built for this was called "albatross." Heh.
Seems like the alternative is to be a minimalist. Currently I use Netlify for static websites. I used an edge function once and it was okay. Deno Deploy could do the same thing if you want to...
Seems like the alternative is to be a minimalist. Currently I use Netlify for static websites. I used an edge function once and it was okay. Deno Deploy could do the same thing if you want to stick to TypeScript.
It lacks a database. If I needed one, I suppose I could get a PostgreSQL instance somewhere, but I don't know what the minimalist way to do it would be.
SQlite and an as thin as possible server wrapper to make it talk JSON? I mean I adore Postgres and what it can do for you, but the number of times I actually needed it so far was... not big. Or,...
SQlite and an as thin as possible server wrapper to make it talk JSON? I mean I adore Postgres and what it can do for you, but the number of times I actually needed it so far was... not big. Or, stated another way, I found that the window between "too big for SQlite" and "small enough for a Postgres instance without a dedicated DBA monitoring and optimizing it" was surprisingly small.
I also suspect that if I'd ever found the time and motivation to really look into object databases (and other NSQL), I could probably have saved myself a lot of work pressing data that wants to be objects or a tree into tables. Or maybe that's the dark side of buzz and complexity whispering in my ear?
One thing I found remarkable about the building blocks of those death stars is that you hear a buzzword a few times and get curious (and FOMO-scared) and look it up, and you land on a very shiny...
One thing I found remarkable about the building blocks of those death stars is that you hear a buzzword a few times and get curious (and FOMO-scared) and look it up, and you land on a very shiny marketing web page that has a lot to say about technology, and who is using technology, and how much money you can save using technology, but after you read blurb after blurb you keep wondering "Yes, fine, but what does it actually dooo". And you either enter a rabbit hole of circular definitions full of unfamiliar jargon, or you just give up and hope that it was snake oil anyway. (But it keeps nagging you).
I'm very glad to have read this and that it wasn't just me.
I read this article around when it originally was posted and while I'm not a fan of DHH in general, I do generally agree with his take on the ever-ballooning-complexity we see in this industry with each passing year.
But I don't know what the solution is. What I find is that when you propose not using something like K8S, or "the cloud", microservices, etc etc, you get a lot of push back from most other devs. Even if what you're building doesn't really warrant this complexity. Like, when you know that you're only targeting internal users now and into the future, and the number of users is predictable, and so the load is also predictable. But you inevitably get other devs talking about scaling and endless other "what if" scenarios. And it's just this crazy battle to get devs to consider other simpler solutions that were commonplace just 10 years ago. But we gotta instead use whatever FAD is "in" today because devs on the team want it (who will undoubtedly leave in the next 1-2 years and so will never have to maintain what they build).
I'm actually not even against Docker or containerization in general, but I disagree oh-so-strongly that everything needs to be architected as some microservices spiderweb of complexity (which often times just devolves into a "distributed monolith" anyway) and that we need to deploy into AWS or Azure. I guess if you don't have servers on-premises already maybe there's some important considerations there, but the places I'm thinking of as I'm writing this post are places that already had existing physical data centers (which were not going away any time soon).
My perhaps overly cynical take on this is that I think many devs today are, consciously or not, practicing a form of "resume-driven-development." So-and-so tech firm is using XYZ stack, so I better too, so when the next project starts, or maybe even during this one, I'll push for us to use XYZ as well. And the justification? Well, FAANG is doing it, so we should do. Ugh. Just ugh.
Thanks for reading my mini rant. lol.
I think this is very much part of the problem. I've joined some internal projects that had 24 "microservices" (distributed monolith) with advanced kubernetes configs (with way too much dev time spent maintaining it) for maybe a few hundred infrequent internal users.
It's ridiculous. Keep it simple until you need complexity I say. I actually think that dockerising projects is part of making things simpler. A simple "docker-compose up" and you have a lovely little dev environment that's consistent on everyone's machine. If it builds on your machine it'll build when it's deployed. It's super simple and cheap to deploy the images to AWS app runner or GCP cloud run.
The projects I've been involved in have now all been monoliths with a pg database and a frontend. Easy. If over time we see a real need for complexity then we can split things out and manage it nicely using the lessons learned so far.
It might not be as standout on the CV, but building things which are performant, satisfy user needs, and are delivered ahead of schedule and under budget can only be good for the CV.
It's a sad state of affairs where building something simple, performant, and maintainable that satisfies the business's needs on schedule and under budget does not stand out on a CV. ;-) And the sad part is that I know you're 100% correct.
I totally agree with you re: docker-compose by the way. I really think that's kind of the sweet spot that has emerged out of the past 8-10-ish years of infrastructure and deployment tools. Sometimes you don't need it, but when you do it (can be) damned simple to get going and provide a consistent environment with.
I'm not in dev, but in my IT workplace I see the same sort of behavior, but I think it's more motivated by hyper-nerddom than anything else. People who really think xyz thing would be cool, and are so focused on how cool and fun it would be to build that it's hard to talk them down and get them to think about the business case. Like okay, that'd be neat, but how valuable is spending 40 hours building it? Does automating that really save any time? Would that idea actually work in the context of our actual environment, or would this be better suited for a home lab?
I think at least in my case part of the issue is that a lot of these people are on the younger side, and haven't had many, if any professional jobs before. They're coming out of school and are in their first environment where you can't just mess around with whatever you want, and getting people to learn that for the first time is not easy.
Though don't get me started on "well FAANG is doing it". That comes from our executives, and it makes me want to beat my face into my cubicle lol.
I think this is a really good point. And it's a almost a shame to me, because such a person is obviously really enthusiastic about something. On different teams I've been on over the years, sometimes I feel like building up that enthusiasm in some co-workers is half the battle! But yeah, it's just people going way too far down the rabbit hole in these cases we're talking about here. I agree with you too about it seeming to be mostly younger folks getting caught in these types of traps. I definitely notice this too.
It really is insane how much time some people will spend working on building automation. I've also been on teams where I've seen people throw way too much time into something that just isn't needed. A company I was at several years ago, one developer on one of the other teams spent way too much time building up a complex set of tools to dynamically build Kubernetes YAML files from a custom DSL he built specifically for this tool. When you looked at the Kubernetes scripts they ended up deploying ... it was just super simple
Deployment,ServiceandConfigMapresources. Nothing complex. Not even a lot of them, only 2-3 as I recall. Just totally over-engineered for the task at hand. Appropriately, the tool he built for this was called "albatross." Heh.Seems like the alternative is to be a minimalist. Currently I use Netlify for static websites. I used an edge function once and it was okay. Deno Deploy could do the same thing if you want to stick to TypeScript.
It lacks a database. If I needed one, I suppose I could get a PostgreSQL instance somewhere, but I don't know what the minimalist way to do it would be.
SQlite and an as thin as possible server wrapper to make it talk JSON? I mean I adore Postgres and what it can do for you, but the number of times I actually needed it so far was... not big. Or, stated another way, I found that the window between "too big for SQlite" and "small enough for a Postgres instance without a dedicated DBA monitoring and optimizing it" was surprisingly small.
I also suspect that if I'd ever found the time and motivation to really look into object databases (and other NSQL), I could probably have saved myself a lot of work pressing data that wants to be objects or a tree into tables. Or maybe that's the dark side of buzz and complexity whispering in my ear?
One thing I found remarkable about the building blocks of those death stars is that you hear a buzzword a few times and get curious (and FOMO-scared) and look it up, and you land on a very shiny marketing web page that has a lot to say about technology, and who is using technology, and how much money you can save using technology, but after you read blurb after blurb you keep wondering "Yes, fine, but what does it actually dooo". And you either enter a rabbit hole of circular definitions full of unfamiliar jargon, or you just give up and hope that it was snake oil anyway. (But it keeps nagging you).
I'm very glad to have read this and that it wasn't just me.