4 ms·
With 200 CPU threads (128 CPU cores), I think most startups can run a complex microservice environment on a single machine. Although Kubernetes requires 3 to s
by bhouston 7y ago
With 200 CPU threads (128 CPU cores), I think most startups can run a complex microservice environment on a single machine.
Although Kubernetes requires 3 to start, but still, this greatly reduces the need to have a lot of separate machines.
256 threads per machine this year. 512 threads per machine 2 years from now? And then hopefully 1024 threads per machine 4-5 years from now? That would be really fun.
(I will take a laptop in 4 years with just a lowly 64 cores please, leaving the heavy iron for the cloud machines.)
I want Moore's law back but in parallel form. The years since 2004 with x85 machines have been quite boring from a CPU performance increase perspective.
- tazjin 7y ago> Although Kubernetes requires 3 to start It doesn't actually, and if you're running on GKE then the master is a managed service - you can have a single-node cluster (I do this occasionally for testing). Said startup might want to consider going with smaller machines in separate availability zones, though ;-) (Disclaimer: I work in Google Cloud)
- brianwawok 7y ago2 is a decent number for GKE. At least some hope of staying up if a node falls over. 3 is more realistic though. If you run at 66% utilization, can deal with a single node down.
- kevinconaway 7y ago> With 200 CPU threads (128 CPU cores), I think most startups can run a complex microservice environment on a single machine. Why would you want to? Your whole environment will be down when the machine, or some component thereof, fails or is rotated out for maintenance I think this is more of a benefit for cloud providers in that they can pack more disparate customer workloads on to a single machine.
- gravypod 7y agoIt'd be great as a CI machine for doing full end-to-end integration testing.
- mike_hearn 7y agoSo have two of them with synchronous replication and fail over between them. You have to think about dying or suddenly slow machines even in a microservices architecture. The advantage of such a machine is that if it starts to die, you fail over everything atomically and then repair/replace the backup. You don't need to think about what happens if one component is on a dead machine and the others aren't (does your load balancer handle that well, given machines often "die" in ways that just make them slow rather than totally failed?) The big win though is if you get rid of the microservices and run the whole thing in one big process. No complex RPC failures, obscure HTTP/REST attacks like https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn https://portswigger.net/blog/http-desync-attacks-request-smu... and so on. That might sound mad but modern JVMs can run lots of languages fast, and have ultra-low-pause GCs that can use terabytes of heap. Like less than one msec low. Many, many businesses fit into these really high end machines with a giant JVM. I've written about the possibility of a swing back to big iron design here: https://blog.plan99.net/vertical-architecture-734495f129c4 https://blog.plan99.net/vertical-architecture-734495f129c4 And a look at modern Java GCs - GC being historically the bottleneck to really large single processes: https://blog.plan99.net/modern-garbage-collection-part-2-1c88847abcfd https://blog.plan99.net/modern-garbage-collection-part-2-1c8...
- qaq 7y agoThis greatly reduces the need to have complex microservice environment.
- merb 7y agoyou can run k8s on a single machine. there is even an easy way to do so k3s: https://k3s.io/ https://k3s.io/
- oliwarner 7y agoAll the hassle of sharding out your workflow for horizontal scaling, with the downsides and expense of vertical scaling. Just buy more cheap 4-8c servers.