Journey Towards Open and Fully Distributed RAN and Networks

As Open Radio and Network Disaggregation ascends from hype to trough of enlightenment , its a great time to catch me live at the Europe’s Prime Cloud and AI Conference (Layer123 World Congress) together with leading voices of the community , sharing views on our journey so far . Register now

Top Considerations to build a Future Transport for 5G Networks

source: NEC Future Networks

According to latest reports from leading Trasnport Infrastructure vendors Ericsson and NEC . it is very vital to build Next Era Transport for 5G that can serve for MPLS and SRV6 end to end . When we think of future business cases like End to End Network Slicing it will become for important .

These are

source: Ericsson

Transport for Open/C-RAN

As 5G will deploy in different scnerios and Cloud will be long term most lucrative one so transport must align with it by offering Packet and Ethernet based transport end to end from device to core preferably using e-cpri models that has significant low latency

Outdoor Dense Urban solutions

In Outdoor in city centers laying NG Fiber may not be feasible solution so offering connectivity using PON and MW is needed that is why it is important to not just lock with Fiber solutions

Automation of Transport

Just like others domains like RAN , Core , Edge the transport also need to be Orchestrated and must be optimized over time using ML and AI . the key for this is build a transport that can automate using T-SDN like ACTL workflows or Open ROADM and that can help collect all data that can be optimized with AI .Cool stuff

Future DC architectures

Transport should be flexible not only to offer transport based on 3GPP service model but based on DC architectures like solutions for Clos architecture , DIs-aggregated scnerios etc

Distributed architectures

Just like with other solutions in 5G the transport should be distributed like support for Hub /Be-spoke rather than full mesh for both reliability , performance and scale .

Secure architectures

Security nevertheless is of paramount importance specially as we will open transport for 3rd party and whole sale connectivity although this domain is well addressed in Orchestration and End to End Slicing however as famous adage we must be leave the software boundary un attended .

“Protecting a software with another software in a cloud is not scalable.”

–Saad Sheikh

Open RAN and Disaggregated Networks in Practice -Analyzing market dynamics in middle east

RAN and Transport is a real cash cow for Telecom vendors (Big 3) and a big $ dose for operators like us , if by any means Telecom operators has to make something out of Cloud and transformation this is where they must invest .

Here are our key findings based on market reality and Technology Radar in the Middle East market

  1. Cloud is good but Front Haul and Radio holds the Key for disruption , $1B R&D funding in 2021 is a must to keep pace with innovation , see Parallel wireless CEO thoughts here

2. Operators need to take a bigger role here , focus on skills than marketing if they have to get out of vicious circle from vendors i am open but better than them so take me,OSS)%20and%205G%20core%20technologies.&text=They’ll%20also%20jointly%20develop,artificial%20intelligence%20in%20the%20RAN.

3. Open RAN is a reality and not a theory , see our latest efforts in O-RAN WG3 and in TIP Open RAN 4T/4R

4. There will be minimum 40% Cost savings on both RAN and Transport with Open RAN

5. Integration on RAN will be a bigger challenge and somehow different than in Cloud , as today services provided by same H/W vendors we need to carefully prepare service delivery when multiple vendors and focus on

  • SLO/SLI for MV components
  • Testing and Certification
  • Life cycle Managmeent like upgrades and scaling
  • Can we plug play all components or a few

6. DSP , Silicon will be the key as current virtualization is only suitable for 4T/4R macro sites , we need to figure our Massive MIMO 64T/64R with 5Gbps per site will require high processing power on front haul and DU

7. Coverage and capacity both are important the question we need to solve is whether same site in traditional RAN like DBS will give same coverage as Open RAN in high multiplexing architectures , i think its not possible today but with DU becoming more powerful and Edge DC’s becoming a reality we will overcome it in TIP Trial planned in Q1 2021

A recent research report from ABI research with excellent thoughts and direction is below

