Amazon's CPaaS: Sid Rao talks about the Chime SDK

TalkingHeadz is an interview format series featuring the movers and shakers of enterprise communications - we also have great guests.  In this episode, we check in with Sid Rao, the  GM of Amazon Chime SDK. 

I fondly remember Biba, a WebRTC video/messaging startup . There was a lot of excitement over WebRTC about ten years ago. Biba was acquired by Amazon and relaunched as the Amazon Chime app in 2017. 

Chime was a lot like Webex and Zoom, but worked entirely in a browser. Both Vonage and CenturyLink (now Lumen) were early resellers of the meeting application.  The app worked well, but wasn't a bit hit. Vonage moved to its own video solution, and CenturyLink turned to apps such as Zoom and Teams. 

AWS discovered that its customers were more interested in Chime's underlying WebRTC than the meeting app. Amazon created WebRTC APIs,  effectively making WebRTC a service rather than a tech stack. This model was a better fit for AWS, so at its reInvent conference in 2018, AWS launched the Chime SDK.  

Then came the pandemic and a boom in most things video. AWS customers and partners used Chime to create all kinds of solutions. K-12 education, for example, needed video for remote education.  Chime obliged, and did so with simple hardware requirements for end users. Blackboard presented its success story at reInvent 2021. 

As for the original Chime app, it's been getting better thanks to new capabilities of the Chime SDK. The Chime app isn't particular popular,, nor marketed. It does well within Amazon, both as an internal meeting and chat app and with many of AWS's large customers. 

Transcript

god: 0:00

We can go ahead and go

Dave Michels: 0:12

look at the talking heads today we'll be talking with Cinderella Amazon chime but before that, Evan, how did you do a Thanksgiving turkey dinner?

Evan Kirstel: 0:19

You know, I had his gigantic Thanksgiving turkey dinner. I fell into a food coma and woke up in a another dimension of time and space.

Dave Michels: 0:29

Oh, it sounds like Irma won the wishbone competition.

Evan Kirstel: 0:34

I don't know what what time it is what day it is, but apparently we're recording. Now what is your favorite? What

Dave Michels: 0:39

is your favorite dish on Thanksgiving? Not counting the turkey. What is your favorite side dish?

Evan Kirstel: 0:44

You know, the side dish would be pumpkin pie. I enjoy that as a side dish to the actual dessert. It's just a side dish. It's not desert,

Dave Michels: 0:56

it's constable's mom's festival.

Evan Kirstel: 0:59

Pumpkins are good for you. Good for it. Speaking of things that are good for you, we have a guest with a lot of knowledge that is going to be good for you. So let's listen. Talking.

god: 1:08

It's a semi monthly podcast with interviews of the top movers and shakers and enterprise communications and collaboration. Your host are Dave Michaels and Evan Kirkstall, both of which offer extraordinary services including research, analysis and social media marketing. You can find them on Twitter, LinkedIn, or at talking points.com. That's points with the Z and Devon kirsten.com. That's ke r s t e l.

Dave Michels: 1:36

Today we have with us Sid Rao, the general manager of Amazon chime SDK. Welcome, sir.

Sid Rao: 1:44

Thank you, Dave. And thank you, Ivan for having me. I appreciate it. Thank you for your time today. I look forward to our chat. Yeah, this

Dave Michels: 1:50

is gonna be interesting. The chime SDK is the seapass that lurks inside of Amazon. But before we get into chime, let's get to know Sid a little better. I noticed your background includes some stints at Nortel and Microsoft, among others. But you had a 12 year run at something called CTI what does that?

Sid Rao: 2:11

Yeah, so CTI group was a software company that focused on serving telecommunication carriers. So we had customers like sprint or Cox business services or Vodafone was another customer of ours as well. I focused on providing hosted Call Recording analytics, transcription speech analytics services, primarily for hosted UCaaS service providers, as well as contact center as a service providers. And I worked with partners such as like a broad, soft or meta switch on some of the very early stints in providing business telephony and business context and our services in the cloud. And that's kind of the background that I that I kind of cultivated there. And that's after that I came to Amazon after the company was assaulted and trials group.

Evan Kirstel: 3:00

I moved to Amazon. Well, you have been around the block a few times. So when you arrived at Amazon, was the chime SPK already there or?

Sid Rao: 3:10

Oh no, absolutely not. Amazon, nine years ago had actually some pretty rudimentary communication services aide had it, it was his typical startup, everything had been kind of put together in a little bit of a rush to try to get some sort of a communication platform up for the business to operate. And that's actually where I first focused was on helping Amazon as a business manage their real time communication needs, such as sending out a text message when an order is being processed on the retail website, or ensuring that a public telephone network call can be delivered to a you know, to our context or services. So I was responsible for a number of real time communication workloads for Amazon as a business. And you know, when I joined there, it was probably about 40,000 information workers and very rapidly it had grown many times that in terms of size, and the company's real time communication needs expanded with that accordingly.

Dave Michels: 4:14

