Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
DevOpsDays Boston - Platform Engineering and Internal Developer Platforms
1.3k Plays1 year ago
In this episode of Kubernetes Bytes, Ryan and Bhavin sit down with Alexandre Pauwels and Kevin Scheunemann at DevOps Days Boston to talk all about IDPs and Platform Engineering.
The discussion focuses on how organizations can build IDPs from open source tools and the how DevOps, SRE and Platform Engineering teams work together.
- Check out the KubernetesBytes website: https://www.kubernetesbytes.com/
- Join the Kubernetes Bytes slack using: https://bit.ly/k8sbytes
Ads:
- Ready to shop better hydration, use "kubernetesbytes" to save 20% off anything you order.
Timestamps:
- 00:00 Interview with Alexandre Pauwels
- 16:00 Interview with Kevin Scheunemann
Show links:
- https://bitmantle.com/
Recommended
Transcript
Platform Engineering and Analogies
00:00:03
Speaker
You are listening to Kubernetes Bites, a podcast bringing you the latest from the world of cloud native data management. My name is Ryan Walner and I'm joined by Bob and Shaw coming to you from Boston, Massachusetts. We'll be sharing our thoughts on recent cloud native news and talking to industry experts about their experiences and challenges managing the wealth of data in today's cloud native ecosystem.
00:00:30
Speaker
All right. Thanks for joining Kubernetes Bites podcast. We're live here at DevOps days, Boston. Um, so a hometown event for us, I guess you could say, and we're joined by, why don't you introduce yourself? Yep. So my name is, uh, Alexander. No one can ever pronounce the RE at the end.
Experience with IDPs and Automation
00:00:51
Speaker
Yeah, and I'm here because I did a talk yesterday about sort of my vision on how to model platform engineering and developer platforms. And I have this whole thing about drawing an analogy between what a computer, the layers that build up a computer, the layers of abstraction that build up a computer and how you can translate that into how you can build layers of abstraction in the same way in your cloud infrastructure.
00:01:12
Speaker
Awesome. And I attended that talk, Alex, that was a good one, right? I like even when you started the talk, you said you have already helped a couple of organizations build these IDPs. And even though IDPs are like brand new, I just wanted to know, like, okay, when did you start? What does what does that implementation look like? And then maybe focus more on your talk at DevOps Space Post.
00:01:32
Speaker
Sure. Um, so I think, you know, people say that IDPs are a new concept. I think IDPs are just a word applied to a concept that we've been trying to build for the last 20 years or so. But, uh, I would say it started, you know, one of my first job out of college, I was working at IBM on the, uh, IBM blockchain platform team and we were looking to automate sort of the creation of, uh, customer blockchain networks. And that's when I first started working with infrastructure and automation. And I was pulled into the dark side of Kubernetes. I still remember my manager explaining to me, all right, this is what a pod is.
Preference for Open-Source Self-Hosting
00:02:00
Speaker
It's a collection of containers.
00:02:02
Speaker
Whoa, that's crazy. And then from there, I moved on into a FinTech startup, and I was originally supposed to do blockchain stuff with them, but as a startup does, we ended up having to wear many hats. And one of them was, I was like, I'm sick and tired of manually putting this thing on an EC2. So I'm going to automate this for you. And that's when I really started to develop an opinion on how it should work.
00:02:24
Speaker
And initially i'm very passionate about open source and supporting open source products and i just see a lot of companies using as a service systems you know because they're like it's faster and we don't have to maintain it. And i keep hearing this term tco total cost of ownership like.
00:02:41
Speaker
Well, we could self-host and it'd be cheaper on a monthly basis, but then we have to support it and what's the amount of work involved with that. And I just fundamentally didn't believe that necessarily. I was like, I just don't think it's that hard to maintain these self-hosted products.
Development Journey and Feedback Loop
00:02:54
Speaker
And so I wanted to go out and prove that. And I wanted to automate the lifecycle of self-hosting open source. And that's sort of what I've done with the developer platform that I've built.
00:03:02
Speaker
Gotcha. So is it just you working on the developer platform or you have a team now? No. So it was just me for a long time. And I did the classic engineer thing when you'd make a startup that you should never do. And I've known that the hard way, which is like, I want to write code. So I developed this platform in a vacuum based on my experiences, having built developer platforms in the past for about a year. And then I was like, all right, I guess now it's time to sell and market it.
00:03:25
Speaker
I know how to do the code thing. I don't know how to do this sales and marketing thing. And I've learned a lot of things about why you should not do exactly what I did. You should really find your customer first, build a thing for them, and then deploy it.
DevOps, DevSecOps, and Security Concerns
00:03:38
Speaker
But so I was alone. I've recently hired someone to help me with sort of outbound and communicating with people and contacting people. And really what we're trying to do now is what I should have done earlier, which is I'm reaching out to companies who are building their developer platforms, who are trying to improve their infrastructure and saying, hey,
00:03:54
Speaker
I'm trying to do things that gets you 90% of the way there right now, rather than spending the next six to 12 months just building out your base level of need. And I would just like to talk to you and get some feedback. And I'm not trying to sell anything to you. It's open source anyways. And I just want to know if, am I solving a real problem for a real person? And so that's what I'm doing me and the guy that I hired.
00:04:15
Speaker
That's awesome. Like, okay. I agree with your statement. People are spending the next six to nine months figuring out if they should build or buy something. So that's a perfect place to be in. And you also talk a bit more about DevOps and DevSecOps. I know you focused a lot around that in your session yesterday.
00:04:30
Speaker
Yeah, so when it comes to DevOps and DevSecOps, I think there's a lot of products that try and solve a specific sub-prob, and no hate to them. There's a lot of products that focus on solving the zero trust problem or focusing. And I'm a big, I love Alton Brown. I do a lot of Alton Brown recipes and Alton Brown keeps talking about single use items and multi-use items. And I think you can get a huge amount of value and you can solve these sort of complex problems like how am I zero trust and how do I do this without having to
00:04:57
Speaker
take a specific problem that solves a specific problem that solves that particular problem. If you assemble these complex multifaceted products in a way where they all communicate with each other, all these other problems are solved along the way. And when we talk about DevSecOps, if we look at the security one in particular,
Open-Source Tools for Platform Development
00:05:14
Speaker
One big thing in security and zero trust is making sure that every single request, every single part of your infrastructure is authenticated. We know who did it, we know why they did it, we specifically authorized them to do it. And there's a lot of specific problems that do that. Well, if you just look at combining Istio, which is a service mesh that runs in Kubernetes,
00:05:31
Speaker
an identity management platform which you could go as a service like octa or author or you can self host open source which is key cloak you can actually make those things communicate with each other in a way that you solve that problem internally just because they're integrated with each other so you can tell is to communicate with my idp.
00:05:49
Speaker
make sure that the JWT has these specific claims that it's signed by this specific person, and then if it's not, deny the request to the container, right? And the container now, the code, doesn't have to do all that logic internally. The developer doesn't have to rewrite that code for every single service they deploy. All they have to do is read a header, and if the request even made it there in the first place, that means that it was authorized. And if you want another layer of security, the code can check the JWT again, right? And so I'm just trying to get people,
00:06:16
Speaker
My whole platform is about taking these basic blocks and combining them in the best way possible that each of them does multiple things in the best way possible and you don't have to go out and get these specific products.
00:06:27
Speaker
So do you have like a prescribed list of different projects that you put together from the open source landscape to help? Okay. Yep, absolutely.
Infrastructure and Management Strategies
00:06:34
Speaker
Yeah. So, you know, I like to break it down into five verticals like I did in my presentation, right? So you have your CICD, you have your identity management, your config management, your observability, and then your networking, which is your service mesh. And then for each of those, I pick an open source implementation. So.
00:06:48
Speaker
Do you want me to give you some of those examples? Yeah, so so for CI right? I'm using tecton which allows me to run my pipelines and kubernetes for my CD I use flux which basically allows me to define the state of my cluster in a github repo Oh, yeah, and that's the other thing I say is that a UI should be read only like I don't believe in clicking buttons like that's why we have terraform like if we built terraform so we can write code and
00:07:10
Speaker
To defend and we can track it with get commits and why are we why are we making platforms that make us click buttons again? We're just gonna make a terraform module that clicks the button for us in the platform, right? so Right, so I said CD for flux for identity management. I love key cloak, you know, they've had a rough past but they're really getting really good and I think their features really rival any of the other service products and
00:07:33
Speaker
For config management, I use HashiCorp Vault. There's quite a few competitors out there for Vault that I'd like to explore as well, but that's what I use for now. And then for observability, I like the Grafana Stack. And I like the Grafana Stack particularly because my issue when I've built observability in other places is that if you're self-hosting it, you also have to self-host a rather complex database. One thing I don't like doing on Kubernetes is anything that requires a state in the form of a PVC. The moment you have a persistent volume in Kubernetes, it starts to get a little more complicated to manage.
IDP Promotion Challenges with Startups
00:08:02
Speaker
And what I like about the Grafana stack is they stick everything in S3. And there's nothing more simple than just sticking everything in S3. Yeah, sure. I mean, it's a little avoidable if you can use something like object, right? But there are some cases like running databases on Kubernetes. Obviously. It's hard to get away from not caring about the PVC. And here I'm going to sneak away in a corner and tell you that all my databases are fully managed on RDS.
00:08:27
Speaker
So we've interviewed a bunch of folks that do manage state on Kubernetes. And we find that they tend to go in a couple different camps, which is one, they probably just use a managed service and say, well, I don't want to deal with it. And they do a good enough job. And so just let them go for it. So it's a totally fair answer, the same answer as you don't have to do Kubernetes in the first place half the time. So that's fun. So how many developers are actually using the IDP that you build now?
00:08:56
Speaker
So an early version of the IDP I built, I put out in the second company that I helped build these things. And they had a development team that was about 20, 20, 30 people. Right now, I'm trying to actually get more people to look at my IDP. So you could say zero, unfortunately, right? No, that's fine. I'm trying to get people to look at it and tell me if it's useful, if this is an interesting thing for me.
00:09:20
Speaker
I'm struggling because for startups, like I think a lot of startups which want to do the things on their own in the cheapest way possible and they're not looking at getting something off the shelf. And also the price of running all these different services together on Kubernetes is going to be like, like I said, $2,500 to $3,000 a month. And sometimes a startup, especially if they don't have any sort of seed investment, is not looking
00:09:39
Speaker
do that. So I'm looking to reach people above a certain scale. And then those people are either hard to talk to or there's a huge amount of switch over friction because once you've reached that scale, you actually have already a particular, it may not be the best way of doing things, but it certainly works and I totally get that. If it works, it works. And you've got to convince them it's worth it to go through all that friction.
First DevOps Days Experience
00:10:00
Speaker
to switch over to a new way of doing things. Right, right. Like how you bolt on what they're already using. Yeah, it's hard to just, you got to find that smallest and usually what I tell people is just pick that one service, one thing that would be simple, right? Stand up what I've got, you know, this open source platform and try and switch that one service to it. And if you like it, you can switch another and then another and then another. You don't have to do it all at once, you know, just a little bit at a time. Yeah.
00:10:27
Speaker
Yeah. And I'm wondering, so with this platform that you're kind of building is the idea for someone to be able to take this and kind of like stand it all up in one motion, sort of like all automated and sort of scripted in the sense that you can hand this over to, you know, a team or someone with that one service and say, you know, here's how to do it. Or like, do they have to install everything individually?
00:10:49
Speaker
and know how to do it themselves. No, so the idea, right, and I also, the whole thing about my platform is I don't want you to depend on a new tool that I have to write. I want only to use tools that you're familiar with. So all it is, it's a set of Terraform modules, which you run in order. One of them sets up your AWS orgs. One of them sets up a database. One of them sets up your Kubernetes cluster, right? Like I said, you bootstrap different layers of the hardware stack in the presentation. And then the other component of it is that GitOps repo, which sets up the inside of the Kubernetes cluster. So the idea is that within a single day,
00:11:19
Speaker
you know an engineer could run the modules in order, point flux at that GitOps repo, they get everything set up and then they're able immediately to start publishing services to it. Very cool, very cool. Alex, one question around IDPs, right?
00:11:32
Speaker
Building your own in an open source way, that's perfect. But have you looked at backstage? How does that compare? Did you realize that there were challenges that it doesn't solve for with its architecture that you had to go down your own path? Yeah, absolutely. So when I boil that down to opinion.
Invitation for Collaboration and Feedback
00:11:48
Speaker
So I think backstage tries to be as unopinionate as possible, which is awesome because
00:11:52
Speaker
you can basically build it to do it anything you want, any way you want. The way that I build things, I'm saying, all right, I'm claiming that there's a better, a best, quote unquote, way of doing this, which I know, immediately someone's gonna come and hit me with a hammer the moment I said that. But there's a generally good way of doing this, and what's difficult about building IDPs is not necessarily finding tools. There's a lot of great tools that do a lot of different things. It's, like I said, linking them together in the best way possible. And when you start linking things together, you immediately start implying opinion.
00:12:22
Speaker
of I think they should be linked this way. And so what I should say the major differentiator between what I built is I'm saying, rather than spending a much like customizing backstage. Mine works right away because it's built in an opinionated way and they're all linked right out of the box in a way that makes them provides you all these really cool features like
00:12:39
Speaker
really high security and your CI pipelines work right away. You don't have to write them right now. All the interfaces have been set so that you just have to write a Docker file, push your code and it just starts working. So yeah, it would be the opinion. That would be what I would say. Okay, that makes sense. Yeah.
00:12:55
Speaker
Okay, so I guess one last question for me. Have you attended DevOps Space Boston before or is this your first time and how do you like it so far? So this is my first time. I used to live in Somerville when I worked near Boston. I went to school at WPI. But this is my first DevOps days. I live in Lisbon, so it was a bit of a travel, but I decided to make it into a bit of a trip, see all the friends I haven't seen in a while, go to New York.
00:13:20
Speaker
This is my first, but this is my first DevOps days and I'm really, really happy to be here to meet you guys. I've had lots of fantastic conversations with really smart people and I'm hoping to also learn from them and maybe plug in some of the improvements they've suggested into my own platform.
00:13:34
Speaker
Yeah, I feel like the open spaces do a really good job of giving you that platform to say, here, I want to talk about this topic, or maybe there's one you've already been interested in. So how do people find out more about what you're doing? Like, how do they connect with you or the project you're working on? Yeah, absolutely. So you can either reach out to me on LinkedIn. I'm just AJ Powell's Alexander Powell's. You can go to my website. The name of the platform is BitMantle. There's a whole philosophical idea behind.
00:14:01
Speaker
It's like the mantle of the earth. It's like the foundation of your infrastructure. I like it. So bitmantle.com works. And then you can also, since it's open source, you can go to, I'm currently switching. I'm in the process of switching from, originally my company was Powell's Labs because that was just sort of like, oh, I want to put all my ideas in one place, Powell's Labs. And then BitMantle is like the product that came out of it.
00:14:22
Speaker
There's been other products that came out of Palos Labs, more based in the data security and privacy space. But yeah, so BitMantle, or just contact me on LinkedIn, and my email is Alex at bitmantle.com.
Product Advertisement: Liquid IV
00:14:33
Speaker
Awesome. Well, thanks for joining us here and enjoy the rest of the show. Thank you very much. Have a great day. We'll be right back after this short break.
00:14:40
Speaker
As long time listeners of the Kubernetes Bytes podcast know, I like to visit different national parks and go on day hikes. As part of these hikes, it's always necessary to hydrate during and after its turn.
00:14:54
Speaker
This is where our next sponsor comes in, Liquid IV. I've been using Liquid IV since last year on all of my national park trips because it's really easy to carry and I don't have to worry about buying and carrying K to rate bottles with me. A single stick of Liquid IV in 16 ounces of water hydrates two times faster than water and has more electrolytes than ever.
00:15:18
Speaker
The best part is I can choose my own flavor. Personally, I like passion fruit, but they have 12 different options available. If you want to change the way you hydrate when you're outside, you can get 20% off when you go to liquidiv.com and use code KubernetesBytes at checkout. That's 20% off anything you order when you shop better hydration today using promo code KubernetesBytes at liquidiv.com.
Career Transition and SRE Role
00:15:46
Speaker
And we are back.
00:16:00
Speaker
All right, welcome to Kubernetes Bites. Kevin, we're here live in Boston. Thanks for joining us. Why don't you give a little introduction for our listeners about who you are and what you're doing? Yeah, thanks for having me. My name is Kevin Schindeman. I'm a staff SRE at TechOff Technologies. I've been there for four years. I've seen the gamut from going from Doctor Compose to Kubernetes and now on to Serverless Technologies.
00:16:26
Speaker
So I've witnessed it all. Yeah, I had the pleasure of working with you about four years ago now. I noticed you left out the whole OpenStack piece there. Was that maybe on purpose? It was correct. I think all those brain cells of OpenStack have left my brain.
Tech Burnout and Work-Life Balance
00:16:45
Speaker
Maybe for the better, maybe not. Anyway, so what brings you to DevOps stays Boston? I know it's not your first, so tell us a little bit about your experience here. Yeah, I've been coming to DevOps days for probably
00:16:56
Speaker
I don't know exactly how many years but probably six to eight years way before I was here at the cyclorama. It's always good to hear you know what other people are working on or
00:17:08
Speaker
their experiences in the DevOps world, even in platform engineering, all that kind of stuff. And it's good to hear those high-level things. And even the burnout one was very interesting this morning. Sure. Because that was not technology-specific or just general. We like to run so fast and then have to just slow down a little bit.
00:17:28
Speaker
I wonder if talks like that, like, I didn't attend it, but it's a common theme on if you had a many conferences in this space. I'm wondering if we're scaring away people from getting into into this type of thing. Tell me a little bit more about the talk and maybe your have you ever experienced kind of an influx or burnout in your SRE job? Oh, for sure. As far as the presentation went, it was
00:17:55
Speaker
basically how to identify burnouts in yourself.
00:17:59
Speaker
Um, how you can, uh, mitigate some of that either by getting a new job or, or just taking vacation or, um, all that stuff. So that was very good to hear some of that. Um, as far, you know, as far as burnout, my, my personal life, yeah, I definitely experienced that from time to time where I'm just running so fast. In fact, I probably hit that right now working on the project. I'm like, you just hit a point where it's like, all right, I gotta take a break, switch to something else. And I can come back to it, you know, to, to just.
00:18:26
Speaker
give a mental break from what we're working on. Yeah, definitely. I saw an analogy the other day about, you know, us as humans in the workplace, um, how we're always sort of like acting as like a spring. We should always be striving for more to get to the next place and, and, and, but at the same time, our human bodies sleep every night.
00:18:47
Speaker
Right. Right. And so if you take a wider look, we should also be able to sort of not sleep per se, but, you know, take those breaks to rejuvenate ourselves. Right. I know a lot of people that believe in sort of like, you know, work seven days a week, 24 seven. And, you know, God bless them if they if they can work that way. But some people just aren't built that way. So, yeah, I think Brown
Evolution of DevOps Days Topics
00:19:09
Speaker
is real. But at the same time, like,
00:19:11
Speaker
You know, I think it's also part of the information age that we're in. It doesn't just stop at sort of our daily lives in technology. We're just flooded with new stuff, new new parts of the stack, new pieces of DevOps all the time. So I guess, like, how has to you the topics since you've been coming to DevOps days for a long time, how has they changed over the years?
00:19:37
Speaker
I have to kind of think about that one. They have changed a lot, for sure, from the first days to now. I think early on, it was more geared towards like...
00:19:47
Speaker
CICD and automation and those kind of things. And I think as we've already done all that stuff and moving more forwards, it's like thinking about platforms and obviously thinking about more observability and those type of things. And so those are the talks that are coming out this year.
00:20:08
Speaker
But then we're also leaving out people who are brand new to DevOps. And so one of the nice things that Paul and Don and the group has done is brought in that 101 track to guide new people who don't understand DevOps for automation or what it really means to help them get up to speed for these later talks or advanced talks.
SRE vs. Platform Engineering Roles
00:20:30
Speaker
Interesting.
00:20:31
Speaker
Okay, so Kevin, I wanted to ask more about your personal journey, right? Like you said, you have been doing SRE for the past five years. Sure. How has SRE treated you and what are your thoughts about DevOps or platform engineering titles, which are kind of responsible for the same thing, but yeah, just different titles.
00:20:47
Speaker
Yeah, I think in my opinion, like there's two different things. I mean, SREs came out of the Google world and reliability and focus on reliability, plus about platforms. But there was a talk, I think it was last year from one of the Google SRE people and they were mentioned like platforms could come out of
00:21:08
Speaker
you know, comes out of SRE because it's like, you know, you're supporting the dev teams and you still need, you know, eventually a platform. And then we used to have this focus on platform engineering as well.
00:21:19
Speaker
kind of the two aspects. I think at a really big organization, probably at Google, they probably have both, right? They have an SRE and a platform team, right? And the SRE supports, yeah, so on and so forth. Do you think the platform side of the boat there, in that example, is more tied to sort of the developer experience in sort of what that platform is versus, you know, keeping the lights on?
00:21:42
Speaker
Oh, for sure. Oh, for sure. Yeah, because like, yeah, the platform engineering, their, their role is to, uh, you know, reduce that, um, you know, lead time to, to production and the developer experience and getting, uh, new, new ideas out, out the door much quicker. Well, on the SRE side, they're more about like, okay, reliability, right? Yep.
00:22:01
Speaker
How can we monitor this? Do we have our SLOs and SLIs in place? And if it goes out of whack, we're going to need to make sure we're coming back and fixing that. So there are two things, but slightly different. And they all focus on automation and making sure developer lives are much easier, and they can focus on getting their features out
Platform Engineering Debate: Revival or Advantage?
00:22:25
Speaker
the door. Gotcha. And yesterday in one of the talks, I think the first talk that Pete did, he spoke about how
00:22:31
Speaker
before DevOps there was an IT team and there was a dev team. Correct. And then the whole point of DevOps was to make sure that they work together and we break down that barrier. And now they're with after DevOps the next iteration sounds like platform engineering where there is again that central team who's building that platform or these DevOps developers to push code on. Do you think that it's cyclical and we are going back to the old ways of doing things or this actually has a benefit?
00:22:57
Speaker
I think it's slippery slope. So if a platform engineering gets too overzealous, they can like rate more of a locked world where you can only do it this way and the developer teams can't do it. I mean, I, you know, when a platform team emerges, they should really think about, okay, here's the golden path, right? So this is the easy way, but we can, you can either provide to the platform so you can expand it to like what you want or, um, or outside that box, like, you know, you can go way outside that box and just do what you want.
00:23:26
Speaker
Okay. But providing those two features to a developer or development team so that they can choose like, okay, I'll take the easy path. Or I'll make, oh, I don't like your easy path. I'm going to try my hard part. But then they're going to have to be bogged down with all of the usual stuff. We're like, oh, I got to do my own CACD pipeline. I got to do my own automation. I got to make sure all this isn't, you know, security and compliance and all that
Importance of Observability in SRE
00:23:49
Speaker
stuff. Gotcha. Yeah.
00:23:50
Speaker
Yeah. Um, so, I mean, so one thing I've noticed and I think I mentioned to it yesterday or maybe this morning was I noticed there was a lot of talks about observability this time around. Um, now can you tell me about maybe the, a little bit of the importance of observability in sort of your day job, maybe even, or, or just more conceptually, uh, for my day job, observability is like the last part of it. Like, um, a lot of the times.
00:24:19
Speaker
we're letting the teams in our, in take off, we're letting the teams kind of figure out their observability. And we're trying to find the right way to communicate that to them to make sure they're putting in the right metrics. So we're still learning on how to do that in our world. And we're also, you know, dogfooding ourselves and making sure that we put our own SLOs on all the services that we maintain.
00:24:42
Speaker
Um, so for example, some of the networking stuff that we do, you know, we just put in some SLAs or SLOs are in place so that we're monitoring that in a.
00:24:50
Speaker
more SRE type fashion versus just like random metrics and something goes down and we get alerted kind of thing. Because that obviously leads to burnout as well when we have too many
SRE Team Structure and Evolution
00:25:00
Speaker
alerts. So as part of your day job, do you see the SRE team giving a lot of feedback to the developers? Because we have heard terms like observability driven development. Do you see that metrics that you care about from a reliability perspective going back into the dev cycle and making its way all the way in the application stack? Yeah, we're trying to figure that out.
00:25:19
Speaker
I wish we had that kind of feedback, but we're still trying to figure that out. Awesome. Do you have a team of just SREs or do you also have the split between SRE platform? We just have SRE. The way that our domain structure is set up, we have obviously our product domains and then we have our production domain, which is half SRE and half QA.
00:25:49
Speaker
And so we're trying to like merge together to be like one big kind of SRE team, but there are two different things because the QA team was kind of put in place as a release engineering team to put out essentially a release train every two weeks. We're trying to get away from obviously that because that's not DevOps focused anymore. And everybody's
Kubernetes to Serverless Transition
00:26:08
Speaker
on board of that. It's just slowly kind of getting there as an architecture.
00:26:15
Speaker
It's like, if there's no name for that, maybe extreme waterfall or like super fast waterfall. Yeah.
00:26:22
Speaker
Yeah, that's fair. And I think there's pockets of DevOps at various places in different companies and stuff like that. They're all different phases. Like you said, there's a lot of people who are still looking to enter this community. So the 101 track here is really valuable, especially you coming from the background of SRE and coming to this conference a long time. It's easy to forget that someone's just walking into this whole community. I almost called it mess.
00:26:50
Speaker
I wasn't going to be that mean about it. So, you know, I want to switch gears a little bit because yesterday I feel like I had a really interesting conversation with you about the metrics around cost and what that means for running platforms. All right. And so we've talked to a few individuals who are moving away from Kubernetes even. Now, I'd love to hear your thought on that. And if you could talk a little bit more about that.
00:27:17
Speaker
Oh, for sure, yeah. We're definitely in the process of getting rid of Kubernetes for our standard runtime. And the reason for that is cost, because the way that we architect our system was we had an environment or a Kubernetes stack per customer. And so when you have 10 customers, you have 10 Kubernetes clusters, and each one of them costs a lot of money. And then we have multiple environments, so static environments that don't need to be around as well.
00:27:45
Speaker
So we had a couple of projects going on. One was to make that all ephemeral, right? So we can make ephemeral environments, bring up GKE, deploy all the stuff, give it a new base domain name, and away we go, right? That took a while to build. We actually excited that we built it and got it out there. And that saved a lot of money on our non-prod environments, or development environments, in QAI, is what we called them. So that saved a ton of money.
00:28:12
Speaker
Um, and, but we're also trying to focus, you know, rewrite our platform into go from closure. And with that, we're focused on, um, serverless technology. So functions cloud run, because we're a Google shop. And, um, by doing that, it's much more, you know, obviously you don't pay, you only pay for usage at that point. And our usage is much, is very bursty.
00:28:37
Speaker
So it's never a constant, you know, we never have a constant number of requests per second. So, so that, that's where it comes into play where it's like, well, you know, we only pay for when we, when we use it. Yeah. Interesting. So you still see the benefits of containerization and that's how developers are building code, but then instead of managing Kubernetes clusters, you just let Google orchestrate them whenever they got it. Yep.
Choosing Go for New Development
00:29:02
Speaker
Very cool. So, um, you know, one of the things I think that's interesting is that's, um, a use case that, or I should say it's use case dependent. Right. Um, because in some scenarios you, you would want to maintain at least some level of, of, you know, compute, I'll call it doesn't have to be companies. Um, and you know, you have to be able to.
00:29:22
Speaker
you know, sacrifice those warm up times or those kinds of things. Have you chosen the Go programming language for specific reasons? I heard you mention that. I'm curious about that.
00:29:36
Speaker
Yeah, mostly because the market, you know, the development market is more geared towards go now, um, uh, for sure. Because, you know, we did definitely want to do Java, um, because closure is Java and there's not closure developers are hard to find. Um, and, and there's a lot more go develop development out there. And it's, you know, it's just a simpler language for anybody to actually pick up and learn. Um, cause it's way, you know, so many open source projects using it.
00:30:00
Speaker
Uh, Kubernetes, Terraform, everything, you know, you look at, you look at anything new and it's pretty much it's go, but it's written and go. Always a few new rust things out there, but, uh, but yeah, I think more development is doing, is doing that. Um, you know, there's still, there's some pipe. We have some Python and such, but yeah, the most part it's mostly because of the market, you know, developer market, it's easier to find people, right. And go
Low Profile Online Presence
00:30:22
Speaker
language.
00:30:22
Speaker
Yeah, absolutely. Well, very cool. Um, I wanted to thank you for coming on the show and, uh, can people find more about what you're working on? Can they contact you, find you on LinkedIn? How, how do you want to do that? Unfortunately, I just fly underneath the radar. So
00:30:41
Speaker
I don't blog post. This is my first podcast. But yeah, you can reach out to me on LinkedIn. I can give the guys my LinkedIn information. Sure. Yeah. Absolutely. Well, I appreciate it again and thanks for coming on the show, Kevin. Excellent. Thanks for having me. Thank you for listening to the Kubernetes Bites Podcast.