Amazon's Werner Vogels talks AWS Outposts, innovation

Amazon CTO Werner Vogels is recognized for his role with Amazon Web Services, but in fact, Vogels heads up technology innovation across all of Amazon.

Vogels spoke with TechTarget at last week's AWS Summit event in New York City. In the first part of the interview, Vogels discussed transparency, the AWS developer experience and his views on multicloud. Here, Vogels talks about AWS Outposts, how AWS balances its speed of innovation, and ways customers can contain cloud costs.

AWS made headlines at last year's re:Invent with the introduction of AWS Outposts, racks of AWS hardware and software meant to run inside customer data centers. Availability is expected sometime this year. Can you provide an update on AWS Outposts?

Werner Vogels: I think we don't have anything new. It's still in private preview. We are working with customers to see what is the minimal set of services that they need.

What we did is really targeted towards customers that want to develop for AWS but need it to come closer to, let's say, their SAP system which is on premises. We're working with customers to see what works and what makes an ideal product. Or let's say a minimum viable product that is very usable for customers, and how does that work.

Customers may have something that they can't move to AWS. There are only a few companies like Capital One that are able to actually take all their mainframe transactions and move them over to Lambda. There's not that many customers that actually have made that move and found a way to do that. So there may be customers that really want to develop for AWS because they believe that their new applications are going to run there in the future, but still need to be for a particular period of time close to that mainframe.

Given how much faster AWS moves each year on the service development front, how does AWS balance its speed of innovation with the risk of confusing customers?

Vogels: We tried to, but we probably didn't do a good enough job [in the AWS Summit keynote] explaining that. We've always believed that having a very large tool box and lots of tools is the right approach. Mostly because we have no idea how development is going to change, so then you'd better give really customized tools so customers can pick the right one.

You see it more and more happening in something like Lake Formation. Lake Formation and office policy encompasses probably 10 different services. So if you have to do it yourself, you have to stitch these things together.

What you will see more and more, whether we do that or whether partners do that, is building solutions out of things. Companies just want the data lake. They don't want to stitch standard pieces together.

It's a bit like the machine learning space. Some [customers] want to really operate at the data scientist level, making new algorithms and things like that. Those will be using the lowest-level tools. But then there will be others that will have a sort of higher level tools that make it just easy -- click here, click there, and you have what you want.

Before we could do that, we needed to have low-level tools. And as such, we created the tool box. Lots of our partners have created equal solutions out of sort of the lower-level components.

If you had started at the data lake level, you would have forced your customers to go 'this path.' Now they can customize things exactly how they want.

It has to do a little bit with that each of our service teams is actually operating kind of independent of each other. They're in contact with their best customer base, or most demanding customer base. They create their roadmap. And we've always said that when we have something ready to get into the hands of your customers, you should get it in the hands of your customers.

Instead of [having] marketing control what the release cycle is, individual development teams control a release cycle. That may look like sometimes to the outside that it is a little bit chaotic or not necessarily coordinated. But that's just to get things in the hands of our customers as quickly as we can so you get the feedback cycle going.

AWS has thousands of SKUs, but immense choice also means more complexity. How will you maintain this level of services choice, and also improve clarity around pricing for customers?

I think [there's a big role for] automation. Tools like Trusted Advisor, for example, telling you, 'You know, you have had these six backups laying around that you haven't touched for six months. Maybe you should move them to Glacier.'

Vogels: I think automation. Tools like Trusted Advisor, for example, telling you, 'You know, you have had these six backups laying around that you haven't touched for six months. Maybe you should move them to Glacier.' Or something similar. I think there's a big role for automation.

A number of partner companies actually make a whole business out of really diving deep on what they should use, what's optimal. There's a role for building a lot more tools there in that space.

For example, I find that as a developer I'm equally guilty of that myself. If you were to ask me, 'Is this CPU-bound or is it I/O-bound?' You bet you pick the wrong one, yeah? Intuitively. [What] if we had better tools and better matching between sort of being able to look at your application and then say, you know what? You should go with [an M5 instance type].

I think helping customers make better choices there through automation and tools is definitely a path we are looking for.