The term “cloud-native” gets thrown around a lot, especially by cloud providers. Not only that, but it even has its own foundation: the Cloud Native Computing Foundation (CNCF), launched in 2015 by the Linux Foundation.
‘Cloud-native’ defined
In general usage, “cloud-native” is an approach to building and running applications that exploits the advantages of the cloud computing delivery model. “Cloud-native” is about howapplications are created and deployed, not where. It implies that the apps live in the public cloud, as opposed to an on-premises datacenter.
The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.
“A cloud native app is architected specifically to run in the elastic and distributed nature required by modern cloud computing platforms,” says Mike Kavis, a managing director with consulting firm Deloitte. “These apps are loosely coupled, meaning the code is not hard-wired to any of the infrastructure components, so that the app can scale up and down on demand and embrace the concepts of immutable infrastructure. Typically, these architectures are built using microservices, but that is not a mandatory requirement.”
For cloud-native applications, the big difference then is really how the application is built, delivered, and operated, says Andi Mann, chief technology advocate at Splunk, a cloud services provider. “Taking advantage of cloud services means using agile and scalable components like containers to deliver discrete and reusable features that integrate in well-described ways, even across technology boundaries like multicloud, which allows delivery teams to rapidly iterate using repeatable automation and orchestration.”
Cloud-native app development typically includes devops, agile methodology, microservices, cloud platforms, containers like Kubernetes and Docker, and continuous delivery—in short, every new and modern method of application deployment.
Because of this, you really want to have a platform-as-a-service (PaaS) model. A PaaS is not required, but it makes things a lot easier. The vast majority of cloud customers start out with infrastructure-as-a-service (IaaS), which helps abstract their apps from the underlying hardware. But PaaS adds an extra layer to abstract the underlying OS, so you can focus entirely on the business logic of your app and not worry about making OS calls.
Differences between cloud-native and on-premises applications
Cloud-native application development requires a very different architecture than the traditional enterprise applications.
Languages
On-premises apps written to run on company servers tend to be written in traditional languages, like C/C++, C# or another Visual Studio language if deployed on a Windows Server platform, and enterprise Java. And if it’s on a mainframe, it’s likely in Cobol.
Cloud-native apps are more likely to be written in a web-centric language, which means HTML, CSS, Java, JavaScript, .Net, Go, Node.js, PHP, Python, and Ruby.
Updatability
Cloud-native apps are always current and up to date. Cloud-native apps are always available.
On-premises apps need updates and usually are delivered on a subscription basis by the vendor, and require downtime while the update is installed.
Elasticity
Cloud-native apps take advantage of the elasticity of the cloud by using increased resources during a use spike. If your cloud-based e-commerce app experiences a spike in use, you can have it set to use extra compute resources until the spike subsides and then turn off those resources. A cloud-native app can adjust to the increased resources and scale as needed.
An on-premises app can’t scale dynamically.
Multitenancy
A cloud-native app has no problem working in a virtualized space and sharing resources with other apps.
Many on-premises apps either don’t work well in a virtual environment or don’t work at all and require a nonvirtualized space.
Connected resources
An on-premises app is fairly rigid in its connections to the network resources, such as networks, security, permissions, and storage. Many of these resources need to be hard-coded, and they break if anything is moved or changed.
“Network and storage are completely different in the cloud. When you hear the term ‘re-platforming,’ that is typically the work to accommodate the changes in networking, storage, and even database technologies to allow the app to run in the cloud,” says Deloitte’s Kavis.
Down time
There is greater redundancy in the cloud than there is on-premises, so if a cloud provider suffers an outage, another region can pick up the slack.
On-premises apps might have failover ready, but there’s a good chance that if the server goes down, the app goes down with it.
Automation
So much of the cloud is automated, and that includes app management. “The benefits of cloud-native delivery, especially speed and agility, significantly rely on a substrate of reliable, proven, and audited known-good processes that are executed repeatedly as needed by automation and orchestration tools rather than through manual intervention,” says Splunk’s Mann. Engineers should look to automate virtually anything they do more than once to enable repeatability, self-service, agility, scalability, and audit and control.
On-premises apps have to be managed manually.
Modular design
On-premises apps tend to be monolithic in design. They offload some work to libraries, to be sure, but in the end it’s one big app with a whole lot of subroutines. Cloud-native apps are much more modular, with many functions broken down into microservices. This allows them to be shut off when not needed and for updates to be rolled out to that one module, rather than the whole app.
Statelessness
The loosely coupled nature of the cloud means apps are not tied to infrastructure, which means they are stateless. A cloud native app stores its state in a database or some other external entity so instances can come and go and the app can still track where in the unit of work the application is. “This is the essence of loosely coupled. Not being tied to infrastructure allows and app to run in a highly distributed manner and still maintain its state independent of the elastic nature of the underlying infrastructure,” Kavis says.
Most on-premises apps are stateful, meaning they store the state of the app on the infrastructure the code runs on. The app can be broken when adding server resources because of this.
The challenges of cloud-native computing
One of the big mistakes customers make is trying to lift and shift their old on-premises apps to the cloud, Mann says. “Attempting to take existing applications—especially monolithic legacy applications—and move them onto a cloud infrastructure will not take advantage of essential cloud-native features.”
Instead, you should look to do new things in new ways, either by putting new cloud-native applications into new cloud infrastructure or by breaking up existing monoliths to refactor them using cloud-native principles from the ground up.
You also need to dispense with your old developer methods. The waterfall model certainly won’t do, and even agile development might not be enough. So, you must adopt new cloud-native approaches like minimum viable product (MVP) development, multivariate testing, rapid iteration, and working closely across organizational boundaries in a devops model.
There are many aspects to being cloud-native, including infrastructure services, automation/orchestration, virtualization and containerization, microservices architecture, and observability. All of these mean a new way of doing things, which means breaking old habits as you learn the new ways. So do it at a measured pace.
