 Hi, this is your host Ali Bhartia and welcome to a special episode or TFR. Let's talk here at KubeCon EU in Amsterdam, Netherlands. And today we have with us once again, Billy Thompson, Solutions Engineering Manager at Akamai. Billy, it's great to have you on the show. It's great to be back. Thank you. Let's service some of the basic. Can you explain the difference between cloud native and platform native or portable approach to running and managing applications? What is the difference? So cloud native is a design pattern. It's an approach or technique for application development, deployment that leverages technologies that take advantage of the elasticity and scalability of on-demand resources in the cloud. It's a design pattern and that can imply portability. It can suggest portability and a lot of times it does. And I think that the CNCF does a really good job, in my opinion, of promoting portability with all the open source solutions that they foster and nourish. And as such, you have hyperscalers who produce a lot of very opinionated content and narrative on how to develop cloud native applications that use services that they natively provide on their platform that only exist on their platform. And there you have a cloud native application that is vendor locked and that is only built to run on their platform. And that's what I'm referring to as platform native. So for portability, you need a cloud native design that is also cloud agnostic. And when you build in that platform native way, you also are more susceptible to this industry crisis that we know is cloud waste, a over $26 billion a year industry crisis, which simply boils down to unnecessary spend on cloud services, but it's roughly one-third of many organizations cloud spend falls into this category of cloud waste. So when you think about it, it's common for SMBs who have workloads on hyperscalers to be spending $1.2 million a year in cloud spend. That's $400,000 just wasted. That's the salaries of four engineers that could be making your product more robust, your cloud native application and delivering on the voices of your end users faster and being tomorrow's cutting edge. So that is a lot of waste compared to an intentionally portable design where you typically be a lot more conscious and aware and tactical about how you're using your cloud resources and commoditizing so that you get the most out of it and so you can reduce that cloud waste. You also believe that modern organizations are better served by running their cloud native portable applications on commoditized cloud. First of all, how would you define what is commoditized cloud and why do you believe this is the right approach? So portable design allows you to commoditize your cloud providers, to pick the right provider for the right job, the right tool for the right job, by being able to swap out resources and to pick ones that are best fitting for the particular use. So say you want to reduce cost, you can pick your more data intensive workloads that will run just fine on a lower cost provider. If you need more performance, you need a certain instance type. You can pick a provider that has that. If you need to serve a specific geographical region, you can pick a provider that better serves that area. So by commoditizing your resources and having that interchangeability and being able to structure your architecture around what best suits that workload in contrast to you're running this workload on this hyperscaler, so everything you run is in that hyperscaler. That's not getting the best use out of all of the cloud resources available to you. That's not squeezing the most juice you can from the fruit of all these trees. So when you're talking about portability so that they can leverage commoditized cloud, do they have to do any extra work or this portability is the very essence, the very design of cloud-native applications? So if it's not already a portable design, then yes, that can take some work. And a way to get started with that is to identify points of vendor lock-in and ask yourself, why are you using that service? If the answer is, I don't know, that might be a good opportunity to think about what are the alternatives to? What are the one-to-ones? How can we be portable? If there could be legitimate reasons why you choose a particular service on a particular provider for the current use case at this given point in time. And it could be that you started that way, you were consulted that way with this idea that maybe down the road we can do something like containerize this application for Kubernetes or do things in a more portable way. But don't let that just be a thought, right? As soon as that thought comes, start thinking about what does that look like? Start scoping out what is that going to look like? Because the longer you sit there in that current environment, the easier it is to go deeper and deeper and more difficult it can be to unwrap from that. When something happens later on that you want a more portable strategy and then you find out, well, at this point it isn't that simple. So it is a design choice that you should consciously make. I will say that I've talked to organizations that kind of by accident have a portable strategy just the way they're doing things. But there are others that are very conscious about it and specifically architect just around open source and core cloud infrastructure primitives. And that's what I want to touch on here is open source and the core cloud infrastructure primitives. There are things like your compute, your storage, your networking. In today's world, I'll even include things like load balancers, block storage, Kubernetes engines, the things that you will find on all of the cloud infrastructure providers. So you build on those core cloud infrastructure primitives and open source and you have a design that can run on any of the providers that you can pack up, that you can move around, that you can expand and contract and so on. Excellent. Thanks for explaining that. Now, if you look at current landscape, if you look at three major hyperscaler, the whole messaging is to eliminate the whole complexity that comes with cloud at your Kubernetes is to use managed services on their cloud. Yes, it does look easy. It does look appealing, but managed services, they're opinionated. Some extent, you lose the flexibility that you would get from things like Linux and Kubernetes. So what are your thoughts on that approach? In my opinion, I think that they just introduce complexity in a different way. So the idea being that they give you the subtraction, you don't have to focus on the underlying resources or how to scale it and secure that, but a lot of these managed services themselves are not always necessarily easy to use and easy to implement. The documentation can be difficult and the amount of time and energy is spent into getting certifications and other training just to kind of break the ice and understand it and better use it could be spent on learning something like Terraform. And that's something that's not specific to an environment and a great thing for a multi-cloud strategy and infrastructure is code in the whole direction that this industry is going. And that's a way that you can manage workloads that you can scale them. So, you know, my thought on it is that a lot of people believe that this is going to be the easier route for them to go and when you have so much cloud waste because of billing complexity, when you're having trouble navigating a bloated platform and when you have to hire a specific talent to help you use the managed services that are there to, I guess, make it easier for you by doing things, but it wasn't that easy. I don't think that's any less complex. In fact, I think in many ways it's more complex in addition to losing the flexibility and your agility to move around the cloud space. So I think a lot of times it comes down to where do you want to focus your time? Do you want to focus it on a particular platform? Hiring people who've been through some of that learning curve who understand it a little bit better? Or do you want to focus on tools and techniques? They will travel with you anywhere you go and on any platform. Yes, you're absolutely right. But sometimes when we look at startups who do not have a lot of resources in the very beginning, public cloud or hyperscalers, they do appeal to be, yeah, that's easy, move it. You can just get started on day two. You can scale as you want. You don't have to go through any procurement process. So if you look at just this market and do you think that when they don't have a lot of resources initially, CEO is also the, CTO is also doing everything themselves. Can portable architecture help them at that stage or kind of hyperscale is the only alternative available to them at that stage? So my company has a startup program and as part of that, they get access to my team for consulting. So I have a lot of experiences I can share where these are startups that have really, really good products. They are tomorrow's cutting edge and they got to market and they have a portable architecture. And what they don't have is some big engineering team and all these resources, a big company, like they've been told that they would need if they do this, they don't have that and they're doing good this way. Despite there being a sort of popular narrative that this is the worst thing a startup can do, that this will make it harder for them and that the best thing they can do is to abstract away everything as much as possible so they can get to market faster. So that's a narrative I hear broadcast a lot but in my experience, I'm really not seeing that so much. I'm seeing startups fully capable of doing this and doing very, very well at it and having a portable design from the start. I've also seen startups go from a vendor lock platform native environment into a more portable open source environment and I see the same engineers, the same teams, the same people just doing things differently. So I think ultimately it comes down to you do what you feel best for your business at that point in time. And at that stage, if you really feel more comfortable going with the man of services, I'm always gonna say do what you feel is best. But I don't think you should be afraid of the portable approach or just necessarily just buy into the idea that that inherently means it's gonna be so much more work and you need so many more engineers because I'm just not seeing that be the case. It's really a matter of how you do things, what you put your time into learning and what resources and it may be learning something new, learning some different tools and technologies, but that's part of the industry. Learning's involves one way or another. If you're on a hyperscaler, there's learning involves. If you're doing things fully portable where you can move around cloud providers, there's different learning involved. So this is still something that startups can do. And in my opinion, it's something that is better for startups to do because you're already setting yourself up for success in this space. You're future-proofing yourself and a rapidly evolving industry. It's evolving at the speed of light. And I have a good example that I like to share. There was a client who came in through our startup program. They did some shopping around and where they landed was, okay, we like your platform because of the simplicity and the customer support and the pricing. So we're gonna put some of this core workload here, but we have this other workload that we're gonna put on this European-based provider. And there are some things we don't like about that provider, but this is a more bandwidth-heavy workload. And we did the math and found that we can get better pricing on egress for the size of this workload. So we're gonna put that one there. And should that ever change, we can put that one onto you as well or somewhere that we see a better fit. So this is a startup that right out the gate has a durable multi-cloud strategy. They're flexible, they can move around. If they pivot their business strategy, they can pivot their architecture design to support that. So by architecting in a way that's portable, on open source and just core cloud infrastructure primitives, they can evolve at the speed of this industry and they can do so with minimal cloud waste. What advice do you have when you look at these startups or people who are looking at it and they want to embrace this portable approach, is there any difference between cloud native and portable architecture? If there is or this is the same thing, we are just calling it different. How much work is needed and what is your dose, how they should get it started? Cloud native is a design pattern. It does not necessarily mean that you have portability and we see that where there's cloud native applications that still get vendor locked or still built in a way that can only run on a platform. So for portability, you specifically, you want to develop in a way that is cloud native, but that is cloud agnostic and using technologies and making design choices around technologies that can work on any of the cloud infrastructure providers. So cloud native in a way that is cloud agnostic. Now, my advice for achieving that, if you're starting out, then start with infrastructure as code. And the reason for that is because you have tools like Terraform and Pulumi that wrap around all of these providers' APIs so it can work across providers. It can help you develop a strong multi-cloud strategy and you have a documented architecture that you can version control the state of. My recommendation is for things like configuration management. Right? If you're not using a managed service, if you're managing your own infrastructure, you shouldn't be doing things the old-fashioned way and manually log into every server and do run software updates. You should have configuration management and build that into your automation pipelines. And where I'm going with this is a GitOps-like approach, right? If you have Git, the same thing that you use to version control your application, you have all the means to version control all the components underneath of that. And that is really powerful and really flexible and does cross-platform a way that you can version control a multi-cloud environment. Quality automation like that can take some time to build and to tune just right. But again, think about the amount of time it can take getting certified for a hyperscaler and learning that platform and then having to hire new people to still help you with that platform. These things take time. So where do you want to invest that time? Where do you want to invest that learning? So my advice for a portable architecture is to travel further and further into the everything is code direction if you have not already. Billy, thank you so much for taking time out today and talk about this portable architecture and how companies can embrace it. Thank you so much. And Azula, I'd love to talk to you again soon. Thank you. Awesome. Thanks for having me.