Requirements: Scalability

Often times when we roll out a new server, we just go and create that server and then it's up and running. Maybe it didn't really take us much time to do that. But now do that to two servers. Now do it to 10 servers. Now do it to a 100. Now do it to a thousand. Can we replicate that? That is called scalability. When we have just a server, we don't need to be too scalable. But as we start growing as a company, if we've not created things scalable, this could be problematic.

Here we have a server. It's a small server. It doesn't do too much. It's for a small company, and we just have a person within the company that goes and maintains the server now and then. It's not a big deal because we're a small company and it's a small server.

But then we start to grow. In this case, we've replaced that server with a bank of three servers. Maybe there's some sort of high availability here. Again, not too big of a deal — we can manage this. That one person now is managing three servers. Probably doable still, and it's not that big of a deal. We're still a small company, but we continue to grow.

Now we've grown to the point where we just have a ton of servers and a ton of things to manage. And it's all based off of that one server that we set up so long ago, but we didn't set it up to really think about scalability. We didn't name it right. We didn't have the right resources on it. We didn't develop it to a point where we can expand and grow. And so now, that one person that was managing this, we have to have a team of 20 people to manage all of these servers, because we weren't scalable.

Scalable is this idea that when we create things, we create it in such a way that we can actually grow it without having too many more people. So in this case right here, let's say we focused on scalability of that server right there. We named it something that we can create hundreds of and still have an accurate naming convention. And we've managed those servers in such a way that when we deploy it, it deploys quickly. And now, rather than growing to 20 people managing all of these servers, we really just have two people that are managing all those servers. And they can do it because we've created everything in a scalable way.

How we create things scalable

Well, how do we create things scalable? We use automation for deployment and for the way we do things. We try to automate things. We design it that way. We use things like virtualization and the cloud and containers. We document things accurately. We remain organized. We communicate when things change. We implement certain processes and we implement technologies. This makes things much more scalable. And now when we grow as a company, we don't have to grow our IT department linearly with that growth. Instead, we grow just slightly more as we bring on more and more resources and more and more services, because we created it so it's scalable.

Manageability versus scalability

Now, manageability and scalability are two separate things. Manageability is, if we roll out a server or a service or a product or software or whatever the case may be, making sure that we can manage that, that we have the resources to manage whatever service that is. We might not even make it scalable, because it might be just a one-off and it doesn't make sense to put a lot of time and effort into this one service. We just want to make sure that it's manageable. Versus scalable is this idea that things can scale quickly, and we use things maybe like automation to do that.

And so what we can do is, if we don't use automation, we could just throw more resources at it. We could hire more people, so that as we scale we can do it with just more people. So there are other ways that we can scale, but really it's a subset of manageability a lot of times, because scalability means that we can quickly do that without adding a lot of headcount, without adding a lot of people — that we can scale quickly with the resources that we already have.

Vertical and horizontal scaling

There is two types of scaling. There's a vertical scaling and there's a horizontal scaling. Vertical scaling means that we're going to add more resources. So here we have a server right here, and let's say now we need more resources to this. And so what we do is we take that server and we add CPU to it. We add RAM. We add storage. We add GPU to it. Whatever it needs to scale, we're scaling larger. Well, that's vertical right there. We're going vertical with this because we're adding extra resources to the server we already have.

Horizontal scaling means that we're not adding extra CPU to the server, but instead we're adding more servers. And there's a lot of advantages and maybe some disadvantages to doing this. But horizontal means that we're scaling out by adding more servers and services rather than adding more CPU to a single server.

This is a good time to mention that there's also automated scaling. You can autoscale vertically, but a lot of times it's much easier to autoscale horizontal. That is, maybe we have some servers that are turned off, but when load gets large and we need more servers to handle that load, then we turn these servers on. They come on and then we balance it out. And then when the demand for these servers drops, then we turn those servers back off. So we can turn them on and off depending on what the demand is.