Black Friday. 0 downtime. How Bunnyshell & Vegeta & UiPath can help

According to a Worldwide 2015 Consumer Mobile Holiday Shopping Survey, a staggering 81% of millennial customers declared they will abandon a site if they encounter bugs or slow loading times.

Thus, in order to keep their reputation unstained, online retailers must quickly expand their infrastructure and operations to meet surges in demand. While, at the same time, make sure that if anything happens, they can find a quick fix. One of the things every retailer should do to prepare for Black Friday is to test the entire site.

How many users do you think will come to your site on Black Friday? Your site’s traffic could double or even triple within 24 hours, with peak times between 6am and 10am. Are you sure your site can cope with such large amounts of traffic? Testing your website or app before Black Friday, until breaking point, will help you understand the limitations and problems which can occur and what to do to avoid such issues.

Evidence shows that 47% of customers expect a web page to load within 2 seconds or less with 40% of people abandoning a site if it takes more than 3 seconds to load. Google calculated that by slowing its search results by just 0.4 seconds they could lose 8 million searches per day.

A good tool you can use to perform stress tests is Vegeta. Vegeta is a versatile HTTP load testing tool built out of a need to drill HTTP services with a constant request rate. It can be used both as a command-line utility and a library. It has a very simple interface, and it supports multiple request targets and requests bodies to easily send a lot of varied, ‘real world-like’ traffic to an API.

You can also use Bunnyshell to quickly create multiple environments in different locations around the world and in different clouds in order to emulate a real scenario for your site.

The most basic use of  Vegeta is something like the following:

$ echo “GET http://example.com/some/page” | vegeta attack -rate=10 -duration=30s | vegeta report This will make an HTTP GET request to the URL given at a rate of 10 requests per second for 30 seconds, generate a binary report and then display it via the vegeta report command.

You will be able to see the latency of your servers in milliseconds after x time passes. This basically represents how long it would take your server to respond to requests after 10 seconds, 20 seconds, 5 minutes, etc.

With over 24,000 different devices and platforms, it is vital that your site is optimized across the board to increase conversion rates and sales. Recent data shows that more than half of e-commerce browsing and 28% of purchases come from mobile devices. Testing the functionality of your site across a large proportion of devices will eradicate any foreboding errors and is a vital part of your marketing and QA development. Do this not only before Black Friday.

One of the most robust testing frameworks out there is Selenium, definitely worth checking out. The tool is specifically designed to test web applications and websites.

Another cool way to perform functional tests is with robotic process automation tools, like UiPath. RPA tools can do some very handy things like test data and regression testing.

So we can say RPA is the next level of existing automation tools. It allows people to build a very complex rules-based process with very little software development skills. You can do all things using UI Path which can be done by Selenium but vise versa is not possible.

A few ways Bunnyshell will help you run tests easier :

An ounce of prevention is worth a pound of cure, an old saying goes. Sometimes, however, all the stress tests in the world aren’t enough to prevent your pages from slowing down or crashing, particularly during peak times like Black Friday, with huge amounts of traffic.

When that happens, your only choice in order to prevent your company from losing lots of money is to come up with a quick fix and deploy it to production without downtime.

With Bunnyshell, you can quickly deploy an upgrade of your application, such as a bug fix on Black Friday, and expect full availability during deployment. The platform can apply multiple deployment methods with zero downtime. Bunnyshell users can choose from rolling, immutable or blue-green deployments, which I will explain further in this article

Rolling deployment is a great fit for big applications composed of multiple independent nodes.

With this type of deployment, you get better fault tolerance, the ability to perform quick rollbacks, and very granular control over infrastructure overhead. You can also monitor the newly deployed nodes and the overall KPIs to ensure that only high-quality features make it into production.

Rather than updating all servers or tiers simultaneously, the organization installs the updated software package on one server or subset of servers at a time. A rolling deployment is used to reduce application downtime and unforeseen consequences or errors in software updates.

Let’s consider deployment on 3 instances, with batch number 1.

The batch number represents the number of instances that are updated at the same time. Possible values are from “1” to “n-1”, where “n” is the total number of instances.

In this scenario, Bunnyshell’s backend process would look something like this:  

In the first step, the load balancer does not send any more requests to the first instance and waits for all requests that were already initiated to finish. This is called “connection draining”.

In the second step, the first instance finished processing all remaining requests and enters deployment. Because the load balancer does not send any more requests to it, there will be no downtime for an eventual webserver restart.

Third step: Steps 1 and 2 are applied for all remaining instances. For a batch number greater than 1, for example 2, in each step we would have 2 instances entering connection draining followed by deployment.

The main problem with the “rolling” deployment is that the instances which remain connected with the load balancer may not be able to handle all the traffic that is received. The “rolling with an additional batch” deployment solves this problem by adding a number of instances running application 1 to the Load Balancer so as to ensure that at any time there are enough instances to process all requests. This is also called “extra provisioning”.

Let’s consider a scenario on 3 instances deploying with batch number 2.

In step 1, two additional instances running old app version are added to the Load Balancer. Then, two instances at a time start connection draining, followed by deployment.

After steps 1-6 have been performed, instance 3 is added back to the load balancer and the extra instances are removed with connection draining.

Immutable environment updates are an alternative to rolling updates. This type of deployment ensures that configuration changes that require replacing instances are applied efficiently and safely. If an immutable environment update fails, the rollback process requires only terminating an Auto Scaling group. A failed rolling update, on the other hand, requires performing an additional rolling update to roll back the changes.

To perform an immutable environment update, Bunnyshell creates a second, temporary Auto Scaling group behind your environment’s load balancer to contain the new instances. Then, it connects them to the load balancer, allowing it to serve traffic alongside all of the instances in the original group that are running the old configuration. Old instances enter connection draining. Once that’s done, it removes the old instances and connects the load balancer to the ones with the new version of the app.

Blue-green deployment is a technique that solves an issue which all of the previously mentioned deployments can’t, which is, having two versions of your application running at the same time and while this may be okay with some applications, it may crash others.

The method implies creating a group of new instances running version 2 of the app. In the second step, the load balancer starts sending requests only to the new pool of instances while still receiving requests that were already in progress on the old instances (connection draining). The user can also choose not to run connection draining.

This technique eliminates downtime. In addition, blue-green deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.

All the above methods would be performed differently, depending on your cloud provider. The good news for Bunnyshell users though is that all deployment types are one click away, on any cloud.

So, in the doomsday scenario of having to deploy a bug fix on Black Friday, bunnyshell.com helps you be your company’s hero. Easy. Quickly. Without opening ssh.