(upbeat music) >> Welcome to theCUBE and our Q3 AWS Startup Showcase. I'm Lisa Martin. I've got two guests here with me, Erez Berkner is back, the Co-Founder and CEO of Lumigo. Hey, Erez, good to see you. >> Hey, Lisa, great to be here again. >> And Kevin O'Neill, the CTO at Flex is here as well. Kevin, welcome. >> Hi, Lisa, nice to meet you. >> Likewise, we're going to give the audience an overview of Lumigo and Flex. Let's go ahead, Erez, and start with you. Talk to us about Lumigo, and I think you have a slide to pull up to walk us through? >> Yeah, I have a couple, so, great to be here again. And just as an overview, Lumigo is a serverless monitoring and debugging platform. Basically allowing the user, the developer to get an end-to-end view of every transaction in his cloud. It's basically distributed tracing that allows you from one hand to monitor, to see a visual representation of your transaction, but also allows you to drill down and debug the failure to get to the root cause. So essentially, once you have the visualization and if we'll move to the next slide, you can actually click and drill down and see all the relevant debug information like environment variables, duct rays, inputs, outputs, and so on and so forth. And by that, understanding the root cause. And sometimes those root causes of the problems are not just errors, they are latencies, they are hiccups. And for that, we can see on the next slide, where Lumigo allows you to see where do you spend your time? Where are the hiccups in your system? What's running in Paula to what in the same transaction, where you can optimize. And that's the essence of what Lumigo provides in a distributed environment and focusing on serverless. >> Got it, focusing on serverless, we'll dig into that in a second. Kevin, give us an overview of Flex. You're a customer of Lumigo? >> We are indeed. So Flex is a build smoothing platform. We help people pay their rent and other bills, in these times of uncertainty and cashflow, the first of the month for your rent, it's a big bill. Being able to split that up into multiple payments is a lot easier. And when we entered the market, you were looking at a place where people were using things like payday loans, which are just ridiculous, really hurting, hurt people in the longterm. So we want to come in with something that is a little more equitable, little fairer and help people who can well afford their rent. They just can't afford it on the first, right? And so we started with rent, and now we cover all the bills like utilities and things like that. >> What a great use case, and I can't even imagine, Kevin, in the last year and a half, how helpful that's been as the world has been so dynamic. So talk to me a little bit about what you were doing before Lumigo and we'll get into then why you went the serverless route. >> Right, so I came to Flex to help them out with some problems that we're having as our servers were scaling up. Obviously, when the business hit, it was really, it went from zero to 100 miles an hour so quickly. And so I came in to help sort out some of the growing issues. And so when I started looking at that, we were three developers and didn't want to spend time on ops, didn't want to spend time on all of the things that you have to do just to be in business, right? And it's really expensive in the technical space. If you get into something about Kubernetes or things like that, you spend a lot of time building that infrastructure, making sure, and that's really minimal value to your business. It's there for reliability, but it doesn't really focus in on the thing that is important to you. So we wanted to build something that minimized that, we talk about DevOps, we want it ops zero, right? So that's like DevOps is a really nice practice, but having people in that role, it seems like you're still doing ops, right? You still got people who are doing those things, and we want it to kind of eliminate that. So I had some experience with serverless before joining Flex. I thought we'll run up a few things and spike up a few things. When you come out of environments like Kubernetes or your more traditional AC to type infrastructure, you'd lose some things. And one of the big things you'd lose is platforms of visibility. So things like OpenTrace and Datadog, and things like that, that do these jobs of telling you what's going on in your infrastructure, you've got fairly complex infrastructure going on, lots of things happening. And so, we initially started with what was available on the platforms, right? So we started with your CloudWatch logs and New Relics, right? Which got us somewhere. But as soon as we started to get into more complex scenarios where we're talking across multiple hops, so through SQS and then through EventBridge and Dynamo, it was very difficult to be able to retrace a piece of information. And that's when we started looking around for solutions, we looked at big traditional pliers, the Datadogs, the New Relics and people like that. And then the serverless specific players, and we ended up landing on Lumigo, and I couldn't have been happier with the results, from day one, I was getting results. >> That's great, I want to talk about that too, especially as you say, we wanted to be able to focus on our core competencies and not spend time in resources that we didn't have in areas where we could actually outsource. So I want to go back to Erez, talk to me about some of the challenges that Kevin articulated, are those common across the board, across industries that Lumigo sees? >> Yeah, I think the main thing when we met Kevin main were about visibility and about ability to zoom out, see the bigger picture and when something actually fails or about to fail in production, being able to drill down to understand what happened, what is the root cause, and go ahead and fix it instead of going through different CloudWatch logs, and log groups and connecting the dots manually. And that's one of the most common challenges when enterprise, where software engineers are heading toward serverless, toward managed services. So, definitely we'll hear that it was many of our customers. >> So Kevin, talk about the infrastructure that you've set up with serverless and go through some of the main benefits that Flex is getting. >> Right, so look, the day one thing of course, is the number of people we need doing operations as we've grown is next to nothing, right? We are able to create in that, we all want this independence of execution, right? So as you scale, I think there's two ways really to scale a system, right? You can build a monolith and shot it, that works really, really well, right? You can just build something that just holds a ton of data and everything seems connected when you release it all in one place, or you build something that's a little more distributed and relies on asynchronous interactions effectively, like in everywhere but the edges, both of those things scale. The middle ground doesn't scale, right? That middle ground of synchronous systems talking to synchronous systems, at some point, your lightency is your sum of all the things you're talking to, right? So doing anything in a quick way is not possible. So when we started to look at things like, I'm sorry, so the other challenge is things like logging and understanding what's happening in your system. Logging is one of those things that you always don't have the thing logged that you're interested in, right? You put in whatever logging you like, but the thing you need will always be missing, which is why we've always taken a tracing approach, right? Why you want to use something like Lumigo or an OpenTrace, you don't sit there and say, "Hey, log this specifically," you log the information that's moving through the system. At that point, you can then look at what's happening specifically. So again, the biggest challenge for us is that we run 1500 landlords, right? We run 600 queues. There's a lot of information. We use an EventBridge, we use Dynamo, we use RDS, we've got information spread out. We moved stuff, but to third party vendors, we're talking out to say, two guys like Stripe and Co, and we're making calls out of those. And we want to understand when we've made those calls, what's the latency on those calls. And for a given interaction, it might touch 20 or 30 of those components. And so for us, the ability to say, "Hey, I want to know why this file to write down here." We need to actually look through everywhere, explain, and understand how it's complex, right? Where this piece of data that was wrong come from? And so, yeah, which is difficult in a distributed environment where your infrastructure is so much a part of somebody else's systems, you don't have direct access to assistance. You'd only got the side effects of the system. >> Right, so talk to me in that distributed environment, Kevin, how does Lumigo help to improve that? Especially as we're talking about payments and billing and sensitive financial information. >> Right, so in a couple of ways, the nice part about Lumigo is I really don't have to do much in order for it to just do its thing, right? This comes back to that philosophy of zero ops, right? Zero effort. I don't want to be concentrating on how I build my tracing infrastructure, right? I just want it to work. I want it to work out of the box when something happens, I want it to have happened. So Lumigo, when I looked at it, when I was looking at the platforms, the integration's so straightforward, the cost integration being straightforward is kind of useless, if it doesn't actually give you the information you want. And we had a challenge initially, which was, we use a lot of EventBridge, and of course, nothing tries to EventBridge until we got, I mentioned this to Erez and Co, and said, "Hey guys, we really need to try to EventBridge, and a little while later, we were tracing through EventBridge, which was fantastic. And because I would say 70% of our transactions evolve something that goes through EventBridge, the other thing there. We're also from an architectural standpoint, we're also what's known as an event source system. So we derive the state of the information from the things that have occurred rather than a current snapshot of what something looks like, right? So rather than you being Lisa with a particular phone number and particular email address stored in a database as a record, you are, Lisa changed the phone number, Lisa changed her email address. And then we take that sequence of things and create a current view of Lisa. So that also helps us with ordering, right? And at those lower levels, we can do a lot of our security. We can do a lot of our encryption, we can say that this particular piece of information, for example, a social security number is encrypted and never is available as plain text. And you need the keys to be able to unlock that particular piece of information. So we can do a lot of that, a lower level infrastructure, but that does generate a lot of movement of information. >> Right. >> And if you can't trace that movement of information, you're in a hurting place. >> So Erez, we just got a great testimonial from Kevin on how Lumigo's really fundamental to their environment and what they're able to deliver to customers, and also Kevin talked about, it sounds like some of the collaboration that went on to help get that EventBridge. Talk to me, Erez, about the collaborative partnership that you have with Flex. >> Yeah, so I think that it's more of a, I would say a philosophy of customers, the users come first. So this is what we're really trying to about. We always try to make sure there's an open communication with all of our customers and for us customer is a key and user's a key, not even a customer. And this is why we try to accommodate the different requests, specifically on this event, this was actually a while after AWS released the service and due to the partnership that we have with AWS, we were able to get this supported relatively fast and first to market supporting EventBridge, and connecting the dots around it. So that's one of the things that we really, really focused on. >> Kevin, back to you, how do you quantify the ROI of what Lumigo is delivering to Flex? >> That's a really good question. And Erez, and I've talked about this a few times, because the simple fact is if I add up the numbers, it costs me more to trace than it does to execute. But if I look at the slightly bigger picture, I also don't have op stuff, right? And I also have an ability to look at things very quickly. The service cost is nothing compared to what I would need if I was running my own tracing through OpenTrace with my own database, monitor the staff to support those things. But the management of those things, the configuration of those things, the multiple touchpoints I'd need for those things, they're not the simple thing. So, if you look at a raw cost, you go, oh man, that part is actually more than my execution costs at least certainly in the early days, but when I look at the entire cost of what it takes to watch manage and trace a system, it's a really easy song, right? And a lot of these things don't pay off until something goes wrong. Now we're heavy users of EventBridge. EventBridge has had two incidents in USA in the last six months, right? And we were able to say through our traffic, that was going through EventBridge, that the slowdown was occurring in EventBridge. In fact, we were saying that before was alerted in the IDR VUS dashboards, to say, "Hey, EventBridge is having problems," like we watch all their alerts, but we were saying an hour before leading into Titus saying, "Hey, there's something going wrong here." Right? Because we were seeing delays in the system. So things like that give you an opportunity to adjust, right? You can't do it. You're not going to be able to get everything off of EventBridge for that period. But at least I can talk to the business and say, "Hey, we're having an impact here, and this is what's going on. We don't think it's our systems, we think it's actually something external. We can see the tries, we see it going in, we see it coming out, it's a 20 minute delay." >> There's a huge amount of value in that, sorry, Kevin, in that visibility alone, as you said, and even maybe even some cost avoidance is there, if you're seeing something going wrong, you maybe can pivot and adjust as needed. But without that visibility, you don't have that. There's a lot of potential loss. >> Yeah, and it's one of those things that doesn't pay for itself until it pays for itself, right? It's like insurance, you don't need insurance until you need insurance. These sort of things, people look at these things and go, "Ah, what am I getting it from day to day?" And day to day, I'll use Lumigo, right? When I'm developing now, Lumigo is part of my development process, in that, I use it to make sure the information is flowing in the way I expect it to, right? Which wasn't what I expected to be able to do with it, right? It wasn't even a plan or anything I intended to use it for, but day to day now, when I buy something off, one of the checks I go through when I'm debugging or when I'm looking at a problem, especially distributed problem is what went through Lumigo. What happened here, here and here, and why did that happen in response to this? So, these things are, again, it's that insurance thing, you don't need it until you need it, and when you need it, you're so glad you've got it. >> Right, exactly. >> Actually it's already said, I have a question because, yeah, I think that it's clear on that part. And how did this, if it change the developer work in Flex, do you feel different on that part? >> I think it's down to individual developers, how they use the different tools, just like individual developers use different tools. I tend to, and a couple of people that I work closely with tend to use these tools in this way, probably where the more advanced users of serverless in general inside the organization. So we were more aware of these weird little things that occur and justly double-checks you want to do. But I feel like when I don't have something like Lumigo in place, it's very hard for me to understand, did everything happen? I can write my acceptance tests, but I want to make sure that, testing is a really fun art, right? And it's picking my cabinets nice and easy, and you can run all these formulas to do things, it's just not right, and there's just too many, especially in distributed space, too many cases where things look odd, things look strange, you've got weird edge cases. We get new timeouts in Dynamo. We hit the 100,000 limit in fresh hall on Dynamo, right? In production, that was really interesting because it meant we needed to do some additional things. >> Lisa: Kevin, oh, go ahead. >> Go ahead, no, go ahead, Lisa. >> I was just going to ask you, I'd love to get your perspective. It sounds like, you look at other technologies, there's been some clear benefits and differentiators that you saw, which is why you chose Lumigo, but it also sounds like there were some things that surprised you. So in your opinion, what are some of the key differentiators of Lumigo versus its competitors? >> So I guess I've been a partner with Lumigo for like eight months now, right? Which is a long time in the history of Flex, right? 'Cause we're just out of two and a half years old. So, when I did the initial evaluation, I was looking for the things. I'm lazy, so I wanted something that I could just drop in and it would just work, right? And get the information I wanted to ask. I wanted something that was giving me information consistently. So I try to figure these things out and hit them with some load. I wanted it to have coverage of the assistance that we use. We use Dynamo a lot. We use Lambros a lot, and I want it not just cursory coverage, how it's just another one of the 20,000 things that they do, I wanted something that was dedicated to it. That gave me information that was useful for me. And really the specialist serverless providers were the obvious choice there. When you looked at the more general providers, the Datadogs and New Relics, I think if you're in an environment that has a lot of other different types of systems running on, then maybe the specificity that you'd lose is worthwhile, right? There's trade off you can make, but we're in a highly serverless environment, so one of the specificity. When I looked at the vendors, Lumigo was the one that worked best straight out of the box for me, it gave me the information I wanted. It gave me the experience I wanted, and to be frank, they've reached out really quickly and had a chat about what were my specific problems, what I was thinking. And all of those things add up, a proactive vendor, just doing the things you wanted to do, and what became and has become a lasting partnership, and I don't say partnership lightly 'cause we've worked with a number of other vendors, right? For different things. But Lumigo, I have turned to these guys, 'cause these guys know serverless, right? So I've turned to these guys when I've gone, "Look, I am not sure what the best approach here is." You have trusted me about it, this is vendor, right? >> Right, but it sounds like it's very synergistic, collaborative trusted relationship. And to your point, not using the term partner lightly, I think arises, probably couldn't have been a better testimonial for Lumigo, its capabilities, and what you guys are able to do. So I'll give you, Erez the last word, just give the audience a little bit of an overview of the AWS partnership. >> Sure, so AWS has been a very strategic partner for Lumigo, and that means that, I would say the most critical part is a product, is a technology. And we are design partners with the serverless team. And that means that we work with AWS to make sure that before new services are released, they get our feedback on whether we can integrate easily or not, and making sure that on the launch date, we are able to be a launch partner for a lot of their services. And this strong partnership with R&D team is what's allowing Lumigo to support new services out of the box like Kevin mentioned. >> Excellent, gentlemen, thank you so much for joining me today, talking about, not just about Lumigo, but getting this great perspective of it through the CTO lens with Kevin, we appreciate your insights, your time, and what a great testimonial. >> Thank you very much, thank you, Kevin. >> Thanks, Lisa, thanks Erez. >> You're most welcome. For Erez Berkner and Kevin O'Neill, I'm Lisa Martin, you're watching the AWS Startup Showcase for Q3. (gentle music)

