Journey of an on-premise web application to cloud

This post is helpful to guide any person/ organization who have their web application hosted on-premise or on some vendor servers and have futuristic view that they see their user base to grow in coming future. It's understood that initially it would sound difficult to move an application to cloud because we do not know if our application is fit to run on cloud. 

The phases below show approach that a Cloud Architect would adopt to migrate a web application hosted on non-cloud environment to cloud.

Phase I  [Initial adoption phase to understand if our application can run on cloud]	Phase II  [Now that application runs and we are happy, adopt the best practices of Cloud computing]	Phase III  [Try adopting to Cloud services]	Phase IV  [Cost cutting]
* Lift and shift the application as is into Docker and push to cloud.  * Backend database into separate EC2 instance.  * Deployment pipeline.	*Break big application into smaller chunks, Microservices to be introduced for most of the transaction to enhance performance.   * Microservices wrapped in containers.  * Introduce communication channel between components like RabbitMQ or SNS/SQS   * ELK for storage of logs, analysis and visualization for application and infrastructure monitoring, faster  troubleshooting, security analytics, etc.	* Check for Cloud services for Middleware, replacing your backend DB with RDS.  * Make use of Adapters that connects to Cloud services, shielding our application from a Cloud specific API.	* Define the minimum required instances [Dedicated/ Reserved capacity], based on this information connect with Cloud provider and have a contract defined.

Log shipping vs Mirroring vs Replication for Data Architects/ DBAs

Log Shipping: 

It automatically sends transaction log backups from one database (Known as the primary database) to a database (Known as the Secondary database) on another server. An optional third server, known as the monitor server, records the history and status of backup and restore operations. The monitor server can raise alerts if these operations fail to occur as scheduled.  

Mirroring: 

Database mirroring is a primarily software solution for increasing database availability. 

It maintains two copies of a single database that must reside on different server instances of SQL Server Database Engine. 

Replication: 

It is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. Using replication, you can distribute data to different locations and to remote or mobile users over local and wide area networks, dial-up connections, wireless connections, and the Internet. 

Basic requirements for each of them

 
Log Shipping

• The servers involved in log shipping should have the same logical design and collation setting. 
• The databases in a log shipping configuration must use the full recovery model or bulk-logged recovery model. 
• The SQL server agent should be configured to start up automatically. 
• You must have sysadmin privileges on each computer running SQL server to configure log shipping. 

Mirroring

• Verify that there are no differences in system collation settings between the principal and mirror servers. 
• Verify that the local windows groups and SQL Server logins definitions are the same on both servers. 
• Verify that external software components are installed on both the principal and the mirror servers. 
• Verify that the SQL Server software version is the same on both servers. 
• Verify that global assemblies are deployed on both the principal and mirror server. 
• Verify that for the certificates and keys used to access external resources, authentication and encryption match on the principal and mirror server. 

Replication

• Verify that there are no differences in system collation settings between the servers. 
• Verify that the local windows groups and SQL Server Login definitions are the same on both servers. 
• Verify that external software components are installed on both servers. 
• Verify that CLR assemblies deployed on the publisher are also deployed on the subscriber. 
• Verify that SQL agent jobs and alerts are present on the subscriber server, if these are required. 
• Verify that for the certificates and keys used to access external resources, authentication and encryption match on the publisher and subscriber server. 

DB terms ABC - ACID, BASE and CAP

 

ACID is an acronym which is commonly used to define the properties of a relational database system, it stand for following terms 

• Atomicity - This property guarantees that if one part of the transaction fails, the entire transaction will fail, and the database state will be left unchanged. 

• Consistency - This property ensures that any transaction will bring the database from one valid state to another. 

• Isolation - This property ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed serially. 

• Durable - means that once a transaction has been committed, it will remain so, even in the event of power loss. 

• 
  

BASE properties are the common properties of recently evolved NOSQL databases. According to CAP theorem, a BASE system does not guarantee consistency. This is a contrived acronym that is mapped to following property of a system in terms of the CAP theorem 

• Basically available indicates that the system is guaranteed to be available 

• Soft state indicates that the state of the system may change over time, even without input. This is mainly due to the eventually consistent model. 

• Eventual consistency indicates that the system will become consistent over time, given that the system doesn't receive input during that time

•  

CAP theorem for distributed computing was published by Eric Brewer, This states that it is not possible for a distributed computer system to simultaneously provide all three of the following guarantees: 

1. Consistency (all nodes see the same data even at the same time with concurrent updates ) 

2. Availability (a guarantee that every request receives a response about whether it was successful or failed) 

3. Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system) 

 
The CAP acronym corresponds to these 3 guarantees. This theorem has created the base for modern distributed computing approaches. World's most high volume traffic companies (e.g. Amazon, Google, Facebook) use this as basis for deciding their application architecture. It's important to understand that only two of these three conditions can be guaranteed to be met by a system.