Cloud Application Models.

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.







要查看或添加评论,请登录

Theophilus Bittok的更多文章

  • BGP MTU Discovery.

    BGP MTU Discovery.

    What is MTU and Why is it Important? The Maximum Transmission Unit (MTU) is the maximum size, in bytes, that a packet…

    2 条评论
  • BGP Best External.

    BGP Best External.

    By default, BGP speakers only advertise their best route for a destination. The BGP best external feature allows BGP…

    2 条评论
  • BGP Multihop.

    BGP Multihop.

    External BGP (eBGP) Multihop Support Connections between BGP speakers of different ASs are referred to as External BGP…

    1 条评论
  • IP Time To Live.

    IP Time To Live.

    Time to Live (TTL) is a computer networking term that refers to the lifespan of data on the network. TTL determines how…

  • BGP Max Prefix Limit.

    BGP Max Prefix Limit.

    What is BGP Max Prefix Limit? Border Gateway Protocol (BGP) is essential for routing data across the internet, enabling…

    6 条评论
  • Path Hunting in BGP.

    Path Hunting in BGP.

    BGP is a path vector protocol. This is similar to distance vector protocols such as RIP.

  • BGP Monitoring protocol (BMP).

    BGP Monitoring protocol (BMP).

    What Is BMP? BGP Monitoring Protocol (BMP) is a protocol used for monitoring BGP sessions. Prior to BMP, network…

    5 条评论
  • BGP Slow Peer.

    BGP Slow Peer.

    Update Group A router implementing an Exterior Gateway Protocol (EGP) such as Border Gateway Protocol (BGP), typically…

    5 条评论
  • BGP Add-Path: Enhancing Path Visibility in Networks

    BGP Add-Path: Enhancing Path Visibility in Networks

    BGP routers only advertise the best path to their neighbors. When a better path is found, it replaces the current path.

    7 条评论
  • BGP Multipath.

    BGP Multipath.

    What is BGP multipath By default, BGP does not perform load balancing. BGP will select only a single path for a prefix.

    4 条评论

社区洞察

其他会员也浏览了