Below you will find the finding from Market in Middle East based on analysis on green field networks , often the RAN guys think Open RAN can not interwork well but what i want iterate all of below challenges already we are addressing with in O-RAN and Open -RAN

Security Framework to Secure Online Education and Remote Workers

The Recent report by Cisco reveals 250% increase in security attacks since Covid-19 Sets in . It required a new paradigm of how to secure our online presence

A part from increasing attacks the factors like Government encourage to not using VPN and presence of public Wifi make the whole story more horrible .

Cisco Latest Umbrella Offering is the answer to these challenges with subscription SaaS Model and options of Delivery whether onprem or on the Cloud it is best suited for both home and Enterprise customers .

Logically Umbrella only requires DNS re-routing

Finally the Provision of policy manager to manage and subscribe to policies like Parental control and URL filtering for business and personal use is something important both from security and improve efficiency on line .

SaaS offerings for Security is the answer and for sure Cisco Umbrella is a good solution to adress that .For Details please refer to

Cyber Security for 5G and Cloud World

New Cybersecurity Companies Have Their Heads In The Cloud

Cisco Latest report quantifies in 2019 1272 breaches that exposed 163M customer records . In a 5G and Cloud connected world to adress security concerns 5G Security SA5 and community defined some key principles that we must adhere to build dis-aggregated Networks .

1. Use of SUCI (Subscription concealed Identifier) to ensure even during first Latch the subscriber ID is not sent as plain test

2. 5G Auth and Key Agreement uses private/public key something very familiar to Cloud hyperscalers to grant resource access

3. Before device join network the Core will validate device then the device authentication start (This architecture make use of AMF ,UDM and AUSF and SEAF)

4. Use of Network Slicing in NPN and Public NW to ensure only users can reach his service slice only

5. To solve issues that limit operators use of encryption on Iu interface is addressed in 5G with the use of Data validation to ensure even protected streams can have integrity check

6. The New SecGW (Security end point GW) to tunnel the Radio GnB traffic directly at access/metro

7. API and Digest level protection for MEC and Developer system combined with security DDoS ,Malware protection

8. IdM and HSM for Infra security

For details refer to latest info graphics from Samsung

#Cyber #Security #Cloud #Infrastructure

Using Cloud and AI to Differentiate your 5G Investment

Source: Disney

In a recent Webinar about how to build a successful 5G networks a question that took my mind was .

“How successful we can be if we address a fundamentally new Problem using a new Technology if we still use old principles to build our Telecom Networks and with out disrupting the supply chains”

I think the answer for these type of questions in the context of 5G fundamentally will depends on following two key initiatives.

  1. How to use Radio spectrum to gain strategic advantage over competitors
  2. How to use Cloud to gain advantage for 5G

The Radio Spectrum is a complex topic primarily driven by many factors like regulatory and existing use of Spectrum making real 5G a slight different than what is really possible with Spectrum of today . This alone is not enough as Smart cells vs Wifi6 will be again something that will really depend on Spectrum use of 5G .These details i will leave it for now for future discussion and want to focus on Cloud and how really it will make your 5G successful.

During our recent work with in ETSI NFV Release4 Sol WG , GSMA and LFN CNTT we have discussed and agreed on a number of ways really Cloud can support you to differentiate your 5G network . Knowing this can be a real game changer for Opcos who are investing in 5G and Future Networks


A homogeneous Infrastructure Platform on 5G that can be used by all applications like traditional 5G CNF’s , MEC , Developer applications and any legacy IT /OTT applications that are required to be offered to users . One such example is OpenShift or VMware Edge and Last mile solutions using technologies like CNV or VCF7.0/NSXT3.0 that will build the edge clouds in an automated manners and enable day 2 through standard tools whether use VM or containers or BM’s as a baseline architecture

A uniform IPI that can be deployed using standard Red Fish solutions such as the one from HPE really will make is possible to build 5G using the Clone technology as used in most automotive industry today and that really enabled them to produce with minimum toil


