As the success of VMworld proves—over 20,000 IT professionals and more than 300 exhibitors participated at the conference this week in San Francisco—enterprises are adopting en-masse cloud technologies (public, private and hybrid) to better deliver services and business values faster.
However, with the success of cloud automation and orchestration technologies like VMware’s vSphere or Kubernetes, one of the key issues that remain for corporate IT teams is how to bring that same level of automation to the configuration and management of the physical infrastructure (routers, switches, firewalls, etc.) that supports and enables an agile cloud environment.
Any networking vendor, any workload, any cloud
Indeed, our research shows that what enterprises realize often too late is that the physical networks that they’ve built could not sustain the level of performance, security, and reliability that a highly distributed, cloud-like architecture requires.
This is why I was intrigued by Apstra’s platform which claims to treat the network infrastructure as code.
“This is exactly what our intent-based networking operating system (AOS) enables corporate IT to achieve by bridging the physical and the virtual infrastructures,” told me Apstra CEO Mansour Karam. “The networking team tells AOS what the virtual network needs and the system will automatically configure all the physical equipment to make deliver the business outcome.”
I’ve sat down with Karam for an exclusive interview to learn more about the Menlo Park, California-based startup and get his perspective on the evolution of enterprise networking with the rise of cloud computing, virtualization, and containers. Below is a transcript of our conversation that was edited for brevity and clarity.
Jeb Su: Start by telling us what Apstra does?
Mansour Karam: We were founded in 2014 and we pioneered intent-based networking which is a powerful automation and abstraction of the network infrastructure services. So if you’re building a network infrastructure, you expect it to deliver services, like connectivity, security, compliance, performance, so that ultimately, you can deliver on business applications on top of that infrastructure. And so, before Apstra, what organizations did is that they built a network manually, box per box, using spreadsheets and other manual processes, typing in the commands. And then they also operated it in that way. And so they delivered those services pretty much manually: If you wanted a layer 2 connectivity between this particular workload in this rack to another workload in this other rack, then you planned it out, you went into these devices, and you configure those VLANs. So you put in some arcane configurations in order to make this happen. And, of course, it was fine 10 years ago, but today, at the speed organizations have to deliver business services and especially in view of the abilities of the public-cloud, infrastructure teams had to transform if they wanted to deliver on their digital transformation initiatives. And the way they had to transform is by automating the entire process of delivering services by the infrastructure. So what Apstra does is that we’re this layer of software that automates and abstracts out the infrastructure to deliver those types of services automatically, in real-time, across the lifecycle of those services.
JS: Give us some examples of the kind of cloud-like services that enterprises are delivering today?
MK: Sure, so I need to connect a web tier and a database tier, and they’re in different tracks. And so the network needs to have the ability to connect these two so that they can talk to each other. That’s a service. Another example would be a security service: I want to make that some particular workloads are not allowed to talk to endpoints. And so the network needs to deliver a service to ensure that these endpoints do not talk to these other endpoints. So you need to block the communication between these two groups. Another service is performance which is based on how much bandwidth you allocate per workloads, the latency requirements, etc. These are all services.
JS: But couldn’t you do that already with existing networking tools?
MK: So then there were some really old school solutions that mostly took care of the day zero configuration. So you configure your network the first day, and then you don’t expect much changes which is very inadequate for supporting today’s applications. Now, you need to be able to adapt real-time with business initiatives happening continuously. Moreover, organizations no longer want to be locked into one specific hardware vendor. A lot of these old-school solutions were being provided by specific vendors: Cisco would provide a solution, Arista would provide one, and HP would provide another. But when you go to Amazon and you get services from Amazon Web Services, do you think of what hardware they have underneath? You don’t? Right? You’re just concerned about the service. That’s the most important layer. So now organizations as they try to adopt those similar approaches, they need to think of the service layer, first and it needs to work across domains, across workloads, across vendors, and once they’ve laid that out, then they’re going to choose what the hardware what they want. And so it’s critical for those organizations to be hardware agnostic. So those solutions that are delivered by these hardware vendors are no longer adequate. Essentially, if you choose one of those, you’re dramatically limiting your options, and you’re just stuck with whatever software that hardware vendor provides you.
JS: At VMworld, you’re announcing that AOS is integrated with VMware’s software-defined virtual network technology (NSX). How are virtualization and containers impacting what you do?
MK: It used to be that wit virtualization, applications were contained within a server or within a rack. Now, with the scalability that you need, you need to go across racks, and a lot of applications now have requirements to work across workload types. So when you’re thinking of the service layer, at the networking layer, you need to make sure it works across workloads. So, first of all, you can’t just confine your virtualization to a server or to a rack, so networking becomes critical because you need to extend policies and connectivity beyond that one server and that one rack and that’s done through the network layer. In addition, you need to have a strategy that works across workload types including VMware workloads, KVM workloads and across Kubernetes workloads. Finally, applications need to work across clouds, public and private (your datacenter). There are many reasons why you may want to do that like to be able to burst or to optimize your traffic. There are some studies that showed that the right answer is 70% private-cloud and 30%, public-cloud across two different cloud providers. So you need to add the service layer and intent layer that are unified across those different options.