In the past 20 years I have often found myself looking for just the right technology tool to solve a specific problem. Most often I have been able to find something to fit the bill, but not the sought after, best-of-breed solution that promises to solve all the world’s problems. Sometimes I wonder if it would be possible to find the right combination of tools to create world peace, end world hunger or end global warming. Obviously I’m being facetious, but the problem is this approach of finding specific tools to solve symptomatic problems remains the same as it did twenty years ago. By the time you assemble all the disparate tools to create Utopia, you realize you actually have Frankenstein. Too many tools, like too many cooks in the kitchen, can make success untenable with too much to set up, too much complexity, a non-global view and oftentimes fractured ownership. Not to mention that this approach oftentimes makes solving the root cause of the problem difficult.
I am not unique in finding that he best-of-breed, point product approach has become untenable. Most of us in large enterprise organizations have experienced the same thing. The move to the cloud exacerbated this because oftentimes the new buyer and application user did not know where the functionality he was used to and needed was housed. The allegory coined by Google, AWS, and Facebook that it is good to experiment and good to fail did not help. The good news is that I think that the idea is good to succeed and ideal to save money. Sometimes it pays to experiment and try new untrusted things.
To illustrate this point, lets focus on one product that packs a lot of key features we can all use: the ADC. I’ll focus on functionality that is most interesting to DevOps folks, but if we spend enough time studying the problem it becomes clear this case is for many different requirements. We have a lot of the functionality we require already in tolls or it is simply an add-on feature. Keep in mind the third best tool optimally integrated into the environment and easily managed is usually better than the “best” tool poorly integrated and hard to manage.
Let’s start with tools to optimize migrations to the cloud:
Migration Tool– When you don’t want to rebuild a network component’s entire configuration because you’re only moving one, use a migration tool. In the case of Radware ADC for example, you use a simple click-through wizard to move single VIPS/Apps with only the associated configuration. Moving apps between clouds or data centers is a few minute process, both from a decommissioning and set up point of view.
Using Gateway Functionality to facilitate change and mitigate performance risk- Two truths here: 1) Everybody plans on converting HTTP1 apps to HTTP2, but we seldom have the time especially on older apps. 2) One of the biggest fears when moving from a private (controlled) data center to the public cloud (uncontrolled) is degradation of performance. One simple answer is to use a traditional ADC’s application gateway functionality to deliver enhanced functionality. In this case HTTP2 functionality to give enhanced performance without incurring the development time. This enhanced performance capability should go some way to offsetting the performance risk fear.
Proxy bypass – The cloud can mean many things, but when we are talking about SAAS apps we often don’t take into account some of the unintended consequences; for example, now when we are using an internet security gateway we go from having a reasonable number of concurrent (how we are licensed) active internet users to multiple, always-on, per-user internet connections. In some cases, this can increase spend on the internet security gateway front exponentially. The answer? SalesForce and Office 365 are not like other internet sites. In many ways they are extensions of our own secure internet zones. We can sue our already existing devices like SSL inspection engines to bypass the internet security gateway for that traffic, thus keeping our licensing requirements more reasonable.
Tools to monitor application performance:
APM- Many a DevOps team has found the need for an SLA manager ever more important especially in cloud environments where the infrastructure is not owned. Few of these DevOps folks realize that a robust SLA manager already exists in most ADCs. In fact, it is the ideal spot for an SLA manager, especially since in most cases the ADC manipulates the application session to increase performance and limit latency. Another key point is that ADC-based SLA managers are simple to configure, almost point-and-click. The kicker compared to things like New Relic, is they are very inexpensive from an acquisition and support point of view (are they equal tools, no, but do you get the key functionality you are looking for … most of the time yes, and most importantly a next-gen ADC like Radware is capable of taking action when SLAs are breached in order to correct the situation).
Tools to optimize application deployment agility:
Application delivery optimization- Agility and time to market are key in today’s cyber world. Why spend the time optimizing each and every application you build? Use an optimization gateway that is capable of fingerprinting every incoming device, browser and internet type, and then customize an optimized user experience.
Virtual patching– Many of us are at the point in our application development cycles where we roll out live updates multiple times a week. But what happens when/if we make a mistake? Wouldn’t it be nice if we could roll out a virtual patch to fix that problem as opposed to having a fire drill reprogram and rollback? Most of our WAFs can do virtual patching, which is priceless in a pinch.
Gateway functionality – Things like SSL inspection, HTTP2 Gateway, IPv4/v6 Translation, application optimization, etc. can be used to reduce development time, increase app performance or enhance server capacity.
That concludes this installment of marrying the business need with technology drive, join us again soon for part 5.