elastic and scalable

10 October 2016 · Filed in Infrastructure

Following on from my article about pets vs cattle, we shall go into more detail about what it means have an elastic and scalable application or service.

Is my application scalable?

The first test to answer this question is, does it run on more than one server - and work. This is not a trivial question. One of our clients has a website sitting on two servers behind a load balancer ( a network server that shares the load between servers based on a set of rules). The load balancer was set to a 'sticky' configuration. This means that the customer visiting the website would always be served by the server they originally talked to. However, in this case, should that server not function, die, develop a fault or otherwise become out of service, the customer would find themselves directed to the other server (fail over). Sounds good, until we tried it. When the fail over happened, the server didn't 'know' the customer and asked them to log in again. Not very seamless!

We worked with the developer team to alter the code of the website so that the servers would play nice together. In this case it was a case of making sure shared session data ( who the customer logged in as) was available to both (or all) servers delivering this application. After making the necessary changes and testing, our customer was ready to deploy to production with the side benefit of being able to switch off 'sticky sessions'. These servers however were fixed. There was always two and you could say they were pets.

Is my application elastic?

Elastic applications go one step further. Imagine the marketing manager has just told you they are running an advert for this application on TV tomorrow. With so little warning, there isn't much that can be done but hope that two servers will be enough to cope with demand. If they are virtual servers, you could arrange for them to be upgraded with more cpu and memory (Vertical Scaling).

With some automation however the answer is very different. Another of our clients automate the build of their servers (with our help). This means that on demand or a schedule, a new server is created and built from scratch by a computer following a set of instructions. This means the application can be elastic and autoscale. With the same information above, everyone can rest easy knowing that should the monitoring detect a higher demand, more servers (usually one at a time) will be built and added to the load balancer automatically or it hits a predetermined limit (so the internet doesn't put a hole in your budget). The monitoring also checks when a server has been idle for a programmed time limit and will remove and destroy a server (virtual servers don't feel a thing), until the configured minimum number of servers is reached.

I hope this article helps show the benefits of having your applications elastic and scalable. Please contact us should you want to learn more.

Previous Post: pets vs cattle Next Post: Automation (Puppet, code and schedules)

Tags: automated build · autoscale · elastic · monitoring · scaling