December 2020CIOAPPLICATIONS.COM8onolithic applications running on dedicated servers have evolved into cloud-native microservices that freely scale on cloud. However, in the enterprise space, more often than not, `networking' has acted as a necessary evil that slows down progress, and results in unplanned outages. However, networks can quickly become an asset from liability if used properly. Let's take a deeper look.Networking in the enterprise domain grew up to provide connectivity between office buildings and provide access to Internet and corporate services within data centers. Since many enterprise applications came as third party software, physical networks had to facilitate and enforce segmentation and security needs. The networks were complex, inconsistent and fragile with heavy dependence on a set of in-house support staff as well as dedicated engineers from vendors.Other than configuration inconsistency and failures due to lack of change rigor, the primary factor that contributed was the inherent weakness of protocols like "spanning-tree" that were used to ensure loop-free forwarding path for switching domains. Layer 2 switching domains were needed to support VLAN (Virtual Local Area Network) which has been an integral part of most enterprise networks to ensure IP mobility, enforcing firewalls as the default gateways etc. These domains frequently suffered from broadcast storms that melted the networks due to loop creation. More so, loop-free requirements created topologies that resulted in congestionFast forwarding a little, when companies went into delivering online services, many of the same enterprise networks were used to host services. For online services that are expected to be available for at least 99.99% of time, these enterprise network designs have been a fundamental misfit.Now, to take this discussion one level deeper, let's analyze the impact of a typical enterprise network on cloud-ready workloads first and then on cloud-native workloads. Broadly speaking, cloud-ready workloads are monolithic applications that are packed into a virtual machine (VMs) as opposed to the original bare metal servers. In environments with strong dependency on their incumbent physical network, such cloud-ready VMs have simply slided in to replace physical servers. In many cases the VMs simply connect to the VLANs and the overall online service depends on security and load-balancing services through underlay networks. There have been continuous efforts to use network, firewall and load-balancing automation to cater to the agility needs of such services. However, cloud-native workloads are challenging this very premise. By definition, cloud-native workloads are formed out of applications getting decomposed into microservices. These microservices get automatically deployed, scaled and managed as containers through orchestration systems like Kubernetes etc. Now the question becomes, in an environment with heavy dependency on incumbent physical network services, should the cloud-native applications take any dependency on the services provided by the underlay network or technology leaders should act cautiously EVOLVING DATA CENTER NETWORK FROM CLOUD-READY TO CLOUD-NATIVEPARANTAP LAHIRI, VP, NETWORK AND DATACENTER ENGINEERING AT EBAYMIN MY View
< Page 7 | Page 9 >