Chances are, you’re either building a net-new application in the cloud or using native technology such as serverless or machine learning. Or, you’re porting an application to the cloud, either refactoring it to leverage native services, or lifting and shifting with little or no modification to the code or data.
How do you ensure these applications last more than a few years on the cloud? In other words, how do you future-proof them? I have a few core recommendations.
First, watch the use of native cloud services that are unlikely to be around long term. Although everyone is fond of serverless systems these days, those systems will certainly change within a few years. Sometimes the changes will favor the applications, meaning the applications will have ongoing enhancements; or the system might fall by the wayside in the cloud marketplace if the technology it uses falls out of favor.
I’m not specifically picking on serverless development and deployment. It could just as easily be cloud-native machine learning, or cloud-native databases. In short, we’re placing bets that cloud-native machine learning, cloud-native databases, and serverless will provide an easier path to development and deployment. However, this path opens the potential to lock us into enabling technology that may at some point be eclipsed by something better.
Second, while we can pray to the open source gods and go all-in with open source technology, there are trade-offs here, as well. The advantages, of course, is that open source systems are supported by most private and public clouds, and they are owned and maintained by a community of users. Moreover, there are many solution types these days, such as databases, AI systems, operating systems, you name it.
The trade-off is that they drive additional work in exchange for diminished risk. This means it will require much more coding and architecture time to build cloud-based applications using open source products. Compare this to the ease and speed with which you can build similar systems using cloud-native systems, such as serverless development and deployment.
So, what’s an application architect to do? How do you make the right calls to keep an application alive longer? At its core, this is the same problem we’ve dealt with for the last 20 years. Do we use proprietary technology that provides additional productivity, or use systems that are open but take more time and DIY efforts?
My best advice is that you consider all options to find the best solution for your application development approach. Find or become the expert. View each potential solution through a one- or two-year lens, and then a three- to five-year lens. It always surprises me how many people skip the long view when there are major technology shifts in application development. It’s worth taking the time to learn about the possibilities or find outside expertise to provide knowledgeable advice before you pull the trigger.