Because everyone is prentending that they need to be infinetly scalable like the FAANGs, exacerbated by Cloud providers marketing spiel. In reality nobody knows how to build distributed systems but everybody needs to build them as resume fodder, because they might one day apply for a job at a FAANG... sigh...I sometimes pine back to the days where I saturated the NICs of two quadcore servers with C++ std::unordered_map and FastCGI. Especially the days when I ask what problems the service mesh solves which isn't solvable with internal DNS and loadbalancers in our use case.
Ask HN: Why did back-end development explode in complexity?
61–70 of 78 posts
Re: Ask HN: Why did back-end development explode in complexity?
#62Earlier 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…
My main complaint about Kubernetes is that it's basically a https://en.wikipedia.org/wiki/Galactic_algorithm - unless you're FAANG-scale, the extra overhead and complexity it imposes to use it at all massively outweigh its benefits. And it's usually not that it's different things that you have to understand, but rather that it's more things, to accomplish the same final goal. E.g., to set up networking without Kubernetes, you need to understand traditional networking architecture, but to set up networking with Kubernetes, you need to understand traditional networking Architecture and the Kubernetes way of doing networking.
Re: Ask HN: Why did back-end development explode in complexity?
#63Earlier quoted context omitted.
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…
Heh. So propaganda (or marketing as we now know it) has always worked. When are we ever going to get hip to that reality?
I try to remember that this decades cool hip software trends might become the next decade's enterprise Java.
And that's the outcome for the successful stuff!
(Doesn't mean you shouldn't get into it though -- if I'd jumped on enterprise java 20 years ago, I'd probably be richer than I ended up by just working on the software I was interested in)
Re: Ask HN: Why did back-end development explode in complexity?
#64Oh 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.
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…
The response I dont see represented is that we were more ambitious in the past. There were all kinds of negative effects, bad tools & out-of-touch architecting that was begot; we can acknowledge that, certainly. But that almost all representation of Java here so emphatically emphasize only the negatively bias, without recongizing also some of the idealism, hope, & progress is to our loss.
We were also trying really cool things with many of these java efforts. Rather than a main() routine that imperatively did everything, there were future-sightes notions that we could have a bunch of ambient systems available & interconnected. OSGI solved some thorny library versioning problems, and as a bonus allowed for a very strongly manageable runtime for modules. EJB brought objects up to a higher level, a greater management tier with more interoperability of objects across instances. We were interested in trying more, in tackling harder problems, that microservice era has masked over, deliberately chosen to ignore.
Over time we got more refined forms of many of these systems. Maven calmed much of the ad-hoc madness of Ant. CDI was a more reasonable EJB with event more competent management. JSP kept getting better component libs. OSGi actually was... decent all along, sometimes legit useful.
But the idea that Java was absurdly troubled seems to endure & be enormously popular hatred/FUD to spread. The fads of today are exactly the opposite of the better managed more flexible runtime trend, where the JVM keeps rising as a more capable, flexible, malleable, adaptable, controllable way to tackle processes than the processes at an OS level. And certainly, there's a lot of ease we've bought ourselves by doing much much less. Statically compiled binaries are an example of yet another means of doing less, of finding easy routes; powerful simplifications that have greatly eased many folk's lives.
Less is great, sure. Isolated container instances with dedicated apps is pretty easy to deal with. But there are still constant undercurrents, pushing us towards more interesting complected runtime arraingements, where virtual machines (not fully virtualized os'es but systems like glassfish or erlang, where many sub-processes are co-resident) come back. The idea of very quick very easy to spawn sub-processes allows for interesting security & modularity, where-as today services are almost all monolithic app servers that have complicated multi-user authentication & authorization concerns. We could make simpler safer software if we had more complex runtimes; it's a trade-off, and im deciding we have gone too-deep, unleashed monsters, we have perhaps too polarized ourselves against many of the great capabilities we one tried for.
Re: Ask HN: Why did back-end development explode in complexity?
#65Funny. I am a backend engineer and think so about front end.
Re: Ask HN: Why did back-end development explode in complexity?
#66Earlier quoted context omitted.
Would you happen to know where I can find such companies?
Most government entities, big banks and companies using mainframes and AS/400 systems
There are mainframes & COBOL still around, but speaking as someone who's never worked in the sort of place that uses the trendy things mentioned on HN, I would say Oracle and things built on Oracle are my concept of "normal".
I don't know how decision makers think, but I get a general sense that Oracle is the safe "you can't be fired for choosing..." choice.
I don't think these places have just one server, though, far from it.
Re: Ask HN: Why did back-end development explode in complexity?
#67Microservices and services in general where they weren't needed in the first place. Not saying they don't have their use but most companies just ride the hype train and start using technologies for the sake of using them. A couple of years later they end up with an unmanageable spaghetti of tightly coupled services.
Re: Ask HN: Why did back-end development explode in complexity?
#68I think complexity is conserved. You can move complexity around in an application but in the end someone has to deal with it.
E.g. the whole microservices vs monoliths debate. While a single microservice is usually relatively simple, you have 10s, 100s or even 1000s of microservices and the entire system design becomes crucial. With a monolith you don't have to worry as much about distributed services and inter-service communication but designing a robust monolith is still a complex process.
Re: Ask HN: Why did back-end development explode in complexity?
#69Earlier quoted context omitted.
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.
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.
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.
Re: Ask HN: Why did back-end development explode in complexity?
#70Oh 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.
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…
Does SimpleBeanFactoryAwareAspectInstanceFactory not simply spring to your mind when you're coding solutions? /s