Engineering Simplicity
Explore Juniper’s vision for network innovation and how the company and industry are transforming the future of networking
Engineering Simplicity
Connectivity for a Multicloud Architecture
Mar 5, 2018

While most of the emphasis in multicloud tends to be on the layers that allow for seamless policy and control across multiple domains, there is still an underlying dependence on connectivity. Without devices to handle traffic, none of the multicloud ambitions make much sense. And more importantly, how connectivity is provided can either help or hinder efforts to extend end-to-end security and operational control across a multicloud architecture.


Juniper Networks believes that a complete multicloud strategy requires two things: an end-to-end approach across all places in network (PINs) and a top-to-bottom offering that covers everything from connectivity to orchestration.


All places in network

The most basic requirement for connectivity in a multicloud environment is end-to-end reach. Multicloud is more than just data center and public cloud—it includes campus and branch, as well.



multicloud connectivity number 2.png



End-to-end connectivity demands a diverse set of platforms, as each PIN has different requirements, ranging from features and services to performance and form factor. The data center requires leaf, spine, core and DCI platforms, built on a combination of merchant and custom silicon, depending on cost and performance requirements. The campus requires closet and campus core switches, likely leveraging merchant silicon for cost. The branch more likely uses general-purpose processors to optimize for cost and to support a rich set of virtual network functions. And the cloud requires virtual devices running in varying cloud environments.


The diversity of these requirements is why most vendors limit their multicloud strategy to a single PIN. It’s not uncommon to see datacenter-only approaches with references to cloud connectivity. This isn’t because it’s sufficient. Rather, it’s because it is highly limited by the portfolio gaps. And while making for a cleaner narrative, it misrepresents the architectural problems that enterprises must solve for. It’s misleading at best, and architecturally limiting at worst.


For more information on all of the Places In Network, please visit Juniper.Net


Simplifying diverse connectivity

While it is true that different PINs have different requirements that drive different platforms as connectivity solutions, there are ways to simplify the connectivity layer so that the frameworks built on top of it can be more uniform across the entire infrastructure.


For Juniper, this starts with the Junos Operating System (OS). Junos is at the heart of every platform across every PIN, whether it’s a switch, router or firewall; whether it’s based on merchant silicon or custom silicon; whether it’s a physical or virtual device. Junos provides a common way of representing network services across all of these. In doing so, Junos abstracts the complexity of the underlying implementations away from the customers, while offering tremendous flexibility in choosing the right solutions for the appropriate PINs - without fitting square pegs in to round holes in the name of simplicity. Customers can use Junos for connectivity ranging from Intel Atom processors through Broadcom merchant silicon all the way up to the highest performing network silicon on the planet, built by Juniper. This diversity enables our customers to make an economic-versus-technology decision as to which platform to use in each environment.


Juniper’s common operating system, running on a wide range of platforms, is key in helping our customers simplify their operations. Because the vast majority of the code is platform-independent, customers can qualify once and deploy everywhere, streamlining the time for new implementations and updates. Importantly, the interfaces are common, meaning things like automation frameworks, API integration and tool integration can be done once and leveraged across the entire portfolio.


In a multicloud world, where the value is extracted by tools above the connectivity layer, this means that those tools have a common foundation on which to rest. While a homogenous network for multicloud is not practical, with a common network operating system, there can be spans of uniformity to simplify overall design and maintenance.


For more info on how Software-Defined Branch plays a key part in multicloud, read Juniper’s CTO, Bikash Koley’s blog, Crossing Tax: Multiplying Complexity in Multicloud


Reaping cost advantages out of the connectivity layer

The operational advantages afforded by a common operating system provide a direct path to reducing costs. Reducing the effort to qualify and deploy, or to integrate, or simply to train means that more resources can be spent on areas that require more attention.


For enterprises, multicloud is going to be a journey—one that will involve many different solutions that must be independently evaluated, but collectively deployed. If this is going to happen without dropping existing demands on IT or unnecessarily floating the budget beyond tolerable levels, it means enterprises need to be thoughtful about how they recoup time and money every where they can.


Good engineering design

While it is tempting to claim that Juniper has taken this building block approach solely to drive operational advantage, the truth is that we architected our portfolio this way because it’s simply good engineering design. At our core, we are an engineering-led company built on strong engineering principles. Modular design is but one of our core tenets.


We exist primarily to solve hard problems in such a way that the complexity of networking is our burden to bear. And providing connectivity across diverse domains in a way that simplifies multicloud is just one of the ways this shows up in the market.


0 Kudos