So so just curious, what was your original title at Amazon?

Sid Rao: 4:18

Oh, my original title on Amazon was I was the software development manager in charge of unified communications at Amazon. That was the official title I was given. So you completely

Dave Michels: 4:29

failed at that image of GM of the time SDK. Is that fair?

Sid Rao: 4:34

That's absolutely fair. I'll take failure as a as a reality point. We actually learned a lot as a business in terms of how to manage these real time communication services at scale. And eventually we got to a point where we felt like we could use those learnings to help our customers and that's actually how we really got into the real time communication service, you know, business as as a as an organization, and we've done that in multiple different ways, the Amazon chime SDK which we're going to talk about today, but also Amazon Connect is run by a peer of mine called Pascal IO. And where we used our learnings, the context in our business to provide a full, feature rich context Center as a service application for enterprise customers like cap one are into it.

Dave Michels: 5:23

Well, before we get too much into the chime SDK, I want to ask you about Max and Hawk, you know, they were our first choice for this podcast, but they referred us to you as their spokesperson. They have a pretty nice Twitter feed.

Sid Rao: 5:35

Oh, yeah. So Max and Hawk are by my pretty much the apart from my wife, my dear wife, who are kind of the center of my little universe, and they've been with me on this real time communications journey at Amazon. So to two shits is that occupies a large amount of my mental capacity every day other than worrying about how to, you know, make sure that audio and video, you know, streams for millions and millions of daily active users every day. Yeah, Max and Hawk take a large amount of mental capacity for me.

Evan Kirstel: 6:07

And I saw Max and Hawk last time on as we were doing a video not not a podcast. So I'd like to collaboration, you know, hashtag golf to Twitter is kind of the big thing. We can even get the blue checkmark for only $8 These days, apparently, yeah, evidently. So what say you about Twitter and Alon these days? Or would you rather no comment,

Sid Rao: 6:27

I tend to focus on kind of customer needs. I've I've given up on trying to speculate on these whole social media acquisitions and new organizations. But what

Evan Kirstel: 6:39

I will not answer here.

Sid Rao: 6:43

What I will say, though, is I do I do really empathize with the 1000s of tech workers are now finding themselves completely shaken up from a career and life perspective, because of all the churn going on in our industry. So that is very unfortunate. And this is why it's important as leaders to be careful about how we hire and how we, you know, not to get too caught up in this in the storm of kind of the tech enthusiasm and frothiness that we see in our industry.

Dave Michels: 7:13

It's not so much how we hire it's who acquires us in that case, but maybe you can't comment on it. But have you ever talked to Twitter about doing a click the call option?

Sid Rao: 7:22

So I cannot talk about a real time communications workload at Twitter, but we definitely do help. You know, social media companies like and, of course, collaboration companies with exactly that workload. So one of the public use cases I can talk about is slack huddles. So slack did exactly that, in terms of, you know, creating a virtual audio space, it started out as just the audio space, it's now a video space in a content sharing space within a Slack channel. And it's quite an innovative use case. You know, they themselves say it's their fastest growing feature ever in the history of slack, which I was, I was super stunned to see that. What we're really excited about there is we were able to take away that undifferentiated heavy lifting of figuring out how to make audio and video streams in real time, you know, with around the world and 18 global regions, and automatically scale so that slack didn't have to worry about all those infrastructure challenges and could instead focus on the user experience and their customer experience. And it's because they're able to focus on their customer experience and not worrying about putting a bid on the wire. They're able to differentiate and innovate at a speed that really keeps their customers happy. And that's why I think we're seeing services like Slack. huddles be so successful.

Evan Kirstel: 8:43

Yeah, I actually like cuddles. I like Twitter spaces, which is their drop in audio service. I like clubhouse. I mean, I can imagine we're gonna see a lot more video and communications coming to all apps. But I guess you agreed on that.

Sid Rao: 9:00

I'm a little biased on that one, of course. Yeah. But yes, I I do think that because of services like the Amazon chime SDK, we're making it easy for developers to manipulate real time audio and video, and especially to real time collaboration. It's no longer left to the elite few who could operate big development teams like Cisco WebEx or zoom or the Amazon chime application for that matter. We're democratizing the ability to add collaboration as a capability, or browser and mobile app communications as a capability into the hands of any web or mobile developer out there.

Evan Kirstel: 9:39

I'd love to see a service where you know, website publisher, let's take a Washington Post and you know, could have a real time chat attached to a leading story. So people could jump on read the article and then chat with other readers or message in real time about about what they read

Dave Michels: 9:58

and you're gonna have to read the art trickle you just just read it, you know, he's always looking for a way out. So I want to get back to the little bit of the historical archives here. Because when chime was originally launched at Amazon, it was a zoom like, you know, meeting and chat application. And it was based on Amazon's 2016 acquisition of Beaba. How in wind chime become an SDK?

Sid Rao: 10:26

