 Good afternoon. My name is Sean Norris. I'm the director of platform architecture for VMware covering Asia Pacific in Japan And it's my pleasure to come to you virtually and remotely today From my home office and talk to you about five aspects of container strategy Now before we jump in I just want to acknowledge that these are interesting times and I'm sure like me You may be working from your home office, but I trust that What we are seeing across industry even in these interesting and challenging times You'll find useful and you might find a few things you can take back and apply in your organization So with that, let's jump straight in and let's look at five aspects of your container strategy so first off just a few seconds about me these are some of the organizations that I've been with in the past prior to joining VMware and Notably JPMorgan Chase and standard Trutter Bank here in Singapore if you Like what I have to say or want to have a conversation further about anything shared today Feel free to interact with me on Twitter Where my handle is at Sean Norris now before we jump in and talk about container strategy You might be thinking to yourself. Well, what is VMware here today talking about? Kubernetes so why why is VMware talking about Kubernetes? Well, you know, we've recently launched VMware Tanzu and Tanzu is to coming together of three really interesting companies and and groups of teams We've got Heptio which includes two of the three founders of Kubernetes. We've got Pivotal Where I've come into VMware from Where we have years of experience running containers in production at scale and we have bitnami Who for years have run the most successful library of open-source package projects? And so the combination of these things together gives us VMware Tanzu and Very shortly. This is going to be the only thing remotely resembling a sales pitch in this presentation VMware Tanzu is going to allow you to build run and manage modern applications And so the build part of that is going to be modern software supply chain how you get code into production easily We expect Tanzu to help you run Kubernetes everywhere and we want you to be able to manage Multiple clusters of multiple flavors maybe with multiple teams involved as well And so all of this is coming together and be a more Tanzu if you haven't heard of it already You're gonna hear a lot about this in the future. So enough sales pitch. Let's jump in and talk about container strategy So first off, let's cover quickly where what we're actually going to look at today We're gonna have a brief history of how is an industry we got to this point We're going to have a look at why I think containers are a big deal and why I would suggest you ought to think so as well We're gonna look at these five specific aspects of very briefly Really when we talk about containers, we're really now talking about kubernetes and kubernetes is both a platform and a chance to reorganize and It's really designed for new ways of working and then we're gonna finish off by looking at is kubernetes a strategic goal in itself Then if you're interested in embarking on this journey or accelerating your journey towards containers and kubernetes How can you get started and maybe how can be a more time to help? So let's jump straight in You know if we think of the last Five decades of computers and we're not going to spend much time on this the overwhelming Thing I want you to take away from this introduction Is that the minimum unit of compute and the minimum cost to get started computing has steadily dropped over the last five decades? If you asked folks in the 1980s Is something going to come and displace the bunch of companies? That was you know Burroughs Univac NCR control data and Honeywell Well, really none of those are household names anymore for anything to do with computing If we move on a decade the 1990s where I kind of started my career was really the rise of x86 computing Intel microprocessors became the norm the internet Began or at least began to be used in full. We really saw the version 1.0 of the dot-com boom We roll forward to the 2000s Well, here we saw people taking physical servers and slicing them up into virtual ones and that's probably how you best know VMware and you know That really became mainstream through the 2000s We also saw the emergence of this idea of public cloud of running API driven infrastructure on someone else's premises and also the first generation of Systems management automation tools for for infrastructure We roll forward to the decade. We've just finished with the 2010s We saw cloud computing go from up an edge niche that may be a few startups and Really leading edge or bleeding edge companies were using to something that is really mainstream now We see this as billions of dollars a year of business of folks Spending money in the hyperscale public clouds We also though in the middle of the decade saw the emergence of this idea of Docker and then Kubernetes So now as we look forward like what is going to define the 2020s the decade that we're just starting well beyond some massive changes to our Lifestyle as a result of the the current virus situation that we're all anxious about from a computing point of view the widespread migration to containers looks as likely a bet as I can see and when I talk to customers across our region and hear from my colleagues globally many companies are thinking about how they can move away or augment their existing infrastructure with containers so With that background and context why do containers matter at all? Why are they a big deal? Well From the pivotal team that I was part of previously and now at VM where we think of Infrastructure particularly in terms of five s's the things that when we talk to CTOs and CIOs These are the things that matter to them in terms of their technology capability, you know speed Can you go faster? Can you provide things faster to developers when you need them and when you look at things starting up in a container? Well, it can start up in in some second time sometimes only a few seconds Whereas virtual machines are still more like starting a traditional server often takes minutes to start them up then if we look at scale one of the Ideas that really caught on as public cloud started to become widespread Was this idea of having auto scaling applications rather than Provisioning for your peak load you provision for a lower base load But then you have the application respond to demand and add more compute infrastructure to handle that load as you go and So Kubernetes and containers allow ops teams to easily auto scale Apps that have been written to take advantage of that Whereas with virtual machines auto scaling was something that came later and there's still a lot of traditional installations of virtual machines and Traditional applications running on those virtual machine farms that don't have that capability yet And so, you know if we're keeping score We really we really score speed and scale on the side of Kubernetes and containers now stability what do containers give us with stability well Kubernetes has self-healing built in as a core component It has these control loops that if you expect two containers to be running for your deployment or pods in Kubernetes language It will always make sure you've got two running if one of them dies If the underlying node that your pod is running on disappears It will try and schedule another pod to replace it and this is just a built-in first-order Characteristic of Kubernetes that you get self-healing baked in now These capabilities are really powerful, but they're also quite new and they take some new skills from people So there is a tinge of caution to this whereas we look at virtual machines and these have evolved over the last 20 years to be really tried and true and you know capabilities like vMotion and Such like for high availability are you know multiple generations of upgrades and improvements having been applied to them and they work really well the interesting thing about that is though that that often requires manual intervention to fail over To a different host not always but and it really depends on the operator the the ability to have Stability baked in is certainly there as a possibility But it's not guaranteed in the same way that self-healing is in a kubernetes cluster So, you know if I kind of score stability, I'd say I think eventually Kubernetes will surpass what's available on virtual machines But today certainly a lot more of the world's revenue generating mission critical applications are still running on virtual machines And so I would score that one a tie between Sort of the new world and virtual machines then if we look at sustainability or the ability to operate Well, Kubernetes because it deals with containers as it's going to first order Way of deploying applications You you need to use an infrastructure as code approach when you're deploying your application to kubernetes It needs that that docker file or equivalent there's going to be a yaml manifest of Essentially infrastructure code describing to kubernetes what you expect to have deployed, you know defining those infrastructure Objects getting them running. We hear a lot of people talking about get ops This is where no longer are you using a version control like get just to store in your software source code for your application But you're actually storing your infrastructure source code all of your kubernetes deployments and ingresses and pods And all of the other aspects of deploying it You're you're storing that in a version control like get and so you're actually making infrastructure changes by doing a poll request Or doing a version change in get which will automatically flow through to your infrastructure Well, if we think of that in comparison to the VM world VMs are often susceptible to you know configuration drift lots of manual activity when I was Working for you know a large financial services institution These were major concerns are the things running in production what we expect them to be and how do we know well Because you you can trace in kubernetes straight back to code I expect over time more and more people are going to go to this because of the The reduced capacity to have configuration drift and the reduction in requiring people to go in and do things manually We know that if manual tasks get done enough times eventually there will be mistakes in the past I think we maybe took the view of blaming the operator and calling that human error I think a lot of teams are more enlightened these days and realize that it's actually the System we need to blame. It's actually the Allowance for manual activity in the first place that we need to eliminate Kubernetes has a lot of promise in helping us do this And so, you know if I look at sustainability or the ability to operate in a modern way I think containers and kubernetes are are winning in that column as well now security is an interesting one as we hit point five here the Isolation boundaries between virtual machines are really tried and true and have been tested over multiple generations and so the Isolation between running containers on a machine is just not the same level of security This is one of the things that's causing teams to have to run multiple clusters because even though you can set up a virtual cluster in kubernetes called a namespace You don't necessarily have the same guarantees of Full isolation and segregation between namespaces that you would between for example between different virtual machines running on VMware and vSphere So, you know really at this point there's a lot of work to do around the kubernetes and container space and security You know not Surmountable tasks, but I think if we're if we're scoring honestly here. I think VMs for Truly mission critical applications still win in the security baked in particularly around the isolation between virtual machines. Well You know, hopefully this gives you a bit of an overview of why containers and kubernetes are getting so much attention in the industry and You know, this brings me to kind of my first aspect of as you think about designing a container strategy or a kubernetes strategy Well, you know, what is it? Kubernetes has sprung up from an internal project at Google which was then open sourced and this really represents the way Google ran infrastructure for a number of years internally and By open sourcing it a vibrant open source community has sprung up around this project And so because it's owned by the whole community People feel comfortable in using it because they don't feel they're going to be locked into a single vendor We've also seen a Number of other competing container scheduling competitors like mesosphere Docker themselves They've all essentially given up and have now admitted that kubernetes is is the winner in this space And they're all supporting kubernetes to some extent or another We're quite confident that kubernetes is the future of infrastructure as a way to schedule workloads and for some of the benefits We just talked about on the previous slide. We think it's You know the argument over which container scheduler is going to win we think is over and we think that kubernetes is the The future direction of containers and container scheduling so So onto our second aspect, you know containers is a platform and as I share these aspects one of the Things I want to do is also share some further reading material you can go have a look at That I think explains it in much more detail in depth than I can do in a 20 minute talk So one of the interesting aspects is that kubernetes Is an API now Why are platforms important? Why are API is important if you want to understand the impact they can have on your organization I recommend you have a look at this book called accelerate by dr. Nicole fore's grand jazz humble and gene kim three of the Smartest folks in the industry when it comes to DevOps and new modern ways of working and in this book they go through Really extensive detail backed up with real real world data and metrics around how these new ways of working can help you build and scale a High-performing world-class technology organization So one of the things that come out of comes out of this research in this book is this idea of Four big metrics or a high-level scorecard on the way to Assess your teams performance and rather than these things being Technically related these really map back to your business And the capability of your business. So in a nutshell these are related to throughput and stability and so you really need both if you're operating a modern environment and Let's look at throughput for a moment if if you're The the accelerate book suggests two metrics to look at for throughput one is the frequency of changes to production So how often do you ship code to production and then you know How long does it take each change to production to go from the developer checking it in to being used by a customer in a production capacity? So, you know, how what's your lead time and then what's your frequency and You know, we've worked with teams that have gone for example from once a month deployments down to many times a day And the impact that has on their business can be profound But going fast is not enough on its own you must do that with safety and stability And so the stability side of the big four metrics is really around. What is your failure rate? How often when you change production, does it break something or do you have an interruption in service and then in those events which hopefully are rare How fast do you recover? What is your time to recover from a failure? And so put together these high-level metrics are actually things that your business will care about the non-technical people in your organization Well, actually go yes I'd like you to deploy a new value faster and I'd like it to take less time every time you do and I would really hope that as you deploy a new value for our customers that things break less and less and That in the rare event that it breaks that you recover quickly So I'm really sold on these big four metrics. I'd recommend them and I'd recommend this book for you to have a look at On this topic of DevOps a lot of people talk about DevOps wanting to adopt it And I'm convinced that DevOps or working together better if you like is really an output of some inputs you could rather focus on so You know DevOps is not something you can wave a magic wand and say we're all DevOps now Really what they dive into in the book is areas like effective use of cloud You know Continuous delivery. What do the specific practices of continuous delivery look like? Using infrastructure as code which pulls us back to Kubernetes and then cross-functional teams rather than having teams That are siloed and doing just one job you need teams that have an end-to-end view of how value gets delivered and so Kubernetes is Specifically architected in a way that I think it can help with all of these areas. So that takes us Nicely to our third aspect, you know in more traditional organizations There's usually a separate team for each different type of technology I Can remember in a large organization. I was working for we had a production incident and in order to solve it we spun up a Conference call bridge and we had to page 13 different team leaders in to help troubleshoot and figure out Where the the fault lay if you like what what part of the stack was not working? And that was siloed into 13 different teams and that's not particularly unusual when we go and look at you know traditional organizations still in industry and so if we just take compute storage networking and security as You know, you'll find these teams in most flyers or well Kubernetes if you're deploying an application You're going to be Choosing what compute you'd like you you know a Docker image You're going to be choosing what storage to use maybe a persistent volume and what flavor of persistent volume that is You're going to be making networking decisions around. Well, how am I going to control my ingress? What sort of overlay networking am I going to choose between my pods? You know Have I designed it so that? Am I going to use External load balancers am I going to use cloud load balancers? There's lots of networking decisions You need to make a Kubernetes and they're not all straightforward and then security. How am I going to decide how many clusters to have? How am I going to? Decide what namespaces to put things in there's there's a number of different aspects to security that you need to take in and Often all four of these areas and more come together in one single YAML manifest file for a deployment and so if You're still organized in a way where you need four separate teams to commit it to come together and write that file together you're going to struggle To to actually see the speed up and the moving fast that might be possible So, you know, I want to introduce the second book that I think you'll find interesting. This is a book called team topologies by two folks in the EU Matthew Skeleton and manual pay and this is probably the most impactful book I've read in the last one to two years and One of the highlights I want to share from the book is this idea of the reverse Conway maneuver now Conway's law Which you've probably heard of it's more It's more a social observation than a hard and fast law like, you know Newton's law of gravity or something like this, but it makes the observation that if we're designing software and We have a particular Organizational structure the software we design will most often reflect our organizational structure Now the example that often gets shared is that, you know, there was apparently a time when four Separate teams were asked to collaborate together and build a compiler and they came back with a four-pass compiler So that gives you an idea Kind of back to these siloed teams working on Kubernetes together is going to be a challenge and so the idea of the reverse Conway maneuver is if you Want a particular outcome with your software architecture and you want to build modern infrastructure and applications Consider actually changing your organization in advance maybe bringing people from these separate teams to work together in a new platform team do that in advance and then things like Building deployments and building YAML files together for Kubernetes will be much more straightforward So highly recommend this book. I think you'll find it really interesting and it was a great read But on top of that, you know, Kubernetes is Also best if you adopt some new ways of working So I want to introduce making work visible and this is by a woman named Domenica de Grandis I've had the pleasure of meeting her at a couple of conferences and she's really a world-class expert in modern ways of working and she goes through and talks about the traditional time feeds in organization things like unplanned work and repetitive work and so You know, we've already talked about how silos and Kubernetes don't mix well We've you know had a look at that But even if you bring the team together you're going to want to look at new ways of working and this kind of Brings us to this point of talking about why declarative work may be better than imperative and so Particularly in programming languages in the past We would often specify all the individual mechanics and directions of how to perform a task Whereas new declarative models say here is the end state that I'd like something to be Keep it that way. And so Kubernetes is really interesting in this regard because it uses a declarative model or at least it prefers that You can make some imperative commands But the the idea behind Kubernetes is that you're you're making declarative calls to an API and saying my deployment my Application in its running state should look this way. Please keep it that way. And so for that reason I'm excited about Kubernetes because I think it's going to be able to help you eliminate manual work It's going to help you eliminate repetitive toil in your teams And these are the things that make people enjoy their jobs less if if folks get to spend their time solving hard problems and Really having their minds Stretched and challenged Work tends to be more interesting and exciting if you're doing the same drudgery over and over again Just, you know, toil and work that doesn't really engage your mind Your your level of engagement your level of productivity tends to suffer over time So on top of the aspects we've looked at I I like this idea that as you're maybe adopting a new organizational Style or even structured that you also think of adopting some new ways of working And I think if you're looking in this direction This book here from Dominican to Grand is called making work visible is an excellent place to start So let's look at our fifth aspect which is really Is Kubernetes strategic in itself? Are you going to achieve business outcomes? Simply by adopting Kubernetes. I would argue no Why not? Well your customers likely won't or don't care that you're running Kubernetes They are Customers of your organization because of the value you add for them They may interact with that value through a mobile application through a website through a call center through in-person shops or branches, but They interact with you because of the value you add for them because of the products and services that they enjoy from you Not because of what's running in your data center Unless you're a data center company or a Kubernetes company selling Kubernetes itself and that's your product Kubernetes is probably not in itself a strategic outcome for your organization And so my colleague James Waters who's our 10 zoo CTO In Palo Alto he talks about this concept of the value line and you know above the value line are things in your organization that your customers Actually interact with see use care about below the value line are things that are not as important to the customer in terms of visibility But still very important to make sure that things above the value line actually work. So the strategic play around things like infrastructure and Things like Kubernetes even though Kubernetes is so important to improving the efficiency and the ability to deliver faster technology Better safe or happier It is not a strategic outcome on its own I would argue so because it won't differentiate you against your peers simply to be running Kubernetes My suggestion is you consider buying Kubernetes from a trusted partner rather than building it, you know At VMware, we're biased in that we would like you to come and have a conversation with us and buy it from us If you decide to and if you decide you want to build it We have some interesting consulting services as well, but this is not particularly a sales pitch This would be advice I'd give anyone in the industry whether they're our customer or not that I think building DIY Infrastructure stacks yourself the long-term costs of running it Away the upfront costs of buying a well-constructed curated platform From a trusted partner. So that kind of wraps up our our five aspects Let's let's look at some ways that you can get started by way of kind of wrapping this talk up You know, I would say you want to start small and iterate The days of big bang approaches where you say we're gonna spend a year building an all-singing all-dancing platform But no one's gonna get any value or any access to the platform for a year Don't do that see what you can build in a month get some feedback as you build from your developers and See what you can build an iterate on to build a working platform that's delivering value sooner And then as you look at your organization Consider seeding a small Kubernetes platform team. Maybe go read the team topologies book Have a few people in your organization read it and really look at the value that the world's best companies these days are getting from this idea of Platform engineering and bringing cross-functional people together from various parts of your technology organization and then I would say Read accelerate read dr. Forrest-Gren and her collaborators work and look at the big four metrics as your high-level scorecard If you agree that Kubernetes while it's really important to improving efficiency in your organization It's probably not a strategic outcome on its own It's not something that is going to differentiate you in the marketplace because you're running it Then go choose an enterprise partner who can help you get to running Meaningful apps in production faster and then the other thing I'd say is consider multi-cloud from day one cloud You know We think of now as everywhere from your data center to a public cloud All the way to the edge and with the emergence of 5g we think there's going to be a lot more interesting Applications that the huge bandwidth increase of 5g is going to run and there's going to be a lot more Applications that need to run and process data right at the edge Kubernetes has an interesting part to play there as well And so as I wrap up I want to leave you with This quote from someone I really look up to John smart and Deloitte and UK said if you want to do an agile transformation Don't focus on better value sooner safer and happier You will end up transforming to have agility. So with that, I thank you very much Thanks to the organizers for inviting me and have a great day