In a previous blog, I discussed the multi-channel coverage of the elastic cloud gateway (ECG) architecture. In short, ECGs consolidate the functionality of multiple point products to improve centralized visibility and control over an organization’s traffic – be it network, web, or cloud application-based. A key enabler of this consolidation is the microservices architecture of ECGs and the inherent scalability that comes from a cloud-native approach.
Enterprises have often gravitated towards best of breed products that offer a focused set of core capabilities. We have seen evolutions where additional functionality has been incrementally increased – think the evolution of NGFW with the integration of IPS and application control. However, in a physical appliance or VM-based architecture, there are typically performance ceilings that limit the number of security services that can be integrated into a single stream of inspection without either dramatically increasing cost or impacting latency.
Yet, there is infinitely less concern about performance limitations when using a cloud-based solution. One important delineation to make here is around truly cloud-native solutions. This means cloud offerings built from the ground up with a microservices-based architecture to provide high scalability when needed. This is in contrast to an on-premises solution that has been virtualized and shifted to the cloud, which does not possess the same inherent elasticity. The ability to seamlessly pull in additional compute resources to decrypt traffic, do deep content inspection, or analyze complex malware during periods of increased traffic, and then immediately scale back down when those capabilities can be handled with less processing is a core tenet of the ECG architecture.
Related to the elasticity and cloud-native aspect of elastic cloud gateways is a consumption model that better reflects actual customer usage. Cloud-based network security solutions are not new. Cloud secure web gateways, cloud access security brokers and other solutions have been in the market for a number of years. However, the typical license meter has been the number of users; perhaps with an option or two for bundled security services.
This type of model obviously simplifies the pricing structure and provides cost consistency, which remains important to a number of customers. Yet it contrasts with other cloud services, cloud workload protection platforms (CWP), for example, where cost is directly tied to the usage of cloud resources. For example, a CWP solution may cost $0.01/hour per AWS EC2 instance. If the EC2 instance isn’t in use, the customer doesn’t pay for CWP capabilities.
Relative to ECGs, expanding the pricing model to include potential meters such as security services used, number of branch or remote sites supported, bandwidth of connections, or number of mobile users could be used to charge customers specifically for the services and capacity they consume. In this model, there would likely be more month to month variance in costs, but customers would have greater visibility into the exact services they’re paying for.
The evolution to a more consumption-based pricing model will take time. We’ve already seen a shift to include some of the above aspects in SD-WAN focused solutions (e.g., bandwidth or sites), but there’s a lot of potential for differentiation in this area. To be successful, vendors will have to educate the market, provide tools to show hypothetical cost analyses, and develop a framework to help customers see the value of such an approach. Part of this framework may include how a distributed enterprise is supported by the global platform providing local points of presence an ECG is built on – which will be explored in more detail in a future blog.