And that's a great question. So you're correct. Amazon chime initially started as an application and focused on enterprise collaboration needs. And it was about two to three years ago, we really started to get a number of inquiries from customers like a slack at the time eventually became Salesforce, Cerner on their telemedicine front in a number of different organizations. Mitel, looking for ways to add real time audio and video capabilities to their apps. And you know, for the longest time, we really were focused on Amazon chime as an application. But we started to see in around that time was also in the COVID shift was had not occurred yet. But we were starting to get a hint that look WebRTC audio video based services are going to be something that is going to be a part of any application, it's not going to just be something that is isolated to just the specific large monolithic applications like a Cisco WebEx or, you know, or even a zoom. When we had that insight, and our customers were telling us that we started to really dive in and pay attention to their needs. And this is pretty typical AWS, we we start to ask what are the unmet needs in that space. And some of the unmet needs we had were around security, being able to provide that video collaboration experience in a FedRAMP, moderate environment, within the government application that say a large hospital who serves government employees needs to be able to provide, you know, in the case of slack as well, they have their government version of slack, and it needed to be FedRAMP compliant as well. So we had some security things that started to creep out. Another thing that started to come out was, hey, said, We need to be able to do this in a very global way, support 18 regions across the globe. And we don't want people to be using a separate application, like chime to join a classroom or join a telemedicine session. Now, we really want the customers to be focused on our application, we want them to be in our application. So there was this need to make sure that the video collaboration capability was actually in the app, it could not be a separate application. So that started to take us by a little bit by surprise. And then we started to see unmet needs around machine learning integrations with transcription services, so that in one case, a company who focuses on people who are hard of hearing, we're we're looking for very accessibility focused version of collaboration for their particular customers. So we really started to get a number of use cases and workloads where customers were looking to add communication capabilities to their apps versus using our application. And this also really focused well on AWS as core competency and serving builders, we, you know, if you think about AWS, as a company, we work with builders every day and application developers and application builders. So we started to see a correlation between the common customer base of AWS and the need to have these communication building blocks to add to their applications. And that's how basically, the Amazon chime SDK was formed, was we said, how can we take the capabilities of the great application we had built here and give them to the builders so that they can add those capabilities into their own applications, whether it's a video based browser chat service, or in the case of Evan was just describing like a real time chat, at the end of a newspaper article? Well, I'll give you a great example that Samsung has a watch party app, for example, where they're you're allowed to chat with people in real time based on a television program in Korea. And they're using the Amazon chime SDK for that chat use case. But we also handle kind of those public telephone network problems that are out there still, because the PSTN is still the most interoperable audio capability on in the world today. So we still also have to provide some of that programmatic capability for the PSTN. So our customers, you know, for that those security reasons, those global reach reasons as machine learning reasons, pretty much drug us from being focused on an application to being focused on these building blocks. And because we had the experience of building the app, we knew what were the building blocks that would be most helpful to customers to build The rich applications that they're trying to build, said helpful, Dave, in terms of the backrub.

Dave Michels: 15:05

Absolutely. Thank you.

Evan Kirstel: 15:07

Yeah, helpful to me as well. So I understand the relationship between the chime app and the chime SDK. But are the teens different within Amazon or the tech stacks different?

Sid Rao: 15:17

So initially, I owned both the application and the SDK. But over time, we did separate the teams because we have a very different focus in terms of go to market motion, the types of customers that we work with. So if you think about the app, it's focused on your traditional enterprise, it are a line of business buyer who's trying to add a video collaboration, you know, service, video collaboration use case within their their work environment. Whereas I tend to focus around independent software vendors that are building apps, I focus on contact center customers who are trying to enrich or expand or enhance their contact center. So I have a very different customer in terms of who I have to serve. And we like to align our business units and organizations around the customers that we're trying to serve. And kind of in our working backwards mentality, we really like to map services to these customers. That being said, the app still continues to use the building blocks we produce, they don't use all of them, we'd like them to use more of them. But they do use all of the building blocks that I mean, they use many of the building blocks that we have within the SDK today. So they are a customer of ours, just like we serve slack huddles or Visa we serve a salesforce.com. They're just very typical at AWS, where you have internal and external customers, and the app is an internal customer, a team of ours, and yes, they are a completely separate team at this point.

Dave Michels: 16:48

Is there any significance to calling chime in SDK? Because normally, you know, in the circles that Evan and I travel in, we normally hear the term C pass?

Sid Rao: 16:59

That's a great question. Yes, there actually is a significance to the term SDK, it was not an accident that it was called an SDK. So one of the things that this kind of actually bothers me a little bit about our industry is that we like to say the word C pass all the time. And C pass means to many different, many different things, to many different things to many different people as

Evan Kirstel: 17:25

clear as the analyst these big weeks like they Michaels they love it, they love. Yes, probably

Sid Rao: 17:31

