Posts

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 mos

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 Intern

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