(bouncy music) >> Welcome to this Cube Conversation, I'm Lisa Martin. I'm joined by Erez Berkner, the CEO and co-founder of lumigo. Erez, welcome to the program. >> Hey Lisa, thank you for having me. Glad to be here. >> Excellent, we're going to have a great conversation. We're going to be talking about the growing trend of using cloud native and serverless. But before we do, Erez, give our audience an overview of lumigo. >> Excellent, so lumigo is an observability platform. Basically allowing developer, architects, the technology person in the organization to understand what's going on with his modern cloud, with his serverless, with his cloud native application. So at the end of the day, lumigo as assess platform, allow you to know what's happening, get visibility, and be able to get to the root cause of issues, many times before they actually hit your production. >> I saw on your website, in terms of speed, getting up and running quickly, in four minutes with four clicks. Tell me how developers do this that quickly. >> Yeah, that's actually great point. Because in general, when we talk about the modern cloud, people are really fed up with deploying agents, long processes of servers, and more and more we see the trend towards APIs, toward code libraries. At the end of the day, at the heart of lumigo, we built a very strong automation engine based on APIs, based on lomdalier integration. And this allows a developer to basically connect lumigo via the APIs in couple of clicks. Doesn't require code changes, deployment of agents, deployment of services. And this is why it's so fast, because it's lightweight. And that's a trend of managed services, of serverless, and lumigo is another stone in that wall. >> Excellent, lightweight, key there. Define serverless, what is considered serverless? >> Mmm, ooh, don't get me involved in dispute of those definitions. But I can share my view, but this is a.. Anyone, I would say, have his own definition. But the main concept with serverless is at the end of the day, really, like it says, serverless. You don't deploy a server. You don't rent a server, you don't manage a server, you don't deploy an operating system, you don't patch a server. You don't take care of scalability, of high visibility. Basically, all the chores of managing, of maintaining a server, basically go away. Now, they don't really go away. Somebody else is dealing with them. So there is a server, but it's not your server to manage. And that someone is a cloud provider, is Amazon, is Microsoft, is Google, it's IBM. And this is how I view serverless. Basically, a managed service that doesn't require to deploy or manage a server, and you use it via APIs. And if you think about that, in the past when serverless started, 2015, serverless was function as a service, Lambda, AWS started that. But today, in 2021, serverless, yeah, it's function as a service, it's Lambda, but it's also storage as a service, like S3, and data as a service, like Snowflake, like DynamoDB. And queue as a service like SNS, like EventBridge, like Kenesis. And even Stripe, payment a as service, and Twilio, and SendGrid. So all these API based services, that you just consume, and they're like Lego pieces that you connect together and you just connect and you go, and you start working and they up and running, this is how I define serverless today. And that's basically allowing you to run any application today with zero servers. >> That's a great definition, that nice and clean, and I think the Lego bricks really kind of clicked in my mind when you talked about that. Let's talk now about for business critical production applications, what are you seeing in terms of adoption of serverless for those cases? >> That's a great question, because I think that we are in a critical point of time, in cloud native, in modern cloud, in serverless market. And I think it's an evolution. You know, when we started, again, back in 2015, serverless was just one or two services. But we got to a critical mass of services, including DynamoDB and S3 and Lambda and EventBridge and all the other services, that step function, that basically allow you to build your application based on serverless. And this critical point of the architecture of serverless being mature enough, being wide enough, to allow you to do what you want, to have the confidence running serverless in production, to know that you have the tooling that you used to have in the past to monitor, to debug, to secure, to understand cost, all of this are really coming together this year. We actually see this year, and a bit of end of last year, but this is what's driving a trend in the industry. I think it's still not known enough to many of the organizations, or not wide enough, or not public enough. But our customers are focused on cloud native and serverless. And we've seen a dramatic change in the last six months. And the main change is organizations that used to play around with serverless, that used to do non-business critical usage of serverless, because it's easy, because it makes sense, because it's fast, all of a sudden they got the confidence to do that with their business critical application in production. And this is a shift that we're seeing. And that goes many times with the technology maturity. You start, you play around with something, it makes sense, it makes sense, you get confidence, and boom! This become more and more mainstream technology. And we're at the verge of that. >> In terms of a catalyst for that confidence, do you think that the events, the world events of the last 12 months and this acceleration of digital transformation, has that played any part in the maturation of the technology that's giving customers the confidence to adopt serverless? >> Yeah, I think it's fascinating, what we're seeing. Because I think the last event really push a organization to innovate. Because of different reason, because they don't have the head count, so they need to reduce the maintenance that they do, they need to reduce the developer head count, the DevOps head count, they need to reduce costs. Serverless is running only when it need to run, so you pay only for what you use. So this is another method that our customer, for example, reduce their cost. So I think beyond the maturity of the architecture, the push forward for optimization, for lower usage or lower usage of engineering force, really pushed serverless forward. And this paradigm, once it worked for one team, it's viral. It's viral with in organization and the cross-organization. So this team managed to reduce 50% of the cost, and 70% of the developers that need to maintain the production. Let's duplicate that. And let's do that four times, and five times, and 10 times. And this is the point in time that we are. So that's a trend and I think it's very much impacted by the world economics. >> Interesting, that trend of virality. Let's dig into, you mentioned a couple of benefits. I heard reduction in total cost of ownership, or costs. Talk to me about the lumigo solution, the technology, and what some of those key benefits are that it is consistently delivering to your customers. >> So I think the basic is that serverless makes a lot of sense, economical, maintenance. That's why the cloud providers are putting so much effort and power in delivering more and more serverless maturity. One of the challenges that we see for almost any organization adopting the new technology, it goes back to we understand the values, but at the end of the day I need to make sure that if something goes wrong in production, I will know about it and I will know how to react and fix it in a matter of minutes. 'Cause that's my service, that's my business. And I know how to do it in a server world, where there's one server or three servers, and everything running in the same server. I have the tools for that. And I want to go serverless, I want to go cloud native, but all of a sudden there are dozens of services that I consume via APIs and they're a part of a bigger picture of my application. So I'm lacking many times the confidence, the tools, the awareness of, something goes wrong, I'll know about it, and I'll be able to fix it. And this is where lumigo comes in. So we built lumigo from the ground up to be very much focused on the modern cloud, on serverless. And that means two main things that we provide for our customers. One is, I would say one thing. We provide confidence. You can use serverless in production, and you can rest assured that if something goes wrong, you will be the one alerting and we'll give you all the information to debug it. And we do it by two main things. One is the visibility that we create. Because we're connected to the environment, we alert on things that are relevant to serverless. It's not about CPU, it's not about a iO. It's about concurrency limits, it's about cold start, it's about time outs, it's about reaching duration limits. These are the things that we know to alert you about. It's very specific to the serverless services. And it's not a generic metric, it's serverless metric. So that's number one, visibility, getting alert whenever something is about to go wrong. But what do you do then? Let's say I have one million invocations a day, and one of them is actually, I have a trigger, something went wrong. And this is where lumigo allow the developers to debug. Basically, you click on a specific issue, and lumigo tell you the entire story of what happened, from the very beginning, an API gateway triggering a Lambda, right into DynamoDB, triggering an Lambda, it tell you the entire story end to end of what happened with that specific request, with inputs, with outputs, with environment variables. All the things the developer need in order to debug, to find the root cause, and then fix it in matter of minutes. And that's the game-changer that allow those organizations to run serverless with confidence. >> You talk about confidence, it's a word that I hear often when I'm talking with customers of vendors. It's not something to be underestimated. It's incredibly important that technology provide that confidence, especially given the events of the last year and a half that we've seen where suddenly folks couldn't get into data centers, for example. Talk to me a little bit about some of the customers. I saw from your website some great brand names, but talk to me about a customer that you think really not only has that confidence that lumigo is delivering, but is really changing their business and their approach to modern monitoring with lumigo. >> Yeah, so there are several interesting. I'll choose maybe one of the more interesting cases, a company called Medtronic. It's one of the largest medical device companies in the U.S. And it's very interesting because they have an IoT backend. Basically they have medical devices around the world that send IoT information back to their cloud. And they get metrics, they run machine learning on that. And they took a strategic decision to run the system with serverless. Because it can scale automatically, because it can deploy one more million devices and they don't need to change anything, and many, many other benefits of serverless. And we met them back in 20, end of 2019. They were looking for exactly a solution that allows them to get issues and drill down to analyze those issues. And they were just in the beginning. The early days they had 20 million invocations, requests per month. They knew they were going to scale, they knew that when they scale, they cannot correlate logs, and try to understand what happened manually. They need a professional tool. And this is where they started using lumigo. And today, a year and a half after, they reached one billion invocations a month. Again, the same concept, IoT devices, medical devices, sending metrics and information for the backend for processing. And today, lumigo is monitoring everything in that environment. And alert them from, you're about to have a problem, or you have an application error, or you have high latency, you have spike of cost, all of that are covered by lumigo. And the developers, once they get this to slot, to play the duty, you're just able to click on it, and drill down and see, one by one, requests that created the trigger that alert. And they can understand, again, the inputs, the output, the logs, the return values, everything. I call it debugging heaven. Because it's always there, it's always post-mortem, you don't need to do anything. At the same time you get the visibility and you can fix it, because this is their production, this is their business critical application. >> Debugging heaven, I love that. That's for developers, that is probably a Nirvana state. I want to wrap up Erez, just giving our folks in the audience an overview of the relationship that lumigo has with AWS. >> AWS is one of our strongest partner. I think there's a great synergy working with AWS. We've been partners for the last three years. And I think the reason for the... You know, we're still... AWS has thousands, tens of thousands of partners. I think that this partnership is specifically strong because there is a win-win relationship over here. On the one hand side lumigo is very much invested on Amazon. Our customers are mostly Amazon customers, and we are solving, providing confidence for those customers to run serverless in production, and answering a need of a customer. And this is also the win for Amazon. Amazon is basically have a great, great technology of serverless. But the lack of visibility, the lack of confidence, is hindering the adoption. And Amazon decided to work with lumigo, saying, we'll develop the core, we'll develop the services, we'll develop the serverless architecture, and you can use lumigo for monitoring, for debugging, for everything that you need in order to run that in production. And that's been very, very strong relationship that just grows as we develop together. And it's been on working together with customers, introducing customers, but also on the technology level. For the audience who sees Amazon announcement on serverless, many times lumigo is a design partner. It's part of the announcement, of lumigo was a design partner and the launch partner, and support the new feature out of the box. This is because we want to get the support as soon as possible, as soon as new features are released. So that's where we are today. >> Sounds like a very collaborative and symbiotic relationship. Erez, thank you for joining me on the program today, talking to us about some of the trends in serverless, some of the things that are catalyzing adoption, that visibility, that confidence, that lumigo delivers to its customers. We thank you for your time. >> Excellent, thank you very much Lisa. Have a good day. >> You too! For Erez Berkner, I'm Lisa Martin. Thanks for watching this Cube Conversation. (bouncy music)

