331–340 of 681 posts
Earlier quoted context omitted.
good thing kubernetes can restart pods fast and have persistent volumes!
Persistant volumes rely on NFS (or a flavor thereof), which is not great for database performance. But that's a moot point anyways, since Vitess doesn't use persistent volumes - it reloads the individual DBs from backups and binlogs when a pod is moved or restarted.
Earlier quoted context omitted.
In my mind standardisation is how we really solve problems in much of software development. Everything before that is just practice and/or hacks.
I'm fine with standardization, as long as I set the standard. For standard 0, I propose that the only spelling for "standardization" will be with a 'z' (which is itself pronounced "zee").
Earlier quoted context omitted.
Why do a comparison? K8S runs on AWS and GCP. They have managed services for setting up one. If you know K8S as a developer, then you simply consume the cloud K8S cluster.
I think the point is that there are people that claim that k8s adds a ton of complexity to your environment. But if you compare k8s alone with managing your infrastructure using (non-k8s) AWS or GCP primitives, you'll find that the complexity is similar.
The simple answer is that Kubernetes isn't really any of the things it's been described as. What it /is/, though, is an operating system for the Cloud. It's a set of universal abstraction layers that can sit on top of and work with any IaaS provider and allows you to build and deploy applications using infrastructure-as-code concepts through a standardized and approachable API. Most companies who were late on the Clo…
Yes, people ought to do a side by side comparison of a new user learning to K8S v AWS v GCP before claiming Kubernetes adds more complexity than it returns in benefits. Remember the first time you saw the AWS console? And the last time?
Earlier quoted context omitted.
IBM charged the customer for each server.
or, as with my experience in licensing IBM stuff, the charged per CPU.
The simple answer is that Kubernetes isn't really any of the things it's been described as. What it /is/, though, is an operating system for the Cloud. It's a set of universal abstraction layers that can sit on top of and work with any IaaS provider and allows you to build and deploy applications using infrastructure-as-code concepts through a standardized and approachable API. Most companies who were late on the Clo…
Oh darn, I still don’t understand. Maybe I should learn what Docker is first?
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
Having extensively used Chef and K8s, the difference is that they try to deal with chaos in unmanaged way (Puppet is the closest to "managed"), but when dealing with wild chaos you lack many ways of enforcing the order. Plus they don't really do multi-server computation of resources. What k8s brings to the table is a level of standardization. It's the difference between bringing some level of robotics to manual loadi…
I think the build, deploy, start and run-time split is an important aspect that gets overlooked quite a bit, and is critical to evaluating tools at this point. That is why we aren't still doing everything with Chef or Puppet. Whether we continue doing it with Kubernetes or Pulumi or something else matters a bit less.
Repeatability is not the goal, as others in this thread have implied. The goal is trusting that the button will work when you push it. That if it doesn't work, you can fix it, or find someone who can. Doing that without repeatability is pretty damned hard, certainly, but there are ways to chase repeatability without ever arriving at the actual goal.
Earlier quoted context omitted.
Hmm really? My experience is that, with k8s I end up learning all the complexities of k8s in addition to AWS. Besides, personally I find AWS console much easier to understand. I don't get why people hate it.
> I don't get why people hate it. Because it is hard to manage the configuration. It's why tools like terraform exist. Anecdote. I worked for a small company that was later acquired. It turned out one of the long time employees had set up the company's AWS account using his own Amazon account. Bad on it's own. We built out the infra in AWS. A lot of it was "click-ops". There was no configuration management. Not even…
Sounds like the tiniest acquisition mistake I’ve ever heard of.
Before K8S, to run a service you need: - Setup VM: and their dependencies, tool chain. If you use thing like package that has native component such as image processing you event need to setup some compiler on the VM - Deployment process - Load balancer - Systemd unit to auto restart it. Set memory limit etc. All of that is done in K8S. As long as you ship a Dockerfile, you're done.
Earlier quoted context omitted.
> I'll never forget when I joined a hip fintech company, and the director of eng told us in orientation that we should think of their cloud of services as a thousand points of light Let's be real, if you are old enough to get that reference without Googling, you probably would not have lasted that long at a hip fintech company anyways :-P
George Sr's term wasn't that long ago. ... was it?