5 ms·

> 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 co

> 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?

tonyarkles 6y ago
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 6y ago
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.
vbsteven 6y ago
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 6y ago
  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 6y ago
    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 6y ago
  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.
- eeZah7Ux 6y ago
  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 6y ago
    They make it cheaper at scale. Most of us don't need that scale, so for us it's expensive.
    - eeZah7Ux 6y ago
      ...and yet all FAANGS implement their tooling instead of using the popular devops stuff. Are they not understanding costs and scaling?
- jcranmer 6y ago
hannasanarion 6y ago
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.

> 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?

tonyarkles 6y ago

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 6y ago

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.

vbsteven 6y ago

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 6y ago
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 6y ago
  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 6y ago
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.
eeZah7Ux 6y ago
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 6y ago
  They make it cheaper at scale. Most of us don't need that scale, so for us it's expensive.
  - eeZah7Ux 6y ago
    ...and yet all FAANGS implement their tooling instead of using the popular devops stuff. Are they not understanding costs and scaling?
jcranmer 6y ago

hannasanarion 6y ago

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.