3 ms·
There is a big difference between learning the nuances of engineering as you go and re-adjusting your viewpoint vs bandwagoning on a new tool because it's cool
by jpgvm 3y ago
There is a big difference between learning the nuances of engineering as you go and re-adjusting your viewpoint vs bandwagoning on a new tool because it's cool even though you can't tie any of it's advantages back to your problem statement.
That isn't making a choice and adjusting based on the data, that is just shoddy engineering.
It should have been obvious to anyone at a cursory glance that not only did serverless not offer anything to this application it would be actively detrimental. Simple napkin math of data rate of a 1080p video stream should have made that immediately clear.
Just because you can use something to get a task done doesn't make it a good choice. I can still write pretty decent Perl. It gets the job done and for some protocols that haven't changed in a long time like LDAP the existing CPAN libraries are still some of the best. But that isn't the right choice is it?
I don't think it's defensible to argue that we should build thing sub-standardly just to give people more choice. That is like arguing that real engineers should have more freedom in choice in how they design bridges. No one would agree with that.
We get away with it because our bridges are much cheaper to replace and noone dies if they break or have to be rewritten because they rotted too much to run anymore.
Right now as it stands arguments for serverless aren't technical in nature. They are a best an appeal to "the traditional way is slow" or some notion of "infinite scalability", the first of which isn't true at all and the latter doesn't matter for anyone that is arguing in favor of serverless.
Also even if it was "faster" (I don't agree but lets postulate) that probably wouldn't make it a good decision either unless it was proportionally faster vs it's costs (not just dollar costs, architecture, complexity of managed objects, etc). Which I highly doubt would be the case.
As you can see from a technical POV it's just very very hard to rationalise a position for serverless > Boring Tech. For me it would take too much mental gymnastics.
I was perhaps a little strong but my points are solid.
If it was good it would have proven advantages by now. K8s adoption curve vs serverless adoption curve tells the real story of quality IMO, especially given how much bigger of a move it was to k8s from what preceeded it.
- richardw 3y ago> I don't think it's defensible to argue that we should build thing sub-standardly just to give people more choice That's like a village of straw men. Stop going around telling everyone they're fucking idiots. We'd probably agree 90% of the time, dealing down the intensity just makes for a better discussion. They "already owned a tool for audio/video quality inspection, but we never intended nor designed it to run at high scale (our target was to monitor thousands of concurrent streams and grow that number over time)" Good principle #1, reuse. They launched faster than starting from scratch. They changed direction and modified some components, and then published, against what marketing would probably have wanted. Real problems are when you paint yourself into a corner and can't fix it. They fixed it. Amazon, keep telling us what lessons you've learned because it helps the whole industry. (Edited to remove some of my own incendiary annoyance.)