The Shift from Host-based to Service-based Networking
As enterprises migrate to dynamic cloud-based environments it's more complex, cumbersome and expensive to base networking around host-based identification. Instead, modern network infrastructures are moving to service registries that provide service-based naming, routing, and discovery.
Speakers
Dave McJannetChief Executive Officer, HashiCorp
Transcript
Probably the most significant change we see amongst our broader customer base is around networking. The networking implications of this new wave line infrastructure are profound, and the simplest way to articulate it is to say that we're going from a very host-based way of doing networking.
I have a phone that has a physical location and therefore I can assign an IP address to it. I have another phone, it has a physical location. I can assign an IP address to it and then I can dictate that they can talk to each other conceptually, which holds true when I talk about servers.
I have a server, a server, component and a server, component and a server. But they have IP addresses at the basis of connectivity, so it's really host-based connectivity. Based on the location of the host, I can then determine who can talk to whom.
Well, in the cloud world, I no longer control the location of those services because someone else is controlling them for me. Number two, a lot of those services are very ephemeral in their orientation.
They may get spun up when I had a lot of traffic on my application and then spun down when I don't. What that means practically is that I may have 100,000 containers that spin up at noon on a Friday and then that goes down to 0 at midnight.
On Monday when I spin them up again, they have different IP addresses. How exactly am I going to declare who can talk to whom? So, we moved to this world of service based networking rather than an IP address being the basis for who can talk to whom, we use the service name as the basis for who can talk to whom.
I can say, "Application A can talk to Database A. Web server A can talk to Database B." I think that's the difference is it shifts the problem set around how to think about the problem, and there's no direct parallel to the way we do networking today. Because you're saying, let’s assume that things are going to come and go, things are going to be ephemeral, and any hope to try and create network segments around application components is essentially impossible.
So let’s move to using the name of the service as the basis of who can talk to whom. Let’s enforce things like TLS between those services. In a sense, they could be running on the open internet, and it wouldn't matter because the idea of having to create closed networks is, in some sense, impossible in the cloud model.
