Cloud Bursting using A10 Lightning ADS and AWS Lambda

 Cloud Bursting

Cloud bursting is an application deployment model in which an application that normally runs in a private cloud or data center “bursts” into a public cloud when the application needs additional resource (i.e. computing power) and use Cloud Computing for the additional resource requirement.

Think of a scenario in which an e-commerce application is running in a data center and suddenly a few items became popular and a lot of users start checking them.  Suddenly traffic starts building on the website and response starts becoming slower because of the load on servers. The only solution now is to scale the server infrastructure by provisioning more servers to handle the traffic. But provisioning new server on-the-fly is not an option in data center. Public clouds come as savor. The additional server can be launched in a public cloud like AWS and additional traffic can be routed to that server.

So, the Cloud bursting relates to hybrid clouds. The advantage of such a hybrid cloud deployment is that the resources become available on-the-fly and an organization only pays for extra compute resources when they are needed.

Cloud Bursting Architectural Model

The cloud bursting architecture establishes a form of dynamic scaling that scales or “bursts out” on-premise IT resources into a cloud whenever predefined capacity thresholds have been reached. The corresponding cloud-based IT resources are redundantly pre-deployed but remain inactive until cloud bursting occurs. After they are no longer required, the cloud-based IT resources are released and the architecture “bursts in” back to the on-premise environment.

The foundation of this architectural model is based on the automated scaling listener and resource replication mechanisms. The automated scaling listener first determines when to trigger resource replication for deploying the server in cloud.  Next, when the additional resources i.e. servers are ready in cloud, it redirects requests to those servers along with the on-premises servers.

Solution Components

In this solution, we shall see how we can burst into AWS environment with minimal cost. A10 Lightning ADS will work as scaling listener and AWS Lambda functions will work as replication mechanism for this solution. AWS API Gateway will be required to invoke lambda functions from ADS.

In steady state, A10 Lightning ADS will front-end the application traffic and will monitor for server latency. An application server instance is expected in the AWS account in stopped state so that it can be started by the lambda function as needed.

Following presentation was done in AWS Bangalore meetup:

Cloud Bursting with A10 Lightning ADS from Akshay Mathur

Demo

Challenges with Application Visibility

After I create a web application and make it generally available to people for use, the first and foremost challenge that comes in front of me is to find out number of servers to be deployed for sustaining the incoming traffic. For determining number of servers I need to know the traffic that is landing on my servers. Knowing aggregated numbers does not help here really because the traffic does not come at a constant rate. Understanding the traffic pattern is interesting. To start with I need to provision servers based on maximum load unless I have a solution that automatically scale my servers based on traffic.

Once I make sure that all the traffic is being taken care properly, I start worrying about the user’s experience. The very first experience builds based on how much time users need to wait after a click to the page load. I majorly divide it into two parts: one is the response time from server and other is the time taken by browser in rendering.

When everything looks good at gross level, time comes to drill down deeper and figure out what areas (URLs) of the applications are being used more than the others. Typically these are the critical parts of application workflow and require special attention for availability as well as response time. When I see that traffic to some URL is going very high, I consider dedicating servers for that traffic and try optimizing that code path.

When high priority infrastructure items are taken care of, I would like to know more about users. First point is how many users are visiting, they are new or returning, after how much time they return, how many pages they look or better what pages they visit in what order, what browsers or devices they use, from what they come, how they are distributed geographically etc.

Next I want to figure out how much of the traffic is coming from non-useful bots so that I can block that traffic somehow and focus on the real traffic. I would also like to detect (as well as prevent) traffic sent with the malicious intent by an attacker. The malicious intent may be DDoS kind of attach for impacting availability of my application or a try to steal data or just an attempt to harm the user interface.

When I come up with new version of my application, I would like to compare its performance with the version currently running. Only if I find the performance acceptable, I would like to expose the new version to all my customers.

Giving the high level visibility into these areas is not enough. When something goes wrong, the tool providing me application visibility should also help me debugging the issue and allow me to drill down to the individual request level.

Google Analytics is generally known to fulfil most of application visibility aspects. However, that does not satisfy the need because of following reasons:

• Google Analytics only capture the traffic in which HTML page is accessed. All my ajax calls and requests to other resources are not included
• Google Analytics gets triggers only when JavaScript on the page is executed. Access of the page by bots in not included

So what I see in Google Analytics is the subset of the traffic hitting my servers. When reports say that the bot traffic amounts to more than 30%, I can’t accurately plan based on Google Analytics number. Also Google Analytics being a client side JavaScript tool has no understanding of my deployment infrastructure and neither helps me drill down for issues not help me scale.

A piece that is in traffic path is load balancer. But load balancers like AWS ELB, NginX or HA Proxy provide very limited visibility into traffic and are not really helpful from insights point of view.

[The post has also been published at Appcito Blog]

Techniques for Scaling Application with Security and Visibility in Cloud

When the traffic to your web application serves increase, you need to do a better job than just horizontal or vertical increase in servers.

You not only need to bring the mind shift on the software architecture side and make the application scale-able at various layers but also deal with the challenges with infrastructure optimization.

In the TechNext meetup Pune, the topic was discussed at length carefully observing the challenges, requirements and possible solutions at every stage of growth.

The discussion was around following topics:

• Architectural mind-shift for scale
• Infrastructure challenges with traffic growth
• Load balancing
• Content switching
• Content optimization
• Traffic insights
• Security against data theft
• Protection against BOTs and traffic surge
• DDoS attack prevention
• Continuous delivery

Techniques for scaling application with security and visibility in cloud from Akshay Mathur