Multi-Cloud and Lock-In

♪♪♪ ♪♪♪ ♪♪♪ ♪♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ ♪♪ Does that answer your question? Is that a fair answer? Just wondering if you have a sense of or if there's a best practice for, you know, at what scale does orchestration and containerization and all that kind of stuff make sense? Because there is a penalty for the management side of it. It's a different way of doing it, but you still have manifests and configuration files and everything else. At what point is it worth investing in that? It kind of... For me, I've seen companies with 10 people do this really well. I've seen companies with 20 people do this really well. It is a paradigm shift. So if you're in this old, like, previous model, you're right, you know, everyone has to change their mind about things. But at the end of the day, it's better for the developers. It's better for DevOps. It moves around the responsibilities, and it makes them easier to handle. I don't think there is, like, a perfect point, but there is a point where you realize it is something you should be looking into. And I think that is for any company. You know, those 10-person companies, they can move quickly and deploy services quickly and make sure that they're up and running because they moved to this model or they built on top of it. It is a different thing when you're saying, I've built this other way, and now I need to move to the containerization orchestration model. And that's when you start looking at small POCs, you know, moving on the cloud, making it easier, you know, doing it on premise, just moving to that orchestration model. Like, we have container engine. We try to make it as easy as possible. I usually tell people that. Move one little service and try that out, and then we can build on top of that. There's no perfect point. Yeah. Yeah, so one question one could ask himself would be how much pain is a certain piece in the current way of deploying software causing us as an organization? And just start with automating that and moving this particular piece into, I don't know, something fancy, basically, and just expanding, extending it, where you start with a simple POC and you expand into glorious pipelines and whatnot. Yeah. Like, to that point, you're right. You know, you start moving to Jenkins, or maybe you're already using Jenkins, and you're using VMs at that point. Then you start thinking, hey, actually, instead of using VMs, let's use containers for some of these, and building that immutable infrastructure that is then built on top of containers. You can start doing that. You're right. You know, having that pipeline is great. Just kick those jobs off, bake those things, and you don't really have to worry about them at all. So we are out of time. Thank you both for being here and for a great conversation. Yeah, thanks for having us. Thanks. Thank you. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks. Thanks.