5 ms·

Oh you sweet child, you haven't seen complexity until you have deployed J2EE services generated using WSDL, running in an OSGi container, interfaced with EJBs p

Oh you sweet child, you haven't seen complexity until you have deployed J2EE services generated using WSDL, running in an OSGi container, interfaced with EJBs packaged using Ant and deployed into GlassFish, integrated with IIS running on a Windows Server. Try finding a starter kit for that.

croo 4y ago
Right? We already over the explosion. Backend development is not complex, it's mature. With spring boot + initializer + bean based configuration, REST interfaces everywhere, maven and gradle are both great what's not to like?
- isbvhodnvemrwvn 4y ago
  Can you tell me exactly what kind of beans you have in your simple spring boot app, and how request processing works step by step?
dham 4y ago
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 runner for even the smallest of projects. Companies would rather hire a 200k plus benefits person instead of paying a few hundred dollars more a month on hosted solutions. I've honestly never seen anything like it.
- halfmatthalfcat 4y ago
  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 different, it's hard or it's something I don't know" aren't valid excuses.
  - dham 4y ago
    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 they're on call they know how to fix it. Why would someone learn Kubernetes when you can spend 5 minutes learning Beanstalk or App Runner? Things were never a problem when devs just managed this stuff. We used Heroku or Capistrano on plain EC2 and it was fine. Once you hit scale and things become more expensive then Docker on ECR / Fargate is fine. This whole dev ops fad just has to go.
    - halfmatthalfcat 4y ago
      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. 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.
      - dham 4y ago
        If that's your experience with it, then it sounds like a success and I'll concede that. 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.
jesuscript 4y ago
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 everything up. We just can’t have nice things.
- yamtaddle 4y ago
  I think some of this is because it's way harder to write a new library for a well-established language & ecosystem and become well-known for it, than it is to do the same in a new ecosystem. This goes for languages and frameworks both—React, for example, generated tons of opportunities like this, to become known for something by basically solving a problem that'd already been solved 1,000 times—but with React. Like, if you want to build your résumé and get offered some of the cushier programming-adjacent gigs and get to present at prominent conferences and generally become A Name, how likely is that to happen if you try to launch some big web framework, or an auth library, or an ORM—in Ruby? Or Java? Nah, too crowded. But if you pick some up-and-coming language (that's up and coming in part because everyone involved is doing exactly what you're trying to do) or hook your wagon to some new framework's (or database's, et c.) hype cycle, well, now you're talking. As a bonus, many of these projects require little or no novelty—it's all well-trod territory. Just half-competently do what hundreds of others have already done, succeed at promoting it (tellingly, this is the harder part) and you're a rockstar. And hell, maybe doing all that does demonstrate some kind of remarkable and valuable skill, for all I know! But the point is, if that's the kind of thing you're trying to do, you need churn, and a bunch of people all trying to accomplish the above drives that very churn. Very little of that activity actually advances the industry, and the churn itself is a huge drag on everything.
- r_transpose_p 4y ago
  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 blogs were during that era (I recall "Joel on Software" having been important), but I do remember that people who paid more attention to such things were really into "Enterprise Java Beans" at the time. So the JVM world might suffer from a bit of an analogous problem. But that world's complexity explosion was decades ago. My feeling is that backend has always been complex, depending on the scale you were trying to operate at (and how much scale your framework and ecosystem forced you to think about whether you wanted to or not). The best you can do to mitigate it is continually ask "Do I really need my backend to handle the scale I'm designing it for?" and "Is all of the complexity in my preferred stack still necessary, or can some of it be hidden/automated?"
smsm42 4y ago
No mention of CORBA? I think it is on the top of my personal "what the heck is going on there and why on Earth anybody would want it to happen to them?" list.
- stickfigure 4y ago
  I used CORBA once about 20 years ago to talk between a C++ server and a Java EJB server. It was pretty ok? It beat hand wiring TCP protocols. I'm not sure hand-wiring REST calls is much better. At least we have gRPC now.
  - nivertech 4y ago
    My first real paid job was using CORBA to communicate from the Java applet running in the browser to the Java proxy running on the web server and then to an app server. Later I also worked with RMI, DCOM, etc. I also used both DCOM and CORBA at later jobs for Soft-Realtime/Embedded distributed systems. I’d say statically typed IDLs are much better than all these REST/HTTP/JSON/CRUD approach. That’s why I prefer GraphQL and gRPC/ProtoBuffers. Not the least important thing is that having a statically-typed and well documented schema reduce the amount of required communication between the developers, and also reduces the number of misunderstandings, mistakes, and bugs.
