Google flexes its Arm; Metronome runs the meter
Today: Google's first custom Arm server processor is now available, Metronome's new tool could help SaaS companies switch to usage-based pricing, and the quote of the week.
AWS evolved into one of the biggest businesses enterprise tech has ever seen by taking the Home Depot approach; it offers everything companies need to build digital experiences around their businesses, but it's up to you to find it and put it together. However, the market has shifted.
AWS evolved into one of the biggest businesses enterprise tech has ever seen by taking the Home Depot approach; it offers everything companies need to build digital experiences around their businesses, but it's up to you to find it and put it together. However, as the market has shifted, customers started to ask for a little more help.
Dilip Kumar is an Amazon veteran who came over to AWS last year to lead the relatively new Applications group, which builds packages of software tools for companies looking for help in specific areas, such as running a call center or managing customer data. The group started about six years ago with the launch of the Amazon Connect call-center application, and has since added several others that tackle problems around marketing services or supply chains.
"If you look at the things that we have done to date, in terms of the services that we've offered, they've all had a long history of us doing something very similar with deep expertise for Amazon," Kumar said in a recent interview. "You have to match their industry expertise with our capabilities and our own experience."
In that interview Kumar touched on the factors that led AWS into this business, how applications are sold a little differently than developer services, and how AWS thinks about its road map for future applications.
This interview has been edited and condensed for clarity.
People have been talking about the need for AWS to go up the stack for years. How did this all come together?
Kumar: I think there have been various invocations of this group formed over a period of time, like Connect had started in 2017, and these businesses had been embedded in different parts of AWS. But two things were happening from an external perspective that said that we need to bring this as well as several other things together under one umbrella because we needed to give it a focus.
The first one was that every year, AWS, as you know, adds 50 services. In almost every meeting that I go to customers with, there is a level of exasperation; "I just don't know how to combine (these services) and so I ended up using a very small group of services, just EC2 instances, or databases, or some of the analytic services, or S3."
And then the vast majority of services are not being consumed in the way that we would like them to be consumed. That's not to say that they're not being consumed, but they're not being consumed to build applications; it's not easy enough. Every (AWS) service, they're targeting their services towards developers. They are intended for developers to be able to build things off of it and that is exactly the right thing for those services to do.
However, in the last few years, there has been an extreme shortage of skilled workers in companies. And in terms of skill sets, hiring has gotten tighter, the ability for people to be able to sort of invest time and energy and dollars in doing in-house development has also reduced. That's the single biggest thing that I can point to.
We've always had (vertical) industries; we do a lot of work in financial services, we do a lot of work in automotive, we do a lot of work in media and entertainment. And one of the things that has happened is that a lot of those companies are also coming to us and saying that, like, we actually need you to be able to build certain things, because they don't want to have to deal with managing 30 or 40 different specific vendors with whom they're getting certain sets of services.
So it sounds like most of the customers for the AWS applications group are current AWS customers, is that correct?
Yes and no. So when you think about our retail vertical, like the identity and checkout stuff, we're actually introducing net new customers to AWS that weren't AWS customers before at all. Even for more established services like Connect, we are now working with customers who were never AWS customers; they've either traditionally been Azure customers, or they've always been on Google Cloud or some other place, and it is proving to be an entry point for several customers across many, many different things.
It's opening up conversations that go beyond CIOs and CTOs to chief supply chain officers and chief marketing officers who have traditionally used other vendors in order to be able to satisfy their needs.
And Supply Chain is another good example where we've had customers who are coming to us from segments where we've done some amount of work with them in terms of compute and database and storage, but they're consuming AWS services at a large and a greater clip because of applications. It's opening up conversations that go beyond CIOs and CTOs to chief supply chain officers and chief marketing officers who have traditionally used other vendors in order to be able to satisfy their needs.
As you think about expanding the AWS Applications family, are there some common threads that you follow in terms of deciding whether or not this is a business for AWS?
In a lot of these conversations, when we're talking to companies and you're selling something other than infrastructure services, we need to bring the level of credibility or an understanding of their business, of their segment, of their industry. Otherwise, it becomes a very thin veneer — (if) you don't really know what their businesses are, it's not possible that you can actually solve their problem.
If you look at the things that we have done to date, in terms of the services that we've offered, they've all had a long history of us doing something very similar with deep expertise for Amazon. So if you think about Connect, we have a long legacy of actually doing something very similar for customer service across Amazon. If you think about Supply Chain, again, we've had a very long history of having built these things for Amazon. You look at you look at some of the marketing or the Clean Room applications that we're building, we're doing a lot of that work for Amazon as well. That level of expertise and credibility that we can bring to bear allows us to be able to create something that can (start) a much richer conversation with a customer. You have to match their industry expertise with our capabilities and our own experience.
And the second lens that we look at is, is this an area (that is) large enough and can it be differentiated enough for us to add value? And we always look at almost every business with that lens. Then we say that even if it's large enough and if we can offer something that is differentiated, we always look for adjacencies.
When I was talking about Connect, Connect has some natural adjacencies to marketing use cases. Our introduction of things like Clean Rooms and Entity Resolution dovetails well with how call centers are evolving in their own ways, from being just inbound call centers to also doing a lot of outbound.
And that has generally resonated with customers because they are looking for things that are more end to end. But rather than saying that we will boil the ocean with a very broad offering that is so broad but it's only like an inch deep, we tend to be specific, and then build those over time as we sort of glean customer demand.