I am not sysadmin, so, thinking out loud here: why not build software services in a way that does not require this large and sprawling infrastructure? The future could be simple binaries that run in user space and cache everything in simple data structures all in RAM. 64GB is cheap and will handle C1M easily.
I want my future server to abstract the hardware (memory, socket too), provide a few simple API calls, run my runtime (C++, rust, .NET, etc.), and then I'll build my application business logic to handle all my customers waiting on the other end of the socket.
Perhaps it the open source way where you have 40+ dependencies. I recently built my own webserver and found it very liberating.
The goal of Containers is to fully abstract the application. That can only go so far - the underlying infrastructure is still a huge part of the application. The responsiveness of a web application doesn't just involve efficient algorithms and storage calls, but also backend call latency, and transport time back to the user.
The infrastructure doesn't have to be large, but distributing parts will help the entire service stay online. Front-end nodes could be distributed to different datacenters, and back-end could also be mirrored or replicated between locations. With some kind of global load balancing, users can be routed to the nearest server for the fastest response.
The binaries have to run somewhere, either in the virtualized unit or its host. And Open Source or Proprietary, you're going to have dependency bundles - .NET, Java, etc. It might be more efficient to lump Containers by dependency so fewer of them need to be loaded by a Host.
Comments
I am not sysadmin, so, thinking out loud here: why not build software services in a way that does not require this large and sprawling infrastructure? The future could be simple binaries that run in user space and cache everything in simple data structures all in RAM. 64GB is cheap and will handle C1M easily.
I want my future server to abstract the hardware (memory, socket too), provide a few simple API calls, run my runtime (C++, rust, .NET, etc.), and then I'll build my application business logic to handle all my customers waiting on the other end of the socket.
Perhaps it the open source way where you have 40+ dependencies. I recently built my own webserver and found it very liberating.
Think outside the container.
The goal of Containers is to fully abstract the application. That can only go so far - the underlying infrastructure is still a huge part of the application. The responsiveness of a web application doesn't just involve efficient algorithms and storage calls, but also backend call latency, and transport time back to the user.
The infrastructure doesn't have to be large, but distributing parts will help the entire service stay online. Front-end nodes could be distributed to different datacenters, and back-end could also be mirrored or replicated between locations. With some kind of global load balancing, users can be routed to the nearest server for the fastest response.
The binaries have to run somewhere, either in the virtualized unit or its host. And Open Source or Proprietary, you're going to have dependency bundles - .NET, Java, etc. It might be more efficient to lump Containers by dependency so fewer of them need to be loaded by a Host.
64Gb is cheap.
So is 640Gb, compared to developer time.
Abandoning well-understood technologies is usually more expensive than just evolving what you have to run on a smarter substrate.
[Edited for confusing redundancy]