Tip:
Highlight text to annotate it
X
>> Uh, next up, we're gonna hear from Werner Vogels. Uh, Werner came to Amazon after being
a researcher at Cornell University, where he was a-- a master of ultra-scalable systems,
and he went on to become one of the chief architects of the Amazon Cloud, which he has
called, and I think rightly, the world's largest distributed system. And it's much more than
that. After four years, starting with EC2 and S3, Amazon now offers 20 different services.
But today, he told me he wants to talk about the motivations of the customers who come
to Amazon Web Services, what they're doing with it, what they want to do with it, and
then what they're actual behavior is, and how that is steering what he's building in
the future. Werner? [pause] >> VOGELS: Well, thanks for giving me a half-hour
of your time today. Um, so putting me in the session together with Marc Benioff gives a
new idea to, you know, industry heavyweights, yeah? Um, so there's a clicker here. So, um,
you know, actually, I can beat--I'm sure I can beat Marc, so can anybody who is an Amazon.com
customer raise their hands? Huh? Can I talk to you later? So--So, um, Amazon Web Services,
infrastructure in the cloud. You know when a technology has reached maturity when this
book arrives, yeah? And actually, I was kind of insulted by this book, because I believe
that one of the pure concepts around the cloud is simplicity, yeah? Um, a cloud for dummies
should not be necessary. I think one of the opportunities we have is build applications
that are really intuitive, and so, um, but what I really want to talk today-- So, if
you think about Amazon, and I'm not going to talk about all these different services.
They have horrible acronyms, so the good thing is that Marc is a sales guy, and he's really
smooth, and is able to bring this message to you, and I'm a technologist, so this is
actually the boring section of this talk. So, but, to avoid that, I'm not gonna mention
all the acronyms, the EC2 and S3 and things like that. What I want you to remember is
that what Amazon delivers is infrastructure as a service. Now, it is all different from
what we've heard about this morning, which is Google Apps and all the other enterprise
apps around it, which are consumer-facing. Um, Facebook and Salesforce and all those
all consumer-facing applications, and this is completely down in the belly of the beast,
right? This is compute, storage, messaging, networking, all of these kind of things--all
your nightmares, huh? And we have the ability to take those nightmares away from you. And
so for that, you know, we've been--It's a business that is really exploding. This is
just an indicator of kind of what the growth is in this business. Um, Amazon Simple Storage
Service was launched first in early 2006. These are billions of objects that customers
are storing actually in Amazon S3. We're now way over 100 billion. And more than the really
actual numbers, while that's important, is actually the curve that you see while this
growth is happening. And from my perspective, the way that we're looking at it, we haven't
even reached the knee of the hockey stick yet. This is really going to explode. And,
you know, this is now four years into, uh, you know, providing the cloud to our customers,
and many of our customers really innovating with it, and now we get rewarded for this.
You know, Jeff, front page of Business Week, um, "Most Innovative Companies," also because
of the cloud. But when we launched this, Business Week had a completely different title. And
this was "Amazon's Risky Bet," yeah? And this is also how many of our customers still look
at the cloud. Remember, Business Week is no longer in business. So what I want to do is
actually first start off with a number of our customers, dive deeper on why they actually
picked to run their applications on the infrastructure as a service. And dive a bit deeper on what,
actually, the different things are that they were doing with it, and then, you know, give
my motivation why I think cloud is really important, and then, uh, you know, finish
off with reviewing a set of other customers. So this is, uh... This is the NASDAQ. So the
NASDAQ--the Data Group of the NASDAQ maintains all the feeds that are coming from the exchanges.
They go in a massive back-end infrastructure, and what they were concerned with was that
customers would call them and ask for at-home queries against that data set. And they were
not set up for that. But they did think that there was a business there. And they did--As
good enterprise architects are, they did--They developed a new architecture, or developed
it, or at least mapped it out and realized that to be able to support this business,
they would have to revamp the complete back-end architecture. They invested $6 to $10 million
to be able to do that, a two-year-long process, for an application, or for a business that
they actually didn't know could be successful or not. And so they did something really simple.
They actually split the big fire hose that were coming from the exchanges, and next to
dumping it into the traditional architecture, they also dumped it into Amazon S3 as simple
text files, small text files, partake a symbol, pour ten minutes, a really embarrassingly
simple solution. Then they picked a whole set of flash objects, built an application
out of it, allowed customers to run that on their own desktops, and then retrieve this
data from Amazon S3. Now, it turns out that this application is really successful. You
can go to Data on Nasdaq.com, download the application, play with it. It really works
really well, but for them, it was really important that they made no capital investment to get
this application off the ground, because if it turned out that this was an application
that was not going to be successful, they wanted to do so with minimum loss. Yeah? And
after, actually, that was the real motivation was no capital investment, but the other motivation's,
like, you know, reduced operational cost. They didn't have to look after the storage
systems. They were sick and tired of running their own databases. They didn't want to have
another ten databases to look after, which they would have to keep up, you know, 24/7,
because that would be the cycle on which their customers would be using it. Another example,
Razorfish. Some of you may know them as, uh, as Avenue A. What they do is actually analysis
of clickstream data for their customers, finding out, you know, what is actually customers
doing on your site. They do market segmentation, things like that. Massive computational data.
And I think they're a really good example of what we now know as being "big data." You
know, where companies know that they're sitting on a huge amount of data, and there is this
needle in there, there's this gold to be had in there. You just don't know where. And these
data sets are huge. And Razorfish was confronted with the fact that they were, um, acquiring
a new customer, and to actually take this customer through the holiday season, they
would need another half a million of actually hardware investment just to support this customer.
And so they also want to do a lot of new innovation in terms of building out new algorithms and
things like that, but they don't have any real big infrastructure to do this on, so
they move all of this over to, uh...to Amazon S3, yeah? Store all the data there, continuously
move customer data there, and they use Elastic MapReduce, which is version of Hadoop, that
Amazon manages on top of the EC2 infrastructure for them to experiment with. And they can
do this experimentation continuously without having to worry about, you know, yes or no,
having enough capacity. Again, for them, you know, the driver was scalability, but to be
able to be flexible to figure out to develop new algorithms as they come, not having to
worry about the amount of capacity that you need to drive these--to drive these algorithms.
Uh, Bild is a German--a large German publishing house. Um, just like many of the other media
companies, they are trying to figure out new business models. And so one of the areas that
they wanted to go into was video citizen journalism, whish mean that, you know, customers--Their
customers can walk around with cell phones, take videos, upload them to this website,
and then create news stories out of that. They went to their internal IT department.
They said, "Oh, that's a really great idea. 9 to 12 months then we can deliver this to
you." It's obvious that in the media world and in the internet age, 9 to 12 months means
you're dead in the water. You know, so they moved onto the Amazon platform, launched in
four weeks after conception. And not necessarily with the whole product as they would have
done, you know, maybe five years ago. They launched with a smaller product, yeah? Which
they could really get to market really fast, and then start innovating on top of it by
looking at how the customers were actually using that particular product. Not knowing
up front how much computation they would need for it, how much storage and things like that.
So time to market was crucial for them. You may have seen this news. Lawson, um, very
large ERP provider, launched their software service product. Um, they launched that on
top of Amazon EC2. You know, their main criteria was that they really needed to be able to
quickly roll out customers, yeah? And be able to scale those customers to any size. And,
actually, Lawson also, um...You know, for them it was, of course, really important if
you run customers' critical processes on this, that it's ultra-reliable, so for them the
choice was really was the most reliable infrastructure that we can find. But they also decided to
do a little innovation around it. They have a whole new structure in terms of licensing,
but they also have something that's called, uh, a Lawson Test Drive, where you can take
this environment, quickly spin it up, and customers can load their data on it, and then
for three months, they can just use it for free, figure out whether this is actually
a product they want to use. And, um, if they--If it turns out that this is a product they do
not want to use, then it's easy for them to take it down and forget about the cost and
forget about the data. Netflix is, um, another great example. They came to Amazon because
it's obvious that their business model is changing. You know, they're really going from
a DVD rental company into a digital streaming company. And so for them that meant tremendous
scale that they would have to deal with. And also reliability, because, suddenly, you know,
this whole infrastructure needs to be super reliable, because that will be the core of
your business. So they looked around for what platform they would build this on. They picked
the Amazon Web Services, and they had to swallow a little bit then, because on the same platform,
Amazon's video on demand runs, yeah? And here we have a platform where we have two competitors
running side by side, both having the same advantages from it, yeah? So for Netflix,
their biggest challenge was, you know, if they would have to build this complete reliable
infrastructure themselves with multiple network providers, multiple data centers, all over
the world, yeah? They'd rather take their expertise and focus on delivering better video
service or a better customer experience than actually investing all of that, you know,
intellectual capital also in the infrastructure. Now, you can see this as, you know, all these
enterprises building their businesses on top of the cloud, and then, you know, there is
still a hideous myth out there that, you know, by the time it is actually holiday season,
all of this will collapse, yeah? Because when it's holiday season, Amazon, who was just
selling off some extra capacity, will take all of that back when they have a better-than-expected
holiday season, yeah? Of course it's ridiculous. The idea that, uh, all of these large enterprises
are moving onto Amazon Web Services, they realize that this is a business for Amazon
by itself, yeah? The reason why Amazon went into this business is because we believe this
will be really, really big, yeah? Probably-- and, of course, nobody has a real crystal
ball--but we believe that it will be on the size of our, uh...Of our e-commerce operation
at this time, yeah? Or maybe even bigger, but we don't know how the future's going to
look like. Amazon.com itself is a very large customer on top of this, but definitely not
the largest customer, yeah? There's many more large customers just like Amazon on the same
platform. Now, if you look at the sort of differing use cases of customers using this,
these are sort of--This is one of those fancy Wordle kind of things, um, that indicate what
other kind of common-use cases enterprises are using, and there's a few that I actually
want to highlight, and we'll get into the more detail later. Um, disaster recovery is
definitely something that's really heating up. Many CIOs hate to write this check once
a year, very large check, and not having the ability to actually continuously test whether
you can do disaster recovery or not. They want something that actually is in their hands
and can test continuously whether your DR is actually working, yeah? You can obviously
see HPC and marketing. We'll get to that later. Collaboration. Many folks are sort of--sort
of first proof of concepts are moving their Sharepoint clusters into the cloud, uh, wikis
into the cloud, all these kind of environments moving into Amazon EC2 for easy growth and
easy shrinking as well. Load testing is another example we'll get to. Now, there's many different,
uh-- many different ways in defining cloud computing. We've seen a number of these this
morning. I'd like to reiterate one that actually Gartner used about two years ago. I think,
uh, Gartner-bashing is a very popular sport these days. Um, and actually, I think it's
a really good definition, yeah? It's "a style of computing where you have massively scalable
IT-related capabilities that are provided 'as a service' across the internet to multiple
external customers," and the key points there are "massively scalable IT-related capabilities
as a service," and "across the internet," and that can be public and private internet,
and by nature, it's multi-tenant. However, I do think there is two things missing in
this definition that are crucial, and that actually from my point of view make cloud
cloud, yeah? The one thing that is missing from this definition is that these resources
should be available in an on-demand fashion. You need to be able to get access to these
resources whenever you want. And if you no longer want to use them, you can able to just
release those resources. And you can also see that as a meta level, yeah? This needs
to be on a purely self-service basis. If you want to use our services, go ahead. If you
no longer want to use our services, you should be able to walk away without any up-front
commitments or things like that. So both at a detailed level, yeah? Getting and access
to, uh, computer resources and releasing them whenever you want to, but also at the business
level. And the other thing that is missing from this definition is that it needs to be
a pay-as-you-go model. In my eyes, at the infrastructure level, that's the only model
that makes sense, yeah? You only pay for those resources that you use. And if you don't use
them, you should not be paying for them. In that sense, it's as close to the--the pure
utility model as possible. And so, if you look back, you know, early 1900s, um, many
of the companies--This is actually a picture of a...a brewery in Belgium, where they had
to gen-- They had their own generator to be able to brew beer, yeah? You can imagine these
two things have nothing to do with each other. These guys needed to have 12 people on staff
just to keep the generator going, yeah? Just a cost of doing business, and it has nothing
to do with brewing better beer. So when public utilities came around, they couldn't quickly
enough actually dump the generator and switch over to public utilities, so that they could
actually focus their resources on what they really was their differentiator, which was
their types of beers. And so that's actually the core, I think, of infrastructure as a
service and the utility model that goes with it. So when we developed these services, when
we built these services, first for ourselves internally, but when we started externalizing
them, there were a few principles that we built these services with, yeah? The first
one is that they needed to be scalable, and with that I mean you need to be able to increase
and decrease this in order of minutes, yeah? If you want to get access to resources, that
shouldn't be an hour-long process. Actually, within Amazon, we had quite a bit of experience
with that, because I believe we were really good before we had this platform. You could
fill in the web form, and capacity would be delivered to you in order of hours. So fill
in the form, two, three hours, you would have ten servers fully provisioned for you available.
It turned out that that didn't trigger the engineers to actually release capacity when
they no longer needed it. You can imagine, at the end of the holiday season, yeah? Um,
during that period, engineers and teams would have additional capacity, so on January 1st,
you should expect that a lot of capacity gets freed up, yeah? And I would go talk to engineers,
and they would say... You know, I'd ask them, "Why aren't you releasing capacity?" "Well,
you know, just in case," yeah? Or, "No, we're launching something at, um, March 1st, and
we thought it would be easier to hang onto it than to actually release it and ask for
it back again." So there's two things that we thought were really important. You need
to be able to get access to these resources in an order of minutes, yeah? And it needs
to be fully automatable. You need to take these engineers out. You need to have just
an API in which you can get access to these resources and then build automated systems
around it that release these resources when you no longer need them, based on business
principles more than on the judgment of an engineer. Needs to be cost-effective, which
means for us, you know, Amazon coming out of the retail business, we really understand
a large, high-volume, low-margin business. And we've been building technology for--for,
you know, for the past 15 years that actually powers, you know, that e-commerce operation,
and so we really know what it means to drive the costs to the floor. So it needs to be
really cheap, and they also want to maintain the same principles as that we have in our
e-commerce business, which is, because of our economies of scale are capable of getting
additional cost-savings, we'll turn around and lower prices for our customers. And we've
done that in the Amazon Web Services business a number of times as well, yeah? Um, in last--We've,
I think, lowered bandwidth pricing three times now in the past four years. Um, last November,
we actually lowered prices on our compute instances, pure because--because of our economy
of scale, we're able to drive the cost down. And, of course, Amazon.com runs on this infrastructure,
and we really understand, you know, reliability from a mission-critical point of view. We
also understand that many of our customers are going to use these services and build
their business completely on this. There are quite a few customers that full 100% run on
Amazon Web Services. They have no servers, no data centers anymore. So many business-critical
applications will be running on this infrastructure, so it needs to be super reliable, because
we feel that we're responsible for your livelihood, and that's something we take really, really
serious. The same goes for security, and we also feel-- Because in security, it's not
a matter of just being secure. In security, there is no finish line. It's something where
you have to continuously innovate in to make sure that you can keep your customers secure.
Again, with Amazon.com, we have a long history there, understanding how important security
is, and actually, if you look at our, uh, investment priorities in the Amazon Web Services,
but also at the Amazon.com side, security continues to rank number one in terms of our
investments. So if you look a bit at, uh--Often, you know, they can take all of these technical
definitions of what cloud is and things like that. I think cloud really gets defined by
the benefits that you get from it, more than from the technology pieces of it. So, yeah?
Important for cloud is that it has to lower costs. It should eliminate capital investment,
but also reduce operational costs. Reducing operational cost really comes from the fact
that you do not pay for those resources that you do not use. So scalability is not only
a matter of scaling up. It is as important to be able to scale down, and if you'll be
able to scale down, you should be able to reduce your operational costs as well. So
many of our enterprise customers come to us with, you know, this lowering cost principle
in mind, but often when they get on board and they've been running for a while, they
will not cite--although they still like the lowering cost, they often cite increasing
agility as a much more important principle of the cloud. The fact that they are no longer
constrained in their thinking about resources and that they can really drive time to market,
really compress that in a way that they've never been able to do before. Of course, it's
important that our customers, if they use this infrastructure as a service, no longer
have to think about data centers, multiple data centers, not how to replicate data across
multiple data centers, how to negotiate with multiple network providers, such that you're
fault-tolerant in that matter. All of these kind of things come for free with infrastructure
as a service. And also important--And it's also in a principle, actually, that many of
our customers cite as really important to them, is that because of the simplicity of
these services and the scalability and the easy access to shrinking and growing and multiple
data centers and things like that, they're able to build much simpler scalable services
and applications on top of this. Now, of course, remember if you go back to this previous picture,
about the generator that was decommissioned at the brewery, um, not everybody was happy
with that, particularly the generator vendors, yeah? They were not happy with the fact that
you were no longer buying any generators. So, you know, these days, and with this morning,
we talked a little bit about a private cloud, if you think about the benefits from the cloud
in terms of reducing costs and improving agility, private cloud doesn't bring you this. It's
a bit like these--The generator vendor, which you have just dumped, telling you, "No, no,
no, no, no, wait, wait, wait. You need to start your own utility," yeah? "Because that's
where your big benefit is going to come from." The big benefits from the cloud are the fact
that you no longer have to hold capital, yet get access to these unconstrained resources
that are out there. Now, for some of our customers, really important that, you know, there is
a transition phase. And you can see this transition phase as internal, but there is a principle
that we've used with Amazon, a feature that we've added to Amazon EC2, where you can actually
seamlessly extend in your data center. So how does this work? So you can take the Amazon
Cloud, cordon a piece of that cloud off, using a sort of a, you know, a firewall or a walled
garden approach, assign your own addressing to that space, and then start populating that
with Amazon resources. You connect that back with VPN to your own data center, and now
this piece of the cloud looks as if it is part of your own data center. Any of the Amazon
resources that you put in this VPC, this virtual private cloud, cannot communicate to the outside
world, except through the VPN that's running back to your own data center. This allows
you to manage all sorts of dependencies between the apps that you're now running in the cloud,
and the apps that you're running in your own data center. Also, data flows through your
standard policy engines and your firewalls and things like that. So this actually helps
you with transitioning into the cloud, but also managing all sorts of requirements that
you may have. So important for many of our customers is actually that they are able to
do worldwide deployment of their applications, and earlier today, we heard lots of good things
about how transparent the cloud is. You know, the cloud is really the cloud. We don't know
where all these services are, you don't need to know where these--where they service it,
or where these data centers are, and that's okay at the application level. At the infrastructure
level, that is not okay, yeah? Because there's many things that are really important to developers
that have to use the infrastructure services that, for them, we need to break this transparency,
yeah? One thing is, uh, for performance cases, yeah? Latency still matters. Where you place
your applications all over the world, whether you do this in the E.U. or the West Coast
or East Coast U.S. or Asia, latency really matters. Also, you need to be able to sustain
many different affiliate modes. so you need to give access to multiple data centers or
multiple availability zones, as we call them, so that you can build fault-tolerant applications.
But most importantly, these kind of boundaries need to also follow, um, U.S. diction, such
that, for example, the E.U. has a whole set of different privacy regulations, which means
that as an engineer, as a developer using these services, you need to be able to be
sure that if you store data in the E.U., that data will never leave the E.U. And maybe at
the application level, you want to make this all transparent to your customers, but those
of us who really have to deal with security and certification and compliance know that
you have to have fine grain controls to actually manage this. So Amazon deploys what's called
regions, those regions follow U.S. dictions, and by using that principle, you can actually
place applications all over the world. So there is an E.U. region, there's a West Coast,
East Coast region, and this is...In the first half of this year, so that's almost over,
but fairly soon, we'll be launching a Southeast Asia region as well. And it's not just--We
talked earlier about pay as you go, but there is actually more models that we are innovating
on, So on-demand is one of them. If you want to run 24/7, there's a reserved instances
model, which can really drive the cost down, and recently, we also introduced a spot market,
where you can actually decide what's the price of my computation when I want to run it, and
then there's a spot market where you can actually enter these jobs into, and they will be run
at the moment that your price will be met. So there's many partners in this. Um, important
for us, and it's a really important principle is that there's maximum flexibility for our
customers, yeah? We do not lock you into any operating system, any database, any programming
language, yeah? If you want to run Windows Server 2008 with Mono or with Doc.net Tools,
or you want to run Apache in it, then you should be able to do so. So all of these operating
systems of these vendors are all available in the cloud. You can also use many of the
open source ones, all their databases, all their middleware, all of the supported software.
And not only actually at the higher level, not only the big tools, but, for example,
Oracle also allows you with RMAN, the backup tool, to actually pick Amazon S3 as a backup
target. Um, many of your traditional software vendors all run on top of this platform. They've
all integrated it into their management tools. Um, there's many more, actually, that could
go on this slide. Same goes for many of the system integrators. All of them have practices
around integrating, um, your applications onto the Amazon Cloud. So I want to close
up with a few other examples. These are some examples of high- performance computing customers
that we have, and they're all different. You know, Eli Lilly wanted to have a high-performance
computer environment for collaborative drug testing, but for them it was important that
this would happen out in the open, meaning that they didn't want to give all these resources--
researchers, actually, access to the Eli Lilly data centers. So they stamp out this sort
of collaborative environment in the cloud, completely secure. All these researchers work
together, and then data from that flows back to the Eli Lilly data centers. Pfizer's the
other way around. They use, the, uh...They wanted to have a completely secure environment
with a VPN back to their own data centers, and they use Amazon Virtual Private Cloud
to actually do-- visit the 5-12 node computational engines. One sort of slam-dunk area where
the infrastructure as a service works really well is, of course, in the internet services
business. Here's a whole range from them. Um, Facebook's been mentioned many times these
days. Playfish is one of the, uh... one of the top game providers. But, actually, if
you look at the whole list of, uh, Facebook applications, the top seven in there that
are not actually made by Facebook themselves all run on the Amazon Cloud. And all of these--Why?
Because all of these were businesses that actually were not in business about two years
ago. To be able to grow to sustain something like, what is it, 75 million customers a month,
you actually have to be able to be on a platform that allows you to grow this fast. And also
if you launch--If you launch any marketing campaign these days-- You know, a marketing
campaign is no longer just a website. It's a website, it's streaming video, it is user-generated
content, it's some casual gaming, it's integration into Facebook. All of these things, you need
to be prepared for success, so it's a slam-dunk to run that in the cloud, instead of, you
know, scaling those for peak in your own data centers. Um, this one, um, I wanted to introduce,
because testing of the cloud's a big deal. Um, we all know that it's very close to April
15th, yeah? Intuit's TurboTax program is, of course, there's an online version of that.
Intuit wanted to make sure that this could actually sustain all the traffic that's going
to happen two days from now, because just like, you know, delivering homework in school,
we are all going to deliver this on April 15, of course. So SOASTA, which is a testing
company, first fired up 2,000 instances in the Amazon Cloud, simulating 300,000 browsers
at the same time submitting their tax forms into Intuit. Testing is a big deal in the
cloud, because now, suddenly, testers have a whole environment that they didn't have
before. And so it's also that these become platforms, yeah? Remember that it's not not
just the fact that customers start running their applications in the cloud, yeah? At
the same time, enterprises start thinking about, "What is actually the kind of unique
IP that I have that I could be reselling in the cloud, where the cloud becomes a market
place for these services. And some enterprises are doing that, because if they're not doing
it, actually, there's a number of startups and younger businesses that are doing it.
So Siemens and Ribbit, for example--Ribbit is in the--It's a voiceover IP package that
actually is now owned by British Telecom, but Twillio is actually a younger business
that does fully programmable voice and SMS services. Really that simple. You can now
build completely voice and SMS-enabled applications, and on a pure pay- as-you-go model. SimpleGeo,
another example of a company that provides you with location-based services. Now, with
all of these higher-level services, it becomes very simple to build a whole range of new
applications that weren't possible before. Add to that, data that comes from Salesforce,
add to that data that comes out of your Google Apps, and you'll have an environment that
is much richer than that we had even two years ago. Now, um, where's Amazon heading with
this? There's only two things that I want to emphasize. Our top priorities in terms
of investment in the Amazon Web Services business are continuing focus on operational excellence,
because it is absolutely crucial that we complete--that we continue to focus on our availability and
reliability. There's nothing more important than that, except for maybe point number two
on this list, which is security. And, you know, of course, there's the online and real-time
security, but also certification in terms of SAS-70, um, you know, ISO 27,001, and a
number of the other certifications that are all on the way, and they're important for
our customers. Yeah, so, I want to close this off. If you think about as an infrastructure
of services, yeah? So infrastructure as a service provider, what do I think are really
the important criterias when you pick one, yeah? Um, of course, I think security--I want
to emphasize that once more. Security is exceptionally important. Is the provider that you're going
to pick not only providing you with security, but are they innovating in it, yeah? For example,
there's this whole new engine that provides you very grind-grain--very fine-grain policy
control over who can access which objects. These guys from Germany on that subnet with
those identifiers are able to access this queue in a read fashion between 3:00 and 4:00
on a Friday afternoon, yeah? And it's not that we want customers to actually type in
those rules, but many of your enterprises will have very extensive higher- level policy
engines that can map down onto this very rich security infrastructure. Now, operational
performance will, of course, remain. What is the track record of this company? Cost.
Are they driving cost down? Are they giving you benefits by you actually joining up? Are
you getting the benefit of actually the economy of scale? Um, as I mentioned earlier, I think
it is really important for you to be able to determine which operating system, which
programming language, which environment you want to run, um, on this infrastructure. And,
as I mentioned earlier, is this provider actually continuing to innovate and making sure that
you can provide--can get access a richer ecosystem. Yeah? So, with that, uh, I want to leave it.
The only thing that you really need is this URL and a credit card, and that's all you
need to get started. Although, we also do billing, and we also do invoicing, and we
do all the other things that, you know, enterprises won't. Thank you. [pause]
>> Thank you very much, Werner. And now we'll have a short break, I believe in the tents,
and also back that way. You'll find, uh...We need to reconvene in 15 minutes at 3:30. You'll
find that Dave's team, aside from being really good programmers, are terrific pastry chefs.
Thanks.