they I don't know, maybe the term see past. So I have to be careful what I say about about that favorite term. But now the challenge with using a term like seapass, is it really doesn't focus around the actual customer workload date, and the customer workload. And when you look at real time, communications involves multiple different things. Yes, there is a cloud service that is making sure audio and video can reach other devices and traverse the PSTN. But there's also a client component to usually these applications, and these client components, render the video provide the echo cancellation do the noise suppression, they have to work across a myriad of mobile devices, you know, in room conference equipment, sip devices. So there's definitely a client component to this story as well. And, you know, if you're looking at a communication service, and you're just saying, See pass, inevitably, what that means to a lot of people is bulk sending and receiving of phone calls or text messages or, you know, kind of at transport level problem, Dave. And really, it's a higher level construct of you working on devices, working on cloud services, and putting it all together so that customers can have a meaningful solution for you know, what they're trying to build, whether it's a huddles application, or it's enabling agent assistance in the contact center. So we that's why we take the approach of saying it's an SDK, there's, there's a cloud service component, there's also a client component. And by putting it together, that's how you get the real meaningful value out of our service. So that's kind of the backstory on the name. Is that

Evan Kirstel: 19:15

helpful? It is. And so what AWS services are commonly used with the Jime SDK? Oh, that's a

Sid Rao: 19:22

great question. So our customers will use a number of different services in constructing their application, whether it's amplified to create mobile and web apps, or you know, it's lambda to you know, orchestrate who they want to meet and when they want to meet or where they want to steer a phone call or route a phone call. So yes, we use a number of different AWS services with the SDK. But a crucial service that customers commonly use with the Amazon chime SDK is transcribed. So with a single line of code, a builder can basically add captions or transcripts basically to real type of audio and video sessions, which used to be actually a pretty tricky thing for a lot of companies to achieve. Now we've made it really easy. So transcribe is a very common partner service that our customers use. It's used also with with huddles from an accessibility perspective, that's where you may have seen it there. But it's also used for things you would never expect to have. And like, we have customers, for example, like T Mobile, with their 60,000 agents who use our you know, they're able to capture the audio via sip, and they also use transcribe, to transcribe that audio comprehend to detect the topics coming out of that audio, and then basically, Drive Agent assistant style applications that are common for their particular contact center. So we see machine learning workloads, whether that's transcribe or in the case of T Mobile, they're using, you know, a transcription engine powered by Nvidia, but it runs out UC two and it still runs on our, you know, on on AWS. And that type of transcription and machine learning workload is very commonly applied with the Amazon chime SDK. You

Dave Michels: 21:07

know, the more I think about it, and listen to you, all of AWS is really an SDK. What determines if an API is part of chime or connect or Lex or whatever?

Sid Rao: 21:19

That's a great question in terms of how we categorize our API. So the way we look at that problem is, who is the customer? And what is the workload. So if you think about Amazon, connect the workload, there is end to end contact center, you need a cloud based contact center, go to Amazon connect, if you're adding communication capabilities, to your contact center, or to your existing application, come talk to the Amazon chime SDK. And so we may, in fact, sometimes have API's that are do the same thing and two services, that's actually not not an unusual within AWS. It's all about the customers workload that decides whether that API exists within one service or the other. So a great example of that today is if I'm hosting a database, I can use obviously, rds MySQL, I can use Aurora for doing a fully managed version of that database. But I also might be using redshift, because it's actually a data warehouse, and I'm doing large analytic style workloads. And so the workload is what decides where that where that API method exists within that particular service. So you know, in the case of all three of those workloads, the need to run a database query is universal. But you may see redshift only offer the ability to do queries across billions of rows versus that may not be appropriate for RDS MySQL, right? So it really depends on the customer workload or the customer application. And so, for example, and in the chime SDK, you'll see the ability to have two people have a phone call together, right? And you're like, Well, look, Kinect also offers that too. Why do you have two services that allow you to make phone calls? Well, our phone calls are focused around people who want to add PSTN capabilities to their applications. Whereas connect supports the PSTN as a channel to a contact center. So yes, similar workloads, but not exactly the same. And so the customer solution is driving

Dave Michels: 23:34

they really do kind of blur and overlap. I mean, you went to the database is when all my databases, but connect chime and Lex kind of working together. Now, you just made some big announcements with Lex and Alexa at the at the recent reinvent conference. Can you tell us about that?

Sid Rao: 23:49

Oh, sure. Absolutely. So kind of going back to that that concept I described about SDKs and supporting devices, we actually enabled Alexa to initiate calls within skills. So if I'm an Alexa skill developer, such as an insurance company, I can basically create skill actions now that go like this Alexa ask insurance company to call my agent. And what it does is it basically initiates a call immediately from your Alexa powered device to the insurance company's local office or contact center via the PSTN or BSF, or even WebRTC. So basically, this enables skilled developers to add human beings into their workflows. It's actually a really it makes the Perl personal assistant market actually super useful above and beyond where it was today, the utility of a skill went up because now when you need help, or when you're trying to do something that requires a human being, you can bring a human being into that skill via traditional traditional telephone call. So yes, we're super excited about that work we're doing with the Alexa team. And it enables a convenience factor that we were a little bit surprised about, actually, in terms of how well it's received by our developers, by skilled developers. For example, we have a we have a large hotel chain who has economic sitting in all of their rooms. And they're using this capability basically to automate calls to their front desk or calls to their in room dining. And we have a large restaurant chain, for example, who's no longer has to program their entire menu, within a whole conversational AI skills.

