New Service – Multai Load Balancer

multai-full

Welcome, Multai Load Balancer.

As AWS and other Cloud vendors move to become the new normal for companies today, there is a need for new approaches ensure your applications are safely and efficiently delivered to your clients. Most load balancers available on the market today are either very basic or costly services, or, were built from legacy technology and adapted to fit into the cloud. We here at Spotinst understand that your applications are constantly evolving and you need support for wherever you applications are hosted.

Introducing the Spotinst Multai Load Balancer (MLB). Layer 7, Application Delivery Load Balancer that was designed from the ground up specifically for providing the same level of load balancing experience regardless to the hardware or cloud vendor that your applications run on, combined with  the kind of analytics you need to ensure you are effectively delivering the experience your customers require. MLB supports hybrid deployments, meaning you can have MLB load balancers located on prem, in AWS, GCP, and Azure all at the same time. Let’s dive into some details below.

 

Groundbreaking Features

  • Intelligent routing of traffic to ensure lower data transfer costs (if an MLB instance is in the same AZ the traffic will be routed to this)
  • HTTP translation layer, browser requests can be HTTP/2 and your application can be an older version.(Support HTTP/2 & HTTP/1.1)
  • Websocket support and advanced routing with multiple ports on the same host
  • Automatically scales to demand. MLB will automatically scale up to meet demand as needed
  • Application level health check via URL endpoint rules
  • Advanced logging provides the ability to record all requests and store them for analysis
  • Robust SSL support including decryption, certificate storage, and end to end encryption to back end servers
  • Circuit breaker to ensure data integrity and resiliency, in case of any network error, MLB retries to spill over the requests to different nodes
  • The “Roshemet” service can watch for changes in the back end and automatically apply a new configuration as needed. Further simplifying your container infrastructure

 

Real World Data Analytics

When we first started coming up with the idea for new load balancer we knew the bare minimum would not be sufficient. We knew even if we were able to deliver a new product at a lower cost this still would not be compelling enough for most users to switch to MLB. This is why we integrated sophisticated analytics directly into our product and delivered to our clients in a slick dashboard. With MLB you are getting amazing data for your applications such as:

  • Real time application latency response time with metrics
  • Ability to identify latency per host, per target group or by cloud provider
  • Application HTTP response code reports per hosts and cloud
  • Real time GEO analysis – Where does the traffic originate
  • Distribution of operating system, user device and browser
  • Tracking user fingerprint (unique users)
  • Latency Distribution graph, which is an aggregated and more clearer view of percentile graph, so you will understand how your application really acts

 

MLB Terms

  1. Deployment: A Load Balanced application managed by the Load Balancer.
  2. MLB Node: A server launched with the MLB Image. These MLB nodes can be launched either on prem or in your cloud provider. Once your hosts are launched you can easily manage your MLB from the host MLB console or via API. This approach ensures ease of use and availability for your Load Balancers.
  3. Load Balancer: A load balancer is an entity that acts as a reverse proxy and distributes network or application traffic across a number of servers. Load balancers are used to increase capacity (concurrent users) and reliability of applications. With MLB you can have multiple servers hosting the MLB for increased reliability and load. Each MLB server can host multiple load balanced sites.
  4. Routing Rule: Url-Based/Header-Based rule to route requests to target groups. (e.g. /app1, /app2).
  5. Target Group: The logical group of servers to get traffic from a RoutingRule.
  6. Target: The private ip and port that will get the actual traffic through the load balancer.

 

How does it work?

We provide you with a server image that can be deployed in any cloud provider or even in your own datacenter. Servers that are launched from this image act as MLB nodes. The MLB is then completely managed from a simple to use console that acts to control and configure your MLB nodes to load balance your applications. MLB is intelligent enough to ensure that MLB nodes that have more compute resources will receive more traffic than MLB nodes with less compute resources.

1

 

Once your MLB nodes are up and running, you can start creating Balancers for your applications. Each balancer will have it’s own ID, CNAME, and analytics that you can view in a powerful dashboard. You can view your request counts, average latency, number of targets hosting your application, health of your targets, HTTP 200 requests, HTTP 500 requests, and load balancer 500 requests.

2

View metrics for each application in the dashboard.

 

3

Drill down to individual metrics for for more detail. You can click and drag a portion of the graph for more granular information.

 

Filter by TargetGroup or Drill Down to a single Host!

MLB can load balance your application targets regardless of the provider or geographical location. As you can see below, application servers are hosted in Azure, AWS, as well as an on-prem datacenter. Each grouping of application targets is referred to as a “TargetGroup” of your application. You can see your application metrics based on each TargetGroup and even drill down to individual servers!

4

Application metrics are filtered by the Azure TargetGroup above.

 

5

All the metrics available to you can easily be filtered all the way down to a single application server (This is not possible with ELB!). You can easily determine which application servers are behaving unexpectedly based on the latency, and 400/500 request counts.

 

Advanced Analytics

You can browse additional analytics by tab. Below, the Overview tab displays a graph of latency by IP range, request distribution by endpoint, 500/400 errors by /path and individual endpoints. With this advanced analytics you can very quickly see what instances or application paths are having problems.

6

 

Launching a new application and wondering where your end users are located? The Geographic tab shows you exactly how many requests are being made by country.

8

Find out where your users are by country in this simple global map.

 

View Metrics by Path (This is a game changer!)

Traffic Source shows you the number of requests for each path within your application. Quickly find out what paths are most popular and find metrics like min/max/avg latency per path.

7Quickly find out about your most popular Referrer URLs are located via Traffic Source

 

mlb-9 mlb-8

You can quickly modify the polling period from minutes to days. This allows you to easily analyze your data within a time range to understand how your application is performing.

Conclusion

We’re very excited about our new MLB product and we think you’re going to love these new features.

Interested in seeing it in action? Sign up today!