> Therefore, the best thing to do is to deploy your program without resource limits, observe how your program behaves during idle/ regular and peak loads, and set requested/ limit resources based on the observed values.
This is one of the author’s fatal assumption. The best practice I understand is to set cpu requests to be around 80% of peak and limits to 120% of peak before deploying to prod.
They set themselves up for disaster with this architecture where they have many idle pods polling for resource availability. This resource monitoring should have been delegated to a single pod.
Also it’s really unclear what specific strategy led to extra costs of 1000s of dollars...
“Why Haskell is important” according to a Haskell consulting company. So taking this article with a big grain of salt.
Haskell might be a great language but barely anyone (besides CS academics) uses it.
We use java and python in production because (among many other things) they’re very popular.
Popular languages have large archives of open source packages and easy to find communities that save enormous amounts of headaches and time. The opposite is true of Haskell, at least for now.
I am still not clear on why Python has become popular. It wasn't a few years ago. They might use it more in universities nowadays but it seems backwards if the business's starts using languages just because they are used in education.
By the way, I don't here much about companies using Python in Scandinavia except for some AI.
All valid points. It could in the future be done in a better way is not really interesting when you are working with your boss breathing down your neck.
Still my fellow academics will try to push in the direction they see fit.
This is an attempt to push Lyft out of CA by raising the cost side of the equation but that cost will eventually have to be passed to riders, which will dramatically drop demand. If the minimum wage law passes and they subsidize rides long enough to edge out Lyft then they finally get the monopoly they’ve been promising investors for the last decade but they also lose a huge amount of their TAM. The laws of supply and demand will eventually come into play.
And of course once they get their monopoly they will raise prices further to get profits and at that point I’d guess they would only be slightly less expensive then Taxis were before all this gig economy craziness.
I also think it's an attempt to ward off a nascent unionization push.
Regarding a different, recent "olive branch" type proposal:
"The one thing they don’t want to give you is the thing that you need to get. This offer from Uber and Lyft is like a kidnapper offering you a softer blanket, as long as you agree not to ever escape. No thanks. These companies know very well that once their workers become actual employees, they will get a host of benefits automatically, and they can formally unionize to win themselves many more benefits and increased pay. These companies, which have never made a dollar even while exploiting their workers, fear this. So they offer some concessions." [1]
What an immature and rude way to criticize a young open source project. I’m disappointed that so many in our community appreciate this disrespectful writing style criticizing our k8s supporting peers.
Secondly, developing on Kubernetes “sucks” compared to what? Mesos? Docker Swarm?
Maybe this engineer is still frustrated with Tilt’s failure as a business (https://www.fastcompany.com/3069164/how-tilt-veered-off-cour...) and Airbnb imposing changes on his workflows like how they deploy their apps. If that’s true then I hope he finds more healthy and mature habits to manage his anger.
> Secondly, developing on Kubernetes “sucks” compared to what? Mesos? Docker Swarm?
My thoughts exactly. I feel like most people who complain about these things are just feeling grumpy about the overall experience, and aren't always quite sure where to place the blame.
It takes a lot of introspection to know exactly where a system should be better than it is... "this yaml is too complex", until you start thinking about how you'd do it better, and then you realize all the problems each of the similar approaches have, and that a lot of it was done for a reason, etc.
Or you start comparing k8s to completely different approaches like just rsyncing some files to a remote webserver and SIGHUP'ing it, which is much simpler but has its own host of reliability/testability/reproducability concerns.
I think in reality, people are overwhelmed by what it really takes to adopt best practices (declarative deployment, CI/CD, health checks, service discovery, etc). Practices that have been hard fought and discovered over many years of people trying things and failing. K8S IMO represents the state of the art in a lot of them, but too often people place blame on k8s when what they're really doing is questioning the best practices themselves. Practices that are also shared across k8s's competitors like mesos and docker swarm.
That's a video from 2007 talking about how high school student can program bacteria. It's gotten a couple orders of magnitude easier and cheaper in the past decade since that talk.
I would be interested in this as well, but how do you measure creativity?
Data on long-term effects of marijuana is rare to come by and that's when we are looking at a clear metric like IQ.
> They cannot use anything except an algorithm to recommend videos
That’s assuming recommendations need to be personalized. They could recommend at a higher level to groups of people using attributes like age range or region.
I’m not a fan of their personalized recommendations. It’s algorithm overfits my views to recommend videos extremely similar to videos I’ve recently watched, which isn’t really aligned with my interests.
If they took a completely different approach (not personalized) it could really impact the UX in a positive way.
No thanks. You try logging out and see the generic recommendations. It's the lowest common denominator, just like anything else targeted at large masses of people.
I’m curious where the term “Superior General Knowledge” in the headline came from. It’s not explicitly defined in the article and ironically is not an intellectually humble way to describe the article’s conclusions.
This is one of the author’s fatal assumption. The best practice I understand is to set cpu requests to be around 80% of peak and limits to 120% of peak before deploying to prod.
They set themselves up for disaster with this architecture where they have many idle pods polling for resource availability. This resource monitoring should have been delegated to a single pod.
Also it’s really unclear what specific strategy led to extra costs of 1000s of dollars...