Evan Kirstel: 25:37

Come on, Dave Michaels really enjoys these 1984 era phones. Well, I

Sid Rao: 25:47

actually, that's a good point, I haven't really seen too many 1980s phones in hotel room in a while now, I have seen echoes starting to show up for in room control and things of that nature. But there you go, that's like a pretty typical use case of they want to get beyond just simply providing in room control, they want to be able to reach other parts the hotel, enrich the hotel visitors stay. And this allows them to bring various different human hotel resources into that conversational AI experience they're having with these devices. So being able to target a number of different use cases like that to the convenience use case of luck, I got a notification that my car insurance is due on my echo and with a single tap of my echo show can call the agent to renew my car insurance, or I can call my doctor's care team to join a telemedicine session. For example, these are the types of use cases that we're now able to power on Alexa powered devices. So that's kind of the backstory and backdrop around what we announced the reinvent,

Evan Kirstel: 26:49

we have really exciting. Now, contact centers traditionally have plugins for websites, you know, click the chat, and now you're enabling Alexa to connect, when it comes to chime, and customer engagement, will chime also work for third party secrets providers or legacy TDM contact centers on the premises.

Sid Rao: 27:10

Oh, absolutely. In fact, that's a pretty common use case, Evan, for why customers come to talk to us about the SDK. So we typically run into organizations, especially through acquisition, like in the case of we were talking about T Mobile just a few minutes ago, with a large acquisition of sprint, you know, they have pretty varied and diverse contexts in our platform. And when you're operating in that kind of an environment, it's not easy to just say, snap your fingers and switch everything over to the cloud overnight. And that lifecycle of communication platforms of, you know, five 710 years is still the lifecycle we observed today. And a lot of that also has to do with the kind of risk aversion you might have some of the best cloud context servers center services out there today. But customers are little, sometimes a little bit risk averse, worried about disrupting their business. After all, the contact center is like the old primary way they get reached, it's the kind of a barrier of last resort. So of course, with Amazon connect, we have a fantastic highly resilient, highly available contact center, Cloud Contact Center platform. But it's not, you know, sometimes customers take their time to migrate. But at the same time, they want to add provide advanced calling capabilities off of their website, they want to add video, they want to add new capabilities to their existing contact center. And that's where the SDK does come into play. We have customers who are basically migrating from traditional dial in pick up the phone and call the contact center style use cases to browser and mobile app calling. If I can quickly go into a great example of that. It just happened to me this morning, I was looking at my my hospital chart, and I saw that I had an appointment with my cardiologist setup. And while I was looking at that hospital chart, there was a I had to reschedule the appointment. Well, there's a little phone icon and I so I'm like, okay, cool, I can call my my care team and reschedule that appointment and reach the hospital contact center. So I clicked the button, and initiates a completely new call now to the hospital. And all of that context of what was going on in the chart, my authentication details, all of that's lost. So I now start over in the contact center having to re authenticate myself. Tell them my reason why I'm coming in, tell them about my care team. And that really frustrates and adds friction to the customer's experience. And it adds time to the agent handling time as well, which is which is a cost of course to these organizations like my local hospital. And so with WebRTC and the Amazon chime SDK, I can take that entire experience and make your really efficient when you click that call button initiates an audio session via WebRTC and the SDK to the customer's existing contact center via Sep, or TDM. If they are really kind of antiquated, and the context of that entire, you know, customer, their authentication details, their, where were they in the chart, what appointment where they looking at all of that detail can be captured and sent along to the contact center. So now when the agent gets the call on their legacy contact center, their screen pops says it said, he was looking at this appointment, he has an appointment with the cardiology care team. And I don't know, I might do an extra check just to be absolutely safe from a security perspective before talking about medical records. And then while I can go right in to help him as a customer, reducing handle time, making the IVR and conversationally I experience more efficient. And, of course, removing friction from the end customers experience, which is what they're looking to do. So those types of use cases have been our absolutely common use cases for the enterprise customer of the Amazon chime SDK. And obviously, on the Alexa side, we do something similar, where if you're signed into the Alexa skill, all the detail about where they were in the skill and what they were trying to ask about. All that detail can be passed along to the to the context that are in that context is super valuable, also from an analytics perspective as well, because now I can go into my reporting infrastructure, especially with my contact center and say, where on the website, our customers getting stuck, when they call and ask me for help, which is actually something that it's pretty hard for contact centers to do today with traditional one 800 Call the contact center. So that type of services,

Evan Kirstel: 31:47

