"I shoulda used containers." A bad experience with VMWare hosting
Linux - ContainersThis forum is for the discussion of all topics relating to Linux containers. Docker, LXC, LXD, runC, containerd, CoreOS, Kubernetes, Mesos, rkt, and all other Linux container platforms are welcome.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"I shoulda used containers." A bad experience with VMWare hosting
When you arrange for your client to sign-up with a [VMWare ...] cloud hosting service, you ordinarily take for granted that the service in question actually has the hardware infrastructure to make good on their contracts. But, not too long ago, I encountered one that didn't. (A well-known but unnamed company whose primary business is providing "data centers." I was stunned ...)
I deployed the site using eight virtual machines, all named for Peanuts characters. Database server, NFS file repository, backup database mirror, web servers and so on. Later on, I was called to figure out why some of the virtual CPUs were reporting "stalls" of up to 30 seconds(!) at a time. (Eventually, the lawyers settled this "material breach of contract" case, and soon thereafter the provider sold its hosting enterprise to another firm which apparently did know what it was doing. The site, in its various manifestations, is now very-reliably doing about $6 million in business a month ...)
But I think I learned something: "containers minimize your exposure to the underlying host." Well, maybe it would or maybe it wouldn't, but since that experience I have shifted ... first of all, to better hosting companies(!!) ... but also to the use of containers. Instead of configuring multiple smaller VMs, I will configure just one big one. Then, I use container technology to carve it up. It works quite well, and it also eliminates the need for things like NFS. Now, the host has only one thing to dispatch, and I know that VMWare knows how to do it if given the resources. Linux does the rest.
"Docker" is one obvious strategy, but I personally don't like being so far out-of-the-loop as to what is actually going on "inside." Therefore, I use lxc/lxd with very satisfactory results.
Last edited by sundialsvcs; 07-21-2022 at 01:49 PM.
Maybe I am misunderstanding here...
But with "one big one" if you have to do any maintenance on that one what would happen to all things running on it? Maybe per SLA there is some downtime allowed?
PS: I see you have been doing this for a long time, so I am not questioning your methods here. But simply am curious...
We're not a 24x7 shop, but have been there a few times where some users tend to think so.
"Maintenance" as seen by the end-user or the client basically consists of actions taken within a particular container.
Yes, the contracts allow for scheduled downtime, but the VM that is running the containers might now have "uptime" spanning multiple years. You have no need to turn this one off. The only reason why you might do so is to update Linux itself, and that's a simple "bump." Less than a minute.
Unlike VMs, containers are extremely easy to spin-up and spin-down. You can even swap one for another. Because it's all really just a software illusion. A well-behaved Linux process that is "wearing rose-colored glasses" without knowing it.
I used VMs at that time because that's what the customer said he wanted me to use. But, looking back, it was "very messy," and dependent on things (settings which could be made only by the hosting company owner) that translated to considerable "technical exposure" for the project. For instance, "two separate VMs" were constantly involved with something as basic as "reading a file." I should have argued harder, and sold the container idea better.
Last edited by sundialsvcs; 07-27-2022 at 01:51 PM.
When you arrange for your client to sign-up with a [VMWare ...] cloud hosting service, you ordinarily take for granted that the service in question actually has the hardware infrastructure to make good on their contracts. But, not too long ago, I encountered one that didn't. (A well-known but unnamed company whose primary business is providing "data centers." I was stunned ...)
I deployed the site using eight virtual machines, all named for Peanuts characters. Database server, NFS file repository, backup database mirror, web servers and so on. Later on, I was called to figure out why some of the virtual CPUs were reporting "stalls" of up to 30 seconds(!) at a time. (Eventually, the lawyers settled this "material breach of contract" case, and soon thereafter the provider sold its hosting enterprise to another firm which apparently did know what it was doing. The site, in its various manifestations, is now very-reliably doing about $6 million in business a month ...)
But I think I learned something: "containers minimize your exposure to the underlying host." Well, maybe it would or maybe it wouldn't, but since that experience I have shifted ... first of all, to better hosting companies(!!) ... but also to the use of containers. Instead of configuring multiple smaller VMs, I will configure just one big one. Then, I use container technology to carve it up. It works quite well, and it also eliminates the need for things like NFS. Now, the host has only one thing to dispatch, and I know that VMWare knows how to do it if given the resources. Linux does the rest.
"Docker" is one obvious strategy, but I personally don't like being so far out-of-the-loop as to what is actually going on "inside." Therefore, I use lxc/lxd with very satisfactory results.
I had a rough experience with VMWare hosting. I had some of my friends use it as well. They all had the same story. VMWare hosting sucks with regards to security, speed and reliability. It's a good choice if you are planning to host your calendar or a small website. But if you are running a business and your site is running on Wordpress or Shopify, then I highly recommend you stay away from VMWare hosting. and I would like to suggest you Devrims. I have had a great experience using it.
"VMWareŽ, itself," is a very reliable and well-designed software platform which successfully "moves the freight" for an awful lot of people. I have no complaints with it. As long as the vendor actually has the hardware resources deployed to fulfill the terms of their contract, I'm quite sure that it will work just fine. But, to the extent that they don't, "you are butt-naked exposed."
The VM layer represents software that you don't have direct control over. Yet it affects the deployment completely.
Looking back now on this deployment – which by the way is still in service, still selling millions of dollars' worth of hotel signs every month – I realize now the value of "containers." I had to use all sorts of things, like NFS shared file-systems, which would have been necessary had the virtual machines been real. And I had to maintain separate Linux installations for every one of them. Completely unnecessary ... simply because the machines were not real.
Well, I yielded to the customer's stated requirements for this job, but looking back I should have tried harder to convince them. "Oh well, next time ..."
- - - - -
There are today a number of "specialized" hosting services, dedicated to particular applications or languages. There are "Wordpress hosts," "Shopify hosts," and even a Python-specific host ("pythonanywhere.com"). Most of these services use AWS on the back-end, but you don't see it. (Yes, you are running in a container ...) Their key advantage is that they specialize in what you happen to be doing. So, they've paved-over a lot of the rough spots. And, because they operate on volume, on "the economy of scale," their monthly subscription prices are generally quite low.
Last edited by sundialsvcs; 08-19-2022 at 08:44 AM.
"Docker" is one obvious strategy, but I personally don't like being so far out-of-the-loop as to what is actually going on "inside." Therefore, I use lxc/lxd with very satisfactory results.
Seems sensible, yeah.
I don't know much about this, but if I was to set up something like that, I would probably rather use virtual machines. At least I imagine I would. But I'm guessing the more "serious" consideration is the network/firewall setup in either case.
Quote:
Originally Posted by sundialsvcs
And I had to maintain separate Linux installations for every one of them. Completely unnecessary ...
Virtual machines work fine, partly due to the hardware-level support for them that all modern microprocessors have, but they are "big and bulky." And yet, that really exists only to supply isolation. Containers provide comparable isolation but do so by misleading the individual processes – all of which actually run as ordinary processes on the host(s). The processes "see" a filesystem, a network, and so forth, yet it is all an illusion. A very efficient illusion. Messy things like "NFS" aren't necessary.
My technical exposure on this project occurred because the hosting company had grossly overcommitted their physical servers. I couldn't see that, of course didn't anticipate it (don't we have a contract?), and most importantly couldn't do anything about it. As it turned out, "lawyers talked to lawyers" and the problem went away, and the hosting company was sold into better hands a short time later. But if I had prevailed on the idea of using containers from the start, the exposure and the opportunity for the same would have been much less.
Last edited by sundialsvcs; 11-01-2022 at 09:30 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.