(upbeat music) >> Welcome back to theCUBE's continuous coverage of AWS re:Invent 2021 I'm Lisa Martin. This is our third day here on set We've got two live sets, two remote studios, over a hundred guests on the program and a lot going on with AWS and its ecosystem of partners am pleased to welcome back one of our Cube alumni, Buddy Brewer, the GVP & GM of product partnerships at New Relic. Welcome back, Buddy. Good to have you. >> Thanks it's great to be here >> Great to be in an in-person event isn't? >> No kidding it's really amazing to see everybody out here and after spending so much time on zoom calls, we had a lot of really great moments among the team and the booth playing the game of seeing if people's height matched up with >> (laughs) >> What your expectation was because so many of the people we work with >> Never mind. >> We've only known over zoom. >> Yes ,and zoom has been a savior for all of us we've been doing so much recording on zoom at the same time it's great to be here in person and seeing what a safe job AWS has done with getting I from hearing upwards of 30,000 people in here that are here in person. So talk to me about you lead the technology partnerships at New Relic. Talk to me about your role, and then we'll get into the partnership with AWS. >> Yeah, absolutely. Well, you know, the point about zoom, it's fascinating. Like you said, that just having the ability to communicate with people has been such a key enabler of being able to make progress and to continue to lead our personal and our professional lives despite the pandemic I mean, imagine what it would have been like if this had happened 10 years ago, even, but certainly 50 years ago >> Right. or something like that, right? Like everything would have ground to a halt and technology took on such an amazing, you know, critical role in allowing us to do all of these things and so at New Relic, we're all about helping people make sure that all of this software works correctly. And so observability helps people understand the detail level about everything from the front end, the end user experience to every single piece that happens along the path of delivering that experience all the way down to the infrastructure into the network. But my role at New Relic is also to help all of the other tools that software developers use every day to create those experiences that they connect into their observability platform so that they can understand all of those details and make sure that people are able to continue doing things that have become really so basic to life like ordering groceries or getting food, or, you know, communicating with a loved one over something like zoom. >> Yeah the things that to your point, if this had happened, you know, five, 10 years ago, it would have been a completely different story. We've been able to function really well and one of the things too, that, you know, I noticed yesterday and today, you probably did as well with the plethora, typical AWS the plethora of announcements, the amount of innovation that's going on, the customer flywheel that we've just seen this acceleration of technology and what it's enabling, but the observability portion is really key you talk about, you know, the developers need to the whole SDLC they need to be able to understand exactly what's going on because at the end of the day, whether it's a consumer or an enterprise of the other end of the spectrum, we need to know exactly what's going on because people's patience is far thinner these days the pandemic showed is that there is really no having access to real-time data. Isn't a luxury anymore it's really a necessity. >> Right, yeah, absolutely. >> Talk to me about some of these so a lot of announcements coming up from AWS, you guys talk to me about the partnership, what you guys are doing there. And some of the things that are exciting on that front. >> Yeah, AWS is a really key partner for us. We're big users of AWS ourselves for our observability platform and all of our infrastructure and, you know, we've had our own journey as a 13 year old business that started out pre cloud and moving our own infrastructure to the cloud. And then along that journey, we've worked closely with AWS and we've built a lot of joint solutions to help people who are moving to the cloud themselves or who are cloud native to understand all of the details about what's happening in that software so we have over 60 different integrations to all of the different tools with Amazon that you can use on the cloud from data storage, to EKS on Fargate and all of that stuff. And then we recently announced a five-year strategic agreement with Amazon to make it even easier for customers to adopt New Relic if they're building in Amazon AWS and so you know, we're in their marketplace, we have an offering for startups, for people who are just getting started that, you know, provides really simple and fast on-ramps with discounts and things like that. That's all designed to help people, software developers in particular, focus on what matters most to them, which is building great experiences for their customers. You know, you mentioned that the SDLC and this is one of the things that, you know, our mission at New Relic is to make observability a daily data-driven habit for developers across all phases of the software delivery life cycle. The problem with observability and how it's used today is that it's only used in the run phase by most people they use it when the software is on fire to put the fire out we believe that, that telemetry has tremendous strategic value in the plan, build and deploy phases of software development as well. And so partnerships like AWS allow us to unlock the accessibility of that data across all of those different phases for people who software developers are as a result in many ways that the things that we were talking about earlier with the expectations that the pandemic has placed on how software has to work, it's not an option they're busier, they're under more pressure than they've ever been before and so we want to help them relieve that pressure with tools that help them do their jobs better. >> Relieving that pressure is key there is so much pressure on developers I mean, these days from observability to security and that sort of thing, but it sounds like one of the things that you're also fundamentally doing is really shifting that observability left and helping them from a cultural perspective, it seems like almost a shift, but you're trying to make things easier for them giving them more tools and to unlock what they're not seeing right now. >> That's right and you know, the interesting thing about it is everyone realizes that observability is critical to, you know, successful software businesses so for example, we did a survey recently of 1300 software developers and IT decision makers and executives, and found that among the C-level executives that were surveyed 80% of them expected to increase their observability budget and 20% of those expected to increase it significantly. However, that same survey found that a very small percentage of those who we actually surveyed feel that they have a mature observability practice today. And when we unpack the reasons why in the survey, we found that most of them reduce down to basically this issue of they just don't have enough time to instrument all of the software, especially in a world where the shift to the cloud has driven a change in architecture where monoliths have been torn down and replaced by hundreds, or may be even thousands of microservices. >> Right. >> And we're in an era now where if observability isn't really, really easy and incredibly fast and simple to execute on then software developers can no longer instrument fast enough to keep up with the pace of the software that they're delivering and so what that leads to is visibility gaps, visibility gaps lead to poor customer experiences. And so what we're trying to do, and we've been on this massive simplification of our own platform to make it, you know, incredibly cost-effective at just 25 cents a gigabyte for ingestion and really simple licensing seat based licensing, where you get access to all of our tools to make it really simple and to take simply minutes to get observability on all those different pieces. >> If simplicity is a word that we throw around a lot, but it's really critical element and it's interesting to understand how do you actually facilitate that? You talked about, you know, kind of the 80 20 rule there. >> Yeah. >> A lot of the organization's not on that maturity curve with observability, how does New Relic and its ecosystem of partners like AWS how do you help have those conversations within organizations in any industry tell them, understand how you can actually simplify that and unlock that visibility, knowing that it's not only a matter of software development, but it's a competitive differentiator. It's also something that can damage a brand if they're not top of it. >> Yeah, we launched a re-imagined version of our partner ecosystem really our entire integration ecosystem about six weeks ago on October 13th called New Relic Instant Observability. And one of the central goals of New Relic IO, which we call it for short is to make it take just like five minutes for people to instrument something. So in the old way, what people had to do is if they wanted observability, they had to go learn about an observability vendor then they had to go install it, figure out how all that works and then they could get to solving their problem, which might've just been simply instrumenting a Kafka you know and so what we want to do is just keep people in that mode if all you wanted to do is instrument Kafka, then go find the Kafka instrumentation tile on New Relic and observability and then there's a guided install process that takes you through that and at the end you've instrumented Kafka and if you want to add something else like EKS Fargate from Amazon, or if you want to add something else like a Java service, you can simply click more of those guidance installs and add within minutes in an incremental way without having to stop and do a whole vendor evaluation to do so in fact, one of the other things that we launched recently is a free tier that's free forever. So there's no trial process or anything you don't have to put in a credit card if all you want to do is instrument this one thing right now, you can go through this process provision a free account you get access to all of our functionality for one user and ingest up to a hundred gigabytes of telemetry data for free within minutes. And so what we're trying to do is take all of that adoption friction out so that people aren't fighting with their instrumentation so much, and again, they can get back to doing what they really want to do in the first place, which has built great experiences for their end users. >> Great experiences for the end users but that translates to employee experience that translates to an end user customer experience, which translates back to brand reputation. I'm just wondering, you know, you're focused on the developers and we've been hearing a lot about the last two and a half days, a big focus on developers has observability kind of escalated up and its evolution up the stack within organizations is this a C-suite concern? Is this a board level concern? where does this fit now? and what's the vision of New Relic to deliver on that? >> With observability? >> Yes. >> Yeah, 90% of those in the survey that I was talking about felt that observability was not just a tool that they needed to use, but strategically critical to their business and, you know, this goes back to, as we know, and especially as a result of the intensity on the importance of software coming out of the pandemic, your digital business is your business these days. And so if you don't understand what's happening in that software and you can't move quickly, then you know you're really in trouble in terms of trying to succeed in a highly competitive environment and that goes back to again, one of our core beliefs is that all of this telemetry data that people have been collecting about how their software operates is so useful in contexts outside of just when there's a problem in production. Imagine if you could take that information and you could actually put it inside the IDE, which is something that we did with a recent acquisition of a company called CodeStream. We can take this telemetry data and put it inside the IDE so that as developers are writing the software, they know where those issues are. You can click straight from a stack frame, for example, inside of our, where we show all of our errors in a capability called Error's inbox and shoot right into your IDE and go see where the line of code is that caused that error, shortening that feedback loop and unlocking this really big investment that a lot of companies make in telemetry data earlier in the software life cycle, we believe is the future of observability and we want to help people get there. >> Well, the observability is really key for organizations these days because we've been hearing every company these days has to be a data company. >> Yeah. >> And it's one thing to say that it's a whole other thing to be able to implement it and observability is absolutely critical to that as being able to take that data and apply it in different contexts to really enable that business to be digital which is absolutely table-stakes these days to be successful and to deliver that customer experience ultimately. >> Yeah. >> That's what it all do. >> Yeah, absolutely. And you know, the other thing is really hard about this problem when I talk with our customers and we found this in the survey as well, is that, you know, software developers, don't just use one tool to create software they use a lot of tools in fact, 13% of those that we surveyed use 10 or more tools. >> Whoa. >> Just for the observability piece. And so, you know, obviously we're always trying to expand organically what we do inside of our platform to cover more and more use cases, but an equally important part of our strategy, if we really want to make observability a data-driven daily habit for people is to find all of those other, you know, really well-built amazing tools that those developers use and find valuable ways to integrate with them. And so that's the other part of our ecosystem that we've built out is this ability to take all of the other tools that you use and wire them into New Relic so that, for example, if you're using, let's say Lacework for security then you can, you know, if someone's installed a Bitcoin miner on your infrastructure somewhere, you can quickly navigate because of that integration from a poor customer experience through the infrastructure that's suffering may be with, you know, a lot of memory pressure, and a lot of CPU being used for this Bitcoin miner and then find out that, you know, through the integration where the miner was installed, how it got installed so that you can remediate those types of issues and connecting those pieces together, making software truly interoperable is another thing that's really critical to our mission at New Relic. >> It is critical to not only to the developers, but to the organizations and their success as businesses these days Buddy thank you for joining me, talking about what's going on at New Relic What's new, how you're really empowering those developers and all of the downstream positive effects that, that leads to we appreciate your time. >> Thank you ,thanks for having me. >> All right, you are Buddy Brewer I'm Lisa Martin you're watching theCUBE, the global leader in live tech coverage. (soft music)