well, we've just said Alexa about 12 times, so I apologize to the listeners 1313 times, we may need to say the a word in future. But yeah, it's amazing how, you know, technology has evolved. I mean, you can offer so many advanced communication services without capex from the cloud. I mean, things like recording and transcription and translation, even, you know, used to be very expensive. So do all these new economics really surprise you? Looking from the inside, I guess out. And you know,

Sid Rao: 32:21

I don't think I'm surprised even as much as I'm actually super happy about it, because so it's actually interesting, he asked me about my prior job, which was as a CTI group and I worked on call recording and cloud based call recording. And there's actually an interview of me by somebody in the analyst space, who was asking me about cloud based call recording in the past, and I went on this diatribe about how I was annoyed about the state of the industry, and how these old guard providers are charging these super expensive capital license fees and high maintenance fees to basically record a call. And that's like, all they were doing, they weren't even transcribing the call, there was no machine learning nothing, just taking audio on the wire, and putting it on a hard drive. So now looking back on that time period of my life, where I was saying, Look, that can be a cloud based service in elastically scale, it can be efficient for customers to provide this common regulatory fat function. Now I'm able to literally provide like almost like a Google search interface to those calls, unlocking all the intelligence and conversational intelligence and sentiment data and topical data, from our most important thing, how we talk to customers and those customer conversations, I'm able to do all of that in an elastic fashion, on a pay as you go basis without these cap, you know, really expensive capex licenses and traditional techniques offered by old guard providers. And I wouldn't say it surprises me as much as it delights me to watch customers be able to do the right thing for their customers now, without worrying about, oh, I have to write a large check to some software company for a gajillion dollars because of the maintenance contract I've signed for the last 10 years. So I'm super, it's super exciting to see the whole customer experience customer service industry, be able to get very intelligent, very efficient, and help people like me who just need to get their cardiology appointment rescheduled go through their life better. So I always get happy when I see software actually improve lives. And that's something I'm seeing happen with that change to the cloud versus what was in the past. It felt like almost like a hostage situation where somebody had to write the check to a provider that year for the ability to take audio and put it on a hard drive. Maybe occasionally transcribe it because transcribing it cost too much, you know, occasionally being able to provide insights to a Customer on how they can improve the customer experience. So anyway, I hope that answered your question.

Dave Michels: 35:06

You started that with always being annoyed. And that's, that's my stick but but you ended up with always being happy. And so it's okay, you're all right, you're safe to about the customer journey through the chime SDK, what gets your customers? Or what gets you leads? What kind of events do they have that caused them to inquire about chime SDK?

Sid Rao: 35:30

Sure, that's actually pretty straightforward. So let's talk about interactive voice response. IVR. So a lot of companies now, especially in the COVID timeframe, decided, look, we need to upgrade the IVR, we can no longer do this DTMF touchdown thing needs to be conversational. We need to improve our you know, our containment scores, and how can we do it. And what they first sometimes do is a first start down the road of, oh, maybe I need to go replace my contact center. But then they realized, look, we don't have the budget, maybe we don't have the retraining cost for agents. Maybe there's some, you know, maybe there's a long term telecom contract, there's, or maybe there's a platform contract. Like in one case, we had a company who had signed a five year deal with Cisco, and they could not get out of their software contract and move to a cloud based service. And when they're so when they reached one of these constraint points, which actually happens even more than I thought it would happen, I'm actually pleasantly surprised by that. What happens is they reach out to a service like the SDK, and they reach out to us saying, hey, we want to add IVR capabilities to our context and a conversational AI. We want to add Amazon Lex to a telephone platform, can you help us out. And so it's those kinds of compelling events, like, I need to add agent assistance, I need to add video to my contact center, I'm adding a collaboration capability to my existing software application. And that is, these are the kind of events where it's usually additive versus like, I'm gonna go replace something. Now, we do have some companies and organizations who, for example, Harvard health and Beth Israel Hospital out of Boston, where they had a hard dependency on a third party for telemedicine, and they wanted to bring that telemedicine service in house. So there are some scenarios where we are doing solution style replacement. But there's a lot of feature style scenarios as well, where they're adding a feature to an application. Both of those use cases are what drives kind of new business or new opportunities to our service. And the reason why AWS has chosen versus other providers has a lot to do with that security challenge of trying to keep data customer data within a single vendor boundary or a cloud boundary. And AWS is obviously a very common boundary for our customers in terms of they know how to secure resources at AWS, they understand that model. And when you build with the Amazon chime SDK, you have pretty much access to anything within your AWS account. So if you if that's transcription or databases, all of that is available to you from that same footprint, which it makes it easy for customers to manage. It's interesting

Dave Michels: 38:22

because, you know, in the CPAP space, people normally start with SMS and they expand into, you know, into video and other services. But it sounds like in your SDK case that they kind of start all over the place. Is it easier to say where they start? Or is it easier to see where they end

Sid Rao: 38:36