>> Announcer: From theCUBE studios in Palo Alto in Boston, connecting with thought leaders all around the world, this is a CUBE Conversation. >> Hi, I'm Stu Miniman and welcome to a special CUBE conversation. I'm coming from the Boston area studio. We were supposed to have a KubeCon Europe in Amsterdam. First in the spring, they pushed it off to the summer, and, of course, the decision due to the global pandemic is it's making it virtual. But happy to welcome to the program two guests that I was planning to have on in person, but couldn't wait for our virtual coverage of the event, though. Happy to welcome the co-founders of TriggerMesh. Sitting in the middle is Mark Hinkle, who is the CEO of the company, and to the other side is Sebastien Goasguen, who is also the co-founder and the Chief Product Officer. Gentlemen, thanks so much for joining us. >> Thanks for having us, Stu. >> Thanks, Stu. >> All right, so, it's interesting, we've been covering the cloud native space for a number of years, and especially at KubeCon, there's always some of those discussions of does cloud kill on-premises, does this new thing kill that old thing. And in some of the early days of KubeCon, it was like, well, containers are really interesting, and there was all the buzz for years about Docker but, hey, the next thing is going to be serverless. And serverless, we don't need to think about any of that stuff, it's the nirvana of what developers wanted. So therefore, let's not worry about containers, but you sit in that space really helping to connect between some of the various pieces. So, I guess, Sebastien, maybe if I could start with you, 'cause you've built some of these various projects, when you go through and look at your background, you've been involved in the co-business space, uBLAS, and now for TriggerMesh but, you know, give us some of that background as to how, from a technological under pinnings, the community's been thinking about how these worlds fit together. >> Yeah sure, it's very interesting because first, the container rejuvenation started with Docker obviously and then Kubernetes appeared, and the entire community started building this. And this was really an evolution from the virtual machine orchestration, right. People needing a better way to package applications, deploy them, and they said, "You know what, "virtual machines are not that great for this. "Can't we have a better vehicle to do this" and that's where, really, containers took over. And it made total sense and so we saw this switch from, craziness about open stack and even cloud stack that Mark and I worked on, and putting all the focus on containers. And then comes AWS always innovating, always in the lead, and AWS saying, "Hey, you know what? "Actually, we need to go serverless. "We need to forget about the infrastructure. "What people want is really deploy applications "without worrying about the infrastructure. "They want things that are going to auto scale. "They want to pay very little, even pay per function call "and not pay when your VM is up." So AWS really pushed this mindset of serverless, but then what was the meaning in that realm of containers, and that's when I started Kubeless and I said, "You know what, if you would need to build function "as a service, you should build it on Kubernetes, "and use Kubernetes as a platform." And from there we started started seeing this fight, a little bit, between people, saying "Hey, forget containers, go serverless." So in TriggerMesh, we're not really taking that stance. We really see on-premises has, it's always going to be here, we have worked clouds on-premises, we have our own data centers but definitely there is more and more cloud usage, and when you start using the cloud you don't want to care about the infrastructure in the cloud, right. So, you want as much serverless as possible in the cloud, but you know you have to deal with your on-premises, data bases and some work loads and so on. So you have to be a pragmatic and you have to pick the best of both worlds and keep moving to modernize your stack and your IT in general. >> Excellent, alright so Mark, at the CNCF I'd seen the Knative project come out and it was talking about how we can connect containers and serverless, and one of the questions I'd been asking is "Well look, there are a lot "of open source projects for serverless." But when I talk to the community, when I talk to users, you say serverless, I think AWS. Sebastien was just talking about, so, I was sitting at the KubeCon shows and talking to the vendors and a lot of really big vendors were working on Knative, Oracle, IBM, RedHat and others and I said if this doesn't connect with AWS first and Azure second, I don't understand what we're doing. Yes, there's probably a place for on-premises but that was when, I think you and I had a conversation, we'd been looking at this space, so how did the ideas that Sebastien talked about turn into an initiative and a company of TriggerMesh. >> Well, early on we latched onto the Knative announcement that Google made. Google had given Sebastien some insight into where they were going with serverless, and the Knative project before it launched. And then they actually quoted him in the release which started interest in our company which was the only company in name at that point. But we really didn't know where Knative and Kubernetes together were going and the serverless movement, but we thought at first that there would need to be management capabilities to do lifecycle management around serverless functions, but what we realized, or Sebastien realized, early on was that it's not so much the management of serverless, because the whole idea of serverless is to abstract away all of the severs and architecture so that all you're really dealing with is the run time. So the problem that we saw early on was not managing but actually integrating applications across serverless framework, so the name TriggerMesh, that came from the idea that you trigger serverless functions and that you would mesh architectures whether they be legacy applications or they be file services or other serverless clouds across the fabric of the internet. So that's Triggermesh and that's really where we're going and we see that there's a couple of proof points in our industry for that already and people having the desire to do that. >> All right excellent, so that integration that you're talking about. Help Sebastien explain, there's some news I believe its the EveryBridge Cloud Native Integration Platform that's just announced. Help us understand what that is and what should we be kind of comparing it to other solutions in the industry today. >> Yeah so, you know we are very happy about the EveryBridge announcement and it's really, we're getting beta, we are doing a beta release of EveryBridge available in our SaaS cloud, the Triggermesh.io and really to first piggy back on what Mark was saying, is that a lot of people still believe serverless is just functions, right. And for us serverless is much more than this. Serverless is about building event driven applications. We see it with AWS, with things like they are doing with EventBridge, for example, but we really believe in this mindset. What we are trying to do is to help people build applications, build cloud native applications, that fundamentally are event driven and they are linking cloud services in the public cloud providers and also on-premises work load, right. So EveryBridge allows people to do this, to build those cloud native apps as basic event flows that connect event sources wherever they are, could be events that are on-prem from an eCommerce application, ERP application, could be events that are circulating through a Kafka infrastructure on-prem, and people can connect those event sources with what we call targets. So those targets could be on-premises, they would be OpenShift work loads for example or they could be in the cloud at AWS lambda functions, Google cloud run, or even dedicated SaaS like Twilio, SendGrid, and so on, so that's when we saw really over the last 18 to almost two years now, is that serverless is more of an integration problem, more like traditional IPaaS that we've seen, right. So basically we are building a new IPaaS solution at the frontier of serverless offerings from the public clouds, traditional messaging systems like Kafka, Remittent, Q and so on, plus the, I would say, the old IPaaS solution and we're doing all of this backed by Kubernetes and Knative. >> Excellent, so Mark I heard Sebastien talking about, he mentioned OpenShift, talked about Google, speak a little bit to really the ecosystems, the market places that TriggerMesh fits into. What are the use cases that you are seeing customers using. >> Yeah, I think a couple of the, to the dive into the on-prem triggers we have capabilities to trigger oracle database changes that could actually pick off cloud based ETL transactions. We're seeing that users are going through digital transformation and really to be more specific given the global climate right now, it's remote work, and the idea of lifting and shifting all of your infrastructure into the cloud is pretty daunting and long ask, but if you can front end those systems with new cloud native architecture and you have a way to create those event flows to tie in your existing systems to new portals for your employees to get their work done, automate workflows to provision new systems, like Zoom for example, and other conferencing systems, you can use the serverless front ends and work flows that actually integrate with all of your existing infrastructure and give you a way to extend your life of your applications and modernize them. >> Yeah, the long pole on attending modernization is that application. Sebastien maybe I'd come to you on this is, I think about iPaaS, when you look at that space they talk about all the integration that they need to work on, usually there are certifications involved, you mentioned Oracle databases, these are things that we need to go in there with a engineering effort and make sure that it is tested and certified by the ISV out there. Does containerization, Kubernetes, and serverless, does this change it at all, does this make it easier to move along these environments? I guess the question is for the enterprise, normally this change is rather slow. Mark was just alluding to the fact that we need to do some of these things faster, to try to react from what's happening in the world. >> Yeah, I think that's the entire premise of containers. It's speeding up the software life cycle and the speed at which we can deliver new features, for all our applications and so on. So, a big part of the job, when Docker started and then Kubernetes has been, if you adopt that type of infrastructure and that type of artifact, containers, you're going to speed up your software management and software delivery. So now what happens is that you have slow moving pieces, maybe pieces that you've had in your data center for 10, 20 years, for quite a while, and then you have these extremely fast moving environment, which is containerized and running Kubernetes plus the cloud. That's even, we could say even faster moving, and you can, that's definitely the challenge, that's where we see the value and that's where we see the struggle, is that you have all those big companies that have those slow moving pieces Oracle DB, IBM MQ, and so on and they need to make those pieces relevant in a fast moving containerized world and in a cloud native world, right. So how do you bridge that gap? Well that's what we do, we provide bridges. We provide integration bridges with every bridge, there you go. So we connect the event sources from Oracle DB and MQ and we bring that to a more fast moving cloud native environment, whether it's managed Kubernetes on Google GKE or whether its still on-prem in OpenShift. >> Mark, want to get your view point, just being a start up in today's global environment, obviously, you look at the cloud data space, many of the companies are distributed. We're talking to Sebastien from over in Europe, you're down in North Carolina, but give us your view point as a startup. How is the current economic environment impacting you, impacting your partners, impacting your customers. >> So, our partners and customers are probably moving more slowly than we do as a startup because they had physical brick and mortar offices and now they are coming into our world. We're 100% virtual, we're in 3 continents across over 12 time zones. That kind of work versus where they're at, I think everybody is consciously moving ahead, the one thing that I will say is that their interest in being more like the startups that are virtual, don't have brick and mortar, are really good at online collaboration. They look at us for sort of inspiration on how they are going to do business going forward or at least for the foreseeable future. So, overall I think that, not only are we teaching them about cloud native technologies but we're just teaching them about distributed work forces in a quarantined world. >> Absolutely, and I think those are some of the key learnings that you look at that are diversity consistent in the cloud native space. Want to give you both a final word and-- >> And Stu if I just add something. Mark and I have been working from home for quite a while, eight to 10 years, and definitely right now this is not the normal working from home, right, we all have, most of us have kids at home 24/7. The cognitive load in the news is huge, this is not the normal environment. So we are extremely careful, we help each other definitely internally in the team, you know, India, Vietnam, Germany, Spain, U.S. We have to be extremely careful that everybody is not falling down and putting too much on the nerves and their spirits right, so not a normal environment and even though we know how to do it we have to be careful. >> Yeah Sebastien, I'm so glad you brought that up 'cause this is not just a, how do we move to a distributed system. There is the rest of the impact on that. All right so lets give you both final words. Hopefully, we absolutely will be gathering together even if we are remote for the KubeCon event for Europe, other event later on this year, but Sebastien let's start with you, final take aways. >> Yeah, so we are very excited to build a startup. It's fast moving, its an exciting industry and really seeing the beta release of EveryBridge for us. We are trying to bring the future of event driven application to everybody, event sources to targets for everyone, not just on AWS and taking all of the strength of Kubernetes with us. It's going to be a familiar system for all Kubernetes lovers. >> Great, and Mark. >> Well as we talked about today, we are very excited about the EveryBridge announcement, and if you are interested in a cloud native, serverless, digital transformation we think we have great tools for you. But on a more personal and global note, I think Sebastien hit something that's really important, it's that even though we are not all together it's really important to check in. Even these virtual sessions have been, it's nice to interact with your colleagues and friends in the industry but be kind to each other and don't just take it for granted. that everything is good at the other end of the wire so reach out to each other and we'll all get through this together. >> Well Mark and Sebastien, thank you so much for joining us. Absolutely the personal pieces as well as TriggerMesh. You're helping to pull some of those technology communities together so congratulations on the progress and definitely look forward to tracking where you go from here. >> Thanks Stu. >> Thanks a lot. >> We appreciate it. >> All right be sure to check out theCUBE.net, we will be covering KubeCon and CloudNativeCon Europe as it goes virtual as well as lots of others in the cloud developer space. I'm Stu Miniman and thank you for watching theCUBE. (upbeat music)

