Martez Reed and Bruno Andrade of Shipa talk about Kubernetes, virtualization, and how to avoid vendor lock-in.
I had virtualization… Then you gave me Kubernetes on top of virtualization. I thought Kubernetes was supposed to be the answer, and now you’re telling me it’s not the answer and I need something else on top of Kubernetes?! The conundrum is solved on this episode of Pulling the Strings with Martez Reed and Bruno Andrade.
Learn More
Demetrisu Malbrough [00:00:19] Hey, everyone, thanks for joining this episode of Pulling the Strings podcast powered by Puppet. I'm delighted to be your host and my name is Demetrius Malbrough and I'm on the product marketing team here at Puppet. And today I'm really excited to introduce my special co-host for today, Martez Reed. Martez is a principal field solutions developer here at Puppet, and he's focused on the creation of technical education content. And today we have Bruno Andrade on. Bruno is the CEO and founder of Shipa. He has led distributed systems design and implementation at enterprises across different industries, defining methodologies, concepts and architecture, and has dedicated the last few years to working on the cloud native space, helping companies through a successful journey. So Martez, go ahead and take it away. I'll let you jump in and lead the questions.
Martez Reed [00:01:24] Thanks, Demitrius. So on today's episode, we're going to talk about a lot of interesting things. Probably one of the most interesting things in the space today is, is Kubernetes. So Bruno, kind of a kind of one of the first questions is what is Kubernetes? I mean, there's a lot of information and thoughts about Kubernetes, but especially for those that are still still relatively new to Kubernetes. What is Kubernetes?
Bruno Andrade [00:01:47] You know, I think that's a great point. And first of all, thanks for having me on the podcast. And when you look at Kubernetes, even though Kubernetes is beem available for a few years now, most of the enterprises they there are just starting to look at Kubernetes now, either implementing or maybe they have some footprint and they're looking at scaling. But when you look at Kubernetes, Kubernetes is basically an extensible open source platform for managing your containerized workloads and services. And it's very much driven by declarative configuration that helps you to automate your environment. So organizations are basically leveraging Kubernetes for managing your containerized applications that you're deploying today.
Martez Reed [00:02:33] Yeah. So actually kind of two interesting words that I heard you say it was enterprise as well as open source. And obviously there's been a lot of interesting conversations going on about the enterprise adopting Kubernetes. What are your thoughts on enterprise organizations adopting Kubernetes and kind of the open source aspects of it?
Bruno Andrade [00:02:53] It is. It is definitely an increasing number and I think this number is just going to grow over 2021. Now, with the New Year. Micro services is just something that organizations are moving towards right now. Kubernetes is not is definitely not the silver bullet, it won't solve all the problems. But for applications that are going towards the microservice architecture, many organizations are looking right now and are probably the ones that are not there yet. There are probably going to start looking at Kubernetes as a way for them to have a reliable way of managing these new workloads that they are deploying.
Martez Reed [00:03:28] Yeah. So interestingly enough, one of the other things you brought up is MICRA services. That's another interesting word that the industry has been hearing a whole lot. What actually are micro services?
Bruno Andrade [00:03:41] That's an interesting question. And when you look at the way most most teams are building architecture and applications today, they are either going to monolith way, which is the way we've been doing for a few years, basically bringing up your infrastructure, your virtual machine and all your application code is inside that one virtual machine. This is basically the way we've been building it for years now. And when you look at microservices, many organizations, they started looking at microservices as a way to break down your application. And the reason for breaking down your application is to make it easier for maintenance and scalability and healing, for example. And one example I can give is when you look at an ecommerce application, for example, when you think about it in the monolith architecture, the e-commerce application is going to be hosted all inside that one single virtual machine. So you have your front end application code, you have your backend application code for processing payments, maybe your shopping cart and so on. So it all lives inside that one single virtual machine or server. When you look at that same e-commerce application, but in a microservice architecture, you start breaking down where your front end, basically, your website, is one single application running. your payment processing is another application running, your app, maybe your shopping cart is another application. So when it's time for maintenance, it doesn't affect all the other applications. You can perform maintenance just on the website. And this won't affect the backend. It won't affect the payment processing. And when there is need for scalability, let's say there's too many payments being processed at the same time, you can scale just the payment application without scaling the others. So it limits costs and resources utilization. It becomes more intelligent. So that's the difference when you start looking at a microservice architecture type of application.
Martez Reed [00:05:36] So basically a kind of decoupling of the various components and aspects, which makes a lot of sense, especially like the public cloud capabilities, as well as what Kubernetes has been able to provide us. Kind of one of the really interesting questions is like, you know, in technology, we go through these ebbs and flows of different things and kind of has been termed the hype cycle. And so my question becomes, what makes us think Kubernetes isn't just the fad, like big data or any of the the blockchains or sort of a lot of the things we've seen that kind of get a lot of buzz and a lot of hype initially and kind of seem to fade away.
Bruno Andrade [00:06:17] That's a very good point. And you're right that many technologies that we've seen in the past, they came, they stayed for a few years and they just disappeared. I think Kubernetes is pretty much changing the way you deploy and manage your applications. I think the key aspect is not to look at Kubernetes, as I mentioned, as a silver bullet that is going to solve all your problems and you are going to try to fit all your applications there; because, if you start doing so, many other applications and many of the things that you're trying to do, they are going to fail and then you're just going to roll back to your old architecture that you have. So I think the key thing is now Kubernetes is being maintained by a large group today. So that's a key difference. You see many organizations involved, such as Google, RedHat, Microsoft, and so you have very large organizations involved with Kubernetes as a project and helping develop and keep Kubernetes. I think it will be key for our users this year to know how to use Kubernetes intelligently. Now, one of the key challenges that people talk extensively about Kubernetes is basically the complexity of implementing and maintaining Kubernetes itself. So there is a lot of focus when it comes to managing the Kubernetes infrastructure cluster and objects. And I believe the more we move towards an automated way that allows us to finally focus on the application, which is basically where Kubernetes has started, this will allow Kubernetes to continue being a key technology instead of fading away because people don't know how to deal with it. So I think that's and there are many learning curves, many learnings that we took from other platforms and other technologies that didn't progress. I think over time, Kubernetes will take a backseat. It will become like your hypervisor, you know it's there, but you don't really care about it. You're deploying your application and focus on the application code. So I think that's what's going to happen with Kubernetes over time as well.
Martez Reed [00:08:13] Yeah, that makes total sense. And it is kind of definitely what we've seen in the past and kind of along those lines. My question, I know you talked about complexity and kind of managing Kubernetes. I know there's been a really big push, especially from cloud providers, to provide like managed Kubernetes, what is managed Kubernetes?
Bruno Andrade [00:08:34] That's a great point. Managed Kubernetes are the offerings that you were seeing coming from many of the cloud providers, such as Google, as Azure, Oracle and others. They understand the importance of Kubernetes. They understand how many organizations and what I call cloud scale companies are leveraging Kubernetes. But they also understand the complexity on the amount of work that it takes for your team to learn and maintain and create clusters and so on. And that was the first wave. So what they are doing now, they're basically offering you Kubernetes already preinstalled so it can easily go on your cloud provider and spin up a Kubernetes cluster with as many nodes you would like and the distributed nodes across multiple regions. So you have high availability and so on. So all the work that you had to do to install and maintain the Kubernetes related infrastructure in scalability that is reconfigured and offered by your cloud provider. So that saves a lot of your time when it comes to infrastructure management. So you see the focus more and more on let's get the focus on the application, rather on the cluster. So that's what the cloud providers are trying to help you do today with their managed offerings.
Martez Reed [00:09:45] Yeah, I mean, it definitely seems like a great option for those that really don't want to have the day to day management of Kubernetes. I think as most organizations battle with, is there a way to avoid vendor lock in, if I say, you know, I want to go with EKS or 8KS or any of these other managed Kubernetes.
Bruno Andrade [00:10:06] That is a great question, because we've been seeing many organizations using different clusters and different flavors. Like I mentioned, some applications have been deployed on 8KS at the same time, some of the other applications are being deployed on Oracle Kubernetes, for example, if you'd like. The initial goal of Kubernetes was to give you that application portability, right. But when you start looking at a way to consume the managed services, many times the managed services offerings are not exactly the same across cloud providers. So you have to keep an eye on that, such as when you're consuming storage or maybe when you're consuming network from Kubernetes. The way you build your applications, they are built to consume the services offered by your cloud providers. So many times the offerings are not exactly the same across cloud providers. So if portability is key for you, is key for your deployment, managing your applications, that is definitely something to keep an eye on. And at the end of the day, managed services are great. But sometimes we have been seeing organizations actually installing and still managing their Kubernetes, when you need to have full control of the infrastructure and small parameters and managing how Kubernetes run. We still see a lot of organizations doing that. But if you are going down the path of the managed services, which is great to get you started, but you need portability, keep an eye on the services and keep an eye on how you build your application and the dependency on those offerings because they are not always completely portable between clusters and cloud.
Martez Reed [00:11:37] Yeah, and that's the kind of the challenge we've obviously traditionally dealt with. Whether you pick certain vendors or a certain product, it is kind of being beholden to kind of the way that that's developed and the way it's architected. I know you mentioned a couple of times kind of along the lines of helping sort of Kubernetes disappear and really help focus on applications in terms of developers really concerned about getting their code pushed out and don't really care so much about how it's done or where it lives. How can we actually start to see that with Kubernetes? Because I know a lot of the challenge with Kubernetes now is like I have to understand what ingresses are and deployments and things like replica sets. And honestly, that kind of feels like a lot and has a lot of complexity that I may not want to dig into. How can I help to try to avoid some of that?
Bruno Andrade [00:12:32] That's a great point. And the first wave that we saw when it comes to Kubernetes was let's help you get Kubernetes installed. Right. And we saw many start ups and many vendors basically starting businesses around it, on how to get Kubernetes installed, operated and maybe upgraded. And then we started a team to manage services from the cloud, from the cloud providers. But now what people are realizing now that they understand Kubernetes, most of the organizations, they have maybe a few applications running, now that they feel good about it, they understand on how to consume it. Now comes the time to scale applications. And we've seen many organizations across different industries, especially mid to large organizations, when it comes to deploying dozens or hundreds of services, it becomes a challenge because we've seen a lot of frustration when it comes from the developer side where, as you mentioned, they have to understand what an ingress controller is, what type of deployment sets you can use with Kubernetes, and that takes the focus away from the application code itself. And we've seen organizations with basically hundreds of developers being frustrated about it and what they do to try and solve that problem, they've been trying to scale the operations team, and at the same time, now the operations, they now there's the blurring line between the developers and the operations, because the operations, they have to understand how code is deployed and how infrastructure behaves and all the different components around it and keeping control and security and guardrails around it becomes really challenging because Kubernetes, when it comes to infrastructure, is very object centric. As an example, when you deploy an application, a single app can go up to about a dozen objects. So now imagine if you're deploying hundreds of applications or services, it becomes a big nightmare. So I think that's where organizations are today. And the way at least we see that here internally here at Shipa is, the way for you to start solving that problem and looking at it, is to start thinking about an application layer framework instead of Kubernetes. Again, leverage Kubernetes for what? It's great, right? But start focusing on how you deploy applications independently of the cluster version that you have underneath. And from a control perspective, how do you keep control at an application level rather than object? So you start freeing up the developer to focus on the application itself. It doesn't really matter if it's 8KS, EKS, version one 117 or 120 that's coming up, but it's just my application code. And at the same time, from an ops perspective, I'm enforcing controls and guardrails and security, at that application layer rather than a bunch of objects that I'm trying to control. So that's I think, where we should start going to see large scale adoption of Kubernetes and not have it as a fad like we've spoken before.
Martez Reed [00:15:12] Yeah, definitely. And that's the challenge I think people are dealing with, whether it's like the sort of the advent of Helme where you're trying to provide some of that abstraction and making things a little bit simpler. But obviously, Helme has a number of challenges itself and a lot of new constructs and concepts that it introduces. And I know you guys have been doing a lot of really interesting work at Shipa. I think for me, as someone who's coming really into the space and really trying to understand more the low level aspects of Kubernetes, I'm interested in kind of the how Shipa works. Like I know Kubernetes you've got the YAML files and Helm, you've got more YAML files that are templatized, had does Shipa work in relation to that?
Bruno Andrade [00:16:00] That's a good question. And you were right. You have components that can try to help you, such as Helm, or maybe Kustomize another one that we see users leveraging today. But when you look at these components, even though they help you, you still have to know a lot about not only how to build Helm, but also the individual objects that your applications are going to consume. So the way we see Helm, it's just the way for you to package those objects and deploy these objects. Right. But it's very object and infrastructure oriented rather than the application itself. And the other problem that we see users having is once they deploy, either using Helm or Kustomize, for example, is once it's deployed, it's deployed. And then you have to live with the bunch of objects that it applies in your cluster and monitoring and managing the lifecycle post deployment is the issue that is still there for both the developer and the operations on the post deployment piece. So when we started thinking about Shipa, is we started implementing the base and saying, well, how can we allow the developer to deploy their applications without knowing there is even Kubernetes in there? Right. They don't need to build Helm charts, they don't need to build Kustomize. They don't need to know the API version of the cluster that is running, they could actually care less if it's running Kubernetes. How do we get the application developer to focus just on their application code? And the second one was, how do we allow the operating or the ops team to actually build controls and guardrails in a way that when they give access to the developers, they're not giving access to Kubernetes directly, which is not the best interface for developers, but giving access to a way to deploy their applications. But at the same time, me as an operator, I'm defining rules such as security, such as resource consumption and others independently from Kubernetes. So every time applications are deployed, applications automatically go through that cycle of security enforcement. Third party services connection is another, not depending on Kubernetes whatsoever. So you can move pieces around. So that's where we started with Shipa. And that's the journey we're going through and building that application layer that allows developers to focus on the application code and the operations to move more and more towards controls and governance, rather than gluing a bunch of things with YAML. So that's our focus on Shipa today.
Martez Reed [00:18:24] OK, yes. Sounds super interesting in terms of what it can do. I think my concern would be, is how does it work with Kubernetes versions or can I use it with Azure's Kubernetes? Can I use it with Google's Kubernetes or am I in my locked into one or two versions or types of Kubernetes that I can work with?
Bruno Andrade [00:18:44] That's an awesome point. And I say that because when and when you look at the PaaS, right, the platform as a service type of offerings, many of these platforms are dying now and people are migrating out of them. One option is we see one example sorry is we see a lot of people moving out of Heroku into Kubernetes because they don't want to have that lock down when it comes to the way you deploy your application, to the cloud provider you're using, to the third party services that you have access to. So when we started building Shipa from an architecture perspective, we didn't want to replicate what the other PaaS's are doing or OpenShift and others that are basically locking you into that. We focus on that applicaiton layer that, if tomorrow, because the organization is moving towards, let's say, Oracle Kubernetes, they can remove one of these clouds or clusters and add Oracle Kubernetes without impacting anything. So we built it in a way that you can plug into different clusters, the different versions, and you focus again on the controls rather than gluing and building a bunch of stuff around Kubernetes. Because I say your worst enemy is to get trapped into building things on top of a single cloud provider, right. Or building a new platform on top of Kubernetes. And we've seen organizations spending between one and two years doing that. And many of these, when we talk to them today, they want to get out of that business and focus just on the applications and control.
Martez Reed [00:20:20] Yeah, I mean, it's definitely one of the challenges that organizations will face as things become obviously much more distributed. And there's the sort of the idea of people actually needing to leverage multi cloud and various aspects. And I think the idea has been, well, if we containerize all of our applications and leverage Kubernetes, hopefully, that provides us the application portability that we would like. But I think a lot of organizations are seeing now that it's not as easy as just move the app to another Kubernetes cluster and there's challenge there. So I think there's definitely a real big value in what Shipa is providing. Kind of question would be is can I kick the tires on Shipa? How can I see if it's right for me or at least tinker with it?
Bruno Andrade [00:21:10] Yeah, no, for sure. Shipa is provided in two ways. You have the professional version which basically incldues support, network policies, security controls and everything that you could want when you're deploying and controlling the apps. But Shipa does have a free version that you can install on any cluster you have. You can install it on top of your Kubernetes and get started today on deploying, controlling these apps. And one thing that we're working towards right now is open sourcing more and more of Shipa components. One example is a project that we open sourced recently called Ketch that we actually got the deployment piece or component from Shipa and we open sourced that component. So if you want to also start, instead of even using the free version of Shipa, you want to use in open source component just to help you get started on deploying your applications on Kubernetes easily, you can also look at that component. So you have open source and you have a free version both available to you to kick the tires.
Martez Reed [00:22:17] Yeah, it definitely seems like the model of the industry is going with the sort of the open source version to kind of let you tinker and see what things can do and really gain benefit from it. I mean, and I think the next question I would have to kind of follow up with that would be I know there's a lot of open source tools and products out there. I mean, you look at the the CNCF landscape and it's kind of an eye chart. What are your thoughts on how Shipa is different from a lot of the other products or the other projects in the CNCF?
Bruno Andrade [00:22:51] Yeah, that's a good point. And when you look at CNCF, it's really even hard to see the logos because it's just so big and massive right now. But each of those components illustrated in the in this CNCF chart basically tackles a different problem. Right. And some of these may help you get your networking in place or some of these may help you get your storage in place and so on and so forth. So you are going to have to end up using some of these components, and of course, if you use a managed Kubernetes service, some of these components are already prepackaged in the offering. So you don't need to deal with them. But as you look towards the CNCF chart, many of these components are available to you to tackle different problems. When it comes to the Shipa side, we give you the flexibility to basically choose a different maybe network plugins or ingress controllers that you have available on Kubernetes or monitoring and so on. And Shipa plugs into that. So we allow you to basically get the best of breed or the best that would fit your application requirements. So we end up integrating with most of these components and help you keep them on their controller and application layer. So you have monitoring, you have security, you have policies and so on that an application. So we integrate with most of the components rather than competing and saying which one is best in that case when it comes to the CNCF chart.
Martez Reed [00:24:15] Yeah, and I know for me as a former ops person, I look at the chart and it can be a bit daunting. I'm curious your thoughts on how individuals in the industry can kind of level up their understanding of whether it's public cloud or Kubernetes or cloud native, all these various aspects?
Bruno Andrade [00:24:38] Yeah, so that a good point that you raise. My background, I'm an engineer and I spent many years also doing sysadmin before we had the pretty name of DevOps, SRE and all that stuff when we're all sysadmin and you used to deal with a bunch of stuff at the same time. Right. But one thing that we have as engineers and sysadmins, we have the curiosity to try many different things right. And we like building things on top of these different components. And while this is great, we see a lot of the teams around the different organizations building a lot of unnecessary complexity. And while this is this is great and really cool to build, I think when you start looking at which components to use and should I use a managed cloud provider and a managed service from Kubernetes, or should I build my own cluster? Should I pick ten different components when it comes to monitoring and so on? I think the key now is to start looking at what type of applications are you deploying, right. How do you need to scale the applications? How do you need to operate the apps? And how do you need to monitor the apps and support them post deployment and what type of services these applications they are going to need across the application lifecycle? Based on that, then you start choosing the right tools for you without building complexity, because one of the things we've seen a lot is people are using a lot more than they actually need and that becomes cumbersome as you start scaling the number of services you deploy. So start playing smart, right? If you don't need to have full control of the infrastructure that Kubernetes is leveraging, maybe managed services is a great option for you. Right? Let's say if you need application monitoring, then choose the monitoring component that fits best and offers you the most that you want to get that your application developers need to see. So be smart when choosing based on really the application rather than building the infrastructure that is cool. Because I myself, I'm guilty of that. And we have a tendency to try to play with a lot and building the complexity there. So I think just playing smart is key for also Kubernetes adoption in your organization.
Martez Reed [00:26:47] Yeah, and it makes sense. It's kind of the classic engineer trap of make it as fancy and complex as possible because it's cool and interesting. You like to really tinker and things like that. I mean kind of along those lines, I know for me, I had kind of evolved, so to speak, in terms of what I was doing as a sysadmin, started doing more in the scripting and configuration management and all the sort of move towards the DevOps things. I'm interested to, from your perspective, what the future role of sort of the sysadmin or the DevOps person is, especially as I know for me, I've seen a lot of traditional devs start to move into the DevOps space and individuals really focused in on trying to collapse the divide between developer and operations person into a single person. And I keep hearing whether it's like the last year, the last two or three years, like the sysadmins sort of dying and going away. Really. Do you think that's true? Do you think there's really more of an evolution or how do you see that?
Bruno Andrade [00:27:51] I don't think the DevOps or the sysadmin or ops team, they're going to die. I think what's going to change is what's going to happen is exactly what you say. It's going to change over time. Right. And as infrastructure becomes more commodity today -- remember, the times was sysadmin we were pretty much focused on installing maybe KVM and we're fine tuning these things. And to make sure the the hypervisor worked as we needed. And then came VMware and they started offering maybe v center and all of these things and our roles started shifting from managing the hypervisor directly in the nodes and tuning these hypervisor to actually being more around controls and guardrails. I think that's exactly what's going to happen with Kubernetes as it takes more of a backseat from an infrastructure component. I see Kubernetes becoming like your Linux kernal or hypervisor. You know it is there. But from a role perspective, I'm more focused on controls. What type of things are getting deployed, how they're getting deployed and so on. So I think as an Ops team, they are not going to go away. I think the role is just going to change. And while it is important for us to understand how every component around Kubernetes runs and the objects and how they interact is also great for us as an Ops team to understand how our applications are being deployed and how they perform using these components. From a developer perspective, I agree with you, many, especially smaller organizations, we see a lot of these developers actually having to dig into more of the DevOps and operations and understand. Which works great, I would say at a smaller scale. But when we look at larger organizations, we see them breaking these roles where the developers are pretty much focused on the apps. And then you have maybe a platform engineering team which is trying to solve the developer complexity and allow them to focus on coding. And you have a DevOps team, so you see more of a breakdown of the different roles as we start scaling the number of people you have in your team, the organizations and services. So I think these roles are going to get more and more well defined over time, and everybody's going to be focused again on the application like we were many times before, or DevOps management itself in controls.
Martez Reed [00:30:07] Yeah, makes sense. You focus really on where the value is being provided. Last question, because it's kind of the classic question, especially as everybody is doing the 2021 predictions of technology trends and things like that. But definitely interested to get your thoughts on where the IT space is headed in the future.
Bruno Andrade [00:30:32] Yeah, that's a good point. It is a new year. I think last year was a challenging year for everyone. And while we all went through challenges from an IT perspective, I think many things accelerated from a cloud native perspective because people started relying more and more on their applications being available to their end users. When it comes 2021, one of the things I talk a lot around is and many people do, some people like some people they don't like. But I say Kubernetes will disappear and your developers, they won't care because they will be happy to focus again on the application. So I see Kubernetes taking more of a backseat this year and application being the at the top of the realm today. As part of 2021, I believe, ops team and developers together, they will choose better the components they want to use. Again, Kubernetes is not a silver bullet. So I think we're going to see more mature workloads and architectures being delivered, where monolith is always going to be there, right? At the end of the day, I say we still have mainframes sitting around at a bunch of companies and they never go away. So you see your monolith there. There are still going to be there. They're going to play a key part in your infrastructure. You are going to see Kubernetes taking a backseat, but my microservices are going to grow and I see serverless coming up as well. Right. And I think we're all going to learn how to use the different components where it fits best. So I think that's where 2021 is headed.
Martez Reed [00:32:02] Yeah. I mean, it definitely seems like it's the case and where things are moving towards. Bruno, how can people reach you and learn more about Shipa?
Bruno Andrade [00:32:14] I'm definitely available across different options there. One is Twitter. I often check that and you can check me either on Twitter. I'm also available on LinkedIn as well as directly from the Shipa website. You can also contact us. And being a startup and a smaller organization, you can definitely get a hold of me very easy. So I'd say Twitter and LinkedIn are best or if you want to contact me directly from from Shipa website or directly from my email, I'm definitely available.
Martez Reed [00:32:45] OK, what's your your Twitter username.
Bruno Andrade [00:32:53] It's @bandradeto.
Demetrisu Malbrough [00:33:06] OK, well it's great that people can at least search to find you. And this is Dimitri is checking back in this. This was a phenomenal episode and I just sat on the sidelines listening to this amazing conversation so I could definitely not have this conversation the same way that Martez was able to lead the way around the conversation around Kubernetes. So be sure to check out the episode. Also, check out Shipa as well.
Martez Reed [00:33:37] Definitely appreciate your time on this episode of the podcast, Bruno. And I think it's really a lot of great information and really intrigued myself about learning more about Shipa and what it can provide for sort of that abstraction of Kubernetes and making things a little bit simpler.
Bruno Andrade [00:33:53] Thank you. I appreciate the opportunity on participating on a podcast. And it's been definitely great to discover these topics.
Demetrisu Malbrough [00:34:01] And I would like to thank everyone for sharing with us on Pulling the Strings podcast powered by Puppet.