A Brief History of Cloud Native

In the spirit of new beginnings for the new year, let’s look at the inception of cloud native software architecture and how one of the networking industry’s most momentous technological changes came to be. Many traditional communications service providers (CSPs) are now getting to grips with the concept of cloud native and what it means for their businesses and even starting to implement cloud native strategies. Knowing the cloud native backstory will help explain why their journey matters, because early cloud application developers were trying to solve many of the same challenges that CSPs face today.


The availability of inexpensive pay-as-you-go compute power in large-scale public clouds opened up a completely new kind of opportunity for entrepreneurs: the ability to rapidly create and roll out network-based services that could be offered to the public at scale, particularly in the realms of social media, messaging, media distribution, e-commerce and the “gig economy.” And it massively reduced the amount of capital risk associated with starting up and scaling such services.

The new ventures that set out to take advantage of this opportunity were not writing software to run on dedicated servers, and then deploying it on virtual machines in the cloud. Instead, they viewed the cloud as an entirely new kind of distributed computing environment that created exciting possibilities for new application architectures.

What these cloud application developers sought, above all, was scalability. They wanted to be able to deploy systems that would scale rapidly through many orders of magnitude with as few limitations as possible, and without the requirement to revisit fundamental aspects of application architecture along the way.

They also wanted resilience and fault tolerance; they recognized that failures can occur at every level of the stack, from individual servers to entire data centers, and from individual virtual machines to entire cloud instances, and they needed to come up with software architectures that would survive multiple such failures and continue to deliver services.  But they didn’t want to buy fault tolerance in the traditional way by doubling up resource usage. Rather, they expected to absorb the impact of failures through modest amounts of surplus capacity combined with automated self-healing capabilities.

In addition to scalability and fault tolerance, cloud application developers wanted to be able to evolve their software solutions quickly to meet new and emerging service requirements. In practice this meant making it possible for multiple teams to work on the software simultaneously without tripping over each other, leading to the concept of decomposing complex services into loosely coupled components that talk to each other through open, language-agnostic APIs.

These were all difficult and challenging problems to solve, but the successful pioneers in cloud-based application development employed some of the best brains in the software industry, and there was a good deal of cooperation and sharing of learnings among them. The design patterns of what came to be known as cloud native software architecture have emerged over the last few years as a consensus within this community.

Metaswitch has pioneered the application of cloud native design to network software. We have long understood what it takes to build cloud native network functions (CNFs) leveraging the fundamental principles of stateless processing, microservices, containers and automation. We started building our cloud native Clearwater IMS Core back in 2012 and applied that know-how when we designed our cloud native Fusion 5G Core. It is only through the adoption of cloud native principles and deployment of CNFs that CSPs can fully benefit from network virtualization.

For more on CNF design, architecture and technology landscape, please download our new white paper.