Scalability in the last mile is the most important criteria for 5G Success . For example a compute solution that can scale and can provide power to process really all sort of workloads at the Edge is certainly a make or break for 5G . When it comes to Data one such example is storage and Disk , with solutions like RedHat Ceph3.0 that supports compression from Q3 2020 using its blue store offering and can integrate CephFS with NFS support makes the real convergence possible .

Convergence vs Automation

IT SRE and DevOps has gained lot of traction recently and this is not without a reason . It has certainly reduced the CFO bills and that is why the Telco’s want to achieve the same . However the requirements of workloads are really unique and that makes us to understand that real automation with out standard modeling is never possible .

On the Cloud side we can make use of TOSCA models together with solutions like automation hub together with secure catalog and registry means we can do both modeling for varying workload requirements and to automate it in the same fashion . Further we can do some advanced testing like the one we have been doing in PyATS

Registries and Repositories

The concept of 5G factory that we have been rigorously trying to achieve in Middle East Telco projects are really made possible using secure registries like Quay for containers , Dockerhub and its integration with Jenkins and CI/CD tools for Telco.

It is no surprise if i tell you these are most important differentiators as we introduce public clouds for 5G


The programmability of Immutable infrastructure is the biblical principle for 5G Networks . Both Service Mesh , NSM and Server less are deployed as operators which a practically CNI programs that makes your infra follow software YAML instead of tight and coupled instructions .Further to that the Operator supports full automation of both day0 and day2 Infrastructure tasks .

For K8S it is currently supported while for VM’s it will be available fully in Dec 2020

Openshift service mesh for 5G CP CNF’s is possible today with

  • Istio
  • Grafana
  • Prometheus
  • Kiali
  • Jaeger

Further to that today we faced a number of issues in Docker to Telco and use of CRI-O and PodMan will certainly support to advance the 5G .

“Podman is more light weight compared to CRI-O so you should expect it better performing on 5G Edge compared to PoDman .

5G Integration

Redhat Fuse online is one of solutions which abstracts Infrastructure and make it possible to integrate developer , integrator and tester using one tool . Except of container it also standardized your VM’s . E.g VM in Openshift running FTP service and that make it possible to run on native containers itself .Fuse Online provides a data mapper to help you do this. In a flow, at each point where you need to map data fields, add a data mapper step. Details for mapping etc

Red Hat® Fuse is a distributed integration platform with standalone, cloud, and iPaaS deployment options. Using Fuse, integration experts, application developers, and business users can independently develop connected solutions in the environment of their choice. This unified platform lets users collaborate, access self-service capabilities, and enforce governance.

An SDK is definitely helpful for 5G platform specially when it comes to open your networks for the developer who need .NET or JAVA . Quarkus from RedHat is a Kubernetes-Native full-stack Java framework aimed to optimize work with Java virtual machines.

Quarkus provides tools for Quarkus applications developers, helping them reduce the size of Java application and container image footprint, eliminate programming baggage, and reduce the amount of memory required.

Advanced Cluster Management

With huge number of 5G sites and future scnerio of site sharing between operators . It will be a real need to deploy Apps and manage them in a hybrid Cloud scnerio and nothing explains it better than burr sutter demo at the RedHat summit . A cool video from RedHat team is available there if you want to learn it more

In a summary you can mange

  • 5K+ poD’s
  • Create clusters in hybrid cloud like AWS,GCP,Azure, Bare metal and On prem
  • Policy management
  • Secure deployment by validating YAML and images using Quay/clair sorted by Labels
  • Possibility for developer to create and deploy policy using GUI

Above all RHACM makes is possible to measure SLA of Clusters and Optimize workloads e.g shift to other clusters in an automated manner .Certainly a Cool thing for 5G to serve heavy lift and Content driven applications

Heavy Lifting of Workloads

The proponents of silo vendor solutions often tell us that 5G Base band processing and e-CPRI heavy lifting with parallel processing will make X-86 a non practical choice to adopt classical cloud way .

