Cloud-native development is having a great run of popularity and growth, but complexity and vendor lock-in are the trade-offs for agility and reliability. Credit: ComicSans / Getty A recent study by Gartner predicts that by 2025 more than 95% of application workloads will exist on cloud-native platforms (up from 30% in 2021). I tend not to believe these kinds of predictions because adoption is never linear. We run out of applications that are easy to convert to new development approaches (in this case, cloud native) and thus adoption slows down or ceases much earlier than most understand. If you’re still a bit confused by what the heck “cloud native” means, you’re not alone. Here’s my best explanation: Cloud-native development is the process of designing, building, and running applications in a cloud computing environment. It leverages the benefits, architectural patterns, and capabilities of the cloud to optimize performance, scalability, and cost efficiency. In other words, we deploy everything to provide cloud-like capabilities, no matter where it runs, cloud and not. This approach is sold as allowing for faster time to market, increased agility and flexibility, and improved scalability and reliability. It’s a fundamental shift in the way software is developed, deployed, and managed, enabling organizations to take full advantage of the cloud’s capabilities to drive innovation and business growth. Also, it works with popular development tech such as containers and container orchestration. Cloud-native application development, while offering many benefits, does have its downsides. Most of the people adopting cloud-native approaches and technologies are quick to overlook them. However, they are becoming more apparent as we use the cloud-native approaches to deploy more and more workloads. Keep in mind that I’m not arguing against cloud-native technology, I’m asserting that we need to consider the downsides as well as the upsides. So, here we go. Vendor lock-in. One of the main issues with cloud-native development and deployment is that it can lead to vendor lock-in. When an application is built and deployed to a specific cloud provider, you typically use the native capabilities of that cloud provider. It can be difficult and costly to move to a different provider or an on-premises platform. This can limit the flexibility of the organization in terms of where they choose to run their applications. It flies in the face of what many believe to be a core capability of cloud-native development: portability. Most of the fans of cloud-native development are under the illusion that lock-in in not an issue. You can understand why, given that cloud native typically means using containers, which are supposed to provide portability. The truth is that you’ll have to use native features on specific cloud providers and platforms (storage, security, etc.), and doing so limits your ability to move them to other platforms cheaply. Skills gap. Another downside is that cloud-native development can be complex and require a different set of skills and tools compared to traditional on-premises and public cloud development. This can be a challenge for organizations that are not familiar with cloud-native practices and may require additional training and resources. I often see poorly designed cloud-native deployments because of this issue. If you’re not skilled in building and deploying these types of systems, the likely outcomes will be poorly designed, overly complex applications. That won’t help anybody. Cost overruns. Finally, organizations may find that the costs of cloud-native development can be unpredictable. Usage-based pricing can lead to unexpected costs if an application experiences a spike in traffic. Organizations need to carefully monitor their usage and plan accordingly, otherwise they could face budget overruns. I would not deploy cloud-native applications without a sound cloud finops program in place. Many an organization is getting $100,000 cloud bills these days when they expected $2,000. Whoops! Cloud-native application development offers many advantages, but organizations should be aware of these potential downsides and plan accordingly to fully realize the benefits of this approach. The problem I’m seeing now is that many enterprises are leveraging cloud-native development and deployment without understanding these downsides. Thus, they can’t manage the risks accordingly. If this is your strategic direction, you’re joined by many. Make sure you go into cloud-native development with both eyes open. Related content feature 14 great preprocessors for developers who love to code Sometimes it seems like the rules of programming are designed to make coding a chore. Here are 14 ways preprocessors can help make software development fun again. By Peter Wayner Nov 18, 2024 10 mins Development Tools Software Development feature Designing the APIs that accidentally power businesses Well-designed APIs, even those often-neglected internal APIs, make developers more productive and businesses more agile. By Jean Yang Nov 18, 2024 6 mins APIs Software Development news Spin 3.0 supports polyglot development using Wasm components Fermyon’s open source framework for building server-side WebAssembly apps allows developers to compose apps from components created with different languages. By Paul Krill Nov 18, 2024 2 mins Microservices Serverless Computing Development Libraries and Frameworks news Go language evolving for future hardware, AI workloads The Go team is working to adapt Go to large multicore systems, the latest hardware instructions, and the needs of developers of large-scale AI systems. By Paul Krill Nov 15, 2024 3 mins Google Go Generative AI Programming Languages Resources Videos