Getty Images/iStockphoto
Should you migrate your on-premises app or go cloud-native?
Learn how cloud-native application development differs from traditional architecture, as well as the benefits and challenges in making the switch.
Developing an application is never an easy process. The architecture and engineering choices require careful planning to ensure performance, security and an overall good user experience. But should you migrate your on-premises application to the cloud or opt for a cloud-native approach, such as a SaaS offering?
Cloud adoption shifts the responsibility for and support of the underlying infrastructure from IT teams to the cloud provider. In addition, cloud adoption expands what the application stack can do -- the application's design is not limited by the local infrastructure.
A cloud approach provides many benefits, including more database options, as well as integration with serverless and other services. But before you decide to migrate your on-premises apps to the cloud, set reasonable expectations around the time, effort and cost involved. Then, see if a cloud-native approach, such as a SaaS offering, is a better option.
Consider database needs
A key component for most applications is the database.
The monolithic application design was the preferred choice in enterprise environments for years. Though it is complex, it also has the benefit of first-in, first-out data processing simplicity. A distributed application, which runs on multiple computers within a network at the same time, relies on separate components coupled together to create an overall app. Distributed applications often have timing challenges related to when data is processed and when it comes in.
Local, on-premises applications typically rely on SQL or Oracle databases, as well as running in a database cluster with logging, snapshots and replicas. A cloud provider, such as AWS, offers various options for database performance, stability and cost savings, but the cloud customer sacrifices some control over the application.
Putting an application on the cloud doesn't make it distributed or event-driven. It is called a forklift or lift-and-shift move of a monolithic, on-premises application into the cloud. Providers can host a compute virtual node, where IT teams can install an OS and SQL setup, and have it work just like it does in the local data center. However, this setup doesn't take advantage of the cloud's benefits.
While some organizations resist this change, think of it as a mindset issue rather than a technical problem. Cloud providers offer a massive selection of database services, such as Amazon Relational Database Service (RDS), Microsoft Azure Cosmos DB and Google Cloud Spanner.
In general, any database technology that an application needs is already available in the cloud. You just have to be willing to use it. Cloud providers offer multiple instances, snapshots and I/O control for databases, among other features.
On-demand resources for code execution
How you run application code can also help you decide if a cloud-native application is the right fit. With a monolithic design on local hardware, the compute resource runs the code based on a trigger from an end-user event, another process or timing aspect. In a data center, the compute resources are always there.
On-demand consumption is a shift away from self-contained local deployment to shared resources. Cloud compute resources are not dedicated to one customer or another. Cloud applications can consume compute resources on-demand, which saves resources and, more importantly, money.
Serverless is fine-tuned, on-demand cloud consumption where the application's code components only run when triggered, rather than code waiting in cloud instances for action. Serverless, event-driven code is not dependent on the previous function's completion, as its trigger can come from multiple sources.
There are benefits and perceived risks that come with serverless code execution -- perceived risks, as the problem that would disrupt a serverless function would likely affect other aspects of the cloud provider. In that scenario, the risk of serverless isn't greater than that of a more traditional server stack on cloud services.
Cloud services are tightly integrated with each other. Cloud adopters can set up automation between the services. For example, a deposit in an Amazon S3 bucket can trigger a Lambda serverless function to add to a database. A monolithic, local application stack can execute this same task, but it has more resources involved. The application team must support all these resources.
Should you choose cloud for your application?
Cloud adoption continues to rise but that doesn't mean your on-premises application belongs there. It's difficult to say if the journey from monolithic, on-premises applications to cloud-native models will be easy. Here are some factors to consider:
- Migration. Cloud providers have extensive tools to import code, databases and other aspects of applications, but an application designed for local operation is not designed for a cloud environment. While the provider's services natively work together, the infrastructure team must be involved to ensure everything in the application can operate in the cloud.
- Security. Cloud providers take security seriously. Everything you do in their environment is by explicit permission. Work with that model, not against it. Resist opening firewalls, permissions and access just to make something work. Code might have to be adjusted to work with this access model, but it's worth it in the end for both your company and users. Expect to spend time debugging and doing initial configuration work within this new security framework.
- Cost and choice. The cost and effort to make an application work correctly on cloud resources are significant. Also, applications running on cloud resources generate a monthly bill that never goes away. Cloud vendor lock-in is an additional challenge. The vendor might make changes in the cloud stack that you don't like or are not ready for.
But most of these challenges exist with the traditional on-premises application stack, too. We got used to them in the data center, and we will get used to them in the cloud.
