Regardless of what you may have heard, the IP address is in fact, dead. Brought down by several public clouds that replicate the same private IP space in perpetuity. Set a workload to auto-scale or deploy a highly elastic, Kubernetes infrastructure, and your head will spin as you try to keep up. It is true that you may be one of the few remaining holdouts that have yet to venture into the hybrid cloud space or leverage containers but, like the IP address, your days are numbered. The public cloud, while expensive, makes too much sense to ignore. You may not be there today, but you will be eventually.
Time is still money
How did the cloud become attractive? It’s simple: because it is so bleeping hard to get an IP address on the local network. I’m not even close to resembling a developer, but even I can set up a static web app in Azure with an integrated CI/CD pipeline through GitHub literally in minutes. It may just be an out-of-the-box web app template from Visual Studio, but you get my point. It’s not important what I did or how, it’s what I didn’t do in the process. I did not have to request a virtual server which, if capacity was exhausted, would require a new physical server to be ordered, delivered, and racked/stacked. I didn’t have to wait for a TOR to be provisioned or a VLAN created. I didn’t have to wait for network security to create an access policy that would allow me to access it on the internal network. I did not have to wait for an IP address.
All that infrastructure takes a great deal of money but, more importantly, the process surrounding it takes time. A lot of it. This is why the IP address is dead. Creating my “web app” in Azure didn’t ask me for an IP address when I connected it to GitHub repo nor do I need or get an IP address to access my app. The same would be true if I wanted to connect to an external database or some other resource endpoint. If I was an actual developer and I knew how to create and deploy a highly scalable application on Kubernetes, I would do so without worrying about IP address space as the internal DNS service routes via FQDN. In all of these cases, I only need a fully qualified domain name a.k.a. FQDN. Now, this may be where you say, “I GOT YOU! The FQDN is tied to an IP address, the IP address still lives!” On-prem, maybe. In public cloud the IP address is here today, different tomorrow. The application and its FQDN, however, remain unchanged.
Scalpels and sledgehammers
If an application’s IP address space is constantly in flux, why would I pour considerable effort into managing IP address space in the cloud? This is a great opportunity to insert a Matrix analogy but instead, I’ll say that it just doesn’t make much sense. You can but you shouldn’t be chasing IP addresses in the cloud. You need application layer networking, what we at Prosimo call App-to-App Transit.
Optimized application infrastructure means that you use the best service for the job. This may be a requirement born of form or function but often it includes cost. As a result, many organizations are in at least two public clouds with many expanding to four or more. Connecting these infrastructures will test the nerves and patience of the most skilled network teams and this is to be expected when the goal posts are constantly moving.
Prosimo set out to solve this problem by connecting applications at the application layer, not at the IP layer. Have we created a new protocol or alternative to the OSI stack? No. We are still networking mortals and we still rely upon common networking protocols and principles. We simply use the FQDN when it’s there or we create one for you when it’s not to help you avoid ever having to configure an L3 routing policy. This is what allows us to simply connect one application endpoint to another endpoint through a simple transit policy. This is essentially micro-segmentation between /32s, but without implementing insane routing and security policies to achieve it across multiple virtual appliances spanning multiple clouds and ISP hops. That sounds great but also too good to be true, right? Let’s dig into how we do this.
Onboard apps, and nothing but the apps
Prosimo’s architecture consists of a policy engine that deploys and manages a series of Prosimo Edges across any supported public cloud with the option to connect to your on-prem apps as well. Once you authorize Prosimo to deploy within your cloud infrastructure, you simply need to start defining apps. Let’s break down the onboarding process:
- Select two application endpoints within your infrastructure that you need to connect – you may use an IP address or FQDN to aid in the discovery of the app.
- Define the app as a source app, target app, or both.
- Define the communication protocol for the target endpoint(s).
- Identify the cloud account where each app resides.
- Decide how you would like to connect to your endpoints: in AWS you may choose Transit Gateway but in Azure, you may prefer to use peering over a VWAN Hub.
- Determine the optimization profile.
- Approve the security policy.
- Click “Onboard.”
That’s it. That’s all it takes to connect two apps in one or more clouds. There’s no BGP, GRE, NAT, or IPsec. Just mTLS tunnels (that we set up and manage) between Prosimo Edges that keep your app communication secure regardless of whose infrastructure it crosses. You now have network and application telemetry. You have troubleshooting tools to help you determine network quality and health between regions or clouds. You may also have more time to grab a coffee or do some Tai Chi in the park. You can meditate on how you won’t miss performing packet captures on some abstracted appliance deployed on someone else’s abstracted infrastructure.
The challenge
Have I convinced you yet? Are you ready to let go of the IP address? Did I mention our Free Trial where you can validate my claims, but without my snarky comments? Check out the link here and you’ll soon see that it’s much better to work with abstraction than fight it. The IP address is dead, but it’s a good thing. It’s time to move on and move faster than ever before.
