Subscribe
Share
Share
Embed
Sid Rao is the GM of Amazon Chime, AWS’ communications platform for voice and video calls. Prior to joining AWS, Sid worked at CTI Group, serving as the company’s CTO for a decade before joining its board of directors. Over the years, Sid’s worn many other hats, including working as a consultant for DaVinci Capital and a program manager at Microsoft. He was also the founder and vice president of R&D at I/O Medical Systems, makers of a device that could acquire multiple physiological indicators using a tablet device.
Join Corey and Sid as they discuss the newly announced Amazon Chime and Slack and partnership and what it means for virtual meetings, where the optimal place to host a video meeting between a user in New York City and a user in Taiwan is, how chat becomes exceptionally difficult when you’re trying to scale to hundreds of thousands of users, how the Amazon Chime team responds to user feedback, how Amazon’s own usage of Chime doubled in recent months and Chime scaled without a hitch, why the Chime team focused on and perfected the app’s plumbing first and how it’s now shifting its attention to polishing the porcelain, why the Chime interface displays a region label, what Sid thinks the number one misunderstanding about Chime is, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: Hello, and welcome to Screaming in the Cloud with your host, Cloud Economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Sid Rao, the GM of Amazon Chime. Sid, welcome to the show.
Sid: Thank you, Corey, for the opportunity. It's great to join you today and talk about Amazon Chime. Happy to be here.
Corey: It's easy to make a joke about you’re a hard person to get in touch with, but you're really not. And because you're on Chime, you sort of have to be accessible to some extent. But for the longest time, you were engaging with me on Twitter through a user account that just had your pets up there, and I've got to be honest, I thought for the longest time I was having conversations with your dogs.
Sid: Well, let's be clear: Sam and Max and Hawk—well, Sam, unfortunately, passed away last year, but Max and Hawk, they’re much better spokespersons and or spokes-dogs then Sid is, so I tend to use them in that capacity from the Amazon Chime team. They're very capable members of the team. One of them just got promoted from Puppy Level One to Puppy Level Two, and we use them routinely as mascots and spokes-dogs for various different activities. And you know, I'm not very familiar with Twitter, I will tell you, I'm not the best Twitter user. I've just started using it as of a year ago. So, I'm learning and it was better to learn with my dogs than learn alone. So, that's why you see Max and Hawk on my Twitter profile.
Corey: Excellent. I'm sure that they rank highly on the dig deep leadership principles.
Sid: Yes, they absolutely do. Especially Hawk. He's very good at diving deep. He definitely thinks big when it comes to food. And he definitely shows customer obsession in terms of licks, and you know, asking to be pet all the time. So, Hawk is definitely a role model on Amazon leadership principles applied to a puppy.
Corey: So, we started talking when I wound up making fun of your service, which it turns out is a terrific way to meet people. If you want to get to know what they're doing, insult their work, and oh, they come at you in a serious way. In all seriousness, don't do that the world has enough jerks in it. But my running joke about Chime for the longest time was that it has no customers because it was easy to fall back on. You had this, sort of, giant war in the messaging apps, originally of Slack versus HipChat. And then, HipChat, really, discovered that failing to innovate for a decade wasn't the best plan, and Atlassian sold the HipChat stuff over to Slack. Teams was then on the rise significantly, and they tend to talk about all of their daily active users because it likes to open itself, which is, yeah, if you can bundle something in, it works out super well. I'm not a fan of Teams, because I tried to use it once. And that really leaves Slack in that space. So, Slack has always been the yeah, that's adorable. We're going to be using Slack, but Chime is there just more or less as a placeholder until an actual competitor comes along. And now you're announcing that you're actually doing business with Slack. What's the deal here?
Sid: Correct. Amazon Chime has a number of different features and different service capabilities. We have a messaging platform in there. We have a meetings capability. We have a business calling and PSTN connectivity capability. And so, it's very easy to be, kind of, misunderstood as to is Chime a chat app? Is it a meetings app? Is it a calling app? What is it doing? And if you look at the world of unified communications today, that's actually pretty common across all of these services. Even if you look at Slack today, they have a chat capability. They have a meetings capability. They recently introduced a calling ability that actually works with Microsoft Teams. So, it's very easy in our industry to get confused about what is the primary focus of an app? Where are they going? And is Chime supposed to be a Slack competitor? And I'm going to answer Corey that usually these applications have all the functionality that a customer needs to communicate within their enterprise context, but they tend to focus on one area where they're going to do well. In the world of Slack, they've had a focus around messaging. Its world-class, best team messaging, and collaboration, and a platform for hooking in various different sources into a common channel. And they're really good at context management and how to keep context within that particular channel. They do also have a meetings capability, but it does have some limitations. It only supports up to 40 participants. You know, there's some limitations in terms of the audio and video capabilities that it supports such as PSTN dialing.
Corey: Oh yeah, they bought Screenhero which was fantastic, and then, from all accounts from the outside, immediately set about ruining it. And on one level, it's easy to cast stones, on the other, it turns out this stuff is super hard to scale. The idea of being a household brand, especially in a time when surprise, everyone's doing video conferencing in some form now when they weren't expecting to, is a hard problem.
Sid: Correct. And you know, it's not, I would say, the primary focus of Slack. If you look at how Slack presents itself to customers, it's very focused around messaging. So, now we are actually doing some work with Slack. And what we're doing is helping Slack extend the capability, security, global distribution, low latency audio and video services into the Slack application as a native capability of Slack meetings. So, when you use Slack meetings, starting now, you're going to start using Amazon Chime’s infrastructure and global deployment to power those meetings; improving the quality of those meetings, improving the resilience of those meetings; and also allowing Slack to continue to focus on their core competency around messaging, and leaving the problem of how to get video streams across the globe to talk to each other in real-time to Amazon Chime. So—
Corey: It splits the world. You’re right, it leaves Slack to focus on their core competencies of messaging, and changing their UI at random and confusing all of their user base. So, this has been in the works for a little while. So, that leads to two questions. One, what was that now that I'm allowed to ask? And two, what does that mean for the future?
Sid: Sure. So, what Slack was doing there was an experiment using one of the capabilities of the Amazon Chime SDK to determine what AWS region was closest to the Slack end-user to determine what region to use to host a meeting or to stream video or audio to, and what's the closest region to use to limit latency for customers. So, we provide an API. It's backed by Route 53 and a number of other AWS primitives, which allow our customers to discover regions that are optimal to host meetings. So, what Slack was doing was running an experiment across their entire user base to determine where the regions that are optimal for certain end-users, store that information, perform data analytics on that information, and then apply a meeting hosting algorithm to optimize audio and video latency using our SDK. So, that was what Slack was up to. They did it—they didn't want to obviously reveal to the world that we were working together, yet, and that's why we asked you politely, Corey, to not see that and be quiet about it. But—
Corey: Believe it or not, I am capable of being quiet. Not my core competency, but I am capable of it.
Sid: You are capable, and thank you for doing that. But that was the focus of Slack. They were trying to basically get ready for the rollout and determine what regions should be used to host a meeting. And so, they ran that experiment, they have their data, but that, again, highlights a benefit of Amazon Chime's SDK and infrastructure. We're in 14 regions; we're expanding that count every day; it would not surprise me in the fullness of time that we're in every AWS region that's available for customers to use our services. Latency is a very important problem in the audio/video streaming space. Limiting that latency is what drives a very high-quality audio/video service. So, what Slack was doing there was actually capitalizing on our infrastructure and our global reach using capabilities of the SDK that allow Slack to optimize what regions are used to host meetings. It's actually a very interesting problem. So, if you have, for example, a user who's based out of the East Coast of the United States, and they want to collaborate with a user who's in, for example, Taiwan or India. It's a very interesting problem as to what AWS region should be used to host that meeting. The natural choice a lot of application developers would do is just host it in either India or host it in the East Coast of the United States. Actually, the optimal spot, due to network and fiber routes, is actually in Paris. In France, actually, is the middle point that's most optimal for hosting that meeting. And you know, what the Amazon Chime SDK allows you to do is start that meeting in France, and then you can spin up another meeting, say, as participants start to join in and the majority of participants are, say, in India, you can start up another meeting closer to India, like Singapore, and start migrating users between meetings, optimizing on the fly for audio and video latency. So, there's some pretty exciting things you can do with our SDK by the flexibility we allow you to start up multiple meetings, migrate users between meetings, optimize audio and video latency based on region selection. And these are things that are really hard to do unless you have an SDK like Amazon Chime's SDK. If you were trying to build all that on your own, it's a quite a bit of operational load, it's a lot of effort, you have to manage a large amount of infrastructures across 14 different regions. And you're responsible for all that.
Corey: Well, aren't you overstating it just a little bit. I mean, I've been reliably informed by randos on Twitter, that Slack is just IRC as a Service and only fools would wind up falling for it, and here we are as a society that has been completely taken by the scam. Thank you random egg-looking person on Twitter with a bunch of random numbers after your name.
Sid: I think it's easy to think that chat is easy, or audio and video streaming is easy. After all, all you have to do is put up a box on EC2, and stream some packets between two endpoints, web RTC is already part of the browser. Shouldn't this be easy? And yes, it's easy to do that for a one-on-one conversation. When you're trying to scale this to hundreds of thousands of users across the globe with varying different connectivity and access types: customers coming across LTE, and 5g sessions, and DSL still a thing, and various different connectivity types. Managing the quality, managing the latency, managing the bit rates, reducing echo, these are all really challenging things to do. And in fact, we apply artificial intelligence and machine learning techniques to our streams to start to optimize them. We do a number of things that are really hard to do on your own. You can definitely go and try to do it on your own. The WebRTC is a standard, there's plenty of open-source packages that support WebRTC, and you can definitely get your initial deployment to 100 users done in the cloud, on your own, but when you want to scale that, or managing that over the long term, or supporting end users over the long term, it's a little bit harder to do that just on your own. So, that's a core problem we're solving with the Amazon Chime SDK.
Corey: So, this is always gotten to a bit of a, well, I'll call it mental challenge for me, where I look at things that AWS does, and if I can steal a borderline insulting analogy from the Git project, they talk about porcelain versus plumbing, and nowhere is this more evident than in Chime. We have the plumbing underneath: the infrastructure for communications that takes messages, routes them appropriately and securely. And that is awesome. AWS does plumbing super well. The app that we install on our phones, our tablets, our computers, etcetera, probably on an Echo device, because why not? That tends to be the porcelain portion of it, and it feels like AWS’s user interface pieces, the applications that end-users interact with has never been as robust or as polished as the plumbing. How do you feel about that?
Sid: That’s definitely fair feedback. We obviously can always improve our user experience, the customer experience of our applications. And Amazon Chime, as a service owner of Amazon Chime will tell you that it makes me sad every time an end-user has a problem with their applications. We definitely need to do better on the application side of Amazon Chime. And we regularly take feedback, focus on our customers, stack rank it, and try to fix the user experience problems in a iterative and consistent way. In the last year we shipped, I would say, at least 20 or 30 features that are end-user focused. For example, we supported the ability to share content just natively from the browser without requiring a plugin. We support a new Outlook plugins for better integration with Windows and Mac desktop users and Outlook. We supported Slack, actually, as an application and plugin mechanism as well. So, we continue to make end-user enhancements to Chime. I think there's two things to keep in mind though. It's evident from our launches that we've been a little bit more focused on meetings than on the messaging side. And that's what confuses a lot of end-users. They expect us to rise to the end-user capabilities of an application like Slack or Teams, and we're not doing that. And they get confused because they expect us to do so because we have a messaging function. And I think the second thing that folks need to think about is team tends to take an approach that until the plumbing is good—not just good. Great. Fabulous. You really shouldn't focus too much on the porcelain. And we basically have taken a intense amount of focus, Corey, over the last year about making sure the plumbing is good. Now, we have demonstrated the plumbing is good. We have customers who are using that plumbing. So, for example, Mindbody is using our plumbing for virtual yoga and health services on May 15, supporting a number of virtual capabilities that are focused around how to keep people fit and healthy during this time. And you know, the plumbing works. And the plumbing is actually not just good, it's fabulous, and that's what our focus has been on. If you look at how the plumbing has had to scale over the last couple months, Amazon itself had to double its utilization of Amazon Chime. So, they're, of course, a rather large customer in our customer list. And they doubled their utilization of the platform and we had to scale for that, and we scaled without a hitch. There were no capacity problems. There were no availability problems when we had to go through that scaling exercise. We then subsequently onboarded an insane number of customers onto our platform, with over—thousands and thousands of percent of growth. Let's just put it to you that way. Multiple orders of magnitude of growth and the plumbing did fantastically well. So, focusing on the plumbing is an important thing, and we wanted to make sure we got that right. We have started to show signal that we've got that right. We're now going to use that to start to add functionality to the application: improve the meetings experience, and start to focus more on that porcelain, and make that porcelain shiny. But the first thing to do is to make sure that the food is good. As you know, if you use the restaurant analogy, you can have the best friend to the house. But if the food tastes like crap, you're not going to eat dinner there. We've made sure the food is good, and now we're going to start to think about the front of the house a little bit and improve the meetings of application and the meetings user experience. And I think that's how we'll focus on the porcelain. So, it's a two-step process for us, and it does confuse people because they expect the porcelain to be good at the same time as the plumbing. And Amazon Chime has been launched and been out in the market for a couple years, and we had to go and focus on the plumbing and make sure it was good. And now we can come back to the user experience.
Corey: And you got to be able to focus on the plumbing because if you look at what a messaging app is, effectively every user has a monitoring system sitting open in focus on their computer most of the workday, and as soon as there's a slight blip in the messaging—maybe it's their terrible ISP, maybe there's a systemic problem, maybe there's a capacity issue somewhere along the line—but your app is going to get the blame for that. So, making sure the blame falls where it needs to is going to be incredibly important.
Sid: Yeah, I mean, blame is a very interesting topic for us. When we think about blame, we actually don't think blame is a good thing. What we'd like to do is point out when there's a problem, whether it's the ISP, whether it's your WiFi network, whether it's the Bluetooth headset you're using, all the way up to maybe we do have a problem with our infrastructure or capacity. You know, it's important to point out where the problem happens and exists, but then automatically help the customer with that problem. And that second part is the hard thing to do. The first part is actually relatively straightforward to do. We have monitoring hooks across the entire chain. We can tell what your signal strength is on your WiFi while you're in the middle of a call and realize that you're going to have a bad experience. So, there's definitely a ton of hooks we have, and monitors and alarms we have, but it's actually fixing the problem that's the hard thing to do. Yes, some things can only be fixed if human being gets involved. If your Comcast cable modem is having challenges and needs a reboot, you give it a reboot. But generally speaking, there are things we can do that actually optimize the end-user experience. So, for example, if we see that your ISP is having packet loss, connecting to a meeting that's hosted in say, us-east-1, we can test and proactively probe as to what the network telemetry looks like to connect to Ohio-based region, for example, and transition the meeting to Ohio. And what the SDK does is it enables a tremendous amount of power for the app developer to do those kinds of activities. One of our customers has built a town hall application, actually, where they have multiple different meetings set up for various different use cases. One is like a green room where people who want to contribute content to the town hall first get vetted and interviewed before they're put on air with the VIP who's actually doing the town hall, and then there's another meeting for the VIP to talk to people in their constituencies, and then there's another meeting for the popcorn gallery to interact about the town hall that's occurring. Well, what's really neat is they have multiple meetings being managed within a single application that's used by content moderators, the VIP, and participants, and they can have meetings that are, for redundancy purposes, set up in various different regions so that if they see problems, they can basically automatically switch users and optimize to a meeting that's better suited for their needs at that moment. And that flexibility is what the SDK empowers. If you want breakout rooms, if you want redundant meetings, if you want the ability to do green rooms, and various other different use cases, you can do that with the SDK. If you look at the meetings in collaboration world today, a lot of us are used to these very static monolithic applications, whether it's Chime the application, or Zoom the application, or Teams, or whatever it might be, and they're limited in terms of flexibility. When you're on a Chime meeting, you're on a single meeting. When you're on a Zoom meeting it's the same thing, you're on a single meeting. You can do breakout rooms because it's a feature, but there's a limit to that as well. And those limitations go away if you're using our SDK. So, what we've done is allowed JavaScript developers, iOS developers who like Swift or Objective C, Android developers who love Java, or Kotlin, to basically—we've given them a really powerful SDK that allows them to do basically whatever they need to for their collaboration needs, and customize both the security context, the quality context, and the usability context to the application that they're adding collaboration to, versus being constrained to a fixed application and trying to kind of modify it to meet their needs. So, for example, if you want to add virtual stand-ups to a coding tool or a development lifecycle tool, well, you can do that with a couple hundred lines of JavaScript added to that web app. And you can control it to be an all-day standup so there is no dial-ins or anything of that sort. You just drop in when you want to give a update and you drop out. So, that's very powerful and allows collaboration to be customized to the context that a user is living in, whether a developer living within a development tool, a financial services operator focused on an accounts payable or accounts receivable system, a yoga instructor who's living within their yoga scheduling app and that particular environment, or a doctor who's focused around the electronic health record. So, the final thing I'll say about the electronic health record is when the health crisis started, the first thing that almost every healthcare institution did was allow for automatically creating meetings for every doctor-patient interaction. So, everybody went and started their Chime meetings, the Chime link or Zoom link, or a Teams link. People would click on this link and join a regular meeting and perform their telemedicine activity. What they learned though, as soon as they rushed that out is they lack security controls over that meeting. It required the doctor to basically flip to another application so that when they're trying to update the electronic health record, they aren't able to see the patient at the same time. It reduced the amount of context brought into the meeting as to the medical record that's in play versus the actual communication that's ongoing with the patient. So, what the Amazon Chime SDK allows that electronic health record company to do is basically bring in the conversation with the patient into the context of the medical record, the prescriptions the patient’s on, the follow-up actions that are required, they literally can see the patient in the top right of the application they're using to update the electronic record. So, that context switch between a voice and video app and the business application the customer is trying to use at the same time, that's not a good context switch. You want the doctor to be constantly looking at the patient while they're updating the medical prognosis for that patient. And so, we're really happy about how a number of different electronic medical providers and telemedicine providers have started to adopt the Amazon Chime SDK to provide that level of integration and seamless experience.
Corey: If you're like me, one of your favorite hobbies is screwing up CI/CD. Consider instead looking at CircleCI. Designed for modern software teams, CircleCI’s continuous integration and delivery platform helps developers push code with undeserved confidence. Companies of all shapes and sizes use CircleCI to take their software from bad idea to worse delivery, but do so quickly, safely, and at scale.
Visit circle.ci/screaming to learn why high-performing DevOps teams use CircleCI to automate and accelerate their CI/CD pipelines. Alternately, the best advertisement I can think of for CircleCI is to try to string together AWS’s CodeBuild/Deploy/Pipeline suite of services, but trust me, circle.ci/screaming is going to be a heck of a lot less painful and it's where you're ultimately going to end up anyway.
Thanks again, to CircleCI for their support of this ridiculous podcast.
Corey: So, I have a couple of questions. First is when I have a Chime call set up, it tells me which region it's routing through. Now, if I were a regulated entity, I would probably care about that more. But from my perspective, I just want it to work, and I want it to be quickly. In fact, the only slight concern I have is some of these meetings are so freaking boring, that I want to make sure that they're handled domestically because sending it across borders is almost certainly a war crime. It's not something that tends to matter to me on a day-to-day basis. Am I weird like that, or is that a very specific edge case for a very specific customer profile?
Sid: So, when we added their region label to a meeting, there's a number of things that went into that thought process. The first thing is, there are actually a number of customers who are very paranoid about where a meeting is being hosted—
Corey: And rightly so.
Sid: —and said, “Look, we're taking meetings and making automatic decisions about where customer content is going to be processed.” Now, obviously the customer has control of this, they can go into the AWS console, and select what regions you want to use to host a meeting. So, first of all, I want to state that right upfront. Customers are in control of their content. They get to choose what regions are used to host meetings. But by default, we're going to automatically optimize that. And that's a great thing to do, to optimize audio and video latency by picking regions automatically for customers, but you better tell customers what's going on. So, that was the first reason why we did that. The second reason why we picked that was to also highlight to customers that this is a global service. We are in a number of different locations, and we're using the power of AWS to ensure that your latency is optimized, and your audio/video quality is great. And we're trying to keep that multimedia as close to a customer as possible. The first reason was the primary driver. Look, it's pretty scary. If I'm working on a very sensitive project with sensitive intellectual property considerations, I may not want meetings to be hosted in particular regions, and if that happens, I want to know about it so I can adjust my behavior accordingly. So, a lot of this was about making sure customers realize they were in control, and they knew what was happening to that media as it was processed. And some of the substitutes and alternatives in the market have had challenges around that. They haven't been very open and transparent about where meetings are being hosted and processed, and customers are rightfully annoyed about that. So, we wanted to make sure that didn't happen when we rolled out our solution to this problem, and that's why we put a specific label around it.
Corey: It's one of those things that's useful for some folks, and for the rest of us it more or less, it's just one of those things that shows up there. And I always feel like I should be doing something when I see something tell me what region is going through. Like I should be sitting there and [unintelligible] measurements to see which supported region is the closest for all people, and I don't think that's what it was telling me to do, but I always view those things as something actionable.
Sid: But, this is a very interesting thing to raise, which is happening, I think, in the collaboration space. So, collaboration spans so many different use cases. Like right now where you people are using video to talk to their friends and family. They're using Amazon Echos to drop in on various different family members, and they're using FaceTime for talking to their families on their iPhones and iPads. They're using Zoom for consumer needs, even though it would start out as very much a business application. They're using Chime to do that as well. Everybody's got all these tools, and they're using them within consumer context and enterprise context. And this is going to be one of the interesting things that happens in the tool space, is that Chime does something that's very focused on a business use case, which is presenting the region where your content is transiting through what specific region. It’s very important to do that in a business context. Doesn't make sense in an end-user or residential context. And so, this is why, again, we felt the SDK was the right posture. What the SDK allows you to do is make sure the customer experience that you’re vending, whether it's a telemedicine experience, or maybe it's a party app. In fact, we have customers today that are doing virtual tours and virtual consumer activities together, using Amazon Chime—games as well, that are also in that world—well, guess what? They don't need to put the region up. They don't need to present the region. Region doesn't matter. And in fact, you can capitalize and use the entire display to render video, and you don't even have to put any other labels out there whatsoever. So, the SDK enables that level of flexibility, and it puts it within, again, the application developer’s hands, so they can select what the right customer experience is for the context that the customer’s using video, whereas these tools are very rigid. Like even Amazon Chime the app is pretty rigid. It has a very specific way it goes about starting an audio/video call. It involves pins, it involves lobbies, and moderated rooms, and all these other things that really aren't relevant in a consumer context. So, rather than taking a square peg and trying to stick it in a round hole, which is what happens when you try to take these multi-party video, enterprise video collaboration tools, and then use them within consumer context, rather than trying to do that, you should use the SDK and customize the user experience for the context that your end customer is actually going to be using your application for, whether it's a real estate app to home showings, or it's a telemedicine app for helping doctors connect with their patients.
Corey: Is that going to happen on the actual Amazon Chime native app itself, too? I mean, given the fact that you're now signing deals with Slack, does that mean the application itself isn't a priority? I mean, to put it bluntly, does Amazon care about the app anymore? Or is that more or less a, you don't know how to deprecate things, so it's going to sit there in limbo forever?
Sid: Oh, we absolutely care about the app. There's a number of reasons why we care about the app. Obviously, we have customers who are using the application, and we are here to support customers, and I want to state that right up front. But the second reason is, the app is the perfect vehicle for exercising the features of the SDK. We are our own customer now. So, we use our SDKs to add features to the application. And so, there's a symbiotic relationship there. If we have a customer who asks us for a feature in the application, for example, there's a customer who's asked us recently for better noise suppression in the application. Well, that feature now gets built into the SDK, and the application then consumes that feature out of the SDK. So, everybody wins: the app developers who are betting on our SDK and using it routinely within their applications now get the benefit of features we build within the app; the users of our app get the features that we build within our SDK. And so, it's a virtuous cycle of being able to build features into the SDK, get benefit in the app, get feature requests in from the app, which lead to features within the SDK, which our application developers can now use. So, everybody wins. And the app is a very important part of that lifecycle. If we just built an SDK, we don't get that feedback loop on better supportability mechanisms, better audio and video quality things we could be doing. We just don't get the learnings from our customers to improve the SDK. And that's actually a differentiator, we're an owner/operator, we have to operate the primitive and also be an operator of the application. And by being an operator of the application, it helps us bar-raise the software development kit in a way that no other competitor who provides that SDK can do. So, it's a very important thing to be an owner/operator, and we are an owner/operator: we operate the SDK, and we also have to operate the app. They both feed into each other, and we're going to continue to do that in the fullness of time. Think of the app as the ultimate example code of how to use the SDK. Does that help, Corey, provide some context on the app and why we're going to continue to invest in it and support it?
Corey: Oh, it does. It absolutely does. And it sets me up, I think, pretty well for my final question for you, since we're coming to the end of our allotted time, much to the relief of pretty much everyone at AWS once they realize I'm talking to you. And that is that Amazon is a company that is famously willing to be misunderstood for long periods of time. So, my question for you is, what about Chime is being the most misunderstood right now?
Sid: I think the number one misunderstanding customers have about it—and this is our fault, and you know, I think it's an area of improvement for our service is we’re misunderstood to be a messaging app first, with a audio and video capability on it. We do it to ourselves in terms of how—if you launch Chime, the first thing you get is our messaging service. And so, people just naturally are assuming we are a messaging app with audio/video capabilities versus, actually, we're an audio/video app with a pretty rock solid messaging service as well. And that’s a misunderstanding that the team is going to work on, we're going to iterate on, and we're going to improve on over the coming time. So, that misunderstanding sets up for customer disappointment because they immediately assume we're going to have all the features that a Slack would have, or they assume that we're going to have all the features that Teams would have. And that's just not our core focus. If you look at our roadmap from last year, yes, we did improve the messaging service. We added a number of features to it, but the majority of our work went into improving audio and video capabilities within the application. So, this is a misunderstanding the team is going to work on, and we're going to try to help educate customers on what our position is, and what we're going to improve on. I think the relationship with Slack is a very good first step in doing that. By providing audio and video services in Slack, we're basically telling our customers where our focus is and where the majority of our investments are going, and where our roadmap is heading. So, I think that's a very important first step. But that's an area of misunderstanding that we would like to work on as a team.
Corey: That is one of the hardest parts about—I would imagine—being in AWS is when someone walks up to you, “Oh, AWS, what do you folks do?” “Well, pull up a chair, son. It's going to take a while.” Because the answer is yes, there always is. And Chime is one of those lesser-known services externally. In the Amazon ecosystem, everyone uses it and is very familiar with it, and I scared the crap out of people who didn't realize it was globally federated, and I would pop up asking them questions. It's given rise to a parody song: Chime after Chime. But it's felt always, for now, like an Amazon-specific ecosystem tool. I'm curious to see if announcements like this will begin to shift that narrative.
Sid: I think it will. Look, again a couple weeks ago, Mindbody used Amazon Chime in a way that nobody would have ever expected. I would have never expected to see virtual yoga sessions being hosted by Amazon Chime within the Mindbody application to be a thing. So in a way, this health crisis and the need to add video collaboration into various different contexts and support various different customer experiences with video and audio has just basically changed the entire way Amazon Chime is received by customers, by the overall tech industry, and by actual end-users. I got a direct message on Twitter from a student the other day who's using Amazon Chime for their learning, and education, and classroom activities. And she loves the app, and she was actually just like, why didn't I know about this? Well, there's a reason why you didn't know about it, which is we really had not found a way to introduce the great things we had done to the broader market. The SDK was an excellent solve to that problem, and now people are consuming us as an application, as an SDK, and we're getting broader awareness. And I think sometimes you have to do small things to fit within that broader construct of AWS. Surfacing our primitives and vending them to customers made us a more natural fit in the world of AWS, and I think that was a singular biggest improvement we've done as a service to help resolve that question of is Amazon Chime an external service? It absolutely is. It absolutely has use cases outside of the general AWS community, and we now have people from online learning, to telemedicine, to virtual classrooms, to virtual yoga sessions, and actually virtual experiences is the new thing I saw the other day, all using Amazon Chime. So, we've now managed to introduce Amazon Chime into all kinds of user experiences from consumer, to business, to enterprise, and it's been an exciting journey over the last couple months.
Corey: I'm looking forward to see where you folks go next. Because honestly, I think it's time for me to come up with a new joke for Amazon Chime.
Sid: I think so, too, Corey. I'm sure you'll find one, and help drive us because those jokes—we laugh at first, then it hurts a little bit, and then we internalize it, and we work hard to make sure you have to find a new joke about Amazon Chime. So, Corey, I think you should find a new joke other than we don't have customers anymore. We have plenty of them. And they're all across the globe in all kinds of use cases. So, time for you to find another joke, Corey.
Corey: You're right, and I don't know what that's going to look like yet. But at least for this episode, I think that winds up taking care of itself. There was, as I mentioned, a parody song was written by Spencer Johnson and then performed by Tim Leehane. I will play you out with that song, for those who have not had the dubious pleasure of a ridiculous song about an Amazon service.
Sid: Okay, there we go.
Corey: So, thank you once again, for taking the time to speak with me today. I really do appreciate it, given that you have literally everything else that would be a better use of it than entertaining my nonsense.
Sid: No, thank you, Corey, you're helping us get our message out as well, and we definitely can do a better job at that. And you're definitely have been a helpful vehicle for doing that, and we thank you for your time and spending the time to learn about Amazon, and Amazon Chime, and AWS. We really appreciate it.
Corey: No, and I appreciate you as well with all the hard work you do in suffering my egregious slings and arrows. If people want to hear more about what you have to say, where can they find you?
Sid: Just go to https://chime.aws and you'll land on our product detail page, and that also has links to our GitHub repos, and example codes, and customer references as well. So, just go to chime.aws and you'll land on our information pages.
Corey: Excellent. And we will, of course, throw links to that in the show notes.
Sid: Thank you.
Corey: Sid Rao, general manager of Amazon Chime at AWS. I am Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts. Whereas if you hated it, please leave a five-star review on Apple Podcasts anyway, and a comment telling me exactly what redeeming feature you seem to think Microsoft Teams has, even though you're wrong.
[“Chime after Chime” by Tim Leehane and Spencer Johnson]
Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.