In Part 1 of this blog, I described the purpose, need, and requirements of a controller. I also differentiated a controller from a device manager and compared a controller (and the infrastructure it oversees) to a self-driving car: give it direction (apps/policies), and it will take care of the rest.
For Part 2, I want to get into the details of building that self-driving car – the controller, the functional and technical requirements, what we did at Valtix to meet those requirements, and the results of that work – the benefits Valtix customers have seen.
In Part 1, I provided a list of requirements for a controller. Here, I will talk about them in more detail, where appropriate. The control plane requirements and specifics:
- Scalability. Infinitely scalable to handle large amounts of resources, configurations, policy, and telemetry. This typically means the ability to process parallel transactions for orchestration and other tasks because the number of details is huge, even with just a few resources. Organizations need to be able to see all of it in one big picture.
- Visibility. Provide comprehensive visibility of customer cloud workloads across all accounts/clouds to expedite security policy definition. As stated above, there are many elements to consider – connectivity, identity and context, vulnerabilities, and so on.
- API-driven Support modern IaC (Infrastructure-as-Code) frameworks such as Terraform for defining security infrastructure and policies, with a proper API caller experience (asynchronous handling/queuing).
- No Overhead. Minimal operational overhead for the Controller. Given the huge number of transactions and criticality of security, one might think that a controller would be a high-maintenance beast. Organizations have told me repeatedly that they don’t have the ability to manage such a beast.
- Security. Enable security best practices in terms of both development and ongoing maintenance.
Microservices is the Answer
Given the requirements and the current state of computer science, we at Valtix concluded that the only way to deliver what organizations needed was with a scale-out microservices architecture. Why?
First, the data requirements – specifically as stated under the Scalability and Visibility points above. These are huge volumes of data (resources, configurations, policy, and telemetry), they are pooled for a given deployment, the better the big picture is for that organization. This calls for a separation of the data and compute layer.
Second, the functional requirements – things like processing live configuration requests, some of which are long-running and must be performed in the background, and processing and enriching network logs and events at a very large scale. The variety of types of transactions and the pure volume demand a microservices-based approach, with each specialized service able to scale horizontally and independently.
These requirements dictate a microservices-based approach and preclude a monolithic, virtual machine-based approach.
SaaS is the Way
So Valtix agreed in the early days that a microservices approach was the only way to meet the requirements in cloud. We then agreed that for the controller (not the dataplane, or enforcement pieces), Software-as-a-Service was the only way to deliver a microservices-based controller. For two simple reasons:
Enterprises don’t want to spend the time and effort running a microservices architecture themselves, unless it is their core business application. The installation and maintenance of a microservices security controller is a significant effort that doesn’t make sense for the typical enterprise. For example – we have customers who use Valtix because they don’t want to have to maintain anything, not the least of which being a microservices architecture. Furthermore, the integration with other capabilities – event management, incident response, change management, is critical and intensive.
Security best practices
With the ability to have multiple processing streams and handle infinite amounts of data, yet present it as actionable information in near-real time, a microservices-based architecture offered as SaaS enables better and faster response to security issues.
So at Vatlix, we built a microservices-based, SaaS-delivered controller for our network security solution. A few things worth noting on the functional side:
- The separation of compute and data in the controller architecture
- Different microservices enabling parallel transaction processing, background processing, and high-volume processing and enrichment of network logs
- Despite all this power, the enforcement of policy and the production traffic remains in the customer environment – due to the security and compliance requirements of our customers.
This enables enterprises to have a big picture, consistent enforcement of enterprise policies, lower ops costs, and faster time-to-market of business initiatives in the cloud. We’ve seen these benefits proven in large and small organizations. Which, to me as the architect of the controller and the leader of the team that built it, is exceptionally gratifying given the years of effort we put into it.
Figure 1: Valtix Controller Architecture
Valtix Cloud Controller Benefits
First, this approach meets the requirements discussed in Part 1, and again in more detail above. The combination of microservices and SaaS delivers the scalability, visibility, API first, no overhead, and security required by enterprises. The security benefits are pretty clear – security and compliance meet the stringent requirements of enterprises deploying their most critical assets into the cloud. The operations benefits are similarly clear – that security has the same operational model and agility expected of cloud-native services.
This leads to some significant business benefits – lower cost, obviously, but more importantly – faster time to market of new initiatives. When security keeps pace with app development, initiatives deliver value faster.
Valtix Built the Self-Driving Car of Network Security
Like a self-driving car, the Valtix controller enables an organization to focus on the destination, not the effort required to get to the destination. In other words, focus on the app and the policy, and let the controller handle the rest – alerting you only when you need to pay attention to something important. If only my Tesla could do that…