Blue skies: Designing apps for cloud portability

  • Large scale cloud providers offer services that can greatly enhance your business applications, allowing them to do things they otherwise couldn’t. 

  • Proprietary systems can lock-in app capabilities and vendors, meaning that moving your apps in the future could be difficult.

  • Designing apps for portability, such as using cloud services to augment instead of replace them, can future-proof core elements of your business.

Remember the days when a major upgrade was happening in the server room and everyone would have to log off their machines and head out for an early lunch?

Cloud computing changed all that. In 2006, Amazon Web Services first allowed businesses to run their software (aka applications) on virtual computers in its cloud infrastructure. From that time, organisations no longer needed to manage physical servers and better still, employees had no idea their programs worked anywhere other than ‘in their computer’. It was to be a revolutionary step in cloud computing.1

Fifteen years on, the largest cloud providers (called hyperscalers, such as Amazon Web Services, Microsoft Azure and Google Cloud Platform) offer services all the way up to (and including) the ‘application layer,’ that can deliver end-to-end features and capabilities for your business apps — far more than just the infrastructure they run on. 

In the same way that you might consider yourself an Apple or an Android household when it comes to your smartphones, there can be limits on how easy it is to switch or move apps between cloud ecosystems. Application layer cloud services help you directly solve business problems, not just technology problems, yet for this very reason they can prove stickier when it comes to moving apps from, or between, providers. So how do you realise the benefits of these services without sacrificing flexibility? 

Application portability 

Adopting cloud services that directly solve your business problems — such as plug-in AI search, document extraction and data redaction — provides obvious benefits. It’s also true, however, that using public cloud services for your business apps is similar to outsourcing a capability, and means a greater reliance on a third party ecosystem. 

It can be hard without forward planning to detach your business apps from that system should you want to do so down the road. But if you develop your own business apps, with the right principles and architecture governance, it is perfectly possible to have your cake and eat it too — enabling you to move your apps from the cloud back to on-premise or to an entirely different cloud provider. 

This is what we call ‘application portability,’ and essentially, it means designing your apps with high migratability while keeping the cost and complexity of moving as low as possible. 

Why move?

The importance of application portability depends on the nature of the business application, how critical it is to your business and how long you plan to use it. If you are highly dependent on the application to run your business, and that application has significant third party dependencies, application portability should be considered - even if there is no imminent plan to move between cloud providers.

As an example, at PwC we use a number of public cloud services at the application layer for one of our machine learning automation apps. By using these services, we benefit from higher automation accuracy rates, faster development cycles and simplified scalability. 

However, to service a highly regulated market within a region that's unable to use public cloud, we recently needed to deploy this application onto ‘bare metal’ — an on-premise data centre that is entirely detached from the public cloud. By maintaining application portability as a design goal from day one, we were able to make this transition with almost no architectural or code changes.

Designing for application portability

To build portability into your business apps, there are four principles that we recommend:

Use public cloud’s proprietary tech to augment your apps’ core features rather than to replace them

For example, a critical feature in our machine learning automation app is Optical Character Recognition (OCR) — the ability to convert typed content or handwriting from an ‘image’ into machine-readable text. Each of the hyperscalers have OCR services with different strengths (eg. specific languages, handwriting recognition), but their services (understandably) also have their own proprietary data schemas and interfaces. 

Instead of developing our application’s OCR feature using a single cloud service, we used an open-source OCR solution as our ‘base’, and augmented accuracy rates by using a combination of several OCR services from the hyperscalers; switching based on language and region. In this way, our use of public cloud’s proprietary OCR tech is an extra addition, not critical to the open-source base application.

Explore cloud services that are based on open-source standards, frameworks and protocols

Large cloud providers have some incredible application layer services, but some of those offerings require the use of their exclusive software development kits, protocols and data schemas which could work against later portability.

Cloud services that are developed using common open-source standards often have lower portability risk. Where a viable alternative exists and portability is a goal, opt to use these services instead. 

The good news is that the hyperscalers are making this easier by shifting to open-source alternatives (or making their own standards open-source), so keep an eye out on their offerings, too.

Use services that support hybrid cloud and on-premise deployments

Hybrid cloud solutions use on-premise infrastructure to run private clouds, where computer resources are made virtual in much the same way as those of public clouds. 

Some cloud providers have their own hybrid cloud and on-premise offerings which can simplify your migration to other cloud or local environments.

Not all hybrid solutions support all of the services that are offered through traditional cloud models, so it can be beneficial to check whether the services that you plan to use are included. Additionally, some services are also available to deploy on-premise as self-contained packages, which enable you to transition easily.

Make intentional outsourcing decisions for core business competencies

It’s important to consider how a new cloud service relates to your core business. For example, if you are running a home loan business, outsourcing the management of your servers (a non-core aspect of your business) might make sense, but a core application feature in your lending application process would be more important to keep control of.

In most cases, application layer cloud services are available to use under the same contracts that you have in place for infrastructure and platform cloud services, and you can easily rely on these services without it leading to the strategic conversations you would normally have when outsourcing.

There is nothing wrong with using application-layer cloud services — it may be the right choice for your business — but it’s important that you are doing so consciously and with a strong focus on vendor lock-in risks and portability, particularly if those capabilities relate to your core business.

Weighing up the pros and cons

The above principles are not mutually exclusive, nor are they collectively exhaustive. They should be applied depending on the context of each capability and the importance of portability for each of your business apps.

There are enormous benefits to realise from using application layer cloud services. They simplify the IT value chain, provide access to cutting-edge features you might not be able to afford or run on-premise, and in the end, these will help to solve business problems, not just technology ones. By establishing the right design principles to guide decision-making, you can leverage these services without it coming at the expense of application portability.