Marrying the Business Need With Technology, Part 3: Re-aggregating the Tools

In part one of this blog series we discussed how there is oftentimes a lack of knowledge when it comes to infrastructure technology and knowhow in the relevant DevOps teams. This is not what was intended when “Agile” moved from being a pure development approach to a whole technology management methodology, but it is where we find ourselves. One of the consequences we face because of this is that the traditional user of many technologies, the developers/application owners, know what functionality they should have but not where to get it.

This situation is exacerbated by several factors:

• Ease of procurement and perceived initial set-up is considered of paramount importance (research takes too long).
• Technology vendors have been slow to accept the fact that their traditional buyers are no longer the sole or key decision makers.
• Large clouds call “products” by familiar names but do not offer what has been considered standard functionality in these products. A good example close to my heart was the case of session persistence. When AWS first started offering their load balancer, it could distribute traffic that is true, so in the most basic sense of the word it was a load balancer. However, it was missing so many things that were previously considered basic functional requirements of a load balancer/ADC. For example, every load balancer on the market for at least a decade prior included session persistence as part of core functionality. I know AWS has added this now but it took them over two years. The reaction from the developers when they realized they didn’t have session persistence out of the box illustrates what has happened on a much grander scale with the growth of cloud. They built it themselves (if you can’t buy it, you build it). The problem is the first decision to use AWS LB was made for agility reasons. It’s quick and easy to buy, frictionless procurement from the market place with a CC…. but in the end it doesn’t save time because the developers have to do more coding to get session persistence built into the app.
• The failure by most of the analyst firms to call out the differences or specific deficiencies between technologies. A good example is WAF. The accepted definition of WAF used to include the requirement of positive enforcement. Today, as far as I know, only one cloud WAF company/offering does positive enforcement. Even Imperva, whose own WAF definition on their homepage describes a WAF as having positive and negative enforcement capabilities, does not offer positive enforcement in the cloud, thus making their cloud WAF no more effective than an IPS. At first glance it doesn’t seem like an example of disaggregating tools, but it is because the few times I’ve seen someone rave about their WAF it was not for security but because the WAF was able to virtually patch bad code that wasn’t QA’d effectively. This saved the developers hours and the application its uptime. Most developers unfortunately don’t know that a WAF can do virtual patching. I think it is incumbent on the analyses to lead the market and educate the uninformed about technology and what the different types of technology are meant to do. Today they are too often looking at market spend and deciding on product suitability/definition solely on that factor, which is exacerbating this problem. People still need the functionality, so now they have more products to accomplish the same amount of capability, but with more spend and more complexity.

[You might also like: Marrying the Business Need With Technology Drive, Part Two: Security by Proxy or to Complicate]

Having said all of that, I think we may have reached an inflection point. Several times in the past few months I have seen organizations who are cloud-native or cloud-heavy starting projects to rationalize tools and create standards. This is a great opportunity for the traditional manufacturers who have invested time and effort into building suites of solutions into a seamless product/product set. The key here is that the traditional manufacturers and the analysts need to educate the new buyers (developers) about the differences in the value and how we can answer their core business issues in ways that save time and money.

Several examples:

1) Next gen firewalls – Yes, there are free solutions out there (like AWS security groups often described as firewalls), but 10 years ago they may even have done the job. Today we need solutions that can be more discriminatory. WE need to inspect the actual traffic and make decisions on a per-user access level, not on a per-traffic type level. If we use the free ware we will need several free and some paid solutions (security groups, UR filtering with application control, IPS, possibly anti-malware and anti-virus)to achieve the same functionality and the integration cost that will far outweigh the “free” benefit.

2) ADC– AWS elastic load balancer is billed as an ADC but it is missing many standard ADC functions, specifically around application and resource monitoring and optimization. In most cases multiple tools end up being bought in order to fill the gaps, or a lot of time is invested to build this missing functionality. Some examples: HTTP2 translation, application performance SLA monitoring/management (not just by using logs), and custom per app, per user application optimization.

3) WAF– Cloud Native WAFs offer only a small subset of the functionality that a traditional WAF offers, as they do not offer a positive application security model (discussed above).

Solving this problem is not simple for several reasons:

1. The confusion caused by the clouds’ naming conventions and
2. The independent analysts’ lack of leadership on the issue
3. The lack of co-operation that seems to exist within organizations’ traditional operations and DevOps teams.

As organizations and individuals I can tell you we can simplify our lives. Volume purchasing agreements can eliminate the frictionless procurement objections, help corporations to keep standards, and save time and effort because enterprise solutions bring suites of integrated functions together in one product, thus eliminating lots of time and effort involved with integration. Lastly this all in one cost solution avoids the “death by a thousand cuts” budget problem with disaggregating solutions. The best-of-bread, single-point solutions look cheap in isolation, but can your organization afford the human and monetary capital cost?