Rearchitect applications for cloud with these five tips
It's difficult to fully realize the benefits of cloud computing when you simply migrate an app as is. Instead, consider rearchitecting your app -- and start with these five steps.
While it's possible to migrate almost any application to the public cloud, it's not always a wise, efficient or cost-effective choice. To make the move worth it, developers need to design new applications, or rearchitect existing applications, to take advantage of cloud features.
For those who need to rearchitect existing applications for cloud, here are five important factors to keep in mind.
1. Balance application components and workflow
To optimize applications for cloud, it's generally best to break them down into multiple components -- but this can increase costs significantly. You need to host separate components independently, which adds to the costs. Plus, you need to stitch application components into workflows with network connections, which can also cost more. Before you start, review the benefits and see if the cost is worth it.
If it is, the next step is to determine whether certain application features are always used and scaled together. If they are, it's unlikely that making them into separate application components will increase resiliency or scalability, so it's best to deploy them to the cloud as one component.
If there is a difference in how application features are used, ask whether you're likely to recompose applications from these features, and whether the difference in scalability and resilience is meaningful. Generally, the fewest number of components -- consistent with good scaling and resiliency practices -- is the cheapest and best answer.
2. Cloud scalability and resiliency aren't automatic
The ability to burst a workload from the data center to the cloud, spin up new application copies to improve performance, and replace failed components are all popular cloud benefits. But you can't achieve them without careful application design. Most applications are stateful, meaning that they process requests that contain a sequence of steps. If you spin up a new application or component copy, that copy might not know where it is in the sequence and might cause failures or produce incorrect results.
State control is one of the most difficult parts of rearchitecting applications for cloud. Make sure you manage multistage transactions by their source: the GUI that supports the user. This gives you total control over scalability and resilience. If that doesn't work -- because of the nature of the application -- save the state in a database and share it when you need to replicate or replace application components. Evaluate microservices and serverless features from your cloud provider to see if they'll help control state -- but beware of the cost.
3. Prepare for hybrid and multi-cloud
Because of corporate compliance and governance, most cloud apps need to connect with an enterprise data center to update mission-critical databases that can't move to the cloud. Meanwhile, many public cloud users choose a multi-cloud strategy to reduce downtime risks. You need to design an application for either of these hybrid or multi-cloud architectures, or potentially face cost, performance and reliability issues.
Hybrid or multi-cloud applications exacerbate workflow and scalability issues because almost all cloud providers charge for traffic into and out of their cloud. This means that when you need to scale or replace application components that cross cloud provider boundaries, you'll likely incur new costs. Assess the capabilities of your cloud provider, and any DevOps tools you use, to best control these "border crossings," as well as overall application cost and performance.
Normally, cloud applications work best when their front end is cloud-hosted, and their transaction processing and database update portions resides in the data center. Use this as a reference point to start your application design and deviate only if you have to.
4. Use cloud providers' web services thoughtfully
Cloud providers offer dozens of valuable web services, some of which can radically simplify and reshape applications that move to the cloud. On the flip side, these services can also increase application costs and even pose hidden costs around workflow movement and networking.
When you evaluate these web services, classify your application. Generally, cloud applications are either front-end applications that support a variety of user devices or they are event-driven applications that have a machine-to-machine source for information. Cloud providers have services to support both these models, but compare those services to middleware tools for custom development. In many cases, the one-time cost of those middleware tools will be lower than the ongoing charges for the web services.
5. Seek consistency in the development platform
When you rearchitect applications for cloud, the version of the OS or middleware you select will likely influence the applications' behavior -- and definitely influence your development practices. If you let your application components use their own middleware versions, it might be difficult to keep your platform tools at compatible version levels, which can result in application failures.
Version control for shared application components is especially tricky. If you break an app into components and plan to reuse those components in multiple applications, different uses of those same components might ultimately depend on inconsistent middleware versions. At the least, prepare to update more components in a shared-component application than you think.
