The Evolution of Deploying Node on Servers and Platforms

Hi, friends, welcome to my talk. The title for today is the evolution of deploying Node on servers and platforms. My name is Shedrak Akintayo. I am a developer relations engineer at Platform Message. I also do technical writing and I like to build communities, which I've done with Facebook Devs, Open Source Community Africa and DevRel community Africa.

So the table of content for today is we're going to be talking about how Node is deployed over the years in various forms. So how it is deployed on a server in a garage and how Node has been deployed on monolith servers, how Node has been deployed on a platform as a service and how Node has been deployed on containers. Then we'll do a quick rundown of how Node has been deployed on serverless and cloud function or function as a service. So let's get into it.

So the first thing I would want to highlight is that deployment is not easy. Trust me, anybody that has spent time working as a DevOps engineer deploying Node.js over the years, it's not as easy as it is. But thankfully, as Node.js evolves, the deployment becomes even easier. So thanks to the evolution of Node.js.

So the first thing we'll be talking about is Node deployed on a physical server in a garage. So basically building your own server. So before everything else, Node used to be deployed on a server in a garage actually. So the pros of it basically is that you have a dedicated Node server for just your application. So you have a lot of bare metal for your application. You can clone through your Node environment. To an extent it is secured because you handle everything that has to come with security which is a really good thing because you do not have to depend on any service provider. Whenever a provider is down, you don't have to worry about it. So this is how it was deployed basically. Node can be deployed on a physical server in a garage.

Next up is the cons. So it gets too expensive to set up. You know the manpower, the technical expensive to set up. Another one is it gets very stressful to manage because you are doing all the work yourself. The engineers are having to do all the work themselves. So this is another issue. And it's harder to optimise because most of the work is being done by you and your team, most of the part.

So handling the optimisation by yourself gets very, very tasking. So the requirements then, at the time where to be deployed on a bare metal, even though it's still being deployed like that now, not just as much as it was before. You need the early versions of Node. You need a lot of GPUs, you need RAMs, you need CPUs, basically, to deploy Node on, to be the Cisca server for yourselves, to deploy Node on it.

So the next stop is deploying Node.js on a monolith server. So basically, a monolith server consists of all parts of an application deployed on a single server, from the back end to the static part of the application. The pros of this particular way of deploying Node over the years is that the entire path is in a centralized server, and it's always a great choice to deploy Node as a monolith, so you can have all your applications in a single server, which is really, really great, because you can see every single thing you need to see, you can see all your applications coupled together. The cons is, as the application gets larger, it becomes difficult to update, and the memory requirements increase over time. For the requirements, you need a hosting server and NodeJS 12 upwards.

The next stop is NodeJS being deployed on a PaaS. So PaaS, Platform as a Service, also known as PaaS, involves, it provides a broad set of cloud-based application infrastructure and middleware resources via the cloud. An example of PaaS that you might have come across is Platform SH. Platform SH is quite different, because you can deploy a PaaS on containers, then Heroku, Vercel, Netlify, et cetera. The pro is NodeJS can be deployed faster, then you can also easily add additional data services to your Node application, then the cons is it can be very, very expensive at scale, and vendor locking also is another issue. The requirements to deploy Node on a PaaS are dependent on what the PaaS provider specifies generally.

Next up is deploying Node on a container. Now this is currently the most used way for deploying Node generally. A container is basically a lightweight piece of software that provides a run-time environment for your application. So platform.sh uses PaaS, but you get to deploy on container. It's basically a PaaS that you can use to deploy it on containers in Kubernetes, and also Docker. The pros, it makes your Node app lightweight and resource efficient. It's easy to manage and control your Node infrastructure. Adding external data services with your Node app is easier. Now the cons, it can be very expensive as still, and you also have issues with vendor locking. Whenever a vendor has issues, then it becomes a problem. Requirements to deploy Node on a PaaS are dependent on the container provider. That's the PaaS, the container provider, whoever is providing the container services. You also get to control what Node version memory disk size of your application.

Now, serverless is what we are basically going to talk about next. Serverless basically involves deploying your application without worrying about servers.

Servers are still present, but it's on a PaaS basis. It also uses functions as a service, which is a serverless way to execute modular pieces of code on the edge. Example is which we've basically seen is AWS Lambda, which is one of the most important providers of serverless, and serverless.com.

Another pro, a pro of serverless, is lower costs. You get to build faster. Go to market becomes very, very faster. The backend code is simple because it's mostly in chunks as modular. It basically uses modular programming, which functions, so every part of your backend becomes a function.

Another part is, the cons of serverless, basically, is vendor locking, which is one of the major problems of serverless, and it's unsuitable for long-term tasks. In terms of scaling for a very, very long-term task, serverless doesn't really do well because it becomes a problem, basically, and it becomes very expensive, even though they sell it as something that provides lower cost.

So that's basically the end of my talk. I hope you've basically been able to know how Node.js have been deployed over the years, from point A to point B, from on-premise to containers, from monoliths to serverless. So my name is Chedrak Akintayo. I am a Developer Relations Engineer at Platform Message.