(bright upbeat music) >> Hey everyone, welcome to theCUBE's AWS startup showcase. This is season two of the startup showcase, episode one. I'm your host, Lisa Martin. Pleased to be welcoming back one of our alumni, Alexis Richardson, the founder >> Hey. >> and CEO of Weaveworks. Alexis, welcome back to the program. >> Thank you so much, Lisa, I'm really happy to be here. Good to see you again. >> Likewise. So it's been a while since we've had Weaveworks on the program. Give the audience an overview of Weaveworks. You were founded in 2014, pioneering getopts, automating Kubernetes across all industries, but help us understand, unpack that a bit. >> Well, so my previous role was at Pivotal, where I was head of application platform and I was responsible for Spring and Vfabric, and some pieces of Cloud Foundry. And you may remember back in those days, everybody wanted to build like a Heroku, but for the enterprise. And so they were asking, how can we build more cloud services? And my team was involved in building out cloud services, but we were running into trouble with the technology that we had. And then when containers appeared, we thought this is the technology for us to roll out cloud services. So with some of my team, we decided to start a new company, Weaveworks, really intending to focus on developers. Because these new containers were pretty cool, but they were really complex operational centric tools, and enterprise developers need simplicity. That's what we'd learned from things like Spring. They want simplicity, productivity, velocity, all of that stuff, they don't want operational complexity. So Weaveworks' mission is to make applications easy for developers with containers. >> Talk to me about how you've accomplished that over the last seven years, and some of the things that you're doing to facilitate a DevOps practice within organizations across any industry? >> Yeah, well, our story is pretty interesting because of course in 2014, all of this was incredibly new. You couldn't even take two containers and put them together into a single application. So forget about enterprise. What we did was we built a network, which gave the company its name, Weave. But then we spent several years building out more and more pieces of the stack. We decided that we should go to market commercially because we're an open source company with a commercial SaaS. And we thought we would be like new Relic, that there'll be lots of customers in the cloud. And, therefore, they would need monitoring and management. And Weave started writing a SaaS based on Kubernetes, which was what we chose as our platform, back in the day, very, very, very early. We were one of the very first companies to start running Kubernetes in production other than Google. And so what we learned was customers didn't want to have management and monitoring for applications in the cloud, based on Kubernetes. Because they were all still struggling to get Docker working, to get basic Kubernetes clusters set up. And they kept saying to us "this is great, we love your tool, but we really need simpler things right now." So what we had done was we'd learned how to operate Kubernetes. And we discovered that we were doing it in this specific way, a way that meant that we could be reliable, we could set things up remotely, we could move things between zones. And so we called this approach getopts. So we've named the practice of getopts, which is really DevOps for Kubernetes. We decided that it was exciting after we had an outage and made a very quick recovery. Told people about it and they said, "well, we can't even Kubernetes started, let alone recover it from a crash." So we started evangelizing getopts and saying to people that we knew how to set up and run Kubernetes as operators for developers of apps, based on this experience. And people said, "well, why don't you help us do that?" So we pivoted the company away from a SaaS business, doing management, and straight back into enterprise software, providing a solution for people to run Kubernetes stacks, deploy applications, detect drifts, and operate them at scale. And we've never looked back. And since then we've built, very successfully, a big business out of telco customers, banks, car companies, really global two thousands. Starting from that open source base, continuing to respect that, but always keeping in mind helping developers build applications at scale. >> So in terms of that pivot that you've made, it sounds like you made that in conjunction with developers across industries to really understand what the right direction is here. What's the approach, what's their appetite? Talk to me about a customer example or two that really you think articulate the value and the right decision that that pivot was and how you're helping customers to really further their DevOps practice. >> Well, one of our first customers was actually Fidelity in this new world. Fidelity has a very advanced technology organization, a very forward thinking CTO, who I seem to recall is, or CEO, who I think is female. Really is into technology as a source of, you know, velocity and business strength. And we were brought to Fidelity by our partner, Amazon. And they said, "look, Fidelity have been using your open source tools, they want to run on Kubernetes, the early EKS service on AWS, but they need help, because what they want is a shared application platform that people can use across Fidelity to deploy and manage apps." So the idea Fidelity had was they're going to split their IT into a platform team, that was going to provide this platform, and a bunch of app teams that were going to write business apps like risk management, other financial processing. Paths, basically. And we came in to help Fidelity. And what we did was help Fidelity rollout, using getopts, a Amazon wide application platform. We also helped them to build, this was very early days for us post pivot, we really helped them to build an add on layer. So you could take any Kubernetes cluster and add other components to it, and then you'd have your platform right there. And the whole stack would be managed by getopts, which nobody had done before. Nobody who'd come up with a way of managing the whole stack, so you could start and stop stacks wherever you wanted, at will, correctly. I mean, if you talk to people about what's hard in IT, they'll tell you shutting down Kubernetes is hard, 'cause I know I'm never going to know how to start it again. So being able to start and stop things, move them around is really crucial. What Fidelity also wanted, which made I think the whole thing even more exciting, was to duplicate this environment on Azure and actually also on-premise later on. So where Fidelity are today is the whole Fidelity platform runs on Microsoft and on Amazon and on-premise, using three different implementations of Kubernetes. But using this platform technology and getopts that we helped Fidelity rollout. And if you want to know a bit about the story, type FIDEKS, F I D E K S into Google and you'll find a video of me three or four years ago on stage at Cube Con talking with a Fidelity chief architect about this story. It's pretty exciting and these are early days for these new Kubernetes platforms. >> Early days, but so transformative. And I can't imagine the events of the last few years without having this capability and this technology to facilitate such pivots and transformation where we would all be. I want to kind of dig into some use cases, 'cause one of the things that you just mentioned with the Fidelity example got me thinking use case of hybrid, multi-cloud, but also continuous app development. Talk to me about some of the key use cases that you work with customers on. >> Well you just named two. So hybrid and multi-cloud is absolutely critical, and also sovereign, which is when you're actually offline and you only update your cloud periodically. That's one of the major use cases for us. And what customers want there is they want consistency. They want a single operating model, across all of these different locations, so that all of their teams can get trained on one set of technologies and then move from place to place. They're not looking for magic, where apps move with the sun or any of that stuff. They just want to know they can base everything on a single, homogeneous skillset and have scale across their teams. Maybe tens of thousands of developers, all who know how to do the same thing. That's a really important use case. You also mentioned continuous delivery. That's probably the second really critical use case for us. People say, "I've got Kubernetes set up now, and I have Jenkins." At JP Morgan once told me they had 40,000 Jenkins servers, or something like that, you know, Jenkins at scale. And they're like, "okay, how do I push changes from Jenkins into the cloud?" So getopts provides a bridge between the world of CI and the runtime of Kubernetes. So one group of our customers is help me to put that middle piece of CD that gets you CI, CD, to Kubernetes, that's a classic. And then what they're looking for is an increase in velocity. And what we typically see is people go from deploying once every six months to deploying once a week, to deploying once a day, to deploying several times a day. And then they split things up into teams and suddenly, wow, that vision of microservices has come and everybody's excited 'cause IT velocity has gone up by two X. Another really >> So, >> Sorry, carry on. >> Go ahead, I was just going to say in terms of IT velocity it sounds like that's a major business outcome that you're enabling for, whether it's teleco, financial services, or whatnot. That velocity is, as you just described, is rapidly accelerating. >> Yeah, if you go to our website, you'll find a bunch of these use cases. And one that I really like is NatWest mettle, which is another financial example. They're not all financial by the way. But there's some metrics in there. We're getting people up to two X productivity, which at scale is huge, really makes a difference. Also, meantime to recovery. If you know the metric space, you'll know these are all DORA metrics. And DORA, which was acquired by Google a couple of years ago, is a really fantastic analyst in the space that came up with a bunch of ways of thinking about how to measure your performance as a business and IT organization. Recovery time and things like this that you really need to focus on if you're in this world. >> Well, from an IT velocity perspective, if I translate that to business outcomes, especially given the dynamics in the market over the last two years, this is transformative and probably helped a lot of organizations to pivot multiple times during the last couple of years. To get to that survival mode and into that thriving mode, enabling organizations to meet customer demand that was changing faster, et cetera. That's a really big imperative that this technology can deliver to the business. >> Yeah, I mean, that's been huge for us. So when the pandemic first began, obviously, we had some road bumps and there were some challenges, but what we found out very quickly was that people were moving into digital much faster. And we've been mostly enabling them, not just in finance, as I said, but also, car companies, utilities, et cetera. The other one, of course, is modern operations. So, everyone's excited about the potential for automation. If I have thousands and thousands of developers and thousands of applications, do I need thousands of operations staff? And the answer is, with Kubernetes in this new era, you can reduce your operational loads. So that actually very few people are needed to keep systems up, to do basic monitoring, to do redeployments and so on, which are all boring infrastructure tasks that no developer wants to do. If we can automate all of that, we can modernize the whole IT space. And that's what I think the promise of Kubernetes that we're also seeing as well. So applications speed first and then operational competence second. >> So you guys had a launch, here we are in early calendar year 2022, you guys had a launch just about six or eight weeks ago in November of 2021, where you were launching announcing the GA of Weave getopts enterprise, which is a licensed product building on the free open source Weave getopts core. Talk to me about that and what the significance of that is. >> Well, this is an enterprise solution that helps customers build these critical use cases, like shared service platform or secure DevOps or multi-cloud, using getopts, which gives them higher security, lower costs of management, and better operations, and higher velocity. And all of it is taking all the best practices that we've learned starting from those days of running our own Kubernetes stack and then through those early customers like Fidelity into the modern era where we have an at-scale platform for these people. And the crucial properties are it provides you with a platform, it provides you with trusted delivery, and it provides you with what we call release orchestration, which is when you deploy things at scale into production, using tools like canaries and other modern practices. So, all of it is enabling what we call the cloud native enterprise, application delivery, modern operations. >> So what's the upgrade path for customers that are using the free open-source tier to the enterprise package, what does that look like? >> The good news is it's an add on. So, I have been in the industry a while and I strongly believe it's really important that if you have an open source product, you shouldn't ask people to delete it or uninstall it to install your enterprise product, unless you really, really, really have to. And I'm not trying to be picky here. Maybe there are cases where it's important, but actually in our case, it's very simple. If you're already using one of our upstream tools, like Flux, for example, then going from Flux to Weave getopts enterprise is an add-on installation. So you don't have to change or take out what you're doing. You might be using Flux without knowing it. You may not be aware of this, but it's also insight as your AKS and ARC, it's inside the Amazon EKS anywhere bundle. It's available on Alibaba, VMware have used it in cartographer and Tanzu application platform. And even Red Hat use it too in some cases. So you may be using it already, from one of the big vendors who are partners of ours, as a precursor to buying Weave getopts enterprise. So, you know, don't be scared. Get in touch is what I would say to people. >> Get in touch. And of course, folks can go to weave.works to learn more about that. And, also we want to watch the Weave.works space, 'cause you have some news coming out relatively soon that sounds pretty exciting, Alexis. >> Well, I mentioned trusted delivery. And I think one of the things with that is no CIO wants to go faster, unless they also have the safety wheels on, let's face it. And the big question we get asked is "I love this getopts stuff, but how can I bring my team with me? How can I introduce change?" I have all of these approvals mechanisms in place, can I move into the world of getopts? And the answer is yes, yes you can because we now support policy engines as baked into our enterprise product. Now, if you don't know what policy is, it's really a way of applying rules to what you're seeing in IT. And you can detect whether something passes or fails conditions, which means that we can detect if something bad is about to happen in a deployment and stop it from happening, this is really critical. It also goes hand in hand with things like supply chain and security, which I'm sure we read about in the news far too much. >> Yeah, pretty much daily supply chain and security >> Pretty much daily. >> is one of those things that we're all in every generation concerned about. Well, Alexis, it's been a pleasure having you back on the program, talking to us about what's new at Weaveworks, the direction that you're going, how you're helping organizations across industries really advance their DevOps practice. And we will check weave.works in the next couple of weeks for more on that news that you started to break a little bit with us today. We appreciate your time, Alexis. >> Thank you very much, indeed, take care. >> Likewise. For Alexis Richardson, I'm Lisa Martin. Keep it right here on theCUBE, your leader in hybrid tech event coverage. (bright music) (music fades)

>> 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)