Economics of Load Balancing When Transitioning to the Cloud
One of the concerns I hear often is that application delivery controller (ADC) licensing models do not support cloud transitions for the enterprise or address the business needs of cloud service providers that have a large number of tenants.
Of course, there are many models to choose from – perpetual pricing per instance, bring-your-own license (BYOL), consumption and metered licensing models by licensing by CPU cores, per-user, by throughput, service provider-licensing agreements (SPLA), to name a few. The biggest concern is the complexity in licensing of ADC capacity. In a cloud environment, the performance profile for a particular instance may need to change to accommodate traffic spike. The licensing infrastructure and automation needs to accommodate this characteristic.
Traditionally, load balancers were deployed as physical devices as a redundant pair supported by perpetual pricing, a non-expiring license to use an instance, whether it’s hardware, virtualized or in the cloud. The customer has no obligation to pay for support or update services, although they are offered at an additional yearly cost. As virtualization took hold in the data centers, ADCs began to be deployed as virtual appliances and started supporting subscription licensing model – a renewable license, usually annual or monthly, that includes software support and updates during the subscription term. The license is automatically terminated unless it is renewed at the end of the term. Now, as applications move to cloud, ADCs are being deployed as a service in the cloud and consumption-based pricing is becoming common.
Evaluating Choices: The Problem of Plenty
There are many licensing models to choose from – perpetual , subscription, consumption/metered, so how do you decide what to choose? The key is to understand what problem you’re trying to solve, identify the *MUST* have capabilities you’d expect for your applications, and plan how much of the capacity you’d need and then do an apples-to-apples comparison.
Understand the use case
Let us consider a cloud service provider (CSP) tenant onboarding as an example. The provider offers service to its tenants (medium and large enterprises), which consume their own homegrown applications and those offered and hosted by the CSP.
For example, a CSP whose tenants are hospitals and physician networks offers patient registration systems as a shared SaaS offering among multiple tenants. Each tenant has varying needs for a load balancer – small ones require public cloud-based ADCs, whereas mid-sized and large ones have both public and private cloud solutions. Some of the larger tenants of the CSP also require their application services proxied by hardware ADCs due to low latency requirements. Self-service is a must for the CSP to reduce cost of doing business and so it automation and integration to support the tenants that administer their own environments.
Based on the use case, evaluate what functionality you’d need and what type of form factor support is required
CSPs are increasingly concerned about the rapid growth and expansion of Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform into their markets. Hosting providers that only provide commodity services, such as co-location and web hosting, have realized they are one service outage away from losing customers to larger cloud providers.
- Cost predictability for the CSP (and tenants)
- The ability to offer value-added advisory services, such as technical and consulting opportunities to differentiate
- Self-service to reduce resources via the ability to automate and integrate with a customer’s existing systems
- Solutions that span both private and public cloud infrastructure and includes hardware
For the CSP onboarding use case above, from a technical requirement, this breaks down to: Self-service, ability to create ADC instances of various sizes, automated provisioning, support for Ansible, vRO and Cisco ACI. From a business perceptive, the CSP needs to offer a host of solutions for their tenants that span cloud, private and hardware based ADCs.
Once you understand the use case and have defined functional technical and business requirements, it’s time to review what kind of capacity you’ll need – now and in future. You may use existing analytics dashboards and tools to gain visibility into what you consume today. The data may be your HTTP, HTTP/S, UDP, SSL certificates, throughput per application at peak, connection and requests per second. Based on your growth projections you may define future needs.
Compare Available Options
The next step is to look at the various vendors for the performance metric that’s important to your applications. If you have a lot of SSL traffic, then look at that metric as a cost/unit across various vendors.
Once you have narrowed down the list of vendors to those that support the functionality your applications MUST have, now it’s time to review the pricing to be within your budget. It’s important to compare apples-to-apples. So based on your capacity and utilizations profile, compare vendors on your short list. The chart below shows one example of comparison on AWS using on demand instances versus Radware Global Elastic Licensing subscription as a yearly cost.
As enterprises and service providers embark on a cloud journey, there is a need for simpler and flexible licensing model and infrastructure that eliminates planning risk, enables predictable costs, simplifies and automates licensing for provisioned capacity and enabled the ability to transfer capacity from existing physical deployment to cloud to realize savings.