Serverless Computing

Hey everyone! Today I want to talk about a cool type of technology that's been around for a while, but has only become popular in the last few years: serverless computing.

A server is just a computer that is designed to, well, serve. It runs processes and services when asked to by other computers. For most servers on the internet, your computer will make a request, find the server that matches that request, and the server will respond with the content you've asked for. You can even set servers up on your home internet network if you want to (though your internet provider may not appreciate it). Traditionally, servers are always on and listening for traffic. If the server is off or not functioning correctly, that becomes time that any content hosted on that server is unreachable, or "downtime."

Serverless computing, on the other hand, doesn't lock your code to one specific, always-on server. Instead, a vendor such as Amazon will maintain a point of access where you can call your services, and then start up only the necessary amount of resources to execute that service. This means that all of the worries that go along with managing servers are no longer an issue, because the vendor takes care of all that work for you. It also means that a service will never get slowed down by lots of processes running at once, because it can dynamically allocate resources when necessary.

At Punchmark, most of our infrastructure uses a traditional server structure - we have multiple web servers and database servers, each always running and ready to respond to traffic. There are benefits to this. Finding and fixing errors is easier, and the single server is generally faster for larger and more complex processes. Because our web servers are nearly constantly serving content, it makes sense to always keep them running.

Some of our infrastructure, however, is badly suited to running on traditional servers. Servers are expensive, and not all parts of our platform are being constantly used. If we were to host these on our normal servers, we would essentially be paying extra to host them even when we weren't taking advantage of them. In addition, services that take a lot of processing but don't run frequently could cause slowdowns on our web servers when they do run, so moving them serverless allows us to allocate more resources to them when necessary, then scale back when they're finished.