 Good morning, good afternoon, good evening, and welcome to another episode of Working on Open Shift. And sometimes we have a shift. This is so awesome. We are an open culture that is really, really exciting. Everybody has something that they think it's good. On top of direct portfolio. Hi, and welcome to the In the Cloud. I'm your host, Stu Miniman, and happy 2022. We figured no better way to kick off the inaugural episode of 2022 than to have a guest from the company that most people think about when they think about the public cloud, Amazon Web Services. So, welcoming to the program, Deepak Singh. He's the vice president of Compute Services at the aforementioned AWS. Deepak, great to see you. Thanks so much for joining me. Thanks for having me, Stu. And it's great to see you again and happy new year, everybody. You and I have done this a few times before. Yeah, so roles change. I changed hats about more than a year ago now. But yeah, you and I have been talking since really some of the early days of containers. So Deepak, I wonder if we could start there. You've got a really interesting background. You're the second PhD in chemistry that I know that's deep in tech. A good friend of mine, John Troyer, also is a PhD in chemistry. And it's one of those, OK, how do you get there? I mean, I started engineering. I thought I'd be working on rockets and robots and stuff like that and ended up here in the IT industry for my entire career. You've been with Amazon over 13 years. Kubernetes didn't exist. Containers would be something that if you were talking to the Solaris people about, or there's probably some Linux people that knew what Linux containers were, but well before Docker helped democratize this for it. So give us a little bit, just a quick background if you would, what brought you into tech, into Amazon? And then we'll get into some of the more clouding container discussions. Oh, awesome. So yeah, as you noted, I have a PhD in chemistry. And actually for the first eight years of my career after I finished, I worked in the life sciences industry. So my first job was at this little tiny startup that was doing... Everybody knows Alpha Fold is these days. It's this thing that does protein folding for protein structure prediction. That's kind of what I did in grad school a lot. And it's my first job. I wrote algorithms to detect protein structures. Actually the kind of things that I'm quite jealous. I almost want to go back and do some of that research again, because computers and machine learning have come such a long way since then. But long story short, I was always on the computational side of chemistry. So my Twitter handle is a piece of code and it's actually some theory that I did in grad school. And I have such a common name that when I was first going online long, long time ago in the 90s, finding a handle was really hard. So I went ahead and picked one that I figured that the only other person would ever think about it was my grad school advice. So, you know, it's stuck since then. And along the way... It's good to know. We've talked a bunch of times. I do the background of your Twitter handle. There's the doc in there. So because I had a computational background, I started off doing algorithm work for doing protein structure predictions somewhere along the way. I ended up becoming a product manager for software that I happened to have code in. So I got into product management and that brought me to Seattle at some point. Still working in life sciences, more on the genomic side this time. This is actually things like RNA and mRNA and gene expression. And sequencing. And I met this gentleman named Jeff Barr. I was already into the cloud. I'd started using EC2 pretty much since the second it got announced. I was... I still have an S3 account that I use quite actively. And Jeff convinced me to come to AWS and the rest is history. So to speak, that was in 2008. Wow. That's a really interesting journey. It's always interesting to talk to people. We know career paths don't tend to be all that linear. But you've been with Amazon, since you came on board, you said product manager, you started in the EC2 side of things. Give us a little bit your macro view. Here we are in 2022. Boy, I mean, at Reinvent, not only did you have a leadership session, but your CEO, Adam talked a bunch about all of these wonderful services that have containers wrapped around it. You know, Werner talked so much about so many services where it's either containers or containers underpinning so much of what's going on. So give us a little bit about your organization and how that fits in the BMF that is AWS today. You know, and as you said, I started off in the EC2 side. It's run product management for EC2 instances. So, you know, for some of the weird naming and the sheer variety of instances, I'm sure I can take some of the credit and I guess some of the blame. But it was pretty clear, you know, one of the things I said, I said this in my leadership session at Reinvent is, the way people are building and deploying code today would have happened where the containers existed or not. You had already started seeing it happen with the way Netflix did things, which was, you know, packaging up armies, Amazon machine images and deploying them as immutable units. A lot of other people had started taking that approach. Along the way, this Docker thing came along. And I think what Docker did, apart from having a cute logo, which I think helped a little, was it really, really made that packaging and deploying side very simple. The fact that you could do Docker run, Docker build, Docker push, really opened the eyes of people. And I think the one or two things that have happened because of containers are one, I would think it's fair to say that the packaging format, the OCI format now has become the standard way of packaging software in many ways. And you see this across, even Lambda now supports containers as a way to package a Lambda function. So I think that's become quite the standard. And I think the other parts of containers are actually less about the container itself and more about the orchestration. The container, you know, you actually don't even deploy a single container in many of these cases. You're deploying a task or a pod of some bundle of containers. It's the mechanics of the fact that you have these orchestration APIs, your deployment API that sort of built into how you're running things. And this, so it's difficult to say which is the chicken and which is the egg. But I think that's what made it really, really popular was you suddenly had this very convenient packaging system that everybody liked that you could literally run on your laptop and run in a cloud and run on a main frame, I guess, you know, all kinds of crazy places. And you had all this wonderful orchestration tooling that grew up around it that had deployments and blue-green, all that built in that made containers that as popular as they have today. And yes, I think it's reasonable to say, and you probably see it on the red-hat side, is today when people are building a new application on AWS, almost invariably it's written for containers or for Lambda. It's very rare that somebody is going to write an application today that is VM first, not that common. Yeah, and I guess, you know, brings up a really interesting point. So if I, you know, if I'm existing customer, you know, the born in the cloud customers, you know, absolutely I'm going to be starting. If I go on Amazon, you know, serverless containers, you know, of course that makes sense. I want to be cloud native. You know, I did a whole series, you know, towards the end of my time on theCUBE and said, you know, look, cloud native isn't just about containers or serverless. There's a lot more from the application architecture standpoint. But if I take a traditional enterprise, I've got an entire application portfolio and going from what I have to being, you know, more cloud native isn't necessarily an easy step. So, Deepak, help me understand when you're talking to customers that there's, I guess I'd look at the two axes, there's the, you know, the infrastructure piece going from, you know, a VM to container or serverless. And then there's, you know, how I architect my application getting to that ultimate, you know, modern environment. Doing it all at once isn't necessarily easy. What are you seeing, you know, has anything changed from customers that you're seeing today versus, you know, customers, you know, a year or two ago, where we didn't necessarily have the maturity in the container or serverless world? Yeah, all of the above really. And it also, you have to remember that AWS's customer base has evolved a lot in the last few years. I mean, you've gone from the Instagrams and the Netflixes of the world to large enterprises. I mean, just see Adam's stock agreement where you had, you know, some very well-established enterprises there. And quite honestly, even companies that are kind of between the digital natives and the large enterprises, that maybe don't have very large IT staff. So it's, you know, depending on who you are, you take different approaches. I'll actually talk of some of these larger enterprises that may have adopted the cloud in some ways a few years ago, but are really going in all in right now. I think it's pretty clear most of the new applications are written for the cloud. I mean, that's happening. And I would argue that one of the reasons Kubernetes has been as successful as it is, is they may not be fully ready. And two, three years ago, they were definitely not all fully ready to go into the cloud, but they wanted some of those benefits on deployments and immutability and the best practices of running modern applications. But they didn't have any way of building them on-prem either. I think one of the reasons Kubernetes really succeeded was the fact that it gave them the path where they could take that and deploy it wherever they wanted. It was, they were hedging their bets. They could stay on-prem. They could go to a cloud and they weren't sure where they were going. So I think that really, really helped accelerate the adoption of Kubernetes, which is why you see things like financial services institutions jumping, you know, right into the deep end very quickly. I mean, you see this in the OpenShift world. And we'll talk about that a little bit, I'm sure, in this conversation. I think the more tricky ones is, and I think this is where we have to be honest. Like, there are some applications that maybe you should never continue on. It just doesn't make sense. That's why you have things like Mainframe Migration Programs to help figure out how to move those into the cloud in ways that are safe for those. And some might stay on-prem for a very long time. That's why things like Outposts exist. Like, okay, you want a bit of AWS running next to apps that you cannot move, but you need them co-located. We'll give you a rack of EC2 instances effectively on which you can run AWS services. So I think we see the full gamut of, I'm not going to move this. I'm just going to stay to, there are pieces that I can break out. And I think that's probably the way we see a lot of activity if people are starting to break up pieces and seeing what can be modernized. And then, of course, the whole, here's an app I can refactor. It's a Java app. I can break it up, move it over. A great example of something we did was App2Container, which is, hey, we'll go look at it.net and Java applications and put them into a big, gigantic, large container, which will probably make most container purist cringe, but it just makes it easier to move. And once it moves, then we can figure out what to do with it. And I think that, so you see all of that. And I would say we have better at some today as an industry than at others. And I've seen people get a little, you know, I won't say upset, but they don't like us being parochial and saying this is the only way. And I think one of the things that all of us will have to learn over the next few years is how do we take these existing applications and figure out which are the ones that should be refactored, how they should be refactored. And without necessarily being pedantic about, you know, you have to be mutable. You have to break things up into single processes. Not everything has to be a microservice. Yeah. Yeah. No, absolutely. I'm glad you brought up. There's certain, you know, we talk about the almost the religious wars that we have inside attack, you know, but remember back, you know, go back a dozen, 15 years ago, it was, you know, there is only one cloud. It's the public cloud. And, you know, AWS was the was the leader in that space. One of you touch briefly on, you know, containers and serverless and how those live together for a number of years, you know, the serverless, you know, I guess you'd say almost the war years out there, the ones that are like serverless is the best. And I don't know why you're wasting your time on containers and Kubernetes. You know, that's going to, you know, be short lived serverless is the only way to do things. I interviewed Andy Jassy once and he had said a few years ago, he said, if I was to build AWS today, I would build it all on serverless. Well, serverless is short feeling more and more like it ties into containers today. And if I look at containers, I'm doing more and more things to have that serverless way of of my management, my developers don't need to think about the containers. We've got things like Fargate and Knative that abstract, if you will, or at least, you know, from a developer, I don't need to think about that. So inside Amazon, am I right that, you know, it's more of a spectrum. I know their presentation, your presentation at reinvent talked about it more of a spectrum and, you know, we're going to, we're going to live together and there's certain use cases for certain ways of building things. Yeah, I mean, the way I think about it is pretty simple. And, you know, what Andy said is not completely untrue. It's like today, when you're building a front-end API at AWS, the chances are it's going to be serverless. In fact, a lot of my container services at the front-ends are all serverless. They're all running API Gateway and Lambda. That's just easy, makes the team's lives easier. Backends, it's a little more mixed. Backends tend to often be containerized, which is why you see so many AWS services built on containers as well. And we see this with our customers. We all pragmatic. We learn from each other. We've learned a lot from what's the serverless. And I say serverless here, I mean sort of the event-driven Lambda-style serverless. And I think that is actually how to think about it. As customers think about events, as they think about event integrations and Lambda's beauty is it is scale-free. It is, you don't have to think about, you know, connecting things from one thing to another to a third thing over there because those are all built in in many ways. So if that is the mode in which you are operating, you should absolutely be thinking in that context. But there are places where you will have requirements to have, you know, Lambda is one invoke, one process where you want to multi-thread that. That's how the application is written. That's how you want to write your applications. And today, I mean, today on AWS, for example, whether it's internal or external, a good chunk of those customers end up running on something like ECS Fargate or running on Kubernetes. And I think for a long time you will see that it's not uncommon. It's kind of funny. It's not even funny. A lot of our, like a lot of my services are containers at the back end, serverless at the front end, through for a lot of our customers. And you'll find different inside any of our customers, you'll find different business units and central IT, making the decisions that work for them based on how they want to run things and what they're capable of. And, you know, I'm an old Perl guy. There's always more than one way to do it. And I think our customers kind of do embody that. Yeah, Deepak, you teed up a really interesting discussion. We have in the Amazon space, there's that paradox of choice. There's so many services out there. You know, Werner got up on stage and he says, the reason we have over 200 services is because we listen to you as customers. I loved in your leadership session, you had a phrase, you said we meet customers at the threshold of pain that they want. So maybe talk a little bit to, you know, Massimo on your team did a session at re-event talking about, you know, there's so many different services. What is the decision tree? How can you make that decision? Why do you have so many options? You know, how do I help customers choose the right pieces as to how to engage there? Yeah, I mean, that's why Massimo gave that talk. And you can see the early indications of us being more opinionated on helping customers. I think for a long time we've had customers are very capable of making those choices. You know, for example, if you are a customer without a strong SRE team, my usual advice to you would be you just want to run an application, don't run a container orchestrator. You need, especially Kubernetes, you need a team to do that. Maybe you want to go with something like Lambda or AppRuna. I'm just simplifying here, but that's the discussion we can't have. And I think as our customers evolve and you get a bigger variety of customers, we have to help them get from point A to point B because what I do find, I wonder why, why I think Massimo gave that talk was we were having, we were getting these questions also, where should I start? People who come in with their expectations like I want to run Kubernetes, I want to run Flage, I want to run Lambda, life's easy with them. They know where to go. It's why we have all of them because there are enough people to paraphrase Werner who asked for each one of those and the capabilities that they have. But increasingly we are getting customers who are first-time cloud customers. So I think that's kind of what the goal of that talk was. You'll find us doing multiple things. You'll find us giving talks like that that sort of give people a way of thinking about, put yourself in this flow chart somewhere and see where you end up, knowing very well that you can go in different directions. But I think what you'll also end up, see us end up doing is give people more opinionated services and options. But you know, that's where things like AppRuna or Proton might come in. It's like, hey, you want to build apps a particular way using infrastructure and containers and you want to build a developer platform we have put on for you. If all you care about is the request response service, use something like AppRuna. Don't ever think about Kubernetes, don't ever think about ECS or even Fargate. Just go run. But I think one of the reasons it works is we do provide the foundational building blocks where people who know what they want to do can take that path and whether it's running on ETS or whether it's running on Rosa, such as Red Hat OpenShift Service on AWS or whether it's running on ECS, Fargate or Lambda. There's a sufficient number of people who know what decisions they want to make and everything else builds on top of these. So you'll always see us do both because I think if you come in just with abstractions, other people have tried that. It tends to frustrate people really quickly. Yeah, now Deepak and thank you, you bring up with OpenShift. We always have that challenge is certain customers, they come to us because we can give them an opinionated. Here's what we've learned from our thousands of customers and here's the path that we recommend. Other companies, our development team, we've made our choices. We know what we're doing. We want to do things our way. It's like, well, one of the nice things about containers in Kubernetes is you can have flexibility, but it's like where do you want to go? Yeah, you had another line you used from what do customers need to ask themselves? Who are you and what do you want? So you're an AirBender fan, I know. Oh, I am a huge. I quote Uncle Iroh all the time in my favorite character on the show. No, and I think that's true. Let's take Rosa for example. We have our own Kubernetes service. We have other people running their own Kubernetes on AWS and we work pretty closely with them. Just going back a little bit. I see our team as not an EKS team. I see them as a Kubernetes team and EKS is one of the vehicles, but there are a whole bunch of customers, you know, them really well who like OpenShift and have committed to using OpenShift and are super interested, some very large companies. And instead of telling them to go pound sand or figure it out yourself or go, you know, I think both of us came to the realization where we could say, hey, how can we work together to give them an even better experience in AWS? And we'll keep doing that as long as there's sufficient interest in the right volume and type of customer. It makes complete sense. You know, and I've often jokingly said, I can say this about a Mesa service, but very few people use it now. But if somebody came to us, enough customers came to us today and said, hey, can you build us a managed Mesa service? And it's the next best thing. That's right. We look at it. We may not choose to do it, but we look at it because there is, they're not, they're not secret cows, so to speak. Yeah. Well, deep packet, you know, from a philosophy standpoint, you know, Amazon, you've got all of the primitives. You've made certain services to, you know, make it easier for customers' concern. And then there's the ecosystem, the partners, as you said, you know, I get questions all the time. Well, you know, you've got ECS and EKS and Fargate and all those thumb, you know, why is it Rosa? And I'm like, well, it's Deepak's team where the same team is working with us and there's a set of customers and there's things that we've delivered that that's what they want. And, you know, right, it's not, people have from the outside that don't know Amazon as well as others are like, well, no, no, no, you're going to conquer the world and push out everyone else so that you make all the money. It's like, well, you know, what is the, what's the guiding principle on that Deepak? Yeah, I mean, the guiding principle is usually very, it's simple is how can we help our customers achieve their outcomes? You know, whether in one case it's working with you and Rosa, that's an easier decision to make because we've worked with Red Hat for such a long time on things like well, you know, the EC2, I used to own the REL relationship from an operating system standpoint. I run the Linux team today, you know, and so my team builds Amazon, Linux and Barrel Rocket. But at the same time, we have a team that's fully dedicated to making sure that we work with Red Hat on REL. We always do what our customers want to do. You know, obviously, though the intentional decision, it has to make sense for us and for the partner and for the customer, but that's, you know, that's generally the approach. And containers in particular, I think you cannot do it another way. And a great example is what we've done with EKS anywhere. You know, we were running on-prem where suddenly you don't have VPC, you know, not running in an outpost, but you're running on customer-owned infrastructure. So how do you get networking the way we want it to? So we worked with, in the beginning with Isowale and said, okay, instead of using AWS CNI, which is optimized for VPC, use the Cilium CNI and work with, and you can use that one. And we'll keep doing things like that where it makes sense because, you know, in the end, the goal is to get our customers productive faster. Yeah. You talked about Linux and what you're doing in the space. You know, what's, what is Amazon's role when it comes to open source in general? I understand, you know, you're personally pretty heavily involved in that. Yeah, could you repeat that? I was reading the chat. Yeah, no, it's open source. You know, what's your role and what's Amazon's role when it comes to open source? So I happen to run the Amazon open source program office. So these are folks who help Amazon engineers be more effective open source contributors and also on things like making sure that we, when we ingest packages, they have the right licenses on them and all of that stuff. So, you know, it's a legal side, compliance side, as well as the enablement side. The approach we take is quite simple. It's not, you know, in general, the approach we take today is, the first question we ask is, if you are doing something, is should it be open source or not? If not, why? We ask ourselves that question. It's a standard question. We ask on any of the sort of well-known Amazon PR facts these days. And in some cases, and EKS is a great example, we take an open source first approach. Anything that the EKS team develops, outside of the control plane that's used to run Kubernetes, that's, you know, we are the only people who care about it because you're running it with Amazon tooling. It should, or we always ask ourselves the question, should this be open source? And so far, every single time, the answer has been yes. A great example of that is Carpenter, which we announced that, you know, GA Adreen went, which is a provisioning and scaling engine. We could have just built it into EKS as an EKS feature. We chose not to. We did it as an open source capability that anyone running on AWS, whether you're using EKS or not, can leverage. And we've built it in such a way that if you want to use it outside AWS, you can also do that. You know, bottle rocket, same thing. So we've, I think the approach we try and take for the most part, and I think we're still figuring out what's the right mechanism and how to, you know, build around it is try and do it in a way that other people can leverage because we don't have all the answers. And in a case like Kubernetes, where it absolutely makes, you know, there's always more than five ways of doing the same thing. We want to make sure that what we are offering is brings our experience and what we believe is a good way of doing it and trying to do it in such a way that people can leverage not just on AWS but elsewhere as well. May, will it always be that way? Maybe probably not. At some point, we'll probably have something if it doesn't make sense, but by and large, that's the way we approach it. Yeah. Well, Deepak, it's great to see. I know from a container standpoint if I want to know the Amazon roadmap, it's on GitHub. So it makes it really easy. It's open. If you want to know the, you know, the joiner offering that we have with the Red Hat OpenShift service on AWS, where is it? It's on GitHub. So it's nice, you know, it's something obviously we believe deeply in at Red Hat and we're super glad to see, you know, AWS, you know, doing many of those same things in the open source world. Yeah. I mean, I remember when Abby Fuller, whom some of you might know, had come and proposed the idea of an open roadmap. And I think my whole team was fully supportive and it was an easy decision in the end. And you know, you've seen not just my team, but other teams at AWS. And actually people outside AWS also takes that similar model because it's clearly very popular with customers. So far it's worked really well for us. It gives us great feedback. Leads to some really good discussion. So, you know, I'm glad we did it. So just want to circle back to, you know, the customer discussion. So at the end of the day, you know, containers, Kubernetes, the reason that it exists is it's infrastructure is to run the applications. That's what matters in business. My data, it's my application. And there's often a, you know, skill gap between, you know, knowledge that my team needs to know and the gap between the infrastructure people and the applications people. Yeah. So seeing these days, what are some of the biggest challenges that customers have? How is an industry? Are we looking to address that? I would actually argue that is the biggest challenge we have. You've probably heard me, you know, I want to say rant about it. Get on a sub box about it. It's probably a better way of saying it. You know, I feel like sometimes in the container world, we have regressed a little by making these boundaries worse than they used to be. When EC2 came about, now obviously EC2 was very familiar interface that we used to running on VMs and machines. But one of the things we did was you really never did not have to think about racking and stacking and where the rack is and which building it's in anymore. And in some ways with container, they sort of brought that back. You know, you know, if you use Kubernetes as an example, every cluster has a database. So if you're running it yourself, you really, you know, I half joke and say the EKS team is a manager at CD as a service team because that's the big part of what they do is running all these hundreds of thousands of databases. And I've seen what I've seen companies do, you know, there was this vision of DevOps at some point of time where the developer and operator boundary would just disappear. It's actually gotten, I think, more sharpened. The one of the ways a lot of, and I think it's the only way they can find success and I'll go into kind of how we're helping there is a lot of our customers have made these centers of excellence, centralized teams that become the experts that are running this containerized infrastructure and their application teams are still just application teams and they're writing their apps and they want to vend self-service tools to them. I think it's a reason why, you know, things like OpenShift actually is popular with people because it makes it easy to do that for a lot of these teams. It reduces the friction. And I think everything we can do as a community to reduce friction, because right now the, for large enterprises getting to that place where they have a good platform that their devs can use is pretty hard. I've seen people try for two years and literally deploy two demo applications. And it's a challenge. So that's one of the reasons we built Proton and it's still early, but that was the idea was it's so hard for people to adopt not just Kubernetes but CICD and infrastructure as code and observability and name it at the same time. We've pushed a lot of decisions on them with like 15,000 different options or can we simplify it? And I think I owe that. I've already started seeing that. I think as an industry that's where we'll probably spend our time over the next two to three or four years. Well, if we look at the offering we have of OpenShift on AWS, we've got an SRE team there, part of a value proposition is we don't want you to spend too much time. You need to understand how to build on that, but you don't need to manage that. That's why we can have that expertise. Your team has lots of solutions. I look at AppRunner. It's in the name of the product. What do you do as a customer? You run your app, the rest of it underneath, the infrastructure should be taken care of. So absolutely a trend. We see how has Deepak, how we've been doing as a partner, we really appreciate the partnership with AWS. It was one of the things that I was super excited about when I joined Red Hat is the opportunity to be successful with Amazon to, as your group likes to say, making Amazon the best place to run containers. So how was the partnership? It's been great. I think we've learned a lot from each other around what running, for example, we have so much experience running services. I remember when we talked about operational readiness and what it expects, I think Red Hat probably learned a lot from that. We've learned a lot from how your customers and enterprises think about running applications and what choices they're making and what's important to them. I think that as both companies are learning, because this is a very unique partnership that we have with Red Hat around Rosa. How do you fit it in? I think I won't talk about road maps here. You can go look it up in GitHub. But some of the things that we have planned together over the next year or two are pretty exciting in terms of usability, in terms of accessibility. So I think we've always had a really good relationship with Red Hat, going back a long time and I think you can bring in the IBM side of it that's also improved a lot over the last few years. I think Red Hat joining IBM helped a lot there. And I know that Bob Weiss who runs my Kubernetes service and the technical team at Red Hat love working with each other, talk to each other all the time. So it's super exciting. And I always like, and I have my, actually have a check-in coming in soon on how the services is doing and how the collaboration is doing. And it's one of the meetings I look forward to, because, and I'll say this here, I'm pretty excited about how quickly it's been taken and how customers have adopted it and how many customers are interested. So it's great to go around. Absolutely. Deepak, it was funny. I was actually at Reinvent. You were in Seattle. So it was great. I got to talk to some customers. I met with some of the people working on some of the partnerships. So not just excitement, but I mean, hundreds of customers that are already using it, engaging. I tell you, some of the people watching this though, Deepak, since they like the dark side of the moon poster, we need to talk about something else in your background there. So you are, you know, an avid bird photographer. So, you know, serious camera. I know you've been out there. I believe you've had, you got your son, you know, doing some of it too. So tell us, you know, it's funny in the tech industry, like I remember the first time I became a manager, I was like, I don't think I understand this. Everybody that reported to me was on the side doing wedding photography, or they all had their DSLR cameras and everything like that. So the, the Venn diagram of people in the tech industry and people that are avid photographers, you know, there's absolutely a good overlap. So, tell us a little bit about your bird photography. Yeah, it's kind of funny, both my hobbies and you can see both of them behind me. It's the Venn diagram with other techies. It's pretty high synthesizers and cameras. So no, so I got into birds when I was very little, my father's a bird. And as he likes to remind me, he's a real bird because he doesn't use a camera. He just uses a binoculars and a scope. And, you know, I've on and off being into birds throughout my life. I got into bird photography about 15 years ago. I actually remember the day because there was a rare sighting of a flock of snowy owls here on the Pacific coast. And we had driven over and that was the first time I did some serious bird photography. And I did not have a very long lens at the time. And I remember, you know, on the way back as you're driving back, it was like, okay, time to get a long lens. And it's been my thing. I think it's, I like being out in nature and carrying a camera. So, you know, taking pictures of birds, I'm getting into trees and woodlands now. And, you know, with cameras being as good as they are now, it's just amazing. It's, and COVID is how we got into it as a family. You know, at that time my son was seven. He likes birds. My father had gotten him into birds as well. And every weekend we had nothing to do, no soccer, no activity. So we still got Gordon the wilderness to do birding and he got into bird photography along the way. So some of those pictures of the back are not mine. They're his. And it's become kind of the thing that we do, you know, as dad and kid and as a family in general. And, you know, I was like to say it keeps us out of trouble and it's, it's fun. It's just, and it gets you out there, out into the open, get some fresh air. No, you live in a great part of the country to be able to take advantage of that. It's a great pandemic activity. If I remember right, I think there's been snowy owl sightings on the Cape here in Massachusetts, which was like really rare. A friend of mine actually posted a photo about that. Yeah. And you have a, you had a stellar eagle that showed up in mass on the Massachusetts, which that's a Russian bird. It's almost never comes this far. So climate change has made the world a really weird place, which is sad. But you know, as I said, it, Washington's a great place for birding, especially Hawks and, you know, owls and so on. So we get out there pretty much every weekend and have for the past, I would say, basically since just after COVID started. Yeah. They're, they're asking up there, can you share a little bit about your gear from a camera standpoint? Have you gone mirrorless as Ricky? Yeah. That's the big thing I did last year. I went mirrorless. I have an R5, which is my primary birding photographer. I got an R6 as my second body. My son uses an R6. Then I use a 500mm lens, 100 to 500, because the big giant lenses are too expensive, too heavy. I'm not that good. It's not my job. I like something I can walk around with. But yeah, so that's a big change. So I've been on a 70, for 15 years, the original 70. Last year, I switched over to an R5. Very cool. Yeah. I tell you, I am not an avid photographer. I appreciate it. It's the one thing that drives me usually to the next generation of phone is, what's really nice is just what's in my pocket. I can do things. I actually did a short trip over the holiday break to Iceland, my wife and myself. And I got some decent pictures of the Aurora, just using the night setting on my iPhone. So it's amazing what we can do with the technology. Yeah. Phone cameras become so good. If you're in portraits, landscapes, like just normal day-to-day stuff, I'm picky. I still carry, I'll carry a 35 or 50mm lens for that, but the best camera is the one you have in your pocket. Yeah. I tell you, Deepak, one of my, back when I used to be a blogger, and one of the articles I read that blew my mind was an Atlantic article from, I believe it was from the 40s. And it was someone predicting just things like, cameras and phones and all this thing about the diffusion of technology and what the future might look like. So, you've got background in chemistry, like photography, you're in the cloud space, anything that you look at and say like, boy, we're in such an amazing time in technology today, but just wait, five years from now, the things we'll be able to do at the edge where I'm not just having a super computer in my pocket, but what might I be able to do? And anything that's got you pretty excited about the forward-looking activity with the disclaimer that it's not necessarily an AWS roadmap? Yeah. This is just me speaking. I'm actually very interested in what you can do with devices. Like you look at, it's both you're to be careful because it can have implications, but our devices are getting super powerful, right? In many ways. People have all kinds of computational devices in their home. I think it's one of the reasons actually, I'm very excited about things like ECS and EKS anywhere, just from the AWS perspective, because I think it does speak to where the world is going. We have this combination of really powerful client devices. A lot of IoT roadmap goes there. When my car is basically running computer, it rebooted on me once, it's just the scariest experience that I had while I was driving. It shouldn't happen to somebody for the first time. And I think as you have these very powerful clients, but you also need to build these machine learning. Honestly, most of my career, I've been a machine learning skeptic. I think over the last three years, that's changed. I think our accelerators are powerful enough that technology has come away. Alpha 4 is a great example. Somebody had told me that you would be able to build something like this 10 years ago, and I've told you to go climb a tree. Clearly, that's not true anymore. I think that's this combination of really powerful clients are devices where you can deploy models, very powerful backend training systems and the ability to distribute things, not just in big centralized cloud, but do things like a wavelength or a local zone, or even beyond edge devices, 5G stuff that we talk about a lot. I don't completely understand it, but I believe it's going to be super amazing. Personally, that's an area that I'll probably spend more time thinking about going for just personally and tracking, because it is fascinating. Yeah, well, I'm glad as you said, the relationship isn't just what we do on the open shift, but on the Linux side. When we look at what Amazon's doing, call it hybrid, call it edge, those type of things, we're trying to make sure that our software is going to be able to work in all of the places that you live, not just the cloud in the sky, which is made up of Linux servers, right? Yeah, it is going to be super interesting. I think that is the big change. If 5G, and I use 5G as a general term for broadband, because you've got things like Starlink and Kuiper and all showing up now, it can become more distributed as opposed to these big pipes that we need between data centers. I think somebody talked about microprocessor stuff and with things like ARM, which can run with low power profiles. I think we are in for some very exciting distributed computing, and I think how we think about it, how we evolve our programming models, et cetera, over the next few years, it's going to be fascinating. All right. So last thing, the DPAC, of course, the requisite, if people want to know more about your team, we actually, we put up in the chat there, if they want to find the Rosa Roadmap, we gave the GitHub link, AWS Container Roadmap is also up on GitHub. People want to find your photography. Is Instagram the best place? Yeah. Where are the best places to find all your stuff? The best starting place for any of this thing is just go to my website, depuxing.net, and from there you can find everything else. It's basically just, actually just recently, but we did it over the holidays while we were snowed in. Couldn't go out much. Yeah. So go to depuxing.net, that's the best place to start, and from there you'll go and get to find my Twitter and Instagrams and everything else. Yeah. And I said, it's always exciting to talk to you. We haven't done this for a while, but we used to do this quite regularly. So it's a good start to be here. Absolutely. DPAC, thank you so much from a Red Hat standpoint. We really appreciate the partnership. Looking forward to a lot of joint success for our customers in 2022. Personally, great to talk to you again also. Thanks so much for joining us. And thanks to everyone for coming and watching us. All right. We've got, please do plug in, hit the subscribe and like, share your comments. Let us know who you'd like us to talk to in 2022. This is a bi-weekly cadence. I'll be planning doing those maybe sometime in 2022. I'll get to do one of these in person, but in the meantime, I'm Stu Miniman. Thanks for joining us as part of your journey in the clouds.