5 ms·
I think they mean that 99% of the time you're better off using a single container on a single server and wiring them together using traditional tools (load bala
by spicyusername 5y ago
I think they mean that 99% of the time you're better off using a single container on a single server and wiring them together using traditional tools (load balancers, network-attached storage, etc) than you would be if you adopt Kubernetes. This gives you many of the same application-development benefits (standard packaging format, write once run anywhere, etc) that Kubernetes does without the overhead of managing the infrastructure complexity.
Kubernetes is so complicated and many organizations do not really think about what problems they are trying to solve before diving in. Kubernetes solves so many problems that most IT organizations don't actually have or that are perfectly solvable in a simpler way with the existing virtual-machine ecosystem.
- superkuh 5y ago99% of the time for 99% of people you're better off not using a container at all and actually running your application on your OS instead of under $alot of layers of extra abstraction. Of course if you're not a human person it's different. Corporate people, being made up of multiple different people, care more about their human elements being able to interact with each other's work. There containers might help.
- beckingz 5y agoMicroservices do allow scaling the development of an application on the human side. This is true! A kickass CICD setup and good developer tools probably should be done first for the typical company, otherwise the majority of the added engineering time will go into scaling the infrastructure setup.
- zozbot234 5y agoContainers do not add extra abstraction layers, they're about proper namespacing of all resources. They simplify the OS's existing abstractions and remove a lot of pointless attack surface.
- zekrioca 5y agoExactly. Some people think containers are a whole new layer, akin to a VM. I think it is just their mental model that are used to equate containers and VMs.
- ElectricalUnion 5y ago> They simplify the OS's existing abstractions I am pretty sure they're supposed to use a somewhat "Cooperative Namespacing" schema, that makes both the application and the OS/container abstraction layer more complex, while attempting to deliver lower overhead for said namespacing. Sorta like Cooperative Multitasking, compared to Preemptive Multitasking. And even that doesn't work for some situations; as an example, old versions of Java (7 and older) will use the incorrectly namespaced Linux file system APIs to incorrectly read whole-system limitations instead of current container limitations to setup memory and CPU parameters. > remove a lot of pointless attack surface. Not really, containers are for lower overhead cooperative namespacing, not security. You want bare minimum lightweight VMs for security.
- pengaru 5y agoUnless severely resource constrained, it makes sense to at least toss the application under something light like an nspawn container. If you're using systemd hosts it's already there. Even if you don't use user or network namespaces it at least confers a desirable separation of application and its dependencies vs. underlying host at the filesystem level. It simplifies administration and allows your app and its dependencies to move at a pace decoupled from the host kernel and its minimal dependencies required for providing ssh access and systemd.
- spicyusername 5y agoI disagree. Using container directly on something like RHEL still provides quite a few benefits with very minimal overhead.