>> Narrator: Live from Las Vegas, it's theCUBE. Covering AWS re:Invent 2019. Brought to you by Amazon Web Services and Intel, along with it's ecosystem partners. >> Welcome back, about 65,000 here in attendance, at AWS re:Invent 2019. You're watching theCUBE, and I am Stu Miniman, the host for this seg, and happy to welcome back to our program two of our CUBE alumni. Sitting to my right is Abby Fuller, who is the principal technologist for containers and Linux, with Amazon Web Services. Sitting to her right is Deepak Singh, Vice President of Compute Services, also with AWS. Thank you so much for joining us on the program. >> Thanks for having us. >> Thank you for having us. >> Stu: All right, so as I said, both of you have been on the program, and boy your team's been busy. I mean, one of the things I love, first of all, there is a roadmap for many of the things that are going on. So, we do understand what's happen in the future, but, Deepak, maybe just tell us a little bit about your group and kind of the main focus, and let's start there. >> Deepak: So, my group goes beyond containers. It includes things like Linux systems, our high performance computing organization. But for the purposes of re:Invent, let's stick to the containers org. The containers org owns all of AWS's containerized products. So that includes ECS, EKS, Fargate. We also own our service mesh offering, which is App Mesh. So the way I like to think about it is, it's the right way to build applications in the modern era group, and it's a team that stays quite busy, because this is such a hot space to be in. >> Stu: All right, so we're going to talk mostly about containers, but your shirt is talking about the Linux piece. Tell us what your shirt says. >> Deepak: Ahh, yes, this is the only right way to spell AMI. Unfortunately, my previous, when I was in New York, Corey was at the table interviewing me, and I wore this just for him. >> Stu: So, so, so, if it is AMI, then we're going to spend some time talking about EKS. >> Yes. (Abby chuckling) >> And Esses. >> Yes, which one? (Deepak laughing) We will figure that. For AWS is AWS, I think, is how we will do it. So, absolutely, we're not going to talk about ontological arguments in there. But, Abby, a whole lot of new services in the container space. I want to put a pin and put Fargate to aside for a second. >> Abby: Sure. >> Cause lots of things we want to dig into there. But a lot of other things have been announced, in like the last month or so. Maybe, give us a little bit of a view. >> Yeah, I think a couple big ones for us. So, Fargate and Spot, so run on spare Fargate Capacity for up to a 70% discount off of standard Fargate pricing. (mumbling) things like vulnerability image for scanning for images on ECR. We launched, over the last few days as re:Invent, a capacity providers for ECS, which let's you run, split your traffic between on-demand and spot instances in the same cluster. We also launched something called Cluster Auto Scaler. So, some finer-grained control over how your cluster scales in on ECS. >> Stu: All right, want to take a quick step back. So , Fargate, announced a couple of years ago. >> Deepak: Yep. >> Was only first supported on ECS. Definitely, I've talked to lots of customers, very excited about it. >> Deepak: Yep. >> Maybe talk to us a little bit about how Fargate fits in the whole container discussion. >> Deepak: Yeah. >> And we'll hit with the news. >> Yeah, and, actually, a good way to think about it is from a native US standpoint. If you're a customer running containers, the way we think about our services is: You need a place to store those containers, so that's ECR. You could use your own registry, you could pick a third party one, that's fine. But most of our customers just use ECR. Then you pick your containers carrier. That's either ECS or EKS depending on your preferences. And then you need to figure out where you want to run your containers. And, of course, when we launched ECS five years ago, at re:Invent, there was only one way to do it: On EC2 instances. And two years ago, we added in what in our mind is a cloud native natural way to run containers, which is Fargate. So Fargate serves as a runtime compute engine for containers, and you can pick your scheduler on top of it, and go make hay with your applications. So that's kind of how we think the hierarchy works, and it works pretty well for most customers. They'll start off often with EC2 and move to Fargate over time or mix and match, and it's kind of fascinating to see how many customers of ours have decided they want to be all-in on Fargate. Which is a great place to be for us. >> Stu: Okay, but the big news which actually got a good cheer in the key note yesterday, is Fargate for EKS. So what's the importance of this? >> Yeah I think (mumbling) I think it's saying we've been talking to customers about for a while and it's the ability to run your Kubernetes pods on Fargate Capacity. I think it's really speaking to folks love Kubernetes as a tool and as a community, but it can be a pretty significant lift operationally. And with Fargate they can use APIs that they want or the open source tooling that they want but they don't have to worry about provisioning and managing that EC2 capacity. >> Stu: All right, so Deepak I actually was having a conversation with a good AWS customer, yesterday, and he said he actually started out on Kubernetes before EKS existed, on AKS. And migrated over to AWS when EKS became available. And he said Fargate really interests me, but one of the main reasons he does Kubernetes is he wants to have some portability, has some concerns that, he knows what services he uses and how if he needed to move something there, what do you say to customer that says Fargate's interesting me, but I'm concerned I'm going to get locked in if I buy into this model. >> I would say that he shouldn't worry about it, because of two reasons: maybe more than two. One is: the unit in Fargate that you interact with and work on is the same unit that you interact and work on with Kubernetes in general. Which is the Kubernetes pod. It's the broadspec, it's just a pod, no difference. You can take that same pod and run it on Timbuktu cloud and it will still run. So that's part one. The other one is that he's using the same tools, he's using coup CDL. And in fact you can mix and match your Kubernetes casters. You can run 95% of the application on Fargate, and five percent of it on EC2. All they are doing is changing the part annotation, and if you decide you want to run none of it on Fargate, you just flip that and suddenly everything is running on EC2 capacity. So actually think there's that much to worry about, because it's just the same pod. It's still the same tooling, the operational model is a lot simpler. >> So Abby, we've talked to you at DockerCon, and KubeCon, simplicity is not the word that we hear when we talk about this whole container space. >> Abby: Sure. >> Traditionally. How are we doing overall? I mean, I'm watching the community here, and it's like, wait, Fargate sounds cool but where's my persistent volumes? You know, where are we in, you know give us a little bit of the road map as to where we are to make this, you know, simple and managing more of my environment. >> Yeah, I think the way that I like to look at it, right, is that we've spent, and it's not just us, but we spent a lot of time looking at things like patterns and abstractions that help make these work flows easier for developers. And I think one of the launches that's interesting in that vein is the ECS CLI version two, which we launched a few days ago. And that will help you deploy like a production ready containerized application. It'll help you with the CICD angle, it'll help you with the monitoring and the observability. So I think it's about abstracting away, and adding patterns on top to make some of these common operations and work flows really modular and repeatable, and extendable. And then it's about having the ability to customize where I need to. So being able to run on Fargate, but also to use work loads running on EC2 where I need to, and being able to mix and match, and to focus my energy where I really get any benefit from customizing, rather than having to do the whole thing from the ground up. >> Stu: You know, feedback I've gotten from my friends and the app dev community, is that hybrid is more and more becoming a standard deployment model. Obviously things like outposts and some of the other solutions from Amazon are extending the AWS model of doing things, but many of them also look at just Kubernetes, >> Deepak: Yep >> as a layer to do that. How should we be thinking of this from your solutions? >> Deepak: Yeah, so I thought without both, though, if you noticed in Andy's announcement yesterday, among the list of services available on day one were ECS and EKS. And actually app meshes well weren't on the list, but app meshes available on our post on day one as well. I think when we think about customers who want to run and stay in their own capacity and their own data centers, because EKS is built on (mumbling) Kubernetes with no modifications, the same application, as long as they're running on upstream Kubernetes, on their side, will just run on EKS. And there's a number of models that work there. A great model is the kind that SisCo is running, where they will manage it for you in both places. They become the first person you call, and on AWS it's just EKS. And on premise (mumbling) it's what SisCo has decided to build. Our pro-serf team will also help you by example. So I think there's a number of modes that work there but the key part, and it's the reason why we have stayed with (mumbling) stream Kubernetes, is we never want to make someone say, oh we can't use EKS because they're (mumbling). Somehow modified Kubernetes, and I think that is super important for us. >> Stu: Yeah, I mean Abby I know you're an active participant in the community, what do you say to people that look at Amazon, Deepak you talked a little bit about Fargate. You don't need to be concerned to the same images, so speak a little bit, maybe if you could, to Amazon's community participation, and what you're generally hearing from your customers. >> Abby: Yeah, so I think the root of it right is that we're all building with the same building blocks. I think something that Amazon has been really strong at is open sourcing primitive. So, Firecracker last year, I think was a good example. And we, I think we do really well with saying we built this to solve a problem for us, but we think you might want it too. And in terms of community support, we have been open sourcing more over the last year, we open source our road maps in November last year. We run developer previews off the GitHub road map, App Mesh has a public preview channel as well, so we've been trying to involve the community participation earlier and earlier in our product development life cycle, so that, especially with things like service mesh, where it's really pretty new, we can make sure that we have the voice of all our users and our customers, and there, as early as possible. But to get their hands on keyboards to try it out as soon as they can. >> Deepak: And actually a great example of that is, a word that Weave Works has done. Talking about people who can run Kubernetes on AWS and on premises, they have this project called "Weave Ignite" where they're basically running Kubernetes on Firecracker on premises. And then on AWS a customer just runs on EKS, as an example. And that, I think that part has been not everybody realizes that this is possible. But I think the fact that people are doing it is, excites us a lot. >> Stu: All right, I know you're both meeting with a lot of customers this week, maybe Deepak start with you. Any surprises or any misconceptions other than I know there a lot of people wearing teal shirts, with a certain pronunciation. But bring us inside some of the mind set of your customers here. >> Deepak: So actually, our conversation is very consistent. I think the community as a whole, our customer base has a whole, they all want to get to the same place. How can we move really quickly? How can we give our developers the ability to be more productive? Without putting our company at risk, having the right level of governance? Having the right controls, in place? And I think that's mainly consistent theme across the board. I guess the one thing that would be hard to remind people of a little bit, is a lot of people often think Fargate sits on top of ECS and EKS, it sits below that, and actually the fact that now there is an EKS Fargate, people understand that more quickly. Before that it was a little trickier. But other than that, I think our customers almost all. They come from different places, have very similar problems, they want developers to move quickly and develop deliver business value, and platform engineering teams that we speak to want to figure out how to get out of the way. And that's been great! >> It's interesting, Abby, I love your view point from the developer community Andy talked on stage about very much, to do true transformation, there needs to be the leadership driving things down. I'm curious what you're seeing, customers you're talked to, people you had, cause many of these tools we're talking about, you know, started in the developer world. >> Yeah, I mean there's been, like an increasing amount of curiosity around the cultural side of it. So how can I get my team to work like that? How can I get my team to ship more safely, more quickly, but getting operations out of the way? And I think you see more and more interest in that. So how can we build the tools that work the way our developers do? So we get all the thing that we want, so security and compliance and availability. The developers get what they want, which is easy work flows that match the way they want to work. So you see a lot of curiosity around that. So how do we get to the place where we can run everything on Fargate, and benefit from all the new serverless, severless style (mumbling). >> Stu: All right, real quick just give you the final word. Any websites, or events, or things that people should know when they want to learn more and get engaged? >> Yeah, I think I'd send people first and foremost to the GitHub public road maps. It is the easiest, fastest way to let us hear your voice, and what you want to see us build next. I think especially these next couple weeks coming out of re:Invent, as people start to get their hands on what we announced, think I'm really curious for them to take that back, and then be like, this is great, but here's what I want to see next. And I'd love to see that happen on the road maps. >> Yeah, about a month or so ago, maybe a couple months, we started a dedicated blog for containers on AWS site. One of the nice things about it is a lot of the contributors to that blog site are principal engineers, and engineers in our organization. For example, one of our, the principal engineers in my org are Malcolm Featonby, has a whole blog post on how should to think about scaling and best practices. I think I would encourage people who've now seen what we have, all the new services we're developing, and that's where you'll get the details on how you can use them, how we built them, and I encourage everybody to go to that blog site and check out what we're doing. >> Stu: All right, Deepak, Abby, congratulation to you and your team, great progress, and really appreciate (mumbling) are able to look at the road map, and definitely hope to catch up with you both soon. >> Abby: Thanks so much! >> Thank you so much. >> Stu: All right, I'm Stu Miniman, and back with much more, right in a second, thank for watching theCube. (Techno music)