3 ms·
Well, they're kind of right. Physical servers I get, you can't really do 1:1 without wasting a ton of resources. But VMs can be resized quickly. The problem is
by oblio 3y ago
Well, they're kind of right. Physical servers I get, you can't really do 1:1 without wasting a ton of resources. But VMs can be resized quickly.
The problem is that many companies have very rigid IT departments so even though in theory it can be done somewhat easily, in some places it can be a months-long process to actually get it done.
- jiggawatts 3y agoYou can’t resize a VM below 1 vCPU. Actually in most clouds it’s 2 vCPUs minimum in practice. I have a government customer running 150 web apps in about 20 vCPUs. If you naively multiply 150 apps by the minimum scale for HA, non-prod, and the 2 vCPU minimum for cloud hosts you end up with 450-600 vCPUs! That’s expensive even for governments.
- vegardx 3y agoI don't understand why you'd want to use VMs for something like this when containers exist and you have tools like ECS and Kubernetes. You can serve the same amount of web applications on the same amount of vCPUs and memory footprint, give or take a little bit. As a bonus, if you used AWS ECS, you also get to use things like IMDS (per container/task), Fargate, high availability and autoscaling tools.
- jiggawatts 3y agoWindows. While it's technically possible to run something like an old ASP.NET Web Forms app in a container, it'll be painful.
- DougBTX 3y ago> Windows. You should have put that in your first comment, I've removed my downvote!
- bob1029 3y agoWe are really enjoying using Azure Functions to serve web traffic these days. Probably not in exactly the way Microsoft would prefer us to, but it certainly works for us. All our business really requires is simple web forms, some session state and basic get/post request handling. Our users won't cry if they see a page transition. Az functions might not be the most optimal in terms of per request cost, but for the volume of traffic we are pushing it doesn't scale into the equation. Operationally, they're basically magic. TLS, auth, etc. all handled. GitHub deploys with zero drama. Whatever margin we sacrifice at the request billing is more than compensated by how well our engineers are sleeping at night.
- scarface_74 3y agoA. EKS and Docker brings its own complexity B. Enterprises run a ton of commercial off the shelf software hosted on VMs C. Ever heard of Windows? It’s still big in the enterprise
- redserk 3y agoWhile EKS can be a complicated beast to manage, Fargate (ECS) has been a pleasure to deploy and manage, and with ECS Exec you can jump into the container as if it were a VM. The most difficult part would be getting someone to throw their app into the container to begin with.
- electroly 3y agoNote: you can run Windows containers in both ECS and Kubernetes! I've never heard of anyone doing it but it's possible.
- scarface_74 3y agoYeah it’s also possible to stab myself in the eye repeatedly with a dull knife. One of my first AWS implementations was to autoscale an existing Windows based queue processing C# 4.0 job based on the number of messages in the queue using windows EC2 instances. Startup and shutdown times were and resource requirements were much greater than doing something similar with Amazon Linux 2 based Fargate containers or Lambda. My only experience with Windows/Fargate is running a Windows CodeBuild job. CodeBuild uses ECS/Fargate under the hood.
- 8organicbits 3y ago> You can’t resize a VM below 1 vCPU. There's also shared vs dedicated and burstable options if you need to go lower. Which clouds don't (in practice) offer 1 vCPU?
- zokier 3y ago"1 vCPU" is arbitrary unit, you can run as many vCPUs on physical CPUs as you want. AWS Lambda gives you ~1/14th CPU as a "vCPU" on minimum (128MB config), t3.nano has "5% baseline performance/vCPU". So VMs do not need to be expensive.
- sgarland 3y agoThe irony is that CPU is a compressible resource, and the cloud provider is almost assuredly over-subscribing customer loads. GovCloud may be different for security purposes, not sure.