CODEWITHSUNDEEP
architecturecloud
Sachin Gaur
Sachin Gaur

Reputation: 13099

What are application level changes when it is deployed on cloud vs on-premise

I would like to know the application wide changes if we use cloud / on-premise.
Cloud based: We do not need to worry about servers, software, scalability, session management, load balancing etc.
On-Premise: All this can also be achieved on-premise.

Example: We can consider a simple web application that stores customer information and another page list all customers details registered in the application. It is being developed using Web API, SQL database & Angular/React as front end technology.

Are there any specific changes to be made in application if we chose either cloud or on-premise?

Upvotes: 0

Views: 537

Answers (1)

ChrisC
ChrisC

Reputation: 2683

You can pretty much do a lift-and-shift of an on-premise application into the cloud without no application code changes.

But if you do that you're pretty much missing the point of the cloud, because you'll still be responsible for patching your servers, configuring your load balancers, optimising your databases, etc.

If your only goal is to reduce physical infrastructure costs and you're not worried about operational costs (e.g. the people that will manage your cloud-based infrastructure) and the cloud is definitely cheaper then you can do this.

However if you want to take advantage of the real benefits of cloud - elasticity and more fully-managed services - then you might want to look at the cloud-native capabilities.

For example (using AWS as an example):

  • Instead of managing a MongoDB database yourself, consider DynamoDB (a fully managed no-SQL database)
  • Instead of a traditional SQL DB like PostgreSQL, consider RDS (a fully managed database-as-a-service supporting multiple DBs like PostgreSQL, MariaDB, MySQL, etc.)
  • Instead of configuring load balancers yourself, consider ELBs (managed network and application load balancers)
  • Instead of running a message broker like RabbitMQ, consider SQS and SNS (lightweight HTTP-based messaging)
  • Instead of a whole lot of virtual EC2 servers running your operating system, application server and microservice code, consider whether you could implement it as a stateless Lambda (function-as-a-service, i.e. nothing but your code, no O/S or application server or container management).

A lot of these services can automatically and seamlessly scale up and down to meet demand, and you only pay for what you use rather than needing to over-provision.

That's just a few ideas about how you could rethink your application design to take advantage of the cloud. Just be aware that you are locking yourself into a vendor on this path.

Edit: OK so if you're planning on building for on premise and then migrating later, the cloud native options above are clearly not going to work, although some are still applicable.

So the simplest approach would be to build your application as normal and then shift to infrastructure as a service (IaaS) with your OS, app server and app running on top of that life it does today. Move your DB to a managed service equivalent. Consider simply discarding your on premise load balancers and using cloud native load balancers at the point of migration.

Another approach would be to use containers, specifically Docker, to package and deploy on premise. You'll need to manage your own Docker cluster on premise, but when you shift your app to the cloud you can host it on a managed service like ECS (AWS Elastic Container Service) or EKS (AWS Elastic Kubernetes Service).

Upvotes: 1

Related Questions