51–60 of 78 posts
I don't think it has. We just have a fashion trend where people love to brag about managing 100 micro-services using Kubernetes. But there's still companies out there where the entire back-end is a single binary on a single beefy server, potentially with a hot spare server running alongside it.
Would you happen to know where I can find such companies?
Earlier quoted context omitted.
The frontend answer to complexity had to do with young/new devs fomo’ing into resume driven development and augmenting their growing identity/ego as a developer. But this Java shit, that has to all come from enterprise solutions right? I can’t imagine there were tons of influencer-like blog posts that JavaScript had. What hell hole did those Java ideas even come from? Blah. One way or another, people manage to fuck e…
15-25 years ago, there were hip-for-the-time tech influencer bloggers who would write all sorts of stuff about whatever new frameworks and tech were available in the Java world. If you take all the scary Java Enterprise buzzwords in one of the previous posts on this thread, and look them up, you'll find that they all came about, roughly, between 1999 and 2007. I don't fully remember what all the hip influencer tech b…
When are we ever going to get hip to that reality?
To respond to OP's edit: frontend catches more shit because it's largely gotten worse at the same time as getting more complex. This isn't (only) outsiders looking in leveling that criticism—it's people who worked on GUI software in the 90s looking at the state of things and wondering why it's both constantly changing and, in many ways, worse than it was back then. Slower, worse tools producing slower, worse software…
Earlier quoted context omitted.
I did Java EE, Glassfish, JSF/IceFaces for my first job and at the same time I could have ftp'd a PHP/Perl script on a free host and called it a day (had I known better). I think Devops has a played a huge role in why things have gotten more complicated. They want Kubernetes to be the solution to all problems. Heroku has fallen out of fashion for literally no reason. They won't even consider ElasticBeanstalk or App r…
You're oversimplifying the problem and/or not viewing the problem for the organization. Maybe for an individual developer it's easier to create a Dyno or a Beanstalk deployment, but it's not necessarily easier for the organization . IMO, Kubernetes solves a lot of issues for both camps but most of the Kubernetes detractors I've met are only hostile to it because of ignorance, not any reasonable criticisms. "It's diff…
This isn't the future I wanted, let's solve these problems in some other way. K8s seems to be the second-system effect in all the worst ways.
To respond to OP's edit: frontend catches more shit because it's largely gotten worse at the same time as getting more complex. This isn't (only) outsiders looking in leveling that criticism—it's people who worked on GUI software in the 90s looking at the state of things and wondering why it's both constantly changing and, in many ways, worse than it was back then. Slower, worse tools producing slower, worse software…
> frontend catches more shit because it's largely gotten worse at the same time as getting more complex. The "microservices by fad" based architecture usually comes with a huge decrease in performance and an even large one in reliability. The NoSQL for no reason fad came with horrible performance and some very bad data losses. Every once in a while we get some data leakage story here, certainly many are due to comple…
Good point, that one was a big mess.
> The NoSQL for no reason fad came with horrible performance and some very bad data losses.
100% agreed. My perception at the time, though, was that it was largely driven by frontend folks who'd come to the backend via NodeJS buying (especially) MongoDB's marketing hype. There was a real "finally, all those barriers the backend folks had for no reason whatsoever are gone and this is easy now—better, even, you dinosaur, have you seen the marketing, it makes it so clear that this is the future—so I can be full-stack without having to learn much!" vibe to the whole thing. But maybe that's just what I happened to see and that wasn't really the main cause of that going as far as it did.
Earlier quoted context omitted.
You're oversimplifying the problem and/or not viewing the problem for the organization. Maybe for an individual developer it's easier to create a Dyno or a Beanstalk deployment, but it's not necessarily easier for the organization . IMO, Kubernetes solves a lot of issues for both camps but most of the Kubernetes detractors I've met are only hostile to it because of ignorance, not any reasonable criticisms. "It's diff…
Easier to deploy for the developers is better for the organization. The dev team should own this process since they are the ones that probably have to support it. Objectively, deploying on any of the more managed AWS services, App Runner, ECR, Beanstalk is better for the org. Less risk if someone is leaving, vs the 3 terabytes of Kubernetes scripts required. The team knows how to manage and deploy their stuff so when…
So for every story I hear about "it was better back then", I just remember how much it was a horror for us and find it really hard to believe people voicing these options are actually arguing in good faith.
Earlier quoted context omitted.
You're oversimplifying the problem and/or not viewing the problem for the organization. Maybe for an individual developer it's easier to create a Dyno or a Beanstalk deployment, but it's not necessarily easier for the organization . IMO, Kubernetes solves a lot of issues for both camps but most of the Kubernetes detractors I've met are only hostile to it because of ignorance, not any reasonable criticisms. "It's diff…
Personal rant: the solution to fixing a broken k8s installation made by a previous team in an attempt at some sort "enterprisey" lock-in is, apparently, wiping the clusters and creating a new k8s from scratch. This isn't the future I wanted, let's solve these problems in some other way. K8s seems to be the second-system effect in all the worst ways.
The two biggest wrenches that get thrown into a backend system and blow up complexity in my experience: - 100x in growth, aka scaling. - Needing to set up reporting data pipelines. Metrics, auditing, 3rd party uses. Does the frontend need to worry about either of these? Maybe for scaling, they need to do some CDN work, or is that still the backend developer's job?
Earlier quoted context omitted.
Easier to deploy for the developers is better for the organization. The dev team should own this process since they are the ones that probably have to support it. Objectively, deploying on any of the more managed AWS services, App Runner, ECR, Beanstalk is better for the org. Less risk if someone is leaving, vs the 3 terabytes of Kubernetes scripts required. The team knows how to manage and deploy their stuff so when…
Anecdotally, I was part of an organization that was all in on Beanstalk (hundreds of apps) that did a full migration to Kubernetes and we ended up reducing our spend, deploy times and pipeline complexity by half. We're talking a total yearly cloud spend probably near 9 digits. Moving to Kubernetes vastly simplified our lives and developers were able to learn it pretty easily. Development team was in the low hundreds.…
My experience is: devops is introduced to 2 orgs I was at (much smaller dev teams) to save money. Even though hiring devops negates any savings, but that's another story. They introduce Kubernetes (even though existing solutions were fine) as the flavor of the month to build up their resumes. They all leave after 6 months to a year and dev teams are stuck with the cleanup trying support and be in call for things we had no say in. It's harder to see logs, get a rails console, deploy, debug, etc.
Meanwhile they also spent 6 months trying to get PR apps and staging environments at one company. Something that is one click on Heroku.
If we didn't have Heroku at these companies when we started out we would have literally failed. End of story.
The two biggest wrenches that get thrown into a backend system and blow up complexity in my experience: - 100x in growth, aka scaling. - Needing to set up reporting data pipelines. Metrics, auditing, 3rd party uses. Does the frontend need to worry about either of these? Maybe for scaling, they need to do some CDN work, or is that still the backend developer's job?
Scaling is over-rated and over-sold to most businesses who generally have predictable, stable or no growth over their lifetimes and then see their new system running at 1% capacity for its lifetime.