>> Announcer: Live from New York. It's the Cube. Covering AWS Global Summit 2019. Brought to you by Amazon Web Services. >> Welcome back rush hour's started a little bit early here in New York City with over 10,000 people in attendance for AWS summit in New York City. I'm Stu Miniman, my co host for today is Corey Quinn. Happy to welcome to the program two first time guests from our host, Amazon Web Services. To my right here is Deepak Singh, who's the Director of Compute Services. Sitting to his right is Aaron Kao, who's the Senior Manager of Product Marketing. Gentlemen, thanks so much for joining us. >> Thank you for having us. >> Thank you for having us. >> Alright, so we know that every day we wake up and there's new announcements coming from Amazon and the only way most of us keep up with it is trying to read Corey's newsletter here. But in your group in compute, we know there's a lot going on and quite a few announcements. So Aaron, why don't you kick us off with some of the hard news that went through this morning? >> Yeah, we just launched Amazon EventBridge. It's a serverless event boss that allows you to connect your applications with data from sources like SaaS applications, AWS resources and your own applications. >> All right, so Deepak, I would love to dig into that a little bit. Like you said you that Amazon, you've learned a lot from CloudWatch and building this tool. Everybody looking at kind of, you know, Lambda in the serverless space is like, Okay, how are all these pieces going to come together? Is it all Amazon services all the time? And of course, Amazon has a huge ecosystem, but help us understand or layer down you know how this works? >> Yeah so as you know, AWS services send events to CloudWatch events. They consume events from CloudWatch events. One of the best ways to do it is through Lambda. One of Lambda's biggest strengths is the number of integrations we have with event sources, both taking in events and triggering events. But to your point, there are always events inside database ecosystem. And I think one of the things as a service owner that really excites me about EventBridge is how now customers have access not just to event triggers inside AWS, but also to our partners like Zendesk and the applications you can build will be really exciting. >> Alright, quite a few other announcements, maybe walk us through some of them. >> Yeah, CDK is another announcement where it's an open source software development framework that allows you to model your applications using programming language like TypeScript, Java, Python and .net. You know, the whole thing with building in the cloud, it's slightly different. You used to take your code, put it on a server and run it. Now people are building things a little more distributed, using a lot of different resources for their applications. So it's getting, provisioning your infrastructure is a little bit harder, right? You either have to do a lot of things manually or maybe you're writing a lot of scripts or using a domain specific language. But with CDK, you're now able to use the programming languages that you're programming your applications with, to model and provision your infrastructure. So it's super helpful. Really think it's going to help developers increase their development velocity. They're able to use things like loops, conditions, object oriented programming, they don't have to do context switching and just with a few lines of code, they're able to do a lot more. >> All right. >> I wound up playing with it a little bit when it was in preview and one of the things that I found that it was extremely helpful was, it was a lot easier for me to write something in using CDK, and then see what that rendered down to in terms of cloud formation and then oh, I guess that's how I do it in cloud formation, which was great. The counterpoint though, is it also felt at times like it was super wordy. So if I read that what it generates compared to what I normally write, which is admittedly awful, but I almost start to feel like I'm doing it wrong with that and then with amplify and with Sam and the rest, there's a lot of higher level abstractions that build cloud formation for you. But then it renders down in a few different and key ways. Under the hood, how much are these products that you're coming out with starting to shape the direction of cloud formation itself, or is that mostly baked and done? >> There's a lot of products that we're building that you know, are complementing cloud formation. You know, cloud formation is the templating modeling language to provision AWS resources. But on top of that, we have things like Sam right, that provides a declarative a more high level abstract declarative way to build on top of cloud formation, you know, we have Amplified that also uses cloud formation to help you build mobile applications and front end development. And then finally, you have CDK for just general use. So, these things are all complementing and, you know, things customers are asking for and helping us shape the ecosystem there. >> Yeah, Deepak the container space, of course, has been you know, one of these tidal waves that we've been watching and it's fundamentally changing the way people architect their applications and has huge impact on your product line. Give us the update. If you could just start with some of the high level, I remember first when I talked to you a couple of years ago it was when the whole Kubernetes piece was sorting out. So you know, ECS, EKS, used to have a much longer name that Cory would constantly >> Only for Cory >> Finally you've fixed the compensation problem where someone was getting compensated based upon number of syllables and a service name so good on you on that one. >> Right and you know the acronym A-M-I maybe you can you know settle once and for all you know how how we pronounce that. >> I'm old school it'll always be AMI. (laughs loudly) >> Walk us through kind of, you know your container services. >> I think the great thing about containers is as you said the adoption is everywhere. And what we find is there's a growth of ECS, the growth of EKS whether you're running it on EC2 or Fargate everything is growing like crazy, because people find new interesting ways to run applications based on what they know and what they're comfortable with. We have customers, customers like SNAP that know Kubernetes well and they are building on there're building a big chunk of their new infrastructure on EKS on AWS and it basically helps the developer velocity. On the flip side, you have customers like Turner Broadcasting that run a lot of their web services or the Comedy Central content properties like that on Fargate because they can just stamp them out. They all you know, it's a website, it's a service that they can just keep expanding. So it boils down to what are the key things that you're comfortable with? What are the reasons you've picked something. So if you're running like SNAP across, you know, in many different places, you are likely to choose Kubernetes and standardize on that. So that's the best part for me is, people have choices and then they pick based on what they need at that point in time, which can be two different teams at the same place, picking a different solution. I will add that one of the areas that we are focused on now is observe ability and developer experience. Those are areas that our customers have been asking for. CDK plays into that you saw in the demo this morning and with observe ability with container insights and with the fluid plugins that we announced. I think those are areas that you'll see us do a lot more going forward. >> So right, that was one of news today, CloudWatch container insights just to explain what that one is. >> So historically, when you do CloudWatch look, it's very BM-centric, you're looking at CPU memory, you assuming an application, instances run for a particular period of time. In the container world, you have services where the underlying tasks come and go, all you know, at a very different rate. CloudWatch container insights is meant to be a world that's aware of the fact that your containerized applications are tasks and services and pods, so you're able to get more fine grained metrics on the things that container customers care about and you're not trying to use BM-centric language to look at a containerized infrastructure. So that's the biggest reason for doing that. And then on the Fluent Bit side was, our customers want log routing to whatever they want to do it on. Whether they want it to send to S3 or the Elasticsearch We do that with Kinesis Data Firehose. So we basically wrote a bunch of open source plugins for Fluent Bit that just send your logs where you want them to go. So that's kind of where we are focused. >> Yeah, I view it as more of a log router than I do almost anything else. >> It is that. >> Yeah. A question of: Where does it come from? Where does it go? How do you keep it straight? >> Yeah. >> It's at this point, what does it output to you these days? Are there are various destination options, third party vendors, CloudWatch, history? >> So we wrote two plugins one was for well three, I don't know. One for S3 because so many people don't understand the data to S3. The other one was a Kinesis Data Firehose. So from there, you can send it to Redshift, you can send it to you can send it to Elasticsearch. So based on what you however you want another analyze it, you can send it to a custom resource that's Kinesis. So, you're using some third party provider, you can just send your logs over to those. >> Yeah, Corey, you know, you're dealing with a lot of customers, you know, there's now so many, you know, different instance types and some of the pieces, you know, what's the feedback you're giving to, you know, Amazon these days? >> Entirely depends upon the service teams and it ranges from this is amazing, excellent job to okay, it's a good start. And it's always a question though, it's when you have what 200 service options or darn near it at this point, 170. It's impossible to wind up with something that is evenly consistent and you have services that are sub components of other services and built on top. I mean, I think the, I guess the feedback I've been giving almost universally across the board is, assume that I am about 20% as smart as you right now seem to think I am and then explain it to me and then I'll probably understand it a lot better. It comes down to service to storytelling, more or less of meeting people at various points along their journey and then I was mentioning in our editorial session just before this segment, that that's something that AWS has markedly improved on the last two or three years. Where you have customer stories that are rapidly moving up the stack as far as leverage services. It's not just we took the VMs and now we run them somewhere else. Now it's about building a high, extremely volume intensive applications on top of a whole bunch of managed services and these are serious companies. These are regulators it's not just Twitter for pets anymore. >> Nothing wrong with that. >> No. >> So, you know, we were discussing, like FINRA was a great case study this morning and they talked about in the four years that they've been on, they've re-architected three times. You know, how do you balance all of these new instances coming out with, you know, and how do I make sure that I deploy something today that I've got the flexibility to change, but you know, I want to be able to lock in my pricing and make it easier. >> So actually, we think about that quite a bit. One of the reasons we built app match the way we did, as something that sits outside the container orchestrator, was it doesn't lock you into choosing one or the other or even choosing an architecture. You can start off with a monolith, start putting side cards on it, getting visibility into all your traffic, then portions of your applications you can start breaking out, you can put them on Fargate, you can put them on ECS, you can put them on the EC2. I think that is something we did very consciously because so many of our customers are in that position and I think more and more are going to go higher up the stack using managed databases, using Lambda, but it's not decision they need to make all up front. They can do it piecemeal, and we see our customers find another good example, they've done that. >> One of the philosophies of it, like AWS is giving customers building blocks to build things on. So the whole thing is, here's a new primitive that you can use, then you can take it out, replace something with something else, depending on your needs. So we give customers flexibility and choice. >> And part of the problem is that, that very much becomes a double-edged sword. I mean, most recently, you've had effectively declared war on Alphabet. I don't mean the large cloud provider that turns things off for a living. I'm talking about the English alphabet, where you take a look at all the different EC2 instance types. I think in US East one now there's over what is it 190 different instances you can pick from. It leads to analysis paralysis, which one do I pick? What's the right answer? What am I committing to, what am I not? And you see, that's a microcosm of the larger service problem. I want to build a web app that does a thing, which services do I use, you open up the service listing and you just get this sort of sinking sensation? I get that I can't imagine what someone new to the space is getting to there. >> All right, and this is where things like Amplify, Fargate, AWS Batch where you don't need to select an instance. Where you just tell us what your requirements are and Batch makes that selection for you. The core building blocks are important because you can't really figure out what to do. But then you'll see us do much more about the stack to help people get there. It's an ongoing thing that will keep trying to tackle but you'll see a lot more of that. >> It's controversial. One of my favorite things about Lambda, for example, is there's one knob RAM and as you turn that up, other performance characteristics increase and people complain about it but I love the simplicity, because I don't have to sit and think and make all these different decisions. It's one access. >> Yeah, but if you want more knobs, you can use Fargate. So I think that, that's the beauty of it that you do have that choice. >> Yeah, one of the lines Aaron, I really liked in Werner's keynote is he said, "we've really, you know, my words commoditized IT. "We all have access to all of the tools now." You know, that was, you know what big data originally and cloud also was, you know, you used to have to be a nation state or fortune 100 to be able to do some of these things so, you know, what do you hear from customers? You know, how do they make sure, you know, they're staying competitive and ahead, and therefore, in that relationship between the business and IT, what do you hear from your customers these days? >> In terms of that? Well, I think for, you know, for customers, like I think EventBridge is a, a pretty good example of that, in terms of customers asking us for ability to, you know, integrate their SaaS providers, integrate a lot of different things and not have to, you know, not have to do a lot of undifferentiated heavy lifting and things like that and, you know, customers are increasingly moving towards like event driven architectures and they asked us, hey, we really like CloudWatch events and how you do things with IT automation and then bringing SaaS providers in and, we want to, you know, we don't want to build pulling infrastructure in order to access API's and do all all those heavy liftings. What we did was we built out, we took CloudWatch events and added new features for SaaS applications and built that into a separate service for people to use. So that's like, you know, a lot of the relationships we have with our customers, listening to what they need and giving them what they want. >> And I think that, that's a very valuable thing. You know, we used to say, you know, five years ago, you would talk about, you know, let's get rid of undifferentiated heavy lifting. >> Yeah. >> Well, now it's like, no, no, let's enable, you know, something that you would have thought was heavy lifting and we're daunted to be able to do it but now hopefully, it's easier, because a lot of this stuff, you know, as Corey said, this is still a little bit daunting and you know, well you've got a lot of ecosystem and service providers and services to help us, you know, take care of, you know, because it's the Paradox of Choice with all the options that you have. >> And I think that's the beauty of what, I mean our customers are smart, they manage to find it interesting ways to keep challenging us and they keep us busy. But I also think that really, really many of them, the ones who have been able to be successful, have figured out what it means to take all the tools we give them, which are the ones where they want to completely hand it over to AWS and give us the responsibility and then which ones do they really feel they care about and the ones who can find their balance are the ones that we see moving the fastest. I think that's what we're trying to do. >> All right, now and one thing that does absolutely permeates virtually every service team I've worked with at AWS, I mean, you I've had this experience with you, where I talked about how my use case isn't a terrific fit for your product and your response is always well, what is your use case? It's not, is starting off from the baseline assumption that my use case is ridiculous, which let's face it, it probably is. But being able to address a customer need and understand that even if it doesn't dictate roadmap, is incredibly valuable and I don't find that there are too many players in any space, let alone this one that are willing to have the patience to listen to, frankly, some loud person wearing a suit. >> We try, I mean, I think you heard Andy say there's so much like a big chunk 85, 90% of our roadmap is customer requests, I would say that even the remaining 10% is maybe not things that they've directly asked for but things that we've observed they've run into or that we've run into working with, you know, the one or two customers who are ahead of the pack. And Okay, they have this problem, how do you generalize that? And we try and understand what it means. One of the reasons we made the container roadmap public, was this space is moving so quickly, it's almost impossible for us to talk to enough customers to figure that out. So like, Okay, this gives us an avenue for them to come to us and just tell us, GitHub issues. >> Yeah, so right. Final question I have for both of you. Directionally looking forward, you know, the roadmap, we love when there is publicly facing material not under the NDAs that we normally have to be able to hear. So what are you hearing from your customers? What direction are they pulling you towards and that we should expect to watch AWS kind of further, as we head towards re:Invent later this year. >> I think customers are asking us for different things for developer experience, especially event driven architectures. I think there's going to be a lot of interesting things happening in the Lambda space and that entire space. >> Yeah and to add to that, I think, to your point earlier, helping them simplify choices is going to be a big part of it. Meeting them where they are, in their IDEs with a tooling is a big part of what you'll see us do. So, you know, I think you saw examples today and we'll keep building on top of those. >> All right, well, send our congratulations to the two pizza teams that worked on all of the projects that were announced today. Look forward to seeing you, you know, down the road. Thanks so much and welcome to being Cube alumni. >> Thank you for have us. >> Thank you for having us on. >> Appreciate it. >> Aaron, Deepak you know, from AWS. He's Corey Quinn, I'm Stu Miniman. Back with lots more coverage from AWS summit, here in New York City, thanks for watching the Cube.