So it was really a security problem. How we were handling security was forcing the network to do things that are, as my boss would say, unnatural. That's when I saw that it was a segmentation problem. The way we were segmenting didn't make sense.
I looked at the different segmentation models, starting with the idea of segmenting based on data classification. But with that model the amount of firewall rules you need — because these sensitive data systems still need to talk to the non-sensitive data systems — still results in a huge rule set. You still have a lot to maintain.
Then I looked at it from a compliance perspective, and the same problem occurs. Our PCI systems still need to talk to a lot of other systems in our data center. So that didn't solve the segmentation problem.
And then I looked at the network, and said, "Well, the network is all about services. That's what it does. Services are usually associated with the port, and if you have a well-organized data center, they're usually associated with a place on the network." So it became very simple, once I started looking at it from a service perspective.
So I developed this model and we took it to the technology council and we got approval to start looking at technology. The first idea was to do Layer 2 transparent firewalls paired up with our core router. I call that the big iron solution because the router operates in a bridged Layer 2 mode and you just insert it in the middle of a traffic stream. So basically we'd have the core router and just hairpin traffic off the core router through the firewall. So there's no Layer 3 interface on it, per se.
And you didn't like that approach why?
It was expensive and it didn't optimize east-west traffic. What it did was took that east-west traffic problem and put it in one place in the network where we could then throw enough resources at it to deal with it. But we were looking at a number of options from a range of companies when VMware came out with this new thing called NSX. We had them come down and present and immediately it started to gel for us.
The big thing that started driving us towards the approach is the concept of bringing the physical devices into the virtual world; the fact that we could create a network segment that consisted of both physical and virtual devices. You can do that with a VLAN but it's not pretty. The solution here was much more eloquent.
The second thing was the concept of being able to optimize east-west traffic by keeping the traffic on the host, and that was something that you couldn't do in a physical world. Our plan involved all these different service bubbles, and each bubble would have to send traffic up to the core in order to talk to another bubble. So, like I said, if we centralized that problem we could throw more hardware at it, but what would be even better is if those workloads were on the same host so we could have that traffic inspected on the host without sending it up to the core and back.
Sign up for MIS Asia eNewsletters.