3 ms·
The author fails to explain how these lightweight VMs would be orchestrated. There are two directions that most organizations can go from containers, and they
by btilly 7y ago
The author fails to explain how these lightweight VMs would be orchestrated.
There are two directions that most organizations can go from containers, and they have opposite answers to this question.
The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem. What else do we get? Development is easier. Debugging is easier. We have literally decades of experience figuring out how to make it work.
Very, very few of the people reading this post are solving problems harder than ones I was solving decades ago using that kind of stack. Other than the fact that your resume won't look as good, there is zero reason not to do this.
The other is, as the post's author recommends, even further into isolating the app. Down to something even simpler than a container. In which case you will need a solution for orchestration, but it won't let you leverage a single running VM to a whole cluster. Limiting the attack area will be good for security.
As a bonus things that container folks say work, but don't, will work. For example autoscaling fails in adtech with containers fails hard because the time that it takes to boot up new instances exceeds the time that you are getting flooded by your ad. But if your unikernel boots fast enough, now autoscaling does work.
Now there is a third use case. And that is organizations like Google whose codebase is so big that they can't run it monolithically on a single machine. Containers solve that in a distributed environment by letting them run only some of their code on each machine. There is a hidden cost that RPCs over a network are inherently an order of magnitude more expensive (in time, latency, and resources) than a function call inside of a running application. So you order an order of magnitude more hardware, and containers are the sweet spot for you.
But that problem is of a kind that very few organizations have. And making it actually work takes a lot of thought and organization that very few in the containerization world seem to understand. Certainly if you read a few blog posts, install Docker and Kubernetes, then start deploying through Helm, I am willing to bet large sums of money that you are almost certainly making rookie mistakes.
- mschuster91 7y ago> The first direction is back to a monolithic application running in a VM. Orchestration no longer exists as a problem Of course it does, VMware makes a boatload of money with VM orchestration. Or you setup OpenStack which is free but a nightmare in itself. You do not want a hand-rolled KVM virtualization stack. I've been there, I've seen the horrors.
- eyberg 7y agoI'd agree with all the points you just made. I'd also offer that if one is using public cloud than a lot of the orchestration is already taken care of for you.
- btilly 7y agoIn 2003 I was a developer on a website that served a million pages per hour using 2 databases, 4 webservers, and associated networking. Most of that hardware was there for automated failover. At that scale, orchestration is simply not a challenge. We wrote a deployment script to roll out code changes and life was good. 2020 hardware is not worse than 2004 hardware. And while that business eventually failed, it was not due to technology. (And it made a lot of money before it failed.) As I said, most here are not doing something harder now than we did then. The same class of solution works. As the old saying goes, KISS. Know when it works, and when it doesn't. As another saying says, YAGNIY. (You Ain't Gonna Need It Yet.) Deal with the limits of being monolithic after you encounter them. Don't complicate your life to tackle problems that don't exist.
- mschuster91 7y ago> In 2003 I was a developer on a website that served a million pages per hour using 2 databases, 4 webservers, and associated networking. Most of that hardware was there for automated failover. fwiw, Stackoverflow runs on a similarly sized/deployed stack. But that is because Stackoverflow is fine with their employees running a cheap, un-complex system that works (I can't remember the last SO outage!), and their employees are also happy with this. Others, especially startups? Gotta chase these hipster credentials and use the free AWS/Azure/GCP credits somehow... and the employees don't want boring old school stuff, they want the newest hipster crap that's barely alpha tested, but in production. Utterly ridiculous. Most of them would be fine with three sub-$10k AMD servers and a bit of work by a seasoned Linux sys-admin. But eww. Linux management. Not cool/hip.
- heavenlyblue 7y agoDid that stack include daily traffic analytics hardware?
- wvh 7y agoI mostly agree – which probably betrays my age – though when the load exceeds one server, you're going to have to orchestrate no matter what: deployment, load balancing, fail-over, system updates. While I'm critical of Kubernetes' complexity, I still think that for some people, having that orchestration handled by a tested layer instead of implementing it from scratch in-house is still going to be a benefit. After working with and securing large bare-metal and monolithic virtual host environments for way too long, there's got to be a better way to deploy services and update systems than the snowflake hell some monolithic approaches seem to bring. Perhaps there's a middle way between both worlds that has yet to gain any momentum.