Shared Servers, Virtual Private Servers, and Serverless Computing Explained

Shared servers, your ‘basic’ website hosting option, with providers like GoDaddy, HostGator, and Dreamhost. With a shared host, you upload your files, link your domain, and your website is live and ready to go.

The provider handles everything on the backend side. Your website is run off of servers that run other websites as well. Usually, all you have access to is a control panel, like WordPress Admin, Plesk, or Cpanel, making it an easy but limited option to manage a website.

Shared hosts are more restrictive with bandwidth limits than the other two types that we’ll cover. These limitations are often listed as “visitors monthly” to make the limitations of your plan more clear to the average user.

This is likely the best option for an affordable website that sees up to a couple thousand visitors a day, depending on your needs and plan.

A Virtual Private Server (VPS) is a complete virtual machine in which you run your server from. You will have complete control over this virtual environment, including your choice of OS and configuration. This also means you are responsible for a lot more than you would be with the other two types of servers we are covering today. Even if you selected the handy pre-configured application servers (like WordPress), you’re on your own if something went wrong, or it’s not secure. As long as they’re meeting the uptime guarantees, your VM is reachable and has a consistent network connection, they’ve met their SLA.

You’ll be able to choose your operating system from their list of supported versions (there’s usually an upcharge from Windows Server, if that’s your thing), or for most providers you can also upload your own image via iPXE.

The pricing is by the month or hour. The ones that provide hourly billing are typically the ones that have an API you can use to deploy them automatically. You’ll be renting an amount of memory, disk space, and CPU “cores”, and I say cores loosely because it’s more like threads, not whole dedicated cores. In most cases, they are provisioned in such a way that if everyone went full throttle all the time, it would not work out. This means that you are not allowed to constantly pin the CPU, and you’ll be in trouble with your provider if you have high usage on a product that’s not meant for it.

This is where ‘dedicated’ or ‘bare metal’ options come in. Sometimes it is what you’d think—remoting in to a machine that you share with no one (which is not a VPS technically), but often you are still running on top of a hypervisor. Sometimes you’re still getting half or less of a physical server—it may be cheaper for them to run a beefer server with high core count CPUs (sometimes multiple sockets) and an incredibly high amount of memory than several smaller servers.

Either way these are the options you’d want if you really want to stretch your legs with the cores you are provided.

Much like how coffee you bought instead of making yourself is the coffeeless option to get a coffee, the naming is really the result of new “cloud” related buzzwords coming out of the tech industry at such a density and velocity that they’ve reached critical mass and we’ve ended up with a misnomer like ‘Serverless Computing’ that transforms into an oxymoron when you try to explain it since that computing is done on a server.

The model for Serverless is straightforward—you provide your code, and they run it on their infrastructure.

It sounds really simple (and it is), but the bigger picture is the idea of “focusing on your code”, and not needing to worry about infrastructure when building and launching a web or mobile app. With this, you get effortless scaling, as there’s no real upper bounds for how much it can handle, you’re just billed for usage.

Let’s talk about billing for a second. Serverless is heralded everywhere as the economical option for medium to large scale apps, but that can be incredibly misleading. If you’re not careful, migrating to Serverless can cost you orders of magnitude more with the wrong use case. You’re usually billed for usage time, function calls, and networking, among other fees. It can add up fast.

Going with Serverless means you may also run into a ‘vender lock-in’ problem in the future if you try to migrate away from the platform you’ve chosen, as a lot of these systems are proprietary. Migration is always possible, but it can be more difficult with Serverless.

It does have a lot to provide you—the hands off approach, less backend development time, incredible reliability from vendors, and effortless scaling, but the choice to move to Serverless should be made carefully.

   
We hope this blog has helped clear up these three types of servers and what they’re for. If this is a bit overwhelming, perhaps it’s time to call the professionals. CodeClouds offers dedicated development teams for almost any type of website or mobile app—and yes, we’ll cover the server setup as well.