RSS

Networking in the Cloud needs to evolve

Cloud and DevOps helped us evolve the way we build our apps and our systems. Network seems to be the missing piece. How exactly do we need the Cloud Networking to evolve?
Share this page:

How we operate the Network today

Network is important. Speed, Bandwidth, latency and delay will have a crucial impact on your app performance. Change in a network architecture can have a critical impact, or even cause an outage. This is why the traditional Network Teams are very cautious, and still prefer the old fashioned “open-a-ticket-we-will-analyze-and-configure” way.

This is partly why SDN (Software Defined Networking) never triumphed - the automated private cloud can’t be built without it, and the team with skills to make it happen won’t buy on the idea.

So far, we’ve managed to survive with the “old fashioned” operating model. But the requirements have changed…

What are the new requirements?

Public Cloud changes the game. In the Cloud, Network complexity is abstracted so that the developers are self sufficient when it comes to provisioning connectivity and security to their IP and data flows.

The problem emerges when the application, due to its dependencies, requires connectivity with other elements, outside of the Cloud Account in which the app “lives”. This is where the Product Team tends to get stuck.

Lost in the Cloud

You`d be surprised how many enterprise grade apps require a private network connectivity.Typical product team requests could be:

  • We need to connect to an API in the Data Center to test a functionality.
  • We need Service Stations or Retail Points to connect to a central Data Base.
  • We need Stores to reach the private API endpoint.
  • We need to send our “Things” (IoT) to continuously stream the data to the central platform in the cloud.
  • We need to get the DATA into our Data Lakes.

The old operating work doesn’t work anymore. We need to be able to build a network that is Secure, Scalable, and most importantly - the complexity and the operation needs to be abstracted, and offered to the Product Teams as a self-service.

DevOps and Agile require us to put a user in the center, understand their requirements, and reiterate the design and the implementation to better meet the requirements. This is why, to be agile, we need to follow this principle with the Network.

Back to our app, and the connectivity requirements. There 2 ways we can attend these requests:

1. The OLD way

  • Product Team opens a Ticket to Network/Security team.
  • Security team analyzes the request.
  • Network and Security Operations configure the connection, router by router, firewall by firewall.

2. The GitOps way

  • Product Team uses a Self Service portal.
  • Request goes through a pipeline, where someone wrote the tests required by Security and Network teams, to validate if the flow belongs to the pre-approved, flows. Depending on the case, a manual approval step could exist.
  • If all is OK - an orchestration Runbook is triggered, all is tested, configured automatically.
  • Product Team receives a notification that the network is ready. Network State can be visualized in the portal.

We understand the requirements. It’s obvious the GitOps way is better. Why in hell aren’t organizations doing things this way? This is where it gets interesting…

Two reasons:

  • Network Teams don’t trust automation. At the end of the day, if something fails, they’re the GO-TO department, and they know it.
  • Technology isn’t there… Yet.

What do we need to make all this happen?

We need a well documented API, and an abstraction layer that we can use to configure and monitor our Networks, end to end. SD-WAN, along with a Multi-Cloud connectivity, needs to be delivered as a managed service. We don’t want to configure routing and security box by box. We need a single, end-to-end solution, and a single API.

Why is no one offering this service? Honestly, I’m not sure. Could be a combination of a few factors:

  • Networking equipment vendors still trying to sell the boxes.
  • ISP (Internet Service Providers) forcing the MPLS + “Enterprise grade” internet model that still brings the cache flow.
  • Cloud Providers, mostly focusing on their own backbone services.

Perhaps Aviatrix, or Volterra (acquired by f5) will start offering their products as a managed service? Maybe a startup, swooping in and cleaning up the market? I sure hope so, because current WAN and multi cloud networking is hard to manage, and not in accordance with the evolution of Cloud technology, and product team requirements. We can either build our own end-to-end solution (costly, in both design and operations), or keep opening Tickets and waiting for a savior.