 Andrew Block is going to talk to us about how we run communities in the enterprise He has a ton of experience with actual open shift customers and open and large corporations Running big Kubernetes clusters open shift clusters in real production settings He is one of our lead consultants one of our top gurus here at Red Hat and I'm very excited happen have them here So there's Andrew. How you doing Andrew? Hey, bro. How's it going? Oh, very good. Very good We've totally killed crowdcast today. I can tell you information about hey It's not working just kind of ignore that we're running through as much as possible and getting these things recorded But feel free to share your screen and get going Half the battle is figuring out where the share button is. Yes. It's above your head actually there it is All right one second. We'll go ahead and do that. Can you see my screen? There it is. All right, we see it great All right So today's topic we're gonna talk about Kubernetes in the enterprise as you know being able to deploy Kubernetes anywhere Is very easy whether it be on your laptop whether it be on a server you have out in the cloud It's easy, but when you want to deploy it in the enterprise Things change things change quite a bit. So first of all, let me talk. Let me tell you about myself My name is Andrew block. I'm a distinguished architect at Red Hat I've been working in the Kubernetes space for probably about five years about five and a half years before was even Kubernetes 1.0 I've been a specialized in containers and how technologies Automation and integration as Burr already alluded to I've have experience with a lot of customers from the small little guys to some of the Fortune 5 customers as well as being able to design Patterns and distributed systems and that's really one of the things that I emphasize on and one of the things that I also Like to do is I like to write and teach and as part of this year I was able to get a book out there on helm helm as a package manager for Kubernetes and If you're interested in helm and being able to deploy applications in a package way on Kubernetes take a look at that as well You can reach out to me on Twitter and we'll probably get to that lit near the end of the topic So first and foremost why Kubernetes? Well from our discussions thus far this morning Hopefully you understand the benefits of Kubernetes everything from containers micro services in the ability to Atomically package your applications into an atomic unit being able to manage them at scale And that's what Kubernetes provides you believe when I mentioned scale to burst out You know Paul just talked about you know being able to burst out and manage all those different components It's a good the ability to scale off these these different microservices at different different cadence and it's popular We've had a lot of conferences recently Cube kind North America or private cube kind Europe like all the virtual so it feels like North America to me where I'm based out of But as you know, Kubernetes is incredibly popular one of the biggest and most popular open-source projects out there today, so When you want to go ahead and deploy Kubernetes Have you thought about a number of different factors everything from security storage monitoring metrics logging the user experience and Compliance these are the things that you need to know When you need to deploy in an enterprise scenario, I can go ahead and spin something up You know will you nearly on my laptop? It's great, but when you want to deploy Kubernetes in the enterprise What does it really look like and how do you actually accomplish it? And from an enterprise standpoint and you want to bring Kubernetes in how do you have your organization adopted successfully? So it really is a brave new world, you know if you know as a developer, you know by trade myself I've been working with containers probably for almost, you know, seven eight years right now and It's not new to me, but for a lot of organizations Containers are brand new to them. It's a disruptor. I've continued to call containers the Napster of the 21st century How long does it take you to get a new server provisioned in your environment in an enterprise environment? It can sometimes take one to three months on a container. I can go ahead and spin up a You know postgres database and be able to access it and you know spin up a corpus application talk to it and be able to do That all within seconds If I want to get a full VM stood up in these enterprise environments. That's hard. That's really hard It takes a long amount of time What you need to understand is this is complex for a lot of organizations And that's where containers are a disruptor because it really transforms how Organizations see applications in infrastructure now Kubernetes has a lot of patterns. It has a lot of good things But the problem is we basically have to jam all the great things about Kubernetes Into an enterprise scenario at times. It's like putting the square peg into the round hole And that's what we're going to talk through today is how do we actually succeed in applying these patterns at enterprise scale and The first one that I see and a lot of my customers see is security and There are three areas of security. I want to talk about in the Kubernetes ecosystem Any organization that brings in a new software component, whether it be Kubernetes whether it be really any pizza software They want to understand a few key points. What is the support? Who's supporting? Is it gonna be my app team? Is it gonna be an organization like Red Hat or some other third-party vendor? Are there any compliance regulations around it? Does it comply with certain standards like HIPAA if you're in North America and in the healthcare scenario? If you're in the Department of Defense, you know in the military Is there any security you need to handle that and then the third one is Vulnerability assessments is the software that's coming with the solution Is it meeting any regular regulation standards and has there been any Vulnerability assessments that have been made against it organizations want a full list of this before you even get in the door Now Unfortunately with the cloud native landscape. It's a lot of technologies not only do you have kubernetes? There's a lot of technologies that are underneath kubernetes everything from at CD Which is the database behind kubernetes if you have logging and monitoring you might have Grafana and Prometheus for your monitoring stack every single one of these technologies has to be assessed by an organization Everything from as I mentioned from the three pillars that I mentioned on the slide before Compliance security everything so really it's understanding exactly what technologies you want to bring in toward an organization They all sound great, but how many do you really need? It's really whittling down these different technologies into only the ones that you want and engaging with your customers engaging with your With who your key stakeholders in this initiative will help you understand and curate exactly What resources you need and what solutions you want to bring in? So what are some of the top concerns that do come to mind everything from your containers? The kubernetes control plane what access and controls you need to be worried about? What type of certificates do you need to implement as part of your solution for to make it be secure? Are there any networking constraints? There's a lot of networking with kubernetes So there's different components that talk to each other in a distributed fashion and then storage I'll have a slide later on it talks about storage, but a lot of people don't think about storage in the kubernetes world it still exists. I promise The number one thing I will suggest is you engage your security team first and foremost otherwise You may have grand aspirations for this great system You may even go ahead and start poc'ing and building it But when you go ahead and actually want to implement it you always Always have to get approval from your security team I have been in many large organizations Who have built great things will make a customer the company and the customer a lot of money And we had to delay by six months because security wasn't brought in And we and they didn't sign off and we had to go through all the different security security controls, etc And it slowed the project down. It had them know there was some money lost But they were able to deploy it But it was a lessons learned that we needed to engage security ahead of time When we could have gotten across a lot of all these problems and this collaboration between security development Operations it really enables and encourages the concept of dev sub ops The ability to for security to be in this entire process of dev ops Oh, we hear about dev ops a lot, but we don't necessarily bring security in until after the fact If we bring them in ahead of time it will reduce the amount of burden that we'll have down the road Now the platform itself Kubernetes is great. You go to conferences and you see all these different organizations They talk about the great things they did with kubernetes It doesn't necessarily come fully packaged you have to add to it kubernetes is a great control plane It helps you schedule applications in management scale But from an organization there's a lot of different components that you need to consider And it's up to your administrators your consumers everyone to understand exactly what components you want in your enterprise This is everything from logging Application monitoring alerting if you want to build your applications How do you tie in your continuous integration and continuous delivery systems a lot of organizations already have that built out How will that be integrated into kubernetes? Are you going to switch over and take a hand existing system like jankins and move to a more cloud native pipeline system Like leveraging tecton. How are you going to handle your secure values? Are you going to uh leverage a vault of some sort to be able to handle it in a secure way? And one of the benefits about kubernetes being so popular is a lot of the existing enterprise solutions that organizations already have in place Now have support for kubernetes talk to your isv vendors and see what your options are You don't have to always reinvent the wheel talk to your partners and actually try to Have them bring more to the table because they may have fully baited in solutions that you can basically just turn on And number one thing I will emphasize is As to allude to what I just mentioned with other organizations other vendors may already have the solutions that you're already implementing Don't build your own You may think that oh, I have this perfect use case. It's going to be great In the end it's going to be more of a burden because you may only have one or two developers Who are working on this and they have the tribal knowledge What happens if they decide to move to a different group within the organization or haven't forbid leave the organization? You then have to train up your team to be able to have them succeed successfully And if you look at other solutions, whether it be from a vendor or in the enterprise as a large Go ahead and leverage that because I've seen many many times that these initiatives have failed because of that The next thing to think about is image management Containers are the bread and butter of any type of Kubernetes deployment Think about the different components of your image life cycle everything from first your image composition Where is your base image coming from? Only certain types of images are going to be allowed within an organization Whether it be a you know, a red hat image, whether it be a ubuntu image Whether it be ones that have certain capabilities in them understand what your base image is going to be Next is your image sources. Where are the images coming from? Are they going to mean most organizations I work with they block docker hub docker hub has Over 75 of the images out there have at least some form of vulnerabilities So most most organizations will not allow direct import from docker hub Understanding where your images are coming from and then working with your compliance team to understand how to obtain them And then where are you storing your images within your organization? You're going to produce images as part of your is part of your organization Where they're going to be stored because typically you can't Push them to docker hubs or some public repository They need to be brought in and stored internally to understanding where that's going to be So in an organizational standpoint, what are some best practices to achieve? First of all, it's your import pipeline if you need to obtain an image from an external source How are you going to get it into your organization? As I mentioned, you typically have those external registries blocked You need to provide a common path for not only your operations team But your development team and other groups within your organization to be able to get those images into your organization and then internally Building this set of base images for your development teams being able to ensure that They can go ahead and know what images they can quickly pick up They know that they're validated secure and approved by the organization And they're up to date so they can go ahead and build their solutions on top of them Now certificates now we think now kubernetes itself makes extensive use of public key infrastructure Most organizations have their own certificate authority You're not going to be able to go to use like a less encrypt certificates Or some other public, you know go daddy's And if we get just what are two examples that you can use one, uh Sorry about that seems like I lost my my presentation one second Yeah, you can get the screen back up All right, we'll get back up here. All right. There we go Most organizations have their own on ca Being able to integrate that into your Organizational process for how do we bring these certificates into the platform? So your apis for kubernetes and other other like consoles can leverage the ca from your organization Working with your ca team if you have one or even using an operator type methodology to be able to talk with your If your ca happens to expose a api Being able to integrate with that to automate the process of getting signage certificates for not only your platform But your application resources Networking is important networking organizations have You think a being of a kubernetes itself is complex an organizational network is complex someone's like a web of Of wires all over the place and different network boundaries Understanding how your kubernetes infrastructure will play into it is important and then understanding what ingress and egress traffic You need to handle will ensure that you're able to not only communicate with services in kubernetes But talk to services from kubernetes to an external source and one of the things that I will always say is that I when it comes to networking and especially talking within your enterprise It's always the proxy a proxy firewall server will always get in the way in some form or another Whether it being able to talk between services or being able to talk to external services within an organization Or even externally with outside the organization You typically have to handle being able to talk to these different services and traverse through some form of firewall proxy between different layers of your network And finally the final platform concern that I will talk about is storage It is what I call the fallacy of microservices everyone says. Oh, you don't need storage for microservices In the enterprise scenario you 100 will need storage Everything from the platform needs storage To your applications being able to integrate with different parts of your organizational storage needs whether it be storage It's already in existence or using kubernetes as a way to bring in new storage patterns and new storage technologies into your organization Maybe you don't have object storage now Maybe it's something you want to start leveraging because kubernetes and cloud native analogies like object store And the biggest hurdle you're going to you're definitely going to run into is the lift and shift applications the ones that have been running on servers or Heaven forbid on the mainframe for all these years bringing them into kubernetes or having to integrate with systems That are still living in these legacy systems. I know I have systems running on kubernetes that talk to mainframes They do exist Yeah, you need to think about that when you start playing and then finally defend the platform Always ensure that there's always going to be a bad actor whether it be You know someone from within the organization or someone trying to get into your system understanding employing the principle of least privilege give people the least amount of privilege first and then Start opening them up as you need to ensure there's for various forms of auditing So you know what api calls are occurring and when things change Using tools like open policy agent or gatekeeper can help Employ these different policies and reject malicious actions on the fly And then being able to integrate with different systems that are already within the organization And being able to already leverage these different components will allow you to get up to speed even faster So Myself i'm a developer by heart. I love development It's why i've been working with burr and his team for all these different years And obviously thank him for being able to share my my vision and experiences with you. Let's talk about the developer experience So i'm going to be a developer by heart kubernetes is great. I found this wonderful example application out out there I want to go ahead and deploy it to my enterprise kubernetes cluster to get started. This is going to be great And then I realized all the hurdles that I will run into first one's going to be I won't be able to create cluster level resources. I won't be able to create custom resource definitions I'm not going to be able to create daemon sets. I'm not going to be able to do a lot of things A lot of times the examples that I see on the internet on the web Are going to be from public repositories and images won't be able to obtain those if I need to do builds that need to talk to npm sources for node applications or maven central for maven artifacts I won't be able to get those dependencies And then if I need to have these applications actually talk to external systems during runtime It's not happening either by default It is painful then You need to think about okay. Once I go ahead and I understand kubernetes. I do get something deployed How do I do local development on my on my enterprise provided laptop? Most organizations have everything locked down Everything from packages that come on on the system command line tools like the cube control OOC for open ship helm, etc. Those aren't going to be available that I can just install How do I go ahead and run kubernetes locally on my machine? You know most of the time those are going to be run in a hypervisor Those aren't typically enabled by default And then how do I actually get a container runtime to run everything from docker pod man Then finally, how do I handle the actual development itself everything from the integrated development experience to the tooling? Everything needs to be thought of in an enterprise scenario So if you're looking to develop or encourage development and enterprise scale understanding how to enable developer productivity Let me know putting software that you need in an enterprise repository Making sure there's proper documentation and automation so your teams can easily get up to speed And then as well as investigating new development methodologies Maybe I don't want to develop on my local machine. Maybe I want to develop in a cloud-based IDE Look at red hat code ready workspaces different options for your organization to start thinking about And then from a development standpoint, you're going to be introduced to a lot of different terms You have now in enterprise Everyone may not be up to speed on kubernetes primitives Everything from replicas limit ranges and quotas auto scaling scheduling options A lot of this is foreign concepts to them Understanding this at a foundational level and then providing documentation training material Is going to make the development experience a lot easier as well as providing example applications for your development teams to get started Will allow your developers and your application to succeed in a kubernetes environment And then finally we talked about the platform. We talked about development Now we need to talk about the organization. We talked about these two different pieces First of all All these different teams whether it be development to operations They're in new new territory Developers have new languages and frameworks to worry about They now need to worry about infrastructure before they didn't necessarily have to worry about infrastructure They kind of a lot of times threw it over the wall to them once they checked their code in The the dev ops team or at least the ones that was able to get c i c d They were able to ensure the package the code was packaged and then threw it over again to the operations team That actually put it into production now with kubernetes We have a co-lessons of these different teams, which is great But it's very hard for organizations to under to actually start to actually make that possible Because you have a lot of different opinions and a lot of different people who are getting outside the comfort zone It's that full stack ownership like from operations team I can't tell you how many operations folks i've worked with in large enterprise scenarios That have been working on mainframes their entire lives or been working with just typical VMs or bare metal servers Having them understand that a container can last seconds is just mind blowing to them They're used to having machines available for the year. They do uptime on the machine. They feel proud about that With microservices and serverless your container may only last a second and gets spun down in seconds I mean, it's a completely different methodology for them So it's new rules and responsibilities that you need to introduce within the organization. This goes beyond the actual code itself And unfortunately a lot of times as you work through bringing kubernetes into the organization The organizational practices and processes do get exposed I don't know how many times i've been brought into an organization. They said Dan new kubernetes you went ahead. It's all your fault because you went ahead and uncovered Processes because you know we went through the security and compliance regulation standpoint They were going ahead and signing things off and they talked about okay. How do I get certificates now? Oh We just go ahead and we generated ourselves. Aren't you supposed to go through a team get that And then all these different things and these side steps and kind of back doors that are existing in the organization do get exposed so being able to understand and work with these different Groups ahead of time and talking about what you need Will help the mitigate any of the unforeseen An unflattering practices that come down the road And then kubernetes itself honestly is a marketing It's a marketing campaign Being able to understand and actually get buy-in from everyone is difficult You may have a lot of people on your on your dev ops team or in your kubernetes team Who are really adopting kubernetes who may think it's the greatest thing since sliced bread At an enterprise level all the way up to the sea level. They may not see it that way They may see it as unnecessary risk to bring in this new platform They may have had this platform has been running stable great for all these years. What does kubernetes provide? Well, obviously it provides a lot but from an organizational standpoint It's actually having them understand the benefits of it and especially on kubernetes It's usually brought in by an infrastructure team or you maybe even a smaller niche team in a large Multi region multi sideload organization It can just get lost and among all of that and then make the platform approachable Making sure that you make the experience a great experience because if kubernetes is easy What stops another team in a large organization from spinning up their own kubernetes cluster themselves? and then being able to To failure to manage all of these concepts and paradigms can eventually lead to Failure if all of these things are not managed properly And that's all and i'm actually sensing kubernetes implementations fail The organization just what either wasn't ready didn't understand it or they just didn't get it It's frustrating for a technologist like myself to see all the benefits kubernetes can provide to see it fail So making sure you market it properly will ensure that it's going to be successful And doing that is really building that community within everything from your documentation Having documentation that your organization can take on Having enablement sessions working with the different teams having lunch and learn brown bags, etc Obviously we're a lot of times more in a more remote setting right now But as we start to augment to the new world and we start to Obviously start bringing people back into the office slowly as things start to mitigate Being able to have these either in person or distributed ways of learning is incredibly important to understanding because it's your teams Inputs that make the platform successful and then understanding and adopting that open communication Working with the community working with your team within your organization I can go in and say all the best practices that I can that works with all these different organizations across the globe But if it doesn't work for your organization that i'm working with and you're in It doesn't mean anything It's having the input from those everyone in the community Around the kubernetes platform everyone from operations to development will make it ultimately even more successful And finally it doesn't end there kubernetes itself is a journey Plan ahead if you intend to implement kubernetes. Don't just go ahead and throw it in and say, okay It's ready to go and then go ahead and roll it out Make sure you have a plan of attack for actually adopting and implementing kubernetes at scale with an organization Now if you're an organization that i've been working in You will know some of the pitfalls and the paradigms that that are common with your organization Try to augment them into kubernetes and have them be applied And then and remember every organization is at a different point in their journey not everyone is going to be netflix I mean if you try to become netflix on day one, you're going to fail it's it's it's plain and simple Understand where you are in your organizational journey and assess what success means If success means going in and deploying an application once a week Great if it's deploying once a quarter versus instead of once a year even better It's being out and then slowly iterate And improve upon okay, maybe I deploy every six months. Maybe I'll deploy every every month now And maybe every week, you know three four months down the road Maybe I can get to continuous integration continuous delivery and then ultimately work up to maybe I feel confident with my testing and automation I can go ahead and move to continuous deployment. It's really understanding and and seeing how to go to the next level It's like a big mountain get to the top And then you'll be able to achieve exactly what you want through kubernetes I want to thank you for the time this morning berg. Thanks for inviting me out here Thanks for being able to share some of my Experiences working with the enterprise enterprise in kubernetes is where my life is I love being able to show the benefits at kubernetes at scale to these large organizations and For all of you who are in an organization that is large or small I'm definitely want to get some I'm sure everyone here in the community would love to hear your input about your experiences implementing kubernetes in your own enterprise And your own organization. So let's get the conversation going today. Thanks everyone Hey, andrew. Thank you so much for that And so we actually have a couple questions for you because we have a few minutes left You actually gave us a little bit of time for a couple questions. So you're ready Perfect. I'm actually ready. Go ahead. Yeah. Yeah. All right. So one question about microservices. There's a question from Guillermo, he was what he was like. Well, how do I deal with my microservices? Where are some best practices strategies thoughts tips techniques for microservices, but running them on open shift in kubernetes? What are your thoughts there? The first one is going ahead and starting small as you know When you start breaking up applications into microservices Seeing how one application works and then seeing how we can distribute it out into different services Let's say you have a big monolith where you have your application broken, you know All in one whether it be your front end in a backend database all on one microservice and one monolith Going ahead and deploying it into an more of a lift and shift and then start breaking it up slowly in an iterative fashion Especially in enterprise, they like to see success in any form or another So whether it be just getting something deployed great Going ahead and then seeing how you can then break it up using certain models like domain driven developments in domain driven design Seeing where you can have those specific breaking points is key