Becoming a cloud-native transformer

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 in the audience 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. Virtualization 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 are 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 (“codifying” 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 the hardware, or on virtual machines, or 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 behavior, 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 embedding security into your development lifecycle?program will allow you to fulfill a professional dream and become the Optimus Prime of your organization's AppSec?program

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