[read_if_gay_]

> Today it's just digital plumbing and dealing with all sorts of issues that are not creative. The sheer complexity is frankly absurd as well.

Is this not a contradiction to you?

[vbsteven]

I feel the same way. The plumbing required has become so complex these last few years (if you use new technology).

10 years ago we uploaded the server/backend binary to a VM, installed postgres/mysql and configured nginx/haproxy as a reverse proxy/ssl termination.

Now, if you want to deploy a modern SPA while using some buzzwords like k8s and devops you need:

* complex frontend build process with things like webpack which have huge config files

* Build docker images for all components (each microservice, frontend, etc)

* Build zips for deploying your lambda functions

* Configure docker repository for storing images

* gitlab/bbpipelines/githubactions/whatever pipeline configuration for automating all this building

* Setup a production-ready k8s cluster

* Write the kubernetes yaml files for describing your services

* Figure out how to hookup a cloud load balancer to your kubernetes ingress

* Figure out letsencrypt certificate renewal and make your ingress aware

* Figure out CDN configuration (and invalidation) because apparently we don't serve the frontend from the backend server anymore

* Some network config so your lambdas can access the backend

* Since we're using microservices we're going to need some service discovery, and depending on which SD solution we choose we might need to build this into each individual microservice (Consul)

* And probably lots more as I haven't even touched service meshes, or JWT authentication, caching and cache invalidation

[miltondts]

All this for something that can be handled by a single server. This constant waste of time and energy, both the devs' and the machines', is what bothers me the most. I'm constantly reminded of the quote "anybody can build a bridge, but it takes an engineering to build one that barely stands". Maybe I should go into games or embedded.

[kyawzazaw]

I suppose your argument is that most applications could and should be handled in a monolith.

But I think it would be a terrible idea to be reliant on just one server because downtown, latency are real-troubling issues.

[ux-app]

none of that is required. chasing fad based development would make you think that it is, but there are a lot of successful products that aren't burdened with all this cruft.

[jcranmer]

What you're complaining about is basically that certain features have become simpler to the point that it's feasible to have them in more situations--and adding those features adds a certain amount of complexity.

There are three overlapping issues in what you talk about:

* Moving from bare metal servers to VMs to containers, with cloud deployment optionally thrown in there somewhere.

* Moving from hand deployment to continuous integration.

* Moving from monolithic applications to microservices.

[DrJones1098]

This systems you just described are virtually infinitely scalable.

Lambdas expand infinitely, k8's can easily autoscale stateless docker containers out forever.

All for starting under a 500 dollars a month?

150$ for EKS, lambdas first X million are free, and are cheap as hell from there, cloud LB is 50 bucks a month, etc.

Not to mention all the other benefits that containers provide Infrastructure as Code, no dev environment incompatibility problems, etc..

That is UNHEARD OF historically.

I think you may have some rose colored glasses or I'm just idealistic and naieve, but it's insanely exciting what's possible for a small enterprise nowdays.

The problem nowdays imo is management. The business people have taken over tech instead of tech people running things. And people without knowledge of tech, running a tech shop always makes the job suck.

[eeZah7Ux]

The plethora of tools to make "devops" simpler and cheaper made it much more expensive.

You cannot simplify something by adding overly complex layers of abstraction on top of it.

[square_usual]

They make it cheaper at scale. Most of us don't need that scale, so for us it's expensive.

[eeZah7Ux]

...and yet all FAANGS implement their tooling instead of using the popular devops stuff.

Are they not understanding costs and scaling?

[SahAssar]

If you are doing that and do not want to do it then you are probably at the wrong company or not speaking up about it.

[tonyarkles]

To me, no. A significant amount of the complexity that I generally deal with is “accidental complexity” caused by the current general approach of mixing up a ton of random dependencies of unknown quality or pedigree and the subtle flawed interactions between them. Coming up with ugly workarounds is creative I suppose, but ton in a sense that makes me at all happy.

[lowmagnet]

It's not a contradiction to me. Things can look like plumbing from the surface, require no creativity at all, and run some ML model below the surface that only a handful of mathematicians can understand. The upside: powerful tools that just need to plumb in place, the downside: god help you if it breaks.

[hannasanarion]

Not at all. Plumbing can be very complex, digital ot otherwise. It's not as easy as "connect input to output and done", there are constraints on the system that need to be accounted for, and meaningful design decisions to be made especially with respect to expected volume.

But that doesn't mean it's creative. Plumbing, like web development, may have all of these complexities and constraints, but typically there is really only one solution that can be considered "right" and your job is to go through the steps and do the math to find it, there's not a lot of room for creative thinking, despite the complexity of the problem.