Cloud Application Models.

There are a lot of “cloudy” terms out there now. Is cloud-native better than cloud-based? Am I considered in the “cloud” when my application is cloud-enabled? Let's compare three of the most popular models: cloud-native vs. cloud-based vs. cloud-enabled. While we'll explore the general characteristics of each of these models, the true meaning of these terms lies in the eyes of their beholders.

Cloud-Enabled Applications

Cloud-enabled usually refers to applications built traditionally and then migrated to the cloud. These applications were originally designed in a monolithic fashion and depend on local resources and hardware. In the migration of the application to the cloud, the application is refactored to use virtual resources, but the underlying architecture remains the same. The application cannot take advantage of shared services or resource pools and as a result struggles to deliver the scalability and resiliency of other cloud applications.Cloud enabled can be an approach for legacy applications or as the first step towards cloud adoption.

Cloud-enabled app use cases

Cloud-enabled apps are good fits for situations where businesses want to move a legacy app to the cloud in order to avoid having to maintain on-premises host infrastructure. However, because the underlying architecture stays the same, it doesn't reap the?benefits of the cloud, such as optimized performance.

Cloud-Based Applications

Cloud-based is the middle ground between cloud-native and cloud-enabled. If you want to leverage some of the capabilities of the cloud such as higher availability and scalability, but don’t want to completely redesign your application to use cloud services, this may be an approach to consider. For example, if you move your in-house web application to?AWS?or Azure servers, you now have a “cloud-based” application.

Once you move your application to a cloud provider, you’re no longer responsible for managing the resources for the application, so there’s no need to maintain a server or worry about backup. You also just pay for what you use. The biggest advantage of moving an application to the cloud is enabling it to quickly scale up to meet surges in demand and increase your application availability.

Cloud-Native Applications

Cloud-native is born in the cloud. Cloud-native applications are architected from the ground up to run in a public cloud like in AWS, Azure, or GCP using cloud-based technologies. These cloud technologies allow for accessibility and scalability and allow developers to continue to deliver new services more quickly and easily. Cloud-native is comprised of continuous integration, orchestrators, and container engines. Ultimately, it’s about how applications are created and deployed.

Cloud-native is a new way of architecting our applications and infrastructure; we’re breaking services into smaller and smaller pieces and reusing services wherever possible. We’re deploying our apps and infrastructure in someone else’s data center, so we have to always be thinking about failure. Having this mindset allows us to deploy new, flexible, resilient, cloud-native applications.

Cloud-Native vs Cloud-Based Applications

These new technologies focus on a few key areas.

1. Design

Cloud-native: Must think about failure, so the application must be designed to handle different failure domains. Use microservices architecture.

Cloud-based: Was built on traditional servers hosted in an on-premises data center. Was designed for availability.

2. Ease of Use

Cloud-native: Applications are flexible and built to scale and because of the microservice architecture; areas of an app can be upgraded without disruption.

Cloud-based: Applications are tightly integrated, and upgrades may be needed for the entire stack, causing downtime.

3. Implementation

• Cloud-native: Faster to deploy because there is no hardware or software to deploy.
• Cloud-based: Slower because of hardware provisioning or software setup.

4. Maintenance

• Cloud-native: Interruptions are limited because of the microservice architecture.
• Cloud-based: Interruptions can occur because of hardware migrations or specialized software configurations.

5. Pricing

• Cloud-native: Cheaper because you’re paying for licenses and storage costs in the cloud provider.
• Cloud-based: More expensive because you have to own the whole stack and may need to purchase hardware, power, and cooling before the application can be deployed.

Cloud-based app use cases

Any application could run as a cloud-based app. As such, the cloud-based model supports almost every type of application use case. The only apps that aren't excellent candidates for cloud-based deployment are those that need to remain on premises to meet compliance, security or?data sovereignty requirements.

Cloud-native app use cases

Cloud-native applications have become the default strategy for IT teams today. When building an application from scratch, it makes sense to use a cloud-native approach, provided developers have the resources to do so.

Choose the right type of cloud application

When deciding which type of cloud application model to use, there are four main factors to consider.

1. Development resources.?Cloud-native applications require the most skill to build. Businesses with small development teams or limited time to complete an app should choose a simpler type.

2. Performance.?Cloud-enabled and generic cloud-based applications aren't likely to perform as efficiently as well-designed cloud-native applications.

3. Cloud service dependency.?If developers deploy a generic cloud-based application with a cloud service that is specific to a certain cloud platform, such as Elastic Beanstalk, it may be harder to move to a different cloud in the future. In contrast, a cloud-native application hosted in Kubernetes can migrate to any cloud that supports Kubernetes.

4. Deployment and orchestration complexity.?Cloud-native applications are more difficult to deploy and manage because they have more moving parts. IT teams will typically need to use an orchestration tool. Simpler cloud-based apps hosted in VMs don't require special orchestration layers.