Torbz - Fotolia
Decide between cloud-native apps and app modernization
Whether you want to update current workloads as part of a migration or you're leaning toward a cloud-native model, review the benefits and drawbacks of each approach first.
By now, most organizations realize that simply migrating an existing application as-is to the cloud isn't going to generate compelling benefits. Instead, they need to look into cloud-native apps or modernize existing workloads to take full advantage of the technology.
But first, they must understand the difference between modernized and cloud-native applications. The best approach depends on the workload, as well as IT teams' skill sets and the cloud features they value most.
When modernizing applications, enterprises typically build the front end with scalable, distributable components. These are often obtained from cloud provider web services or third-party software. The focus is on the user interface, which makes them a kind of extension to web servers.
In contrast, the cloud-native approach aims to decompose most -- if not all -- portions of an application that are scalable and distributable so they can be implemented as stateless microservices. This produces a better fit for the cloud and enables enterprises to deploy more of an application's components onto it.
Three issues typically dictate which of these approaches is best for a given application: software implementation flexibility, hybrid boundary location and application load characteristics.
1. Software implementation flexibility
Not every workload is a good candidate for application modernization. Third-party applications often can't be modified. Open source apps can theoretically be altered, but that involves a major learning curve and many development tasks. And modernization of third-party software is often limited to customizable front ends.
It can also be difficult to modify in-house software, particularly if it's older. The source code and documentation may be obsolete and the programming skills needed for modernizing applications may be difficult to obtain. In this scenario, it would be best to perform a limited modernization on what can be viably updated for the cloud.
2. Hybrid boundary location
Understand where you need to draw the line between what's hosted in the cloud and what stays in the data center. Typically, those determinations come down to factors such as compliance rules and data security, and enterprises often find they need to leave core business components and related software on premises. Modernization or cloud-native development may not be beneficial in those cases, especially if little of the application outside the front end is suitable for the cloud.
However, parts of a core on-premises application could be redeveloped to be cloud-native if the app has loosely coupled features and low data exchanges. This rebuild would significantly improve the response of the application to load changes, but only if the core components on the other side of the hybrid boundary can handle the load. The volume of data exchanges is also an important factor, since cloud egress fees can quickly rack up.
High-volume, back-end transaction processing is much more involved than the front-end processing, since it almost always involves accessing and updating databases. Most enterprises have already built or acquired applications to handle those processes in the data center.
Database activity is inherently stateful; a database records the state, which transactions can then alter. Enterprises may be able to use cloud-native techniques in some parts of a core application, such as the pieces that edit information and report activity. For the database part of the application, you'll need to do a design review on your high-speed transaction processing tools to ensure you don't leave the database behind if you make your application front end fast and scalable.
3. Characteristics of the application load
The cloud excels at scaling and distributing application processes. If your application is only lightly used, hosting it in the cloud may not deliver significant benefits. However, modernizing applications that are used heavily and steadily will benefit from the cloud. For large and highly variable workloads, migrating as much of the application in cloud-native form provides the best outcome.
A poor candidate for a cloud-native workload is one driven by transactions that are inputted by a limited number of employees. The size of the workforce would limit the transaction volumes, which likely wouldn't vary much over time. There would be little value in the scaling capabilities of the cloud for this type of app. And while it could benefit from being containerized, it wouldn't require microservices or cloud-native approaches.
On the other hand, consider this same application but change the input source from a community of employees to a set of customers and partners who can access the app via online portals. Now, it's likely that the application could experience major shifts in activity.
For example, a marketing campaign or even a single TV commercial could result in a burst of activity that, without preparation, could break the application, negatively impact customer experience and ruin the campaign. This type of workload is a great candidate for a cloud native app.
Think about the benefits of each approach before you decide on one. Cloud native is well suited to applications that aren't tightly coupled with the state of an account or an inventory item -- you can scale or replace them at will. Cloud-modernized applications take advantage of cloud resilience and also offer some scalability advantages, but they're closer to traditional transaction processing. Determining where your needs fit on that spectrum will go a long way in helping to guide your cloud strategy.
