4 ms·
I was going to reply to the general point, but I got interested on this: > you try moving 50 different clients off the service they've been using for three yea
by outworlder 9y ago
I was going to reply to the general point, but I got interested on this:
> you try moving 50 different clients off the service they've been using for three years
This sounds like a major red flag.
Are they on-prem air gapped servers? Do you manage the infrastructure? Because if you do and they aren't, they are not supposed to see it. And if it is automated, what does it matter if there are 50 or 50 thousand clients?
The point of the cloud is that the customers don't have to care. And you also shouldn't care about individual servers. Or even clusters.
On K8s, it does a lot of really neat stuff that would keep me awake at night otherwise. Oh a K8s worker VM died in AWS. I don't care. There's a machine that's misbehaving. Kill it, another one will come, containers will spawn there. I don't care. Need more container instances, done. Need to deploy a new service? Push the new yaml to the server, done.
Upgrade twice a year and you'll be ok, unless your dev team insists on new features.
- peterwwillis 9y ago> they are not supposed to see it There's a whole lot of things that are not supposed to happen in the tech world, that happen all the time. Most people do not run brand new stateless microservices in K8s. They run stateful apps on VMs in three year old badly configured OpenStack clusters. For what it's worth, moving the client traffic itself is seamless and totally fine. But first you have to get them to stop hard-coding the names of region and zone specific load balancers into their apps. You switch them over... traffic falls over... and it's your fault. Hence, big moves are coordinated with clients, not to mention feature tested, and then tested by sending some real traffic to the new cluster, before you shift all the traffic. The cloud is not magic, and if you treat it that way, it will bite you.