5 ms·
> I could never run a scalable service on the cloud without Kubernetes Can you give us an indication of the scale of your app? e.g rpm.
by shusson 7y ago
> I could never run a scalable service on the cloud without Kubernetes
Can you give us an indication of the scale of your app? e.g rpm.
- flowerlad 7y agoIt is still in development, so no rpm at the moment. That’s another thing: some people think Kubernetes is something you use if you need high scalability. I disagree. Kubernetes should be the default if your app consists of more than 1 service. If you don’t have high scalability requirements you can rent a single-node GKE “cluster” for about $60 per month. If you have just 1 service then a single Docker container is all you need, so Kubernetes not needed.
- merb 7y agowell if you have 1 service k8s is already useful. try to make blue/green or any other no downtime deployment. especially with database changes. in k8s deployments are deterministic, it will roll out X containers at once (X is configurable and defaults to 1)
- mrits 7y agoYour comment makes me so irrationally angry. I totally disagree. But I'll be civil. I write scalable apps without K8. I moved away from it. Stateless services are trivial to scale.
- deleted 7y ago[deleted]
- pc86 7y agoIf anything about the topic of how to scale infrastructure actually makes you angry, you need to see a therapist.
- mrits 7y agoThat's exactly what my therapist said.
- EpicEng 7y agoMost of us have to deal with the design decisions made by others. I can see how poor decisions can make someone angry down the road.
- james_s_tayler 7y agoIt was probably more the "if you have more than 1 service you need Kubernetes". No. You don't.
- regularfry 7y agoIf you don't have high scalability requirements, virtually anything will work. You're probably paying $55/month over the odds.
- petilon 7y agoWhat will you use for service discovery?
- deleted 7y ago[deleted]
- servercobra 7y agoIf you're not worrying about scalability like the OP said, static configs. Add a new service? Roll out config changes. Server goes down? Let the redundancy handle it, roll out config changes in the morning.
- JackRabbitSlim 7y agooff the top of my head? a) Shared data source; each service writes pid/state to a file in the shared data store. It could be a single directory in a single server setup or a dedicated NFS/SMB server for hundreds/thousands of nodes. b) Pub/Sub service; Kafka, et al, in which services simply subscribe to and publish to a central channel to see everyone else. c) Determinism; You use predictable naming/addressing and simply infer. This is tricky to scale but not impossible. d) Any number of stand alone discovery services ala Zookeeper or Eureka. They all end up being effectively the same pub/sub model as B, just prepackaged. e) You don't discover shit, you have a single load balanced endpoints that can scale out instances as needed behind balancer with zero knowledge required by the rest of the system. Pick one to suit your needs. Service Discovery is not that hard and has been way over engineered.
- mcbutterbunz 7y agoAs I was reading this, I thought to myself "How does this scale" and then I re-read the parent comment that said "If you don't have high scalability requirements, virtually anything will work." The fact of the matter is that Kubernetes solves certain problems well but also presents other problems/challenges. For some organizations, the problems K8s solves is bigger than the problems/challenges it creates. It's all about trade offs. Some people do want to hop on the next big thing in order to keep their imposter syndrome in check. Others know a certain technology and stick with it. Sorry, I'm just ranting.
- EpicEng 7y agoThis mentality is how we end up with overly engineered piles of dung. Instead of building something in the most simple way practical which would fulfill our requirements, we go all out. Now changing things takes longer because to do anything you have to weave through 10+ layers of opaque abstraction. No thanks.