From Zero to Fully Provisioned Application in Minutes – Part 1
Imagine you want to rollout a new business application in your organization? How long does it take? How many steps are there along the way?
If we think about it, rolling out a new application usually includes the following high-level steps:
- Purchase servers and allocate storage
- Purchase ADC
- Configure network and rack ADC
- ADC configuration research
- Configure ADC
- Application pre-production testing
- Move from testing to production
In this article I would like to focus on steps 1 through 3. In later articles I would cover the rest of the steps.
So if we look at steps 1-3, we know there are alternatives today for the 1st step using virtualization technologies, which remove the need to actually purchase servers but rather now we provision servers. This reduces the time it takes us to actually rollout the application itself as well as immensely reduce the costs associated with the rollout.
But what about steps 2 and 3? Are we still stuck with purchasing a physical ADC and then unpacking it, racking it and connecting the cabling to it? There must be a better way to do this.
Well there is. And not only can you now do it faster and simpler, like provisioning a new VM, you also don’t need to compromise the benefits of a physical application delivery controller (ADC) offering you guaranteed performance.
So how do we benefit from the speed and simplicity of virtualized technologies while also benefiting from the performance of physical ADCs? The solution is Radware’s virtualized ADC solution called ADC-VX.
Using ADC-VX our customer can now provision new ADC instances in seconds, where each ADC instance (we call them vADCs) is fully isolated from neighboring instances, and it has all the capabilities and characteristics of a physical ADC – dedicated resources (CPU, RAM, SSL TPS), own OS and config file, own routing tables, and L4-7 load balancing features.
But it doesn’t end here; using our multi-dimensional OnDemand scalability approach our customers can add more and more vADC instances on the same ADC-VX hardware as they rollout new applications. Take other ADC solutions for example, there you either purchase more ADCs for new applications, or share a single ADC for each application, both solutions have their own down sides.
With ADC-VX you get all the benefits of a physical ADC which is shared for multiple applications (so cost is low), with the benefits of a dedicated ADC for each application (so reliability and SLA are high).
Going back to our multi-dimensional OnDemand scalability approach, adding more vADCs on demand is just one dimension. Other dimension include adding capacity on demand to the whole ADC-VX solution or for each vADC, so even if you decide to scale the performance of your application, with our solution all you need to do is add capacity to a vADC and in seconds you have a fully fledged ADC that is ready to support your application. Again, if we compare to other competing solutions, there you now need to replace your ADC solution to support more capacity. Here it is much simpler.
But once more our multi-dimensional OnDemand scalability approach goes even further with the ability to add advanced features such as global traffic redirection to each vADC separately, like you would an ADC device.
And last, once you max out the number the throughput a single ADC-VX unit supports, you can migrate the vADC to a neighboring ADC-VX where there is spare capacity without losing any configuration or performance metrics.
So as you can see, using our on-demand scalability approach combined with our ADC-VX solution, users can now really shorten their application rollout times as well as reducing the costs of rolling out a new application – all you need to do is provision an application VM and a vADC instance.
And once you want to scale the application to support more users – all you need to do is either provision another application VM or add capacity to an existing VM and add capacity to the vADC instance.
As simple as 1,2,3
Stay tuned for the next article on this topic.
Regards,
Eitan Bremler