Resizing an instance¶

If your instance is not sized correctly, wether it has to little resources or to much, you are able to resize it.

The typical situation might be that your load has increased (maybe you have added customers to your service or maybe there is a temporary influx in visitors during for instance a campaign) to a point where your application is behaving sluggish (or not working at all).

Methods¶

Resizing (which is the Binero cloud way to scale up) is done by switching flavor . You have four main options for how to resize an instance. Each option has its pros and cons:

• The cloud management portal is very easy to use and will get a user with limited prior knowledge from A to B quickly. The tradeoff is that advanced features are not always available.

• OpenStack Horizon is the web interface included in OpenStack. Some advanced features might only have a GUI implementation here.

• OpenStack terminal client is a command line implementation of OpenStack Horizon giving terminal oriented users a (very) quick way to access the cloud. The learning curve is steeper than the GUI implementation but the workflow will be very efficient.

• The API is the full OpenStack REST API. Its intended for users that are either writing infrastructure as code or using a third-party application (for instance Terraform) that needs to reach the cloud provisioning layer directly.

Scaling methods¶

There are several ways to scale your application. The two main ways are scaling by increasing performance by adding more CPU/RAM (which is done by resizing) or scaling by adding parallel performance (which is normally done by some sort of load balancing).

Scaling up¶

Scaling up (or “vertical scaling) is very easy to use as it just requires a resize of the instance and / or volumes, to instantly add more resources (with no need to change the installation).

While being easy to implement (as its purely reliant on the infrastructure platform and not the application design), the downside is that there is an effective performance limit before diminishing returns on adding additional performance would kick in. What the limit is, depends on the use-case.

Scaling out¶

The opposite method is adding parallel resources (for instance additional instances) and using load balancing) to distribute load between them, this is called “scaling out” or (“horizontal scaling”).

For systems which are expected to need to scale to many times their initial size, this method is likely required. While there are normally bottlenecks in scale out systems as well, they are generally related to the amount of parts the system is broken up into.

A single application (a monolith) may for instance still be able to scale well by using multiple load balanced web servers as frontends and multiple replicated database servers as backends. The web servers will scale pretty much indefinitely but the database would bottleneck at some point (depending on solution).

The same system broken into micro services would scale by adding additional containers to the parts of the system that needed them. A single micro service would (likely) not hit a performance ceiling given the proper limitations in its scope. The performance of the application as a whole is made up of the performance of its micro services.

While containerized microservices is the modern approach to application design (also providing additional management upsides), systems that are not expected to grow to users in the millions, might still work well with only load balancing or on a single server, that could be scaled up.