When I was a child, I didn’t dream of becoming a legendary football player or a rock star. My dream was to become a Transformer. And specifically - Optimus Prime. I am sure some of you shared the same dream.

As you can see, unfortunately, this dream didn’t come true. But what I am going to share with you today, is how to become something even better than Optimus Prime. We’re going to embark on a journey that will make you nothing less than a transformer within your organization – A cloud native Transformer.

But before I do that, let me first define what are the four foundations of a cloud-native architecture:

1. Small, stateless microservices, running in containers, because compared to large things, small things are faster to get deployed and upgraded. And small things use fewer cloud resources, because you deploy just what is needed, instead of the entire network function.
2. DevOps for automation and fast TTM. And when you deploy an upgrade, use canary deployment to test it with a smaller group, then extend it out to everyone.
3. Open architecture & APIs so you can continually onboard innovation. For example, 5G’s core uses a service-based architecture, with well-defined APIs for network functions to offer services or call on each other. This, along with the cloud-native service mesh, enables rapid manipulation of your 5G core, whether for integrating new network functions, or rapidly scaling & deploying per-enterprise slices.
4. Cloud agnostic, so you can deploy anywhere. Because of abstraction, you eliminate the hardware dependencies.

The four steps of cloud native migration

Now, let me take you through the four steps that will help you become a cloud-native Transformer.

1. Cloud virtualization
   The first step towards ‘cloudification’ is virtualization which enables hardware consolidation by making it possible to run applications on generic hardware (and to run old single-threaded applications in a more efficient way). This was the first step towards cloudification but was not yet true cloudification. The VNFs are still siloed, effectively rendering the benefits of cloud less relevant, as there is no pooling of hardware resources across the different applications.
    
2. OpenStack cloud and cloud-native automation
   The next step in the journey is the evolution towards automation and scale/elasticity (“cloudifying” the virtualized software). Cloud layer leverages OpenStack technology, making it possible to automate deployment of applications into the data centers running generic hardware, and (depending on application capabilities) elasticity may be supported e.g. through VNF managers. Unlike virtualization, there is automation in place, and it is possible to run many different applications with the same tools. While able to run the applications in the cloud infrastructures, the applications may still have certain requirements to underlying cloud stacks and/or to the hardware layer.
    
3. Cloud architecture and cloud-native applications
   The third step is to evolve application architecture towards cloud-native applications. This includes de-composing the network functions into microservices and makes it possible to run the applications as “infrastructure independent” - for example directly on hardware, or on virtual machines, or in containers. It also enables for example VNFC (Virtualized Network Function Components) approach for sharing/re-using multi-vendor components across multiple applications (such as session database or load balancing entity). In addition to infrastructure independence, a key quality is programmability, i.e. providing well documented APIs both inside and outside of the applications. This is important to enable DevOps principles also in the telco cloud.
    
4. Software (or anything) as a service (SaaS/XaaS)
   The final step (or destination) is to migrate to a consumption-based model. With all these changes in the network and ecosystem, including the arrival of 5G, CSPs need to take a step back and evaluate if it’s still worth the capital investment in network infrastructure. Especially when they are unsure of the return on investment alongside time-intensive builds. By leaving behind their traditional CAPEX-based buying behaviour, CSPs can introduce flexibility, cost control and the agility to roll out new offerings quicker.

As we realize through the years, not all dreams come true. I will not become Optimus Prime. But migrating to a cloud-native architecture and to a consumption-based model will allow you to fulfil a professional dream and become the Optimus Prime of your organization.

To learn more about the benefits of cloud-native and how (and where) to embark on the journey click here.