Successfully reported this slideshow.
Your SlideShare is downloading. ×

Always On - Zero Downtime releases

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Zero Downtime Deployment
Zero Downtime Deployment
Loading in …3
×

Check these out next

1 of 10 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to Always On - Zero Downtime releases (20)

Advertisement

More from Anders Lundsgård (15)

Recently uploaded (20)

Advertisement

Always On - Zero Downtime releases

  1. 1. Always On Zero Downtime releases for systems with relational databases @anderslundsgard
  2. 2. Always On • What? – New versions of system components deployed at any time without causing downtime for the end user • Why? – Enables Fast turnaround time – Production deployments can be made at any time. Preferably in office hours when the contributors are present. • How? – Automated deployment – Load balanced deploy for webservers – Database changes should be independent on application version
  3. 3. Pre-requirements for Always On • A desire to increase quality and long term maintainability • A desire to reduce the time between production deploys • Versioning of code and database scripts • Tooling for automated deployment – Special tooling for relational databases is a must
  4. 4. How? The deployment of web and database servers
  5. 5. Decoupling database and webserver installations Traditional App (C#, Java) v.98 SQL v.98 App (C#, Java) v.99 SQL v.99 App (C#, Java) v.100 SQL v.100 SQL v.101 App (C#, Java) v.101
  6. 6. Decoupling database and webserver installations Decoupled App (C#, Java) v.98 App (C#, Java) v.99 App (C#, Java) v.100 App (C#, Java) v.101 SQL v.25 SQL v.26 SQL v.27 SQL v.28 SQL v.29 SQL v.30 SQL v.31 SQL v.32
  7. 7. Database server Web1 Web2 Load balancer End users don’t experience any downtime 1. Bring down web server #1 from load balancer 2. Install new version of application on server #1 Updating the web servers 3. Toggle the load balancer 4. Install new version of application on server #2 5. Activate load balancer
  8. 8. Database server Web server 1. Add new schema 2. Write to both schemas 3. Backfill historical data 4. Read from new schema 5. Remove writes to old schema 6. Remove old schema End users don’t experience any downtime Updating the database Read Write Probably after days or weeks
  9. 9. What does this mean to me? • It’s easy! – A database change should always be backward compatible with the old code • Example of what is not doable – Changing a stored procedure so that it changes its interface (in and out parameters) • Solution: Create a new version of the stored procedure – Migrate data to a new structure that is dependent on new data access • Solution: Have parallel writes/reads
  10. 10. @anderslundsgard Questions?

×