I'm not even sure that on-prem is really a financially viable solution when you see the time and expertise it takes to care for those GPUs. I haven't seen any good numbers on that. I think if you have a massive team of data scientist hammering GPUs day-in day-out, it might make sense. After all, at scale everything is different. BUT if you have high scale, you're going to pay for a team of highly specialized datacenter operator who know GPUs. They also forget that the data needs to come from somewhere and the amount of data is now usually counted in PB(> TB > GB). I'd like to see the networking cost of that. It may actually be cheaper to outsource that work to a cloud provider, so I'm still skeptical about the "saving money" part.
I heard that the new RTX 30 series is a considered a major evolution in the architecture of GPU. Here is the NVIDIA keynote : http://youtube.com/watchv=QKx-eMAVK70
As a colleague put it: "If the stock price did not really improve after the announcement, it might not be such a big deal." It has some truth in it, I'm not sure if it applies in COVID times.
As a colleague put it: "If the stock price did not really improve after the announcement, it might not be such a big deal." It has some truth in it, I'm not sure if it applies in COVID times.
If you to a proof that running a data center is usually more expensive than the cloud, here is a twitter thread written by the person who built the physical datacenters of Google: https://threadreaderapp.com/thread/1102401615263223809.html
I hope that the task of managing those on-prem cluster will never fall on me 🙏
On a different topic, have you seen this tool: https://googlecontainertools.github.io/kpt
configuration-as-data (vs configuration-as-code) .... I did not understand the difference at first but it is a very interesting concept....
I'd love to talk about it once I know more
configuration-as-data (vs configuration-as-code) .... I did not understand the difference at first but it is a very interesting concept....
I'd love to talk about it once I know more
FAQ does not really give you much
I would love the web-site to tell what that is for and what problem it is intended to solve
from FAQ I get a feeling that it is somekind of GitOps tool thingy for K8S
I agree that the website is bad at explaining. The ascii cinema should be converted to documentation: https://googlecontainertools.github.io/kpt/reference/pkg/
I hate to have to play a video to understand something.
I hate to have to play a video to understand something.
I see very little different from git submodule command
That is different
though this link can’t be seen without podcaster login
if you want spotify link
Seems like Docker Swarm is still kicking https://searchitoperations-techtarget-com.cdn.ampproject.org/c/s/searchitoperations.techtarget.com/news/252489220/Mirantis-rethinks-Docker-Swarm-vs-Kubernetes?amp=1
I was advocating for Docker Swarm more than kubernetes a few years ago because Devs and Ops were overwhelmed and needed a smaller solutions. Especially since it should not require a massive overhaul of everything by moving from Swarm to K8s.... I don't think it is worth it now unless Docker Swarm has a clear set of features that are difficult to implement in Kubernetes.
it seems that they want to keep docker swarm interface but move backend to k8s
Its hard we have so many nice tools now it was good with swarm was you could have a compose and then point it to server and said go
Still do all local dev in compose instead if minikube ?
My bad have not send invite will do know
is 13 ok ?
that will do for me
also need to pick a topis we can prepare and keep it under 30 minutes...
It was about deleting and archiving things
Like archiving un-used apps
we could also talk about keeping AWS accounts nice and tidy as well as k8s clusters