In isolation, a cloud environment can appear to be fairly simple—one provider, one flavor of server, one data center, one control interface, one set of native tools, one learning curve.
Focusing on networking, as you peel the top CSP marketing lens and look at the constructs you get, all of them are individual pieces of a great to-be Lego model. Each construct like a route entry, a route table, a subnet, an internet gateway, a NAT gateway, a transit gateway or a VNet route, UDR, peering, hub, VNG, etc., all of these are individual siloed islands of their own. The Lego pieces. If any of these are misconfigured, fat fingered, break, misbehave, then they will not adjust to the new state themselves. As a consumer, it’s your responsibility to put all these pieces together in the right way and then when any of these change state, you need to build the logic to react to possible new states.
Even if your organization is using a single cloud, it’s never isolated. You still need to connect that cloud to on-prem servers, integrate it with the rest of your network, and incorporate it into your security policies. The architecture gets more elaborate as you expand that cloud, adding more servers, data centers, and applications.
And eventually the day comes when you need to add another cloud because the business requires it to support a new customer, an acquired company, or a specific app. Now you have multiple providers with multiple sets of native tools hooked up to each other and your legacy on-prem systems through a tangle of uncoordinated and makeshift connections.
Welcome to the complicated world of cloud architecture.
A ground-floor view of cloud complexity hassles
Network architects get mired in this complexity on a daily basis. Your time, effort, and budget are disproportionately tied up in navigating and maintaining many interconnected network components. Here are a few scenarios you might run into in a typical day:
Getting high-level visibility into the entire network is tedious and limited. For each cloud environment, you have to log in to a separate console. You can’t see where all your cloud workloads, external connections, and security controls are at the same time, so you have to manually assemble and update dashboards.
It’s difficult to predict where the potential stress is coming from and where the next problem will occur without data around overall network performance. Where are the hot spots? How is each component performing? You don’t know.
You’re now dealing with latency, which wasn’t an issue when everything was confined to an on-prem data center. But you can’t see the latency metrics, let alone do anything about them.
The changes caused by growth due to new tech or customers can easily break something elsewhere. Then it takes time and trouble to resolve the conflicts. For example, it’s very likely that new customers or clouds provisioned by shadow IT will have overlapping IP address ranges with your existing network. Do you ask the new customer to change their IP addresses or do a complex NAT configuration on their routers? Or do you recreate your own IP addressing plan?
You run up against networking limitations instituted by cloud providers. (Yes, this contradicts their promises of infinite scalability, which hold well for compute and services offerings, but often don’t apply for networking constructs.) You may learn that you can only advertise 20 routes from your cloud network to your on-prem system. The number of routes in a VPC routing table may be limited to 100. When you have a very large network, you have to rework your architecture to accommodate those limitations. (Not to mention, every cloud provider has different limits, so you have to figure out what they are first.)
If something goes wrong and you need to track down the source of the problem, you have a hard time getting help from your cloud providers. They are quick to point the finger back at you, insisting that their service is running fine so it must be your instance. If you want them to investigate further, they ask for a packet capture of your instance before they can proceed. Then you have to set up a packet-capturing service and cross your fingers that it doesn’t have a negative impact on your production instance.
The risk of threats is higher because internet access in the cloud is only a hop or a shadow IT click away. You can funnel everything through a bolted-on security device, but that affects performance, and it’s hard to ensure governance and adherence. One unauthorized change and all of a sudden you’re exposed.
We could go on and on about other Day Two operational challenges, like scaling up the size of the environment for particular applications, updating capabilities to the next version, optimizing for performance and reliability, performing audits for compliance, doing teardown and cleanup of decommissioned environments, testing, cost monitoring—but you get the picture. Complexity everywhere you turn.
The ease and simplicity of a cloud network platform
Now imagine that your organization is running the Aviatrix secure cloud network platform. You still have multiple clouds, data centers, servers, on-prem environments, and applications.
But you have one broad, central view of your entire network. One console that lets you see and configure everything in one place.
You know everything that gets spun up and how it relates to everything else.
You have visibility into your latency numbers, plus insight into what they mean so you can react accordingly.
Networking limitations from cloud providers disappear because the Aviatrix platform is in control and can support thousands of routes.
When someone asks for a change or addition, you can say, “Yes, we’ll have that done by tomorrow,” instead of “I don’t know. Let me research that. It will take some time.”
Overlapping IP addresses? No longer a thing. You can just define a virtual subnet that doesn’t overlap with existing subnets, and your Aviatrix gateways do the network address translation to easily connect them together.
Need a packet capture? Turn it on in an instant, send it to your cloud support engineer, and get your case resolved much faster.
Threat identification and remediation are embedded into the network fabric. You’re not dependent on security added in pockets or at the edge—security is baked into every single hop.
That’s just a sampling of what Aviatrix can do. So if you’re interested in simplifying Day Two operations, learn more in the e-book, We Need To Talk: Start the Right Cloud Networking Conversation Today.
Originally posted at https://aviatrix.com/rethinking-the-complexity-of-cloud-architecture/
Comments