up, it's actually easier to say where they end up when they're done using the SDK. And never really done using the SDK because we're always adding new features and capabilities. But when you look at kind of like the ultimate story of some of these customers, they basically completely taken over the customer engagement experience and have complete ownership of it end to end all the way from chat to voice to video to unit mentioned SMS, they sent send and receive SMS notifications using pinpoint which is sister service of ours as well. So we many times day, we will start in many different parts of the organization. And before you know it, we were doing everything from making a phone call work at that company to driving their entire video mortgage application process if it's a bank, or all the way to sending out SMS text messages for them for one time. passcode. So, usually, and this is kind of true of the industry as a whole, this whole seapass industry is that, you know, customers will usually start with some point need that they have. And then they once they get comfortable with the API's. They just start layering many many, many, many different types of applications on top of it, ultimately leading to finally you know context interest service being deployed. In our case, that'd be Amazon Connect. That's just the way that our customers tend to think about the problem and how they've been approaching the problem. And we of course, follow their lead in terms of how they want to go through their journey with our with a with AWS communication services.

Evan Kirstel: 40:17

So the API economy has been talked about for years, but really seems to be coming to the fore. So does everyone want to become an SDK and seapass provider these days?

Sid Rao: 40:28

I will tell you that based on various events and trade shows, I've been watching over the last couple of months into it sure as heck seems like everybody likes this whole. I'm an SDK. And then they use terms like platform and SDK and ecosystem. And I hate those terms, because that's not really the right way to think about it, Evan, if I had to go back again, and look at the entire origin story of the Amazon chime SDK, the main thing I would change is to actually forget about, really the the term SDK or seapass, or any of those things, and really focus on that workload, the workload is really the important thing, which is, how do I get video into my contact center, that's the workload if I'm in it, because I have a need for video. And maybe I'm a bank that's doing mortgage banking, and videos important for content, show reasons. And also personal reasons, I need to bring video into my contact center. Well, that's the workload. And that's the thing to focus on versus the term SDK, or platform or whatever the case might be. Those are just tools that allow you to build the workload. So I will tell you that everybody kind of is really looking at that SDK platform story, because they realize that the word customer workload is what's driving them towards doing that. Now, if you really look one closely at that problem, the root of all of that is COVID, changed our entire worldview. Basically, communications became just table stakes, there was no way to live without some sort of a video communications capability or audio communications capability, or conference chair. And once that that kind of notion had been built in once everybody was comfortable jumping on video meetings and audio meetings all day long for everything they do, whether it's ordering a burger or talking to their buddy at work, then the problem became about where are the eyeballs going to be located? You and I, Evan and Dave, we grew up in the times of Cisco, WebEx where there was this application, and everybody lived in this application. But that doesn't work for a lot of application developers, they want those eyeballs to be focused on their app. If I'm an E commerce company, and I'm adding a help button to my website, I don't want another application to get launched to serve that need, I want that person to continue to be in my website, because that's where they're going to be buying something from me, I don't want them to get distracted. And so keeping the eyeballs which is typically what a lot of website developers and app developers focus on, is still critical. And communications became critical. And I think that's why you're seeing so many people pivot or talk about an SDK is because the only way you really can provide communications now and be successful and meet both of those requirements is by providing a component that can be built into a website or a mobile app to facilitate communication. So I think that's why you see everybody, a lot of the cool kids in town starting to use the term SDK a lot. And we just happen to be doing it for the last couple of years already. So we've become pretty proficient in handling that builder or developer customer who needs to Website Builder or developer type of customer. Does that answer your question? It does.

Evan Kirstel: 43:58

I guess my additional question would be so many, you're one of the cool kids clearly, but you have so many alternatives. How does one distinguish themselves from the competition in this space? Given all the options? How do you differentiate yourself? From your competitors?

Sid Rao: 44:15

Yeah, there's two ways that the SDK does differentiate itself from substitutes. So usually, when you're making a decision about look at this session, right, me, you and Dave are on a call. Getting these three people together requires some sort of a data service or a database and in security conscious organizations, they don't want that data of Dave evidence ID to leave their cloud boundary. And that is a unique advantage that AWS is able to provide to its customer is that the database of deciding that Dave said and Evan should mean is stored in AWS and therefore the instruction to the communication service to put Three of them together can be retained within AWS. So there's that security advantage. That's kind of important. The next important thing that our customers are looking for is machine learning. It's no longer good enough for customers to just simply send audio packets across the wire or video packets across the wire, and hope that it's all good. from a quality perspective, no machine learning is now required for all kinds of use cases in the communication space. There's the whole everything from simple things like background replacement to noise suppression to echo cancellation, which is driven by machine learning workloads these days to packet loss concealment that is also ml driven. So there's a tremendous amount of machine learning required now to make a communication session go on the fraud and detection for space there used the whole by voice identification and voice printing kind of mechanism. And so the SDK, first of all, provides machine learning construct constructs on its own. It integrates with complimentary AWS machine learning services, and it also gives you access to the data do your own machine learning. And AWS is a great place to do and now so it these are the kind of the common reasons why customers tend to use our communication service and are successful with our communication service versus the many different substitutes and alternatives that are out there. And this is actually why, you know, we think AWS is really serving an unmet need in the communications business is because we're able to provide these types of capabilities.