However the latest Intel atomic series with FPGA’s and NVIDIA GPU’s means we can not only solve the Radio issues such as the ones we are trying to solve in Open-RAN but will enable to introduce latest technologies like AI and ML in 5G era networks . Those who are more interested in this domain can refer to latest work in ITU here

For ML/AI use cases in 5G there are many made possible in both Telco and vertical industry like Automobiles, warehouse monitoring etc today using GPU operator , Topology manager like shows visibility in to GPU ,NIC,BW,Performance etc.

Open Policy Pipeline can optimize the ML model itself using analytics functions of the Cloud

When it comes to Cloud value to data scientist in 5G using platforms like OCP or HPE Blue Data as follows

  • Anaconda tool sets for programming
  • Jupyter notebooks
  • CUDA and other similar libraries
  • Report on both Log and Policy compliance
  • Tekton Pipeline in OCP for CI/CD of ML/AI use cases
  • Models are made in Jupyter by scientists while it is triggered in the Tektron pipeline

Finally using OCP Open Model Manager we can Register, deploy and monitor open source models in one central environment, uniting data scientists and IT/DevOps.


The most important takeaway is that if we have to take full advantage from 5G we not only need to follow 3GPP and traditional Telecom SQI’s but also those advantages offered by Cloud . This is only way to not only manage a TCO attractive 5G but also will enable to introduce both Niche players and new services that will be required to build and drive a Post COVID-19 world economy .

The Top 7 Tools for Developers to Move Applications to the Cloud

Source: CNCF

Are you a Software Architect or a Developer who want to model everything a code.

Or may be you are a developer who want to know how best to move my code to the Cloud in a secure and automated manner. Here are the Top 7 Tools and why you should use it

1. Kubevirt (To run VM’s in Containers using CNV plug-in)

2. PodMan ( A daemonless tool to run containers using OCI

3. Cri-o (Container run time that makes it possible to integrate multi vendor solutions using OCI compatible interfaces)

PodMan and CRI-O are container engines. They are front-ends to manage local containers. PodMan is designed with system administrators and developers in mind, while CRI-O is designed to satisfy the requirements of Kubernetes alone

4. Buildah ( A tool to build OCI images quickly . Easy to incorporate into scripts and build pipelines, and best of all, it doesn’t require a running container daemon to build its image.

5. Quay (A container registry and Repo holder to stores, builds, and deploys container images

.It analyzes your images for security vulnerabilities, identifying potential issues that can help you mitigate security risks

6. Skopeo( A tool to implement CI for container Images . It can inspecting and transport images,It can also copy container images from one location to another. If you want to copy an image from your laptop’s local docker storage to the local CRI-O container store .it can be done also.

7. Ansible A tool to automate Infra using simple YAML playbooks. it can manage both Linux and Windows above it its support of Python and large Networking libraries makes it a cool choice for both Infra and Software .

Finally never forget you need a CI pipeline for all your Apps also so use of Jenkins and Terraform is important .we need to see tools not merely as Infrastructure automation but also as Infrastructure orchestration

Running Containerized Applications in a Cloud Environment

The use of containers and kubernetes in the industry has made a decent progress since the first time it first made its way back in 2013-2014 . However there is still lot of enigma around its use in a production environment . Recently there is a OpenDev workshop organized by Openstack where many domain experts from the industry including Telcos,vendors,system integrators and Enterprise spent a handful of time to clarify many of mis-conceptions and share experiences about how to use in a large scale Enterprise of Telco Environment .

The Purpose of this paper is to share some key insights around this .

How to use containers

There are different industry use cases that need to support different scnerios of deployment . For example some common views are follows

Telco Architects think the containers must be deployed on top of Existing Clouds mainly Openstack or VMware VCF (Through Pacific Project)

Enterprise folks believe containers should run with or without Kubernetes . Mainly wide use support on bare-metal is required

Application or IT guys think everything should run on Kubernetes (A.k.A K8S) . This is same view as the Developers

Build and Test Images

To build images there are different approaches and best approach is to give as many as possible flexibility to the Developer by using base images from where to build . However some best industry recommendations are as follows

  • Start from carrier grade images like CentOS . Although it is a little Fat image but it will offset time in troubleshooting and enhancing , a definite value
  • Second best aproach is to extract images using Mirror Tags like CoreDNS . This is a favorable direction from IT/Developer view point
  • Other approach it to use simple images but with complete support on build utilities , E.g Debian Selenium
  • Use of minimum base images like Alpine is also one direction depending on use case

Once the images are built the most important process will be to test and validate them , for this also our best suggestion is to

  • Start from base images (So that minimum certification cases already tested)
  • First check everything , the deployment approach
  • Run tests in isolated environment first following by multi stage CI to separate test from production
  • Use Utilities like buildX that can support both X86-64 and AMD Architectures


Which Registries to use in Cloud again depends on use cases and industry .For example for Telco the customer wants to have something adaptable with open stack so use of Zull registry is common followed by obviously Docker and Goharbor . Zull is specially convenient as it can tag/push images to docker hub with Zull jobs with wide use of image scan support using Clair

Container Runtimes

Docker is still believed to be the native and widely support run time environment specially in its Enterprise offering from Mirantis . The PodMan from RedHat is specially taking popularity however there are still a number of behavior issues in PoDMan specially on bind mounts and that need to be standardized before this move .OCI and CRIO are taking wider community support and i believe by Kubernetes 1.19 they may surpass PodMan .

For Telecom industry due to tenant isolation and security requirements the use of Kata is important , for some workloads like vIMS , vMME it becomes not a matter of software but regulatory to use certain architecture over other .

Deploy Containers in OpenStack

When it comes to deployment of containers on open stack there can be many approaches like in case of Magnum to build a Kubernetes controller or as simple as just a kernel configuration file using a set of utilities like Spyros that ensure complete LCM and fast deployment of containers on VM’s .

Similarly containers can use storage from Openstack in a number of ways including

  • Cinder API
  • Manila using NFS or Ceph FS
  • Open ebs
  • etcd

Obviously like in openstack the ephemeral storage has disadvantages like you can not know the implementation of provider and that is why implementation using Ceph3.0/Rook looks like the best direction in a hybrid cloud environment

Using the Containers

Networking and exposing containers outside is still a debatable topic and shall be the subject of separate writeup primary due to reasons that many workloads are still stateful and NIC is not floating instance for many workload specially in Telecom . Having said this still there are some suggestion to access containers in a stanard way like

  • Use of Floating IP like in Calico and Flannel
  • Ingress
  • Customer CRD’s
  • Octavia

Again if we are deploying these solution on openstack we may need to use some encapsulation solutions like Kuryr to avoid double encapsulation or disable port security and supplement it using kube router or calico

Cloud Provider SIG

If you are a Telecom provider who already built Telco Cloud in recent years than this will be something really important for you as Cloud Provider supports a way to integrate Kubernetes (K8S) in Openstack using a number of cluster management tools like

  • Magnum
  • Kubermatic
  • Gardener
  • KoPs
  • Cluster API

HPC and Scientific SIG

HPC use cases are becoming extremely important in Telco’s primarily due to ushering of new Tech wave and use cases around Cloud and 5G .

NVIDIA T-Series GPU is specially popular to run ML/AI workloads in Telecom . It can support high performance on VM’s using efficient resource utilization like 1:4 and for containers 1:8 by exposing GPU’s to VM’s running Kubernetes . In addition for special use cases like GIS and Image profiling can support pass through like the famous SR-IOV use cases of Telecom 5G CNF’s like UPF .


In a nutshell the containers are ready for production . However just like other cloud solution there is no one picture that fits all screens so a careful selection of components and solutions is required to ensure maximum advantage coming from the Cloud .This is why to ensure as community and industry we do not miss the boat like somehow we experience in Openstack VM journey it is very important to define and standardize both the consumption models and deployments scnerios that can support to achieve a real carrier grade evolution to containers .The Cloud iNFrastructure Telco Taskforce (CNTT) has recently launched new initiative to help bring focus on cloud-native network functions (CNF) and Kubernetes based platforms. A working group within Reference architecture 2 ( K8s based ), RA-2 has kicked off a short survey to collect data on Kubernetes adoption in telecom. The link is below , i do expect you will play active part to share your insights to uplift the infrastructure to the Cloud Native era .

Enterprise and 5G Software Application packaging using Helm

Enterprise and 5G Software Application packaging using Helm

Always great to start as a programmer


As most prolific developers consider Kubernetes as the future platform for application development , obviously against odds of Project Pacific . It is certainly worthy to know a platform that holds the future by learning how to best use it .

An investigation in to Kubernetes platform will reveal that although Kubernetes as platform is a kitchen with Recipe for all sort of applications in any vertical  however things can become very complex as we implement H/A , Load balancers  and other complex scnerio each of which require its own YAML definition and instance creation. In addition, as we apply more and more complex concepts like node affinity and taints it becomes more difficult to remember parameter definitions and to build configurations. Then in addition to this there are so many tools both in community and provided by partner distros followed by Geeks who are always willing to build their own tools so question is how to unify and address the challenges in the most efficient manner.

Can I use a collection of tools like Ansible + Mesos + Vagrant + Helm to use the best of all solve the Infra provisioning and monitoring issues?

 Obviously, no one tool can satisfy all but how to unify the pipeline and packaging and where to start, let us discuss some details to solve these very vital issues of future infrastructure. Most of these tools like HELM are available in community to accelerate development and find and fix bugs. Users of these tools also share deployment playbooks, manifests, recipes, etc  distributing via repos like GitHub and build platforms like Jenkins , mostly community and partners hardened this knowledge and also share it on secure and trusted repos and libraries like Ansible Galaxy  to which reader can refer to following to get more details


Source: RedHat

All of this require a novel approach to manage the containerized infrastructure , HELM® which is a seed project with in CNCF® is a packaging solution that can address most of the challenges defined above . Just like Kubernetes it also supprots operators through which vendors and ISG can publish their software artefacts and packages to onboard it . This is also a way through which 5G CNF will be onboarded through NFVO (NFV Orchestrator) to the Infrastructure. This is exciting way to manage applications through easy to play charts , template files and easy to manage and control dependencies .

So let us try to understand some key concepts on Helm charts and Helm Operators.


Source: RedHat

Helm Charts:

A Helm chart is a single repository or artefact that contain all objects like deployment , services , policy , routes ,PV’s etc into a single .tgz (ZIP) file that can be instantiated on the fly . Helm also supprots aggregation concept which means you can either deploy each micro service or a collection of them altogether through one deployment process . The later is important specially in Telecom CNF’s . A good collection of helm charts are available at which we can customize and also integrate with CI pipeline like Jenkins to do all operations on the fly .

When it comes to telecom and 5G CNF’s it is important to understand following terms before understanding contents of the package


Source: K8S and ETSI NFV Community


Source: Kodecloud and Project experience

Chart: A collection of resources which are packaged as one and will be used to run an application, too or service etc

Repo: A collection like an RPM used to manage and distribute resources as packages. Satellite can be used to integrate both VIM and CIM Repos in a 5G world

Release: A helm supprots to run a Canary release in a Telco environment, each time a chart is instantiated obviously including incremental changes each time will be considered a Release

Helm latest version is 3.0 release in ONS North Americas In Nov 2019 and includes a major change like removal of Tiller (Major security bottleneck) which was major impediment to use helm on more secure clusters.

Just like VNFD and NSD which follows ETSI ® SOL1 and SOL4 which defines VNF packages and its structure using TOSCA in Kubernetes we follow helm chart standard which YAML descriptors and structure that can be instantiates using helm create chart name , further it can be enriched and customized as per need , the mandatory manifests are values.yaml contains details like IP’s ,networks , template.yaml consumes the values ,chart.yaml the master file to manage charts , NOTES.txt  a comment files and Test.yaml to conduct chart testing once deployed . requirements.yaml is a file that list the dependencies

Happy and ready to apply your own helm charts , then try this out .  Although helm charts provide an easy way to manage applications however not all the changes are acceptable directly specially for the case of stateful CNF’s which are very relevant to the Telecom use case. In this case we need to use the Helm operator which first version 1.0 is GA now and let us discuss its key points below. Similarly Kubernetes operator need to be installed first via CRD’s , Helm charts behave in the same manner with a difference it is installed using Software developer provided charts .

 Helm Operators:

A helm chart and its packaging can be compared to Functions of Kubernetes operator which makes it easy to deploy and manage application across its life cycle using CRD and customer defined definition .

The helm operator is doing the next step of what Kubernetes is by enabling complete GitOps  for helm .It focused on defining a custom resource for the helm release itself thereby making it simple to manage complete artefacts as it is being deployed and managed .

As of April 2020 following are major features already added in Helm1.0 Operator

  • Declaratively installs, upgrades, and deletes Helm releases
  • Pull charts from anychart source;
  • Public or private Helm repositories over HTTP/S
  • Public or private Git repositories over HTTPS or SSH
  • Any other public or private chart source using one of the availableHelm downloader plugins
  • Allows Helm values to be specified;
  • In-line in the HelmRelease resource
  • In (external) sources, e.g. ConfigMap and Secret resources, or a (local) URL
  • Automated purging on release install failures
  • Automated (optional) rollback on upgrade failures
  • Automated image upgradesusing Flux
  • Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade
  • Detection and recovery from Helm storage mutations (e.g. a manual Helm release that was made but conflicts with the declared configuration for the release)
  • Parallel and scalable processing of different Helm Release resources using workers


Helm Operator can also work with other Kubernetes operators and address any dependency constraints infact all those can be expressed as part of the Chart itself. This is certainly needed in CNF’s and Telco use cases where there are lot of dependencies between API versions and cluster components for all rolling updates and each of this will require testing and validation. Traditional Helm obviously can not address it and it is almost impossible for user to address all such changes in an ever changing and complex world of network meshes, Helm operator ensures these requirements are fulfilled with in the GitOps frameworks.

Helm basic commands:

Below is a good jump start to some of basic helm commands .

  • helm repo add

command to add a helm chart from a repo

  • helm create chart-name

command to add a helm chart , a directory with basic files

  • helm install –dry-rundebug ./mychart

Run dry run to install and show debug instructuctions

  • helm package ./mychart

Will prepare the .tgz package and a user can install the application from this package.

  • helm get all UPF -n CNF

Will retrieve the details of application deployed via helm in a give NS

  • helm –help

Want to know all just try it out


Although I have explained the Helm and Kubernetes in a way that one can believe that Helm chart is the replacement of Operator which is not the case. Infact the Helm is mainly aimed to deploy and manage Day1 tasks while still along the LCM of application you rely on CRD’s and Operators with one caveat why I do not like is that each time a new CRD we have to install and manage them. It will definitely change over time as Helm operator will target to resolve for most of day2 issues and that’s why I will encourage to get involved in Kubernetes SIG community.

Finally, as we will standardize the Dev Pipeline for Telco’s as well which is still too much invisible to us it will enable us to build hybrid cloud environment that will certainly solve so many fundamental architecture and business challenges. As an example, in the COVID-19 scnerio so many of the business face challenge to expand their networks to cater for increased load. If Telco’s already have figured out this pipeline it would have been both economical and responsible to share load between Onprem and Public cloud to address the hour need. This is why the journey to Hybrid cloud and software package standardization and delivery is too vital for both growth and sustainability of the Telco industry and national growth.



@Oreily Kubernetes book sponsored by RedHat

The comments in this paper do not reflect any views of my employer and sole analysis based on my individual participation in industry, partners and business at large. I hope sharing of this information with the larger community is the only way to share, improve and grow. Author can be reached at