renaissance_tea 4y ago
I’m 27 and my first job was OSGI at a Java shop. That was some convoluted shit. Class path errors, coupled to blueprint XML and fancy IDE stuff. I’ve worked in different languages and frameworks since and love the simplicity of Go. Excited to learn Rust
marcosdumay 4y ago
Hum... I've done this, and no, the "multiple interdependent microservices" over kubernetes architecture is much worse.

croo 4y ago

Right? We already over the explosion. Backend development is not complex, it's mature. With spring boot + initializer + bean based configuration, REST interfaces everywhere, maven and gradle are both great what's not to like?

isbvhodnvemrwvn 4y ago
Can you tell me exactly what kind of beans you have in your simple spring boot app, and how request processing works step by step?

dham 4y ago

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 runner for even the smallest of projects. Companies would rather hire a 200k plus benefits person instead of paying a few hundred dollars more a month on hosted solutions. I've honestly never seen anything like it.

halfmatthalfcat 4y ago
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 different, it's hard or it's something I don't know" aren't valid excuses.
- dham 4y ago
  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 they're on call they know how to fix it. Why would someone learn Kubernetes when you can spend 5 minutes learning Beanstalk or App Runner? Things were never a problem when devs just managed this stuff. We used Heroku or Capistrano on plain EC2 and it was fine. Once you hit scale and things become more expensive then Docker on ECR / Fargate is fine. This whole dev ops fad just has to go.
  - halfmatthalfcat 4y ago
    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. 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.
    - dham 4y ago
      If that's your experience with it, then it sounds like a success and I'll concede that. 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.

jesuscript 4y ago

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 everything up. We just can’t have nice things.

yamtaddle 4y ago
I think some of this is because it's way harder to write a new library for a well-established language & ecosystem and become well-known for it, than it is to do the same in a new ecosystem. This goes for languages and frameworks both—React, for example, generated tons of opportunities like this, to become known for something by basically solving a problem that'd already been solved 1,000 times—but with React. Like, if you want to build your résumé and get offered some of the cushier programming-adjacent gigs and get to present at prominent conferences and generally become A Name, how likely is that to happen if you try to launch some big web framework, or an auth library, or an ORM—in Ruby? Or Java? Nah, too crowded. But if you pick some up-and-coming language (that's up and coming in part because everyone involved is doing exactly what you're trying to do) or hook your wagon to some new framework's (or database's, et c.) hype cycle, well, now you're talking. As a bonus, many of these projects require little or no novelty—it's all well-trod territory. Just half-competently do what hundreds of others have already done, succeed at promoting it (tellingly, this is the harder part) and you're a rockstar. And hell, maybe doing all that does demonstrate some kind of remarkable and valuable skill, for all I know! But the point is, if that's the kind of thing you're trying to do, you need churn, and a bunch of people all trying to accomplish the above drives that very churn. Very little of that activity actually advances the industry, and the churn itself is a huge drag on everything.
r_transpose_p 4y ago
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 blogs were during that era (I recall "Joel on Software" having been important), but I do remember that people who paid more attention to such things were really into "Enterprise Java Beans" at the time. So the JVM world might suffer from a bit of an analogous problem. But that world's complexity explosion was decades ago. My feeling is that backend has always been complex, depending on the scale you were trying to operate at (and how much scale your framework and ecosystem forced you to think about whether you wanted to or not). The best you can do to mitigate it is continually ask "Do I really need my backend to handle the scale I'm designing it for?" and "Is all of the complexity in my preferred stack still necessary, or can some of it be hidden/automated?"

smsm42 4y ago

No mention of CORBA? I think it is on the top of my personal "what the heck is going on there and why on Earth anybody would want it to happen to them?" list.

stickfigure 4y ago
I used CORBA once about 20 years ago to talk between a C++ server and a Java EJB server. It was pretty ok? It beat hand wiring TCP protocols. I'm not sure hand-wiring REST calls is much better. At least we have gRPC now.
- nivertech 4y ago
  My first real paid job was using CORBA to communicate from the Java applet running in the browser to the Java proxy running on the web server and then to an app server. Later I also worked with RMI, DCOM, etc. I also used both DCOM and CORBA at later jobs for Soft-Realtime/Embedded distributed systems. I’d say statically typed IDLs are much better than all these REST/HTTP/JSON/CRUD approach. That’s why I prefer GraphQL and gRPC/ProtoBuffers. Not the least important thing is that having a statically-typed and well documented schema reduce the amount of required communication between the developers, and also reduces the number of misunderstandings, mistakes, and bugs.

renaissance_tea 4y ago

I’m 27 and my first job was OSGI at a Java shop. That was some convoluted shit. Class path errors, coupled to blueprint XML and fancy IDE stuff. I’ve worked in different languages and frameworks since and love the simplicity of Go. Excited to learn Rust

marcosdumay 4y ago

Hum... I've done this, and no, the "multiple interdependent microservices" over kubernetes architecture is much worse.