- Welcome everyone, and today we'll be talking about
automated digital operations utilizing the power of cloud.
Before we start, let's start with a simple introduction.
Maybe I'll start with you, Aymen.
- Yeah, absolutely.
Thank you, Vara.
So Aymen Saidi, I'm a principal solution architect
within the EC2 Edge 5G team
mainly focusing on new 5G initiatives.
- Bejoy?
- Hi, Bejoy Pankajakshan here.
I run technology and strategy for Mavenir.
- Awesome, Rabi?
- My name is Rabi Abdel.
I lead the automation security practice at AWS
working with customers,
helping them automate and secure the workload in AWS.
- So let's start the conversation.
Bejoy, you, Mavanir has a vision of one network,
all software.
Could you walk us through the vision, please?
- Sure, first of all, thank you for having Mavenir here.
So Mavenir is around 15 to 17 years old now.
So we started as a software company.
So for us, always having our products and software
and optimizing software is very important.
As you know, Telco operators started
with private network deployments
and we need to make sure that a software is well-optimized
with the best footprint to run on private cloud.
And the last five to six years,
I would say, you started seeing more interest
in hyperscaler public cloud engagements.
With for hybrid cloud deployments
or for just disaster recovery kind of scenarios.
So making sure that our software can run
in the private cloud as well as in AWS
where we started our initial relationship,
primarily with Dish as a customer,
a joint customer for both of us,
doing the first open round based deployment.
So it kind of really drove us
towards getting our products optimized
and getting beyond the proof of concept
which is where most of the industry was at that time.
You know, we have been doing a lot of proof of concepts
to validate that this thing can run in the public cloud.
Telco workloads can actually run in the public cloud.
We took it to the next step in terms of realizing the vision
of productizing and running it in a public cloud like AWS.
Of course for us, it's also about making sure
it's a multi-generational technology.
So working across 2G, 3G, 4G, 5G technologies,
all in software for us.
And the third piece of it is being able to run it all
in software.
- Awesome and I mean the great journey that we had with you,
we are really thankful for that.
Can you talk us through how AWS
was helping with your vision?
- So the first part of it is, as I mentioned,
it's about productizing the application.
So it's one thing to put it in a piece of paper
and say, claim that we are a cloud native company
and we can run in multiple cloud environments,
private or public cloud.
The next thing is actually investing in that
to productize our products for getting the best performance
and making sure that's integrated natively
into the tools that the hyperscaler provides
because a lot of talk in the industry
about getting to lower cost,
but unless you use the tools that are natively available
in AWS, eliminate the underlying infrastructure
which would come from third party.
So we did not choose to deploy on top of a VMware
or Red Hat stack on AWS.
We deployed natively on EKS
which meant that you're eliminating a third party there.
And on top of it, when we integrate with EKS,
you need to make sure
that I'm using the tools that AWS provides.
A CI/CD pipeline was very critical for Dish
as a Greenfield operator,
making sure that they leverage all the benefits
of automation.
So getting that in and integrating it
helped us accelerate get to our vision
of being able to demonstrate our product readiness
in true GA quality across our full portfolio.
So including RAN, Packet Core, IMS, messaging, voice,
et cetera, running in a public cloud environment.
And now we are much beyond Dish.
Over the last three to four years,
we've evolved it to multiple customers.
The engagement has been pretty successful.
We see requirements in Europe, for example,
from Telefónica to deploy full IMS there.
The requirements there actually helped us
evolve our products as well in terms
of being able to run on top of Graviton.
So everything earlier was x86 instance-based
so we had to invest in making sure
that these products which work well
and are optimized on Intel x86 instances,
can now, even the software stacks
that come from third parties are optimized
to leverage the Graviton feature set.
So that's also helped us differentiate in the market.
Again, some of our competition
that's still doing proof of concept
but has got a lot of external marketing behind it.
- Awesome, thank you, Bejoy.
And truly that was a fantastic journey
that we went through with you.
And I was part of that working with your team.
Talking about the adoption of CI/CD,
I will turn to my colleague, Rabi.
Rabi, can you walk us through the journey
of zero touch automation?
- Absolutely, as being the consulting arm of AWS,
we work globally with our telecom operators
to help them transform the network on AWS.
I observed few challenges that the customers go through,
I can summarize them maybe in three points.
The first one is really the entry to cloud.
Now before the CSPs or the operators
can actually deploy their workload on AWS,
there is cloud foundation on foundation
that has to be doing in place
to allow them to connect to their OnPrem,
the account structure, the governance, the billing,
the security that they have to impose
to different part of the organization.
And that can be a cumbersome for operators
to use and build, that could take from six months
to one year to do that.
The second one is really the best practices
and as we say in AWS, there's no compression algorithm
for experience.
And these are the things that we learn
working with customers like Dish, for example,
how do we actually efficiently deploy workload in AWS,
leveraging best practices from everything
as a code, from DevOps, CI/CD pipelines,
using technologies like GitHubs as well
to implement the workload efficiently.
And the last one is really all about the tools and services
that can be used.
Now there can be many software tools and services
even in AWS that can be used with telecom operators.
And the question becomes which one,
which is is the right tool for the job in hand
that need to be used?
In ProServe, we actually built an internal framework
we refer to as zero touch automation
which is really a highly customizable framework
that is built to fit the customer need.
And the point of the Zeta framework
is to accelerate the path to innovation.
And the framework encompasses all the components
and elements needed to end to end,
automate the life cycle management of workload
and including the Minus One, which is all about security,
about the connectivity, the account structure,
and also the zero
which is really about the infrastructure automation
and the life cycle management,
taking advantage of CI/CD and GitHubs approaches.
And day one is really how do we deploy the workload,
whether the workload is written to use the GitHubs approach
or whether it is being supplied
as part of Tosca file for example,
this where TMB as a service that we recently launched
can be used for that purposes.
And finally, everything about the life cycle management
of the configuration, including the observability
and monitoring.
And this framework, in fact, if you look at the Dish,
for example, when we're at Mavenir,
we're able to deploy 600 CU of Mavenir workload on AWS
in less than four days.
And this really the power of the automation
when we implement it in real life scenarios.
- I'd actually follow up on,
that's a very good point that you brought up
on the 600 sites a day
because when we started this journey,
there were learnings on both sides, if you recall, right?
AWS brought the experience of having automated thousands,
millions of workloads for enterprises
which is slightly different
from the way Telco workloads start.
In terms of how management happens,
the high availability requirements of Telco workloads.
So I think that journey has actually educated both sides
in terms of understanding how does your CI/CD pipeline
need to adapt to support Telco requirements?
And the specific workloads, for example, on the RAN side
for CU, we talked about CU,
it's enabled us to actually get DISH to say we turn up
thousands of sites in a day.
It's actually, they say literally say
it's a thousand sites a day,
so everything is wired up.
And now with this capability, we are able to turn on,
once everything is wired and set up,
300 sites, 300 CU's, physical CNFs in in a day, right?
That sort of change was not possible
before we got to cloud native deployment.
So and this is a conversation that we continuously have
with the CTOs in all companies
and I was just coming off a meeting with the RMC group,
CTO Lauren and his question is,
is open RAN TCO still matching
what the traditional ones are?
And the answer is, OPEX is a key part to realizing the TCO.
There is some of the parts of the CapEx
that we are still working through,
but OPEX plays a key role in realizing that benefit.
When Taruget Rakuten says that I can remanage
my entire network of today's got close to 50,000 cells
on 4G and 5G, and we've got 8,000 sites in Dish.
Again, that's actually 40,000 equivalent cells
from Rakuten definition,
the way they count radios versus cells.
My point is that you're able to run that
with a very small subset of employees.
In the past, if you look at the ratio of operator,
number of employees managing the number of nodes
to how AWS does it, automation was the key.
It's order of magnitude is like 100x more
because if you manage a thousands of servers
with two or three people and that is an automation benefit
versus in an operator environment like today,
that's the challenge, even Brownfield deployments, right?
You have to retrain the existing employees that's there
that's not in tune with the methods of operation.
They're still used to the traditional mop method
where at night you schedule a window and do things.
And here you need to continuously develop,
continuously fail, relearn, and deploy fast, right?
So we are getting to that stage now
with Brownfield, at least a few of the early adopters.
We'll go through that curve
and we'll see at some point
that these laggards also catch up.
But absolutely, we believe that is the path to take
and automation is the only way to realize those benefits.
- Thank you, Bejoy, for Mavenir's awesome collaboration
in using AWS CI/CD.
As my colleague Rabi mentioned,
we have used AWS internal services and we are very excited
that we launched a new service called TNB.
Let me follow up with one question.
How are you integrating with service orchestrators
from TNB?
- Yeah, no, absolutely.
So AWS Telco Network Builder exposes APIs.
Rest APIs, solve three and solve five.
So we basically have the API for service orchestrator
to leverage direct calls to AWS.
We've demonstrated that as part of our demo
which is actually a multi partnership demonstration.
We integrated with an orchestrator from Cloudify.
The cool thing with AWS Telco Network Builder
is we also have SDKs that are available
for native integration with the application from Mavenir
and other ISVs.
So Telco Network Builder provide the experience
through the GUI, through the CLI,
through SAPI and through SDKs.
So that help our customer from an operational perspective
at the GUI level
'cause a lot of customer may not have the expertise
to start coding and really code use cases, right?
And then we have the CLI
for a little bit more advanced users
and we have SDKs and APIs
to integrate with third party application
because really, we understand that our objective
is just to abstract the complexity
of operating into the cloud.
And we want to enable our partners
and our customers to do what they do best, right?
Which is basically manage the network, right?
So the the optimization of the network itself.
But we want to provide you with the abstraction
so you don't have to worry about the infrastructure
and about the lifecycle management on the infrastructure.
So you can update the network,
you can deploy to the network,
you can upgrade the network,
you can use the versioning of the network function
and the network service descriptor
which make it easier for yourself.
Because, at the end of of the day,
you want to concentrate on the network function
and continue to innovate and bring new features
for your customers.
- That's great actually,
because I didn't get a chance to see the demo.
I'd like to see it right after.
But the way you guys have taken up that use case
of automation and turned it into a use case
that consumers could relate to.
I know that some of the challenges that we had initially,
walking through as we were building this product together,
the end result is really good
because what it helps us realize
is take these different workloads, use that tool set
that you guys had developed to run it natively in AWS cloud
and do it fast, leveraging your benefits, right?
Up until this point
was about our product running into pipelines
in private clouds.
So it's usually a VMware, Red Hat.
We have our own stack as well in tier one in the US
with hundreds of millions of users.
And we've gone through that experience
understanding what it takes to actually automate
and integrate these workloads.
So I'm excited that AWS
is kind of like the first hyperscaler
to come out with a Telco productized version of this.
So the learnings would certainly help both companies,
I believe, down the road as well
as we scale and try and deploy it across multiple accounts.
- Thank you Ayman, for talking about how we were integrating
with a service orchestrator, especially the API play.
I was really fascinated.
Bejoy, talking about APIs, right,
how is Mavenir looking at
moving towards an intelligent program build network?
- So I'll talk about it from a network perspective
and what we are seeing our operators actually do.
So just yesterday for us today, we had Abdul and Ulf
from T-Mobile and Deutsche Telekom
make an announcement about network exposure.
Directly tied to how you turn network into a platform
for new services.
So up until this point,
operators have always been just a dumb pipe.
So they put all the investment in for 4G,
billions of dollars investing in their network,
but then you have applications that over the top,
just went over because it was always seen
as just a connectivity pipe.
And the way you convert your network
from a connectivity pipe into an actual services platform
is you offer APIs
which means that the underlying products
which enable those APIs needs to be cloud native.
Needs to be microservice so it could leverage these APIs.
The good thing is, at least in,
probably this is, you guys are probably not involved in this
from where the Telecom industry has had a long history
of trying to monetize their networks through APIs
but were never successful
because you had the likes of Twilio and others
come in with APIs that the long tail understood.
And this should be no news to AWS
because you guys are so good at doing these APIs
and getting the long tail customers on.
Telcos are never successful in this.
So now there are new initiatives.
Something called Catalyst Project, Camara Project,
where they're trying to simplify the APIs
and expose capabilities externally.
So for example, this DT joint announcement with T-Mobile
and it's not just to two operators,
I just referenced it because it just was announced yesterday
and was was written a lot about it,
is Telefonica, there's many other accounts.
Dish, for example, they have their own play as well
in terms of network exposure.
So some of these initial use cases
around how do you get quality on demand,
how do you trace the user location through an API?
And it's slightly different
from the API that you just referenced
which is around the service orchestration,
solve three, solve five, kind of APIs
which is primarily around how you orchestrate
and manage the workload.
I'm tying these two together
because when you launch new services,
and let's take QoS on demand,
quality of service and demand as an example.
If I'm offering that API,
which is basically a turbo option,
where as needed, I can provide higher throughput
which means that I may need to scale out a network function
as and when it's needed
which is where the API
that you just referenced becomes relevant.
Because if I need to have a cloud native instance
spun up automatically and dynamically as needed
based on a triggered API call
that's exposed from the network,
you need the service orchestration
integrated with the network workload.
And this is something that truly was a vision
with OpenStack deployments, but never really took off
because the orchestration space was not really integrated
with the network.
And we are starting to see some early phases
of where orchestration benefits could be seen
in this cloud native network.
But that is truly the vision.
If we think about how we are looking at
a non-reactive network, a more proactive network
that's driven through automation,
then you need the orchestration is a big part of it.
- I want to add to that, actually,
'cause the work that we've been doing together
is extremely important, right?
Us showing that we're able to orchestrate the network
and the application at once is actually extremely critical
for the network API work that we're also doing.
And a lot of customers have been actually asking us,
how can I deploy the application?
How can I place the application
throughout the edge continuum to benefit from the network?
So us showcasing that we can use one common template
with very little modification ultimately
and the little modification is where do I want to run it,
right?
And with one little modification,
we can deploy the network and deploy the application
in the right spot so the customer can benefit it at the end.
- And rightly.
- So, that's amazing
- And rightly, the vision for AWS
is to make it really seamless
to deploy entire network on AWS.
Whether it is on the region or on the in the edge
or even on local premises,
encompasses services like Telecom network builder,
the one we launched.
So the focus can be shifted toward using the platform
to drive those Telco service API capabilities
and help CSPs monetize the network in a way
that will make it beneficial to them
and help CSPs monetize their network in a way
that will allow developers to have access
to their services
and deliver customer differentiated solution
to their customers.
- So thank you, Bejoy, thank you, Rabi,
Thank you, Aymen.
Really appreciate this exciting conversation.
Really, really inspired and how we can bring
automated digital operations
utilizing the power of cloud.
And truly marching towards the vision
of intelligent programmable networks, 5G networks,
and how we can enable these high end use cases
that how Rabi has talked about.
And you talked about the vision from OpenStack days,
everybody were trying to do it
and how we are truly coming to the age
where we can realize this self-healing,
automated operations, all these high-end use cases
that we can enable through through automation.
I'd like to ask if you can add one final statement
and share your final thoughts for this session?
- I think that a lot of investment has happened in 5G.
We are in the early stages,
but we need to monetize in 5G
and we talk about these use cases.
The way to monetize this,
you have to launch new services pretty fast
and that requires automation.
So I think it's key to the work that we are doing together
is going to be key to realizing that vision on monetizing 5G.
- Thank you, Bejoy.
Thank you everyone.
- Thank you Vara.
- Bye.