Interesting:
Docs is the result of a joint effort lead by the French 🇫🇷🥖(DINUM) and German 🇩🇪🥨 governments (ZenDiS). We are always looking for new public partners (we are currently onboarding the Netherlands 🇳🇱🧀). Feel free to reach out if you are interested in using or contributing to docs.
https://docs.numerique.gouv.fr/login/
#docs #opensource #eu #europe #france #germany #netherlands #collaboration #fosdem
I don’t like the approach of piling more things on top of even more things to achieve the same goal as the base, frankly speaking. A “local” kubernetes cluster serve no purpose other than incredible complexity for little to no gain over a mere docker-compose. And a small cluster would work equally well with docker swarm.
A service, even made of multiple parts, should always be described that way. It’s easy to move “up” the stack of complexity, if you so desire. Having “have a k8s cluster with helm” working as the base requirement sounds insane to me.
Honestly, a lot of the time I don’t understand why a lot of businesses use k8s.
At my company especially, we know almost exactly what our traffic will look like from 9am-5pm. We don’t really need flexible scaling, yet we still use it because the technology is hyped. Similar to cloud, we certainly don’t need to be spending as much as we do, but since everyone else is on or migrating to the cloud, we are as well.
Kubernetes is not really meant primarily for scaling. Even kubernetes clusters require autoscaling groups on nodes to support it, for example, or horizontal pod autoscalers, but they are minor features.
The benefits are pooling computing resources and creating effectively a private cloud. Easy replication of applications in case of hardware failure. Single language to deploy applications, network controls, etc.
I don’t like the approach of piling more things on top of even more things to achieve the same goal as the base, frankly speaking. A “local” kubernetes cluster serve no purpose other than incredible complexity for little to no gain over a mere docker-compose. And a small cluster would work equally well with docker swarm.
A service, even made of multiple parts, should always be described that way. It’s easy to move “up” the stack of complexity, if you so desire. Having “have a k8s cluster with helm” working as the base requirement sounds insane to me.
Honestly, a lot of the time I don’t understand why a lot of businesses use k8s.
At my company especially, we know almost exactly what our traffic will look like from 9am-5pm. We don’t really need flexible scaling, yet we still use it because the technology is hyped. Similar to cloud, we certainly don’t need to be spending as much as we do, but since everyone else is on or migrating to the cloud, we are as well.
Kubernetes is not really meant primarily for scaling. Even kubernetes clusters require autoscaling groups on nodes to support it, for example, or horizontal pod autoscalers, but they are minor features.
The benefits are pooling computing resources and creating effectively a private cloud. Easy replication of applications in case of hardware failure. Single language to deploy applications, network controls, etc.