>> Announcer: Live from the Moscone Center, it's The Cube covering AWS Summit San Francisco 2018. Brought to you by Amazon Web Services. >> Welcome back to our exclusive Cube coverage here at AWS, Amazon Web Services Summit 2018 in San Francisco. I'm John Furrier with my cohost, Stu Miniman. We have a special guest. We have an influencer, authority figure on AWS, Corey Quinn, editor of Last Week in AWS, also has got a podcast called Screaming, >> Corey: In the Cloud. >> Screaminginthecloud.com just launched. Corey, great to have you on. Thanks for joining us. >> No, thank you for letting me indulge my ongoing love affair with the sound of my own voice. (laughing) >> Well we love to have you on and again, love the commentary on the keynote on Twitter. Lot of action, we were in the front row, kind of getting all the scene. Okay, if you're going to write the newsletter next week for what happened this week, if this week was last week, next week, what's your take on this? Because again, Amazon keeps pounding the freight train that's just the cadence of AWF announcements. But they're laying it out clear. They're putting up the numbers. They're putting out the architecture. They're putting out machine learning. It's more than developers right now. What's your analysis, what's your take of what's happening this week? >> I think that certain trends are continuing to evolve that we've seen before where it used to be that if you're picking an entire technology that you're going to bet your business on, what you're going to build on next. It used to be which vendor do I pick, which software do I pick? Now even staying purely within the AWS ecosystem, that question still continues to grow. Oh so I want to use a database, great. I have 12 of them that I can choose between. And whatever I pick, the consensus is unanimous, I'm wrong. So there needs to be, I still think there needs to be some thoughtful analysis done as far as are these services solving different problems. If so, what are the differentiating points? Right now, I think the consensus emerges that when you look into a product or service offering from AWS, the first reaction all of us feel is to some extent confusion. I'm lost, I'm scared. I don't really know what's going on. And whatever I'm about to do, I feel like I'm about to do it badly. >> Yes, scale is the big point. I want to get your reaction. Matt Wood, Dr. Matt Wood, Cube alum, been on many times, he nailed it I thought when he said, look it, machine learning and data analysis was on megabytes and gigabytes, they're offering petaflop level compute, high performance, and then Werner Vogels has also said something around the services where, you can open things up in parallel scale. So, what's your reaction to that, as you look at that and say whoa, I've got a set of services I can launch in parallel, and the scale of leveraging that petaflops. I mean, this is kind of like the new, you know, compute model. Your reaction is it real? Are customers ready for it? Where are we in that evolutionary customer journey? Are they still cavemen trying to figure out how to make fire and make the wheel? I mean where are we with this? >> I think that we see the same thing continuing to emerge as far as patterns go, where they talk about, yes there's this service. Just start using it and it scales forever. And that's great in theory, but in practice, all of the demos, all of the quick starts, all of the examples, paint by numbers examples that they'll give you, tend to be at very small scale. And yes, it works really well when you have effectively five instances all playing together. When you have 5,000 of those instances, a lot of sharp edges start to emerge. Scale becomes a problem. Fail overs take far longer. And let's not even talk about what the bill does at that point. Additionally once you're at that point, it's very difficult to change course. If I write a silly blog, and effectively baby seals get more hits than this thing does, it's not that difficult for me to migrate that. Whereas if I'm dealing with large scale production traffic that's earning me money on a permanent basis, moving that is no longer trivial or in some cases feasible at all. >> Yeah Corey, how does anybody reasonably make a decision as to how they're going to build something because tomorrow, everything might change. You said oh okay great, I had my environment and I kind of you know, built my architecture a certain way, oh wait there's a new container service. Oh, and start building a, oh wait now there's the orchestrated version of that that I need to change to. Oh wait, now there's a serverless built way that kind of does it in a similar way. So you know, it seems like it used to be the best time to do things would've been two months ago, but now I should do it now. Now the answer is, the best time for me to do things would be if I could wait another quarter, but really I have to get started now. >> I tend to put as much on future Corey as I possibly can. The problem is that at one time I could've sat here and said the same thing to you about, oh virtualization is the way to go. You should migrate your existing bare metal servers there. And then from virtualization to Cloud and Cloud to containers. Then containers to serverless. And this narrative doesn't ever change. It's oh what you're doing is terrible and broken. The lords of thought have decried that now it's time to do this differently, and that's great, but what's the business use case for doing it? Well, we did this thing that effectively people get on stage at keynotes and make fun of us for now, so we should really change it. Okay maybe, but why? Is there a business value driving that decision? And I think that gets lost in the weeds of the new shiny conference ware that gets trotted out. >> Well I mean Amazon's not, I mean they're being pretty forthright. I mean, you can't deny what Intuit put out there today. The Intuit head of machine learning and data science laid out old way, new way. Classic case of old way, new way. Eight months, six to eight months, ton of cluster, you-know-what going on as things changed it. They're just data scientists. They're not back-end developers. They went to one week. Nine months to one week. That's undeniable right? I mean how do you, I mean that's a big company but, that seems to be the big enchilada that Amazon's going for, not the pockets of digital disruption. You know what I'm saying? So it's like, how do you square that out? I mean how do you think about that? >> Cloudability had a great survey that they released the results of somewhat recently where they were discussing that something like four or five of the, or I'm sorry 85% of the global spend on AWS went to four or five services that all have been around for a long time. RDS, EC2, S3, PBS, Data Transfer. And so as much as people talk about this and you're seeing pockets of this, it's not the common gaze by a wide margin. People don't get up on stage and talk about, well I have these bunch of EC2 instances behind a low balancer, storing data on S3 and that's good enough for me, because that's not interesting anymore. People know how to do that. Instead, they're talking about these far future things that definitely add capability, but do come at a cost-- >> I mean it's the classic head room. It's like here's some head room, but at the end of the day it's EC2, S3, Kinesis, Redshift, bunch of services that's U.S that seem to dominate. The question I want to ask you is that they always flaunt out the, every year it changes, Kinesis was at one point the fastest growing service in the history of AWS. Now it's Aurora. We made a, I made a prediction on the opening that a SageMaker will be the fastest growing service, because there just seemed to be so much interest in turn-key machine learning. It's hard as you-know-what to do it. >> I agree. >> Your thoughts on SageMaker? >> In one of my issues a few weeks back, I wound up asking, so who's using SageMaker and for what? And the response was ridiculous. What astounded me was that no two answers were alike as far as what the use case was. But they all started the same way. I'm not a data scientist, but. So this is something that's becoming-- >> John: What does that mean to you? What does that tell you? >> It tells me that everyone thinks they're unqualified to be playing around in the data science world, but they're still seeing results. >> But Corey I wonder because you know, think back a few years ago. That's what part of the promise of big data, is we have all this data and we're going to be able to have the business analysts rather than you know, some PhD sort this out. And machine learning is more right. We want to have these tools and we want to democratize data, you know. Data is the new bacon. It's the new oil. Data's the new everything. So you know, machine learning, you think this is all vapor and promise, or do you think it's real? >> I think big data is very real and very important. Ask anyone who sells storage by the gigabyte. And they will agree with me. In practice I think it's one of those areas where the allure is fascinating but the implementation is challenging. Okay we have history going back 20 years of every purchase someone has ever made in our book store. That's great, why do I still wind up getting recommendations? >> Well yeah and I guess, I want to talk that it was the, I see it more as, everything that was big data is now kind of moving to the ML and AI stage. Because big data didn't deliver on it, will this new wave deliver on the promise of really extracting value from my data? And it's things like this, live data. It's doing things now with my data, not the historical, lots of different types of data that we were trying to do with like the Hadoops of the world. >> Got ya. I think it's a great move because either yes it will or no it won't, but if it doesn't, you're going to see emergent behaviors of so why didn't it work? Well we don't understand the model that this system has constructed, so we can't even tell you why it's replacing the character I with some weird character that's unprintable, so let alone why we decide to target a segment of customers who never buys anything. So it does become defensible from that perspective. Whether there's something serious there that's going to wind up driving a revolution in the world of technology, I think it's too soon to say and I wouldn't dare to predict. But I will be sarcastic about it either way. >> Okay well let's get sarcastic for a second. I wan to talk to you about some moves other people are making. We'll get to the competition in a minute but Salesforce required MuleSoft. That got a lot of news and we were speculating on our studio session this week or last week with the CEO of Rubric that it's great for Salesforce. It can bring structured data in, on PRIM and the Cloud. Salesforce is one big SaaS platform. Amazon is trying to SaaS-ify business through the Cloud. So, but one of the things that's missing from MuleSoft is the unstructured data. So the question for you is, how are you seeing and how is your community looking at the role of the data as a strategic asset in a modern stack, one, both structured and unstructured data, is that becoming, even happening or is it more like, well we don't even know what it means. Your thoughts? >> I think that there's been a long history of people having data in a variety of formats and being able to work with that does require some structure. That's why we're seeing things emerging around S3's, increasing capabilities, being able to manipulate data at rest. We're seeing that with S3 and Glacier Select. We're seeing it with Athena which is named after the goddess of spending money on Cloud services, and there's a number of different tooling options that are, okay we're not going to move three x-abytes of data in so we have to do something with where it is. As far as doing any form of analysis on it, there needs to be some structure to it in order for that to make sense. From that perspective, MuleSoft was a brilliant acquisition. The question is, is what is SalesForce going to do with that? They have a history of acquisition, some of which have gone extremely well. Others of which we prefer not to talk about in polite company. >> It comes back down to the IDE thing. How many IDE's does Salesforce have now? I mean it's a huge number. >> I'm sure there's three more since we've started talking. (laughing) >> Yeah so Corey, you brought up, you know, money. So you know, the trillion dollar, what feedback are you getting from the community? You know there's always, well I get on Amazon and then my bills continue to grow and continue to grow. Same thing at Salesforce by the way if you use them. So you know, there's always as you gain power, people will push back against it. We saw with with Mike Hichwa with Oracle. I hear it some but it's not an overriding thing from when I talk to customers about Amazon. But I'm curious what you're hearing. Where are the customers feeling they're getting squeezed? Where is it you know, phenomenal? What are you seeing kind of on the monetary side of Cloud? >> In my day job, I solve one problem. I fix the horrifying AWS bill, both in terms of dollars and cents as well as analysis and allocation. And what astonishes me, and I'm still not sure how they did it. It's that AWS has somehow put the onus onto the customer. If you or I go out and we buy a $150,000 Ferrari, we wake up with a little bit of buyer's remorse of dear lord, that was an awful lot of money. When you do the equivalent in AWS, you look at that, and instead of blaming the vendor for overcharging, instead we feel wow, I'm not smart enough. I haven't managed that appropriately. Somehow it's my fault that I'm writing what looks like a phone number of a check every month over to AWS. >> John: It creeps up on you. >> It does. It's the boiling a frog problem. And by the time people start to take it seriously, there's a lot of ill will. There's a sense of, our team is terrible, and wasn't caring about this. But you don't ever cost-optimize your way to success. That's something you do once you have something that's up and working and viable. You don't start to build a product day one for the least possible amount of money and expect to attain any success. >> Well let's talk about that real quick to end the segment because I think that's a really important thing. Success is a double-edged sword. The benefit of the Cloud is to buy what you need, get proof of concept going, get some fly wheels going or whatever, virtuous circle of the application. But at some point, you hit a tipping point of oh shit this is working. And then the bill is huge. Better than over-provisioning and having a failed product. So where's that point with you guys or with your customers? Is there like analytics you do? Is that more of a subjective qualitative thing? You say, okay are you successful? Now let's look at it. So how do you deal with customers? 'Cause I can imagine that success is, it becomes the opportunity but also the problem. >> I think it's one of those, you know it when you see it type of moments, where if a company is spending $80,000 a month on their Cloud environment and could be spending 40, that's more interesting to a company that's three people than it is to an engineering team of 50. At that point, sorry they're embezzling more than that in office supplies every month. So that's not the best opportunity to start doing an optimization pass. More important than both of those scales to me has always been about understanding the drivers of it. So what is it that's costing that? Is it a bunch of steady state things that aren't doing work most of the time? Well, maybe there's an auto-scaling story in there. Maybe there's a serverless opportunity. Maybe nobody's using that product and it's time to start looking at rolling it in to something. >> They've left the lights on right? So to speak. >> Exactly. >> The server's are still up. Wait a minute, take them down. So, writing code, analytics, is that the answer? >> All of the above. In a vacuum, if you spin up an instance today, and don't touch it again, you will retire before that instance does. And it will continue to charge you every hour of every day. Understanding and being able to attribute who spun that up, when was it done, why was it done, and what project is it tied to? Is it some failed experiment someone did who hasn't worked here in six months? Or is that now our master database? We kind of need to know in either direction what that looks like. >> Alright before we wrap, you got to tell us, what do we expect to hear from your podcast? >> Good question. My podcast generally focuses on one-on-one conversations with people doing interesting things in the world of Cloud, which is vague enough for me to get away with almost anything as far as it goes. It's less sarcastic and snarky than some of my other work, and more at the why instead of the how. I'm not going to sit here and explain how to use an ABI. There are people far better at that than I am. But I will talk about why you might use a service, and what problem it reports to solve. >> Alright Corey, great to have you on. Uh the Screaming Pod, Screaming Cloud, >> Corey: ScreamingInTheCloud.com >> ScreamingInTheCloud.com, it's a podcast. Corey thanks for coming on and sharing the commentary, the insight on AWS, the how and the why, the Cube breaking down. All the action here in Moscone Western San Francisco, AWS 2018 Summit, back after more, after this short break. (spacey music)