 From around the globe, it's theCUBE with digital coverage of AWS re-invent 2020 sponsored by Intel, AWS, and our community partners. Hello and welcome back to theCUBE's live coverage for AWS re-invent 2020. I'm John Furrier with theCUBE. Your host, we are theCUBE virtual. We're not there in person this year. We're remote with the pandemic and we're here for the keynote analysis for Werner Vogels and we've got some great analysts on and friends of theCUBE, CUBE alumni is Rob Hirschfeld who's the founder and CEO of Racken, a pioneer in the DevOps space, as well as early on on the bare metal getting on the hole on premise. He's seen their vision and I can tell you I've talked to him many times over the years. He's been on the same track. He's on the right wave. Rob, great to have you on. I'm going to have Sarp Beach come on, you all come on as well, but great to see you. Thanks, pleasure to be here. So the keynote with Werner was, you know, he's like takes you on a journey, you know? And virtual is actually a little bit different vibe, but I thought they did an exceptional job of stage layout and some of the virtual stage craft. But what I really enjoyed the most was really this next level thinking around systems thinking, right, which is my favorite topic because, you know, we've been saying going back 10 years, the cloud is just to hear the computer, it's operating system. And so this is the big theme. This is, what's your reaction to the keynote? Wow, so I think you're right. This is one of the challenges with what Amazon has been building is, it's, you know, it is a lock box, it's a service. So you don't get to see behind the scenes. You don't really get to know how they run these services. And what I see happening out of all of those pieces is they've really come back and said, we need to help people operate this platform. And that shouldn't be surprising to anyone, right? Last couple of years, they've been rolling out service, service, service, all these new things. This talk was really different for Werner's normal ones because he wasn't talking about whiz bang, new technologies. He was really talking about operations. You dive in the wool, how do we make the system easier to use? How do we expose things? What assistance can we have in building applications? In some cases, it felt like an application performance monitoring or management, APM talk from five or even 10 years ago. Canaries, you know, canary deployments, chaos engineering, observability, sort of bread and butter operational things. We have Sarvichal, who's an influencer, cloud computing, extraordinaire, DevOps, guru. We don't need DevOps guru from Amazon. We got Sarvich and Rob here. So it'd be great to see you. You guys had a watch party. Tell me what the reaction was with some of the influencers in the cloud or Audi out there that were looking at Werner's announcement because this does attract a tech crowd. What was your take and what was the conversation like? Yeah, we kind of geeked out that we had a watch party and we were commenting back and forth like when we were watching it. I think the general consensus is that the complexity of AWS stack itself is increasing, right? And they have been focused on developers a lot, I think a lot longer than they needed to be a little bit. I think now they need to focus on the operations. And like we all love DevOps talks and it's very fancy and it's a very modern way of building software. But if you think deep down once we develop software traditionally and also going forward, I think we need to have that separation. Once you develop something, it's in production. It's operating, right? Once you build a car, you're operating car. You're not building car all the time, right? So same with the software. Once you build a system, it should have some stability where you're running it operating it for a while at least before you touch it or refactor and all that stuff. So I think like building and operating at the same time, it's very good for companies like Amazon AWS especially and Google and Facebook and all those folks who are building technology because they're purely high tech companies but not for GM Ford Chrysler or Kaiser Permanente, which is healthcare or a school district. They need to operate that stuff once it's built. So I think the operationalization of cloud will I think take focus going forward a lot more than it has and observability. And on funny note, I said observability is one of those things right now these days. Like, you know, in the beauty pageants that every contestant says, like whatever question you ask, they say da-da-da and they answer it and say at the end, world peace, right? And that's a world peace term, which is the observability. Like you can talk about all the tech stuff and all the stuff and at the end you say observability. And then you'll be fine. So what I'm making is like observability is and was very important. And what Warnett was talking today about like how we can enable the building of observability into this new paradigm, which is the microservices. Like where you pass the service ID all across all the functions from beginning to the end, right? And so you can trace stuff. So I think he was talking at that level. Let me, let's take an observability real quick. I have a couple of other points I want to get your opinions on. He said, quote, there's three enabling major enabling technologies powering observability, metrics, logging and tracing. Do you know what that is? Of course. But he almost didn't take a position. If you look at all the startups out there that are seeing their, the next observability there's at least six that I know of. I mean, that are saying, and then you got ones that are kind of come in. I think SignalFX was one I liked like I got bought by Splunk. And then is observability a feature or is it a company? I mean, this is something that kind of gets talked about, right? I mean, is it really something you can build a business on or is it a white space? That's a feature that gets pulled in. What's your guys reaction on that? So this is a platform conversation. And one of the things that we've been having conversations around recently is this idea of platforms. And I've been doing a lot of work on infrastructure as code and distributed infrastructure and how people want infrastructure to be more code like which is very much what Werner was saying, right? How do we bring development process capabilities into our infrastructure operations? And these are platform challenges. What you're asking about from the observability's perspective is if I'm running my code in a platform, if I'm running my infrastructure as a platform I actually need to understand what that platform is doing and how it's making actions. But today we haven't really built the platforms to be very transparent to the users and observability becomes this necessary component to fix all the platforms that we have whether they're Kubernetes or AWS or even going back to VMware or bare metal. If you can't see what's going on then you're operating in the blind. And that is an increasingly big problem is we get more and more sophisticated infrastructure. Amazon's outage was based on systems being very connected together and we keep connecting systems together. And so we have to be able to diagnose and troubleshoot when those connections break or if we're using containers or lambdas the code that's running is ephemeral. It's only around for short periods of time and if something's going wrong in it it's incredibly hard to figure it out. And also he reiterated his whole notion of log everything. He kept on banging on the drum on that one like log everything which is actually good practice. You got to log everything. Why wouldn't you? I mean, You do, but they don't make it easy. Amazon has not made it easy to cross and connect all the data across all of those platforms. People think of Amazon as one thing but we who are using it understand it's actually a collection of services. Some of those are not particularly that tied together. So figuring out something that's going on across all of your service bundles. And this isn't an Amazon problem. This is an industry challenge especially as we go towards microservices. I have to be able to figure out what happened even if I used up 10 services. Yeah, it's the classic horizontal scalability argument. Sarvita, I want to get your thoughts on this. So the observability. He also mentioned systems theory. He kind of couched it before he went into the talk about systems theory. I'm like, okay, I mean, I love systems. And I think that's going to be the big, you know, wake up call here for the next 10 years. It's a systems mindset. And I think, you know, Rob's right. It's a platform conversation when you're thinking about an operating system or a system. It has consequences when things change. But he talked about controllability versus observability. And kind of teed up the, well, you can control have systems controls or you can have observability. What's he getting at in all of this? What's he trying to say? Keep, you know, is it a cover story? Is it a feature? What was he, what was it we're getting at with Elvis? I believe they understand that all these services are very, very sort of micro in nature from Amazon itself, right? And then they are not tied together as Rob said earlier. And he addressed that. He announced a service. I don't know the name of that right now off top of my head that we will gather all the data from all the different places and then you can take a look at all the data coming from different services at one place where you have the service ID passed on to all the services. You have to do that. It's a discipline as a software developer you have to sort of adhere to. Even in traditional world, like, you know, like how you do logging and monitoring and tracing, it's your creativity at play, right? So that's what software is. If you can pass on, I was treating what they give example of Citrix when you are using like tons of applications which are streamed to your desktop through Citrix, they had app ID concept, right? So you can trace what you're using and all that stuff and they can trace the usage and all that stuff. And they can map that log to that application to that user. So you need that. So I think he was talking about that. I think that's what he's getting to. Like we have to sort of rethink how we write software in this new Microsoft sort of paradigm which I believe it's beautiful thing as long as we can manage it because Microsoft's are spread across like a smaller piece of software everywhere, right? So the state, how do we keep state intact? How do we sort of trace things? It becomes a huge problem if we don't do it right. So it's a little, this is some learning curve for most of the developers out there. Where does it crash? Rob, Rob was bringing this up. I want to get into this whole crash and what does it kind of break down because there's a point where you don't have the nirvana of true horizontal scalability where you might have microservices that need to traverse boundaries or systems boundaries or silos. So to Rob's point earlier, if you don't see it you can't measure it or you can't get through it. How do you wire services across boundaries? Is that containers? Is that, I mean, how does this all, how do you guys see that working? I just see a train wreck there. It's a really hard problem and I don't think we should underestimate it because everything we just talked about sounds great if you're in a single AWS region. We're talking about distributed infrastructure, right? If you think about what we've been seeing even more generally about edge sites, Colo, on-prem, in-cloud, multi-region cloud all these things are actually taking this one concept and you're like, oh, I just want to store all the log data. Now you're not going to store all your log data in one central location anymore. That in itself is a distributed infrastructure problem where I have to be able to troubleshoot what's going on and know that the logs are going to the right place and capture the data that's really important. And one of the innovations in this that I think is going to impact the industry over the next couple of years is the addition of more artificial intelligence and machine learning into understanding operations, patterns and practices. And I think that that's a really significant industry trend where Amazon has a distinct advantage because it's their systems and it's captive. They can analyze and collect a lot of data across very many customers and learn from those things and program systems that learn from those things. And so the way you're going to keep up with this is not by logging more and more data, but by doing exactly what Werner was talking through, which was how do I analyze the patterns with machine learning so that I can get predictive analysis so that I can understand something that looks wrong and then put people on checking it before it goes wrong. All right, I got to bring up something controversial. I can't hold back any longer. Mark Zuckerberg said many, many years ago, oh, all the old people, they can do startups. They're too old and you got to be young and hungry. You got to do that stuff. If we're talking systems theory, automated meta reasoning, evolvable systems, resilience, distributed computing, isn't that us old guys that have actually have systems experience? I mean, if you're under the age of 30, you probably don't even know what a system is and or coded to the level of systems that we used to code. And I'm putting my quote, old man kind of theory out only kidding, by the way, in the 30, but my point is there is a generation of us that had done computer science in the 80s and late 70s, maybe 80s and 90s. It's all it was with systems. It was a systems world. Now you have a software world, the aperture's increasing in terms of software. Are the younger generation of developers system thinkers or have we lost that art? Or is it, does it matter? What do you guys think? I think systems thinking comes late. That's what I think. I mean, I take the systems thinking into a greater sort of a world like state as a system, country as a system and everything is a system. Your body is a system, family is a system. So it's the same way. And then what impacts that system when you operate it internal things which happen within the system and external, right? And we usually don't talk about economics and geopolitics or the technology. Sometimes we do, like I think we need to talk more about that, the data sovereignty and all that stuff. But even within the system, I think the younger people appreciate it less because they don't see software taught like that in the universities and by these micro universities now online trainings and stuff. Like it's very like, okay, you learn this thing and you're good at this thing. No, no, no, it's not like that. So you got to understand the basics and how the systems operate. I'll give you an example. So like we were doing the client server in early 90s and then gradually we moved more towards like having ESB enters price services bus where you pass the state from one object to another and we can bring in the heterogeneous languages. This thing is written in Java. This is in .NET. This is in Python. And then you can pass it through that. You can make it stateful, right? And that was contained environment. Like ESBs were contained environment. We were, I wrote software for ESBs myself at commerce one. And so like we, what we need today is the ESP equivalent in the cloud. We don't have that. Rob, is there a reverse agent going on with developers? I mean, if you're young, you might not have the juice systems. What do you think? I don't agree with that. I actually think that the nature of the systems that we're programming forces people into more distributed infrastructure thinking. The platforms we have today are much better than they were 20 years ago, 30 years ago, in the sense that I can do distributed infrastructure programming without thinking about it very much anymore. But people know how to use cloud. They know how to use a big platform. They know how to break things into microservices. I think that these are inherent skills that people need to think about. That you're right. There is a challenge in that, you get very used to the platform doing the work for you and that you need to break through it. But that's an experiential thing, right? The more experienced developers are gonna have to understand what the platforms do. Just like, we used to have to understand how registers worked inside of a CPU, something I haven't worried about for a long, long time. So I don't think it's that big of a problem from that perspective. I do think that the thing that's really hard is collaboration. And so, it's hard people to people. It's hard inside of a platform. It's hard when you're at Amazon size and you've been rolling out services all over the place and now have to figure out how to fit them all together. And that to me is a design problem. And it's more about being patient and letting things mature. If anything, my takeaway from this keynote is, everybody asked Amazon to take a breath and work on usability and cross-services synchronizations rather than adding more services into the mix. And that's a sign of- Yeah, I mean, this is a good point. I mean, again, I bring up the conversation because it's kind of the elephant in the room. And I mean, being controversial to make a point there, sorry, because I interviewed Judy Estrin who helped found the internet with Vinsurf. She's well-known for her contributions for the TCPIP protocol. Andy Bestenstein, who's the Rembrand of motherboards Pat Gelsinger, CEO of VMware, would say, both said to me on theCUBE that without systems thinking, you don't understand consequences of when things change. And when you start thinking about this microservices conversation, you start to hear a little bit of that pattern emerging where those systems designs matter. And then you have, on the other hand, you have this modern application framework where serverless takes over. So, you know, Rob, back to your infrastructure as code, it really isn't an either or, they're not usually exclusive, you're going to have a set of nerds and geeks engineering systems to make them better and easier and scalable. And then you're going to have application developers that need to just make it work. So you start to see the formation of kind of the, I won't say swim lanes, but I mean, what do you guys think about that? Because Judy and Andy Bestenstein, they're kind of right. The enemy here, and we're seeing this over and over again is complexity. And the challenge has been, and serverless is like this, people like, oh, I don't have to worry about servers anymore because I'm dealing with serverless, which is not true. What you're doing is you're not worrying about infrastructure as much, but the complexity, especially in a serverless infrastructure where you're pulling events from all sorts of things and you have one action, one piece of code, triggering a whole bunch of other pieces of code in a decoupled way, we are bringing so much complexity into these systems that they're very hard to conceive of. And AIML is not going to address that. I think one of the things that was wonderful about the setting in the sugar factory and all of that sort of very mechanical viewpoint, when you're actually connecting all things together, you can see it, a lot of what we've been building today is almost impossible to observe. And so the complexity price that we're paying in infrastructure is going up exponentially. And we can't sustain infrastructures like that. We have to start leveling that in for that complexity. Great point on the keynote, by the way. Great call out on the setting. I thought that was very clever. Sarge, what do you think about this? Because as enterprises go through this transformation, one of the big conversations is the solution architecture, the architecture of how you lay all this out because it's complexity involved. Now you've got on-premise system, you've got cloud, you've got edge, which you hear in more and more local processing, disconnected systems managing it at the edge with visualization. We're going to hear more about that with Dirk when he comes on the queue, but just in general as a practitioner out there, what's your, what do you see people getting their arms around this keynote? What are they, what's your thoughts? Yeah, I think the pattern I see emerging is like, or in the whole industry, regardless, like if you put vendors aside, is that like we will write less and less software in-house, I believe. The SaaS will emerge and it has to, I mean, that is the solution to kill the complexity, I believe. Like we always will talk about software all the time and we try to put this in the one band. Like everybody's writing same kind of software and they have same kind of complexity and they have the end years and all that stuff. That's not true, right? If you are Facebook, you're writing totally different kind of software, you need to scale differently, you need a lot of cash and all that stuff, right? Cash, like this and cash. Yeah, cash. Well, and I have both caches. But when you are a mid-sized enterprise out there and like a flyover America, what my friend Wayne says, like we need to think about those people too. Like how do they write software? What kind of software do they write? Like how many components they have in there? Like they have three tiers or four tiers. So I think they write little more simpler software for internal use. We have to distinguish these applications and I always talk about this, like the systems of record systems of differentiation, the system of innovation. And I think cloud will do great in the newer breed of applications because you're doing a lot of experimentation. You're doing a lot of DevOps. You have two PZ teams and all that stuff, which is good stuff we talked about. But when you go to systems of record, you need stability. You need some things which is operational. You don't want to touch it again once it's in production, right? So in between that thing is, I think that's where the complexity lies. The systems are, which are in between those systems of record and system of innovation, which are very new green field. That's where, I think that's where we need to focus our platform development, platform as a service development, sort of for dollars, if you will, as an industry. I think Amazon is doing that right. And Azure is doing that right to certain extent too. I worry a little bit about Google because they're more tilted towards data science sort of things right now. Well, Microsoft has the most visibility into kind of the legacy world, but Rob, you're shaking your head there on his comment. Yeah, I watched the complexity of all these systems and I'm not sure that classification of everything that we're doing is leading to less complexity is pushing the complexity behind a curtain so that you can ignore the man behind the curtain. But at the end of the day, what we're really driving towards, and I think Amazon is accelerating this, the cloud is accelerating this, is a new set of standard operating processes and procedures based on automation, based on APIs, based on platforms that ultimately I think people could own and could come back to how we want to operate it. When I look at what we were just shown with the keynote, it was and is things that application performance management and monitoring do. It's not really Amazon specific stuff. There's no magic beams that Amazon is growing operational knowledge in Amazon greenhouses that only they know how to consume. This is actually pretty block and tackle stuff. And most people don't need to operate it at that type of scale to be successful. That's a great point. I mean, let's pick up on that for the last couple of minutes we have left because I think that's a great double down because you think about the mantra. Yeah, everything is a service. It's great for a business model. You know, you hand it over to the techies, they go, wait a minute, what does that actually mean? It's harder. But when I talk to people out there and you hear people talk about everything as a service or a certification, I do agree. I think you're putting complexity behind the curtain but it's kind of the depends answer. So if you're going to have everything as a service, the common thesis is it has to have support automation everywhere. You got to automate things to make things satisfied, which means you need five nines like factory type environments. They're not true factories, but Rob, to your point, if you're going to make something a SAS, it better be bulletproof because if you're automating something, it better be automated right. You can measure things all you want, but if it's not automated, like a safe factory. And you have no idea what's going on behind the curtains with some of these things, right? Especially, I know our business and our customer's businesses, they're relying on more and more services. And you have no idea the persistence that service, if they're going to break an API, if they're going to change things. A lot of the stuff that Amazon is adding here defensively is because they're constantly changing the wheels on the bus. And that is not bad operational practice. You should be resilient to that. You should have processes that are able to be constantly updated in CI CD pipelines and continuous deployments. You shouldn't expect to fossilize your IT environment in amber and then hope it doesn't have to change for 10 years. But at the same time, the more control you have. Well, if you want to get to that big angle about better. DevOps, it's hypothetical, like a factory almost metaphor. Do you care if the cars are being shipped down the assembly line, the output works and the output, if you have self-healing and you have these kinds of mechanisms, you could have, do you care, the services are being terminated and stood up and reformed as long as the factory works, right? So again, it's a complexity level of how much IT or you want to bite off and chew or make work. So to me, if it's automated, it's simple. Did it work or not? And then the cost of work. So I'd be, what's your, what's your angle on this? I believe, if you believe in systems thinking, right? You have to believe in the concept of, oh gosh, I'm losing over, minor, abstraction, right? So abstraction is your friend in software. Abstraction is your friend anyways, right? That's how we human species actually make a lot of more progress than any other sort of living things here in this world. So that's why we are smart. We can abstract complexity behind the curtains, right? We can keep improving, like from the wooden cart to the car to the plane to the other. Like we have this, like when we see we are flying these airplanes, like 90% of the time they are on autopilot. Like that's hiding of complexity. So abstractions is about evolution. Evolvable software, a term he said. Yeah, that is true. All right, guys, we have one minute left. Let's close this out real quick. Each of you give a closing statement on what you thought of the keynote and Werner's talk. Probably start with you. As always, it's superb keynote, very different this year because it was so operationally focused and using the platform and helping people run their applications and software better. And I think it's an interesting turn that we've been waiting for for Amazon to look at helping people use their own platform more. So a refreshing change, and I think really powerful and well delivered. I really did like the setting. Great job, and I found out today that Teresa Carlson is now running training and certification. So I'm expecting that to be highly awesomely accelerated success there. Sorry, what's your take real quick on Werner's talk, walk away keynote thoughts? I think it was what I expected it to be like he focused on the more like a the software architecture kind of discussion and he focused this time a little more on the ops side than the dev side, which I think they are pivoting a little bit because they want to sell more AWS stuff to us to the existing enterprises. So I think that was good. I wish at the end he said not only like go build but also go build and operate. So like they also go build, build, build but like who's going to operate this stuff, right? So I think I will see a little more shift I think going forward. We were talking earlier during our watch party that I think going forward AWS will open start open sourcing the commoditized version of their cloud the services which have been commoditized by other vendors and gradually they will open source it so they can keep the hold on to enterprises. I think that's what my take is that's my prediction is. Awesome. And I'll make sure I'm at your watch party next time. Sorry I missed it. No worries. Taking notes trying to prepare. Sarjeet, Rob, thanks for coming on and sharing awesome insight and expertise to experts in cloud and DevOps. I know them and can firstly vouch for their awesomeness. Thanks for coming on. I think Werner can verify what I thought already was reporting Amazon everywhere. And if you connect the dots this idea of reasoning are we going to have smarter cloud? That's the next conversation. I'm John Furrier your host of theCUBE here trying to get smarter with AWS coverage. Thanks to Rob and Sarjeet for coming on. Thanks for watching.