Dave Michels: 46:37

interesting ways. He's gonna go, I gotta thank you for taking so much time with us. But I want to wrap up on one other topic, a term you use earlier, I haven't heard for a while you use the term WebRTC. That was like the term I don't know, five, six years ago, everyone was talking about WebRTC was going to change the world

Evan Kirstel: 46:56

koleksi pas now. But I guess,

Dave Michels: 47:00

zoom, never embraced it. And Zune certainly hasn't been hurt by that and seems you know, it's it's done really well. WebRTC just doesn't come up as much anymore in conversation. So I believe you're using WebRTC. And let me ask you, is that important? And how do you feel about that? Oh, yeah.

Sid Rao: 47:16

So remember what I said a few minutes ago about how app developers don't want the eyeballs to leave their app. WebRTC is nothing more than an acronym to basically describe browser calling, like, you can initiate audio and video, real time audio video sessions within a browser. And even within the mobile app community, a lot of apps are now pretty much browser based as well. So it's all about making sure that real time audio and video works within a browser, that's basically and So WebRTC is still alive. And well. It's the foundation behind Google Hangouts and meat. It's the foundation behind a number of these services. Facebook, of course, uses it for its own service. Apple does and some of the FaceTime interactions are now support. So vertices as well, is still a well established standard out there. Yes, we do have some market participants who have not embraced WebRTC, and who are very dependent upon their native application and native capabilities to make their service work. And my comment on that is very simple, which is that works when you're in the collaboration business, when, when you're in the business of being that collaboration application like a Cisco WebEx or a zoom or trying the application as well, that makes sense for that workload. It doesn't make sense for these workloads, like in the contact center space, where you really want people to stay within your app, you don't want them moving off of your app, all that context, we described about, like, what's in their shopping cart, how are they authenticated, all of that detail gets lost as soon as you switch application. So just like you don't want them picking having to pick up the phone and start a phone call. Because all that context is lost, you don't want them to click on that button and launch a completely different application to initiate that call either because, again, the context is lost. So you know, when it comes back to context analytics, and providing that rich experience at a website or mobile app, and people the standard out there is still WebRTC. It's maybe not as hot or trendy, but to achieve the customer's business objectives. That is still a very important and critical part of the chain that the tool chain that still needs to be out there.

Evan Kirstel: 49:32

This has been a fantastic deep dive into the world of deep as SDK and application development and for real time communication. So thanks so much for spending so much quality time with us. And we look forward to seeing more from Amazon SDK.

Sid Rao: 49:50

Thank you, Dave and Evan, for having me. And by the way, you can follow me on LinkedIn to see how the team's progressing and what we were announced and of course, we have a pretty active blog channels well aws.amazon.com

Evan Kirstel: 50:02

Don't forget Max and Hawk they deserve some attention as well on Twitter.

Sid Rao: 50:06

Oh, yes, Max and Hawk, they believe they deserve attention all the time, not just on Twitter or the internet. They think they deserve intention just for waking up in the morning. They haven't. So. All right, well, thank you for your time. I do appreciate it, folks.

Dave Michels: 50:21

It's really exciting to watch what you're doing over there. And, you know, time SDK, it kind of came out of nowhere, all of a sudden, that was just there. And now it's really making some big differences for a lot of customers. So it's just been great to watch this.

Sid Rao: 50:32

Thank you. Appreciate it. Dave. And thank you again, Evan, for your kind words and look forward to keep continue to collaborate. Thank you. Take care, take care, have a good one.

Evan Kirstel: 50:43

Well, Syd rose is a fascinating guy. He's one of the most visible business leaders in Amazon. Most of the folks seem to be unwilling to do podcasts and live streams and talk to external analysts like you Dave, what do you think

Dave Michels: 50:58

it's almost like a strategy or something? There's like always different islands in Amazon, like the contact center and, and what we just caught this in, in China SDK. There's legs and there's always different islands. But I think that they're kind of coming together. I'm not I might just be my imagination. But I kind of think there's almost like a master strategy here or

Evan Kirstel: 51:20

something like that. I don't know about that. But But Sid, is definitely the fantasy island of Amazon. You know, he's like the plane Welcome. Welcome. We're gonna talk to you a conversation. We're gonna build Come Come and join our island. So very, very fun

Dave Michels: 51:35

stuff. Well, it was great talking to him. And this will be one of our last podcast of the year.

Evan Kirstel: 51:40

I guess we have one more coming up with Jeff Haas and the Tullio you said last podcast and I was getting a bit worried like you something you need to tell me

Dave Michels: 51:48

last point what we have like one more podcast for the year I think it's

Evan Kirstel: 51:53

okay, just I just wanted to make that clear for the year so thanks, everyone. You made sure man I gotta get out of the phone. Don't wait. Don't read your phone. No, man. No, it's me.