CSC/ECE 517 Spring 2015/ch1a 4 RW - Revision history

Wli29: /* Variation */

2015-02-17T04:36:29Z

Variation

← Older revision		Revision as of 04:36, 17 February 2015
Line 46:		Line 46:
	<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>		<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>
	==='''Variation'''===		==='''Variation'''===
	A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.		A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing<ref>http://martinfowler.com/bliki/CanaryRelease.html</ref>. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
	<br/>		<br/>
	<ul>		<ul>

Rkyadav: /* Database Migration */

2015-02-17T04:20:57Z

Database Migration

← Older revision		Revision as of 04:20, 17 February 2015
Line 34:		Line 34:
	<ul>		<ul>
	<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>		<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
	<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If one need to roll back at this point, it can be done without a need to roll back the database changes.</li>		<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily" (data will migrate as it’s used). If one need to roll back at this point, it can be done without a need to roll back the database changes.</li>
	<li>Finally, once the new version of the app is stable and everything look perfect, apply the update script to finish migrating any old data and remove any old objects. </li>		<li>Finally, once the new version of the app is stable and everything look perfect, apply the update script to finish migrating any old data and remove any old objects. </li>
	</ul>		</ul>

Rkyadav: /* Database Migration */

2015-02-17T04:14:53Z

Database Migration

← Older revision		Revision as of 04:14, 17 February 2015
Line 35:		Line 35:
	<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>		<li>Before the release goes out, add new objects to the database that will be required by that new release.</li>
	<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If one need to roll back at this point, it can be done without a need to roll back the database changes.</li>		<li>Release the new version of the app, which writes to the new objects, but reads from the old objects if necessary so as to migrate data "lazily." If one need to roll back at this point, it can be done without a need to roll back the database changes.</li>
	<li>Finally, once the new version of the app is stable and everything look perfect, apply the ~~contract~~ script to finish migrating any old data and remove any old objects. </li>		<li>Finally, once the new version of the app is stable and everything look perfect, apply the update script to finish migrating any old data and remove any old objects. </li>
	</ul>		</ul>
	<br/>		<br/>

Rkyadav: /* Examples */

2015-02-17T04:13:40Z

Examples

← Older revision		Revision as of 04:13, 17 February 2015
Line 43:		Line 43:

	=='''Examples'''==		=='''Examples'''==
			==='''Blue Green deployment on Amazon AWS'''===
	<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>		<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>
	==='''Variation'''===		==='''Variation'''===

Rkyadav at 04:12, 17 February 2015

2015-02-17T04:12:46Z

← Older revision		Revision as of 04:12, 17 February 2015
Line 42:		Line 42:
	Maintaining two identical production environments require a lot of space and computational resources. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environments. Virtual machines can be used to maintain two separate identical environments as well. Not only system, but many applications have huge databases, and maintaining two copies is a huge financial commitment.		Maintaining two identical production environments require a lot of space and computational resources. This requirement can put a considerable amount of financial burden on companies. In some cases, same machine can be used to host both the environments. Virtual machines can be used to maintain two separate identical environments as well. Not only system, but many applications have huge databases, and maintaining two copies is a huge financial commitment.

	=='''Variation'''==		=='''Examples'''==
			<p>Many cloud service providers <ref>http://searchcloudprovider.techtarget.com/definition/cloud-provider</ref> are releasing new products for web services hosting<ref>http://en.wikipedia.org/wiki/Web_hosting_service</ref>. Amazon web services <ref>http://aws.amazon.com/</ref> is one such product from Amazon <ref>http://www.amazon.com/Careers-Homepage/b?ie=UTF8&node=239364011</ref>. Amazon Elastic Compute Cloud (Amazon EC2) <ref>http://aws.amazon.com/ec2/</ref> is a web service that provides re-sizable compute capacity in the cloud. User can select to either host web services using single instance or multiple instances of EC2. In single instance hosting, each instance of AWS (Amazon Web Serivices) has a private and a public IP address assigned to it. Public ip address can be accessed from outside world, while private ip address is for internal access. During blue green deployment in AWS, for single EC2 instance, switching between instances is as simple as an API<ref>http://en.wikipedia.org/wiki/Application_programming_interface</ref> call. It's easy to replicate current production instance and run updates on that. After updates, all the new in-coming requests can be routed to this system by assigning public ip address to this new instance. Amazon web service provides an API call to assign public ip address to any instance. Older instance can still be accessed using private ip address. Same method cannot be used for multiple EC2 instances. For multiple instances, entire pool has to be changed with a new version of application, which can be achieved either by automating a series of API calls or using AutoScaling <ref>http://aws.amazon.com/autoscaling/</ref> groups</p>
			==='''Variation'''===
	A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.		A variation on blue-green deployment, applicable when running a cluster of servers, is canary releasing. With this pattern, rather than upgrading a whole cluster to the latest version all at once, you do it incrementally. For example, as described in an excellent talk by Facebook's release manager, Chuck Rossi, Facebook pushes new builds to production in three phases.
	<br/>		<br/>

Rkyadav: /* Challenges */

2015-02-17T03:03:35Z

Challenges

← Older revision		Revision as of 03:03, 17 February 2015
Line 27:		Line 27:
	By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.		By using read only constraint on database during transition, Blue-Green deployment can be used to achieve almost zero down time. In case of error, roll back from new version to older version is almost immediate.

	=='''~~Challenges~~'''==		=='''Disadvantages'''==
	===Database Migration===		===Database Migration===
	As explained before, we need two databases servers. If things are not planned properly, users may easily end up working against an old Green database. The database migration during transition should be kept a minimal as possible. System should be made read only for most of the operations right before transition starts. Load any remaining data changes from the blue to the green, that may have occurred during transition (which should be relatively small, and a quicker operation in theory). Though a perfect zero downtime cannot be achieved using this, but a near zero downtime can be easily achieved.		As explained before, we need two databases servers. If things are not planned properly, users may easily end up working against an old Green database. The database migration during transition should be kept a minimal as possible. System should be made read only for most of the operations right before transition starts. Load any remaining data changes from the blue to the green, that may have occurred during transition (which should be relatively small, and a quicker operation in theory). Though a perfect zero downtime cannot be achieved using this, but a near zero downtime can be easily achieved.

Rkyadav at 03:01, 17 February 2015

2015-02-17T03:01:31Z

← Older revision		Revision as of 03:01, 17 February 2015
Line 1:		Line 1:
	<font size="5"><b>Blue-Green Deployment</b></font>		<font size="5"><b>Blue-Green Deployment</b></font>

	This article is a part of a writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref>		<i>This article is a part of a writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref> </i>
	<p>		<p>
	Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.		Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.

Rkyadav at 03:00, 17 February 2015

2015-02-17T03:00:58Z

← Older revision		Revision as of 03:00, 17 February 2015
Line 1:		Line 1:
	<font size="5"><b>Blue-Green Deployment</b></font>		<font size="5"><b>Blue-Green Deployment</b></font>

	This article is a part of writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref>		This article is a part of a writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref>
	<p>		<p>
	Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.		Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.

Rkyadav at 03:00, 17 February 2015

2015-02-17T03:00:47Z

← Older revision		Revision as of 03:00, 17 February 2015
Line 1:		Line 1:
	<font size="5"><b>Blue-Green Deployment</b></font>		<font size="5"><b>Blue-Green Deployment</b></font>

			This article is a part of writing assignment<ref>https://docs.google.com/a/ncsu.edu/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit</ref>
			<p>
	Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.		Blue-Green deployment is a technique used to reduce risk and delay in continuous integration<ref>http://martinfowler.com/bliki/BlueGreenDeployment.html</ref>. It uses an exact copy of production environment, where new changes can be deployed and production testing can be done. After running successful tests, we can just point router<ref>http://en.wikipedia.org/wiki/Router_%28computing%29</ref> to this copy and make it production. In case of any error in system after deployment, system can be rolled back by re-pointing router to old application instance. This process reduces the production downtime during migration and expedite any rollback operation<ref>http://en.wikipedia.org/wiki/Rollback_%28data_management%29</ref> needed.
			</p>
	__TOC__		__TOC__

Rkyadav: /* Background */

2015-02-17T02:57:34Z

Background

← Older revision		Revision as of 02:57, 17 February 2015
Line 7:		Line 7:

	=='''Background'''==		=='''Background'''==
	<p>     Software applications are becoming more and more complex. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology has reduced release-time of new piece of code. On an average, Amazon is pushing changes to production every 11.6 seconds<ref>https://www.youtube.com/watch?v=dxk8b9rSKOo</ref>. Google and Facebook <ref>http://www.infoq.com/presentations/Facebook-Release-Process</ref>are releasing frequent changes to production. With new updates and features going into production at such a remarkable frequency, a need was felt to automate production deployment. </p><p>     More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery <ref>http://en.wikipedia.org/wiki/Continuous_delivery</ref> is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time".		<p>     Software applications are becoming more and more complex. Software development life cycle is trying to adapt to this new paradigm by implementing ways to release new features/updates as frequently as they can be conceptualized. Agile methodology<ref>http://en.wikipedia.org/wiki/Agile_software_development</ref> has reduced release-time of new piece of code. On an average, Amazon is pushing changes to production every 11.6 seconds<ref>https://www.youtube.com/watch?v=dxk8b9rSKOo</ref>. Google and Facebook <ref>http://www.infoq.com/presentations/Facebook-Release-Process</ref>are releasing frequent changes to production. With new updates and features going into production at such a remarkable frequency, a need was felt to automate production deployment. </p><p>     More and more software development houses are using Continuous Integration (CI) nowadays. In continuous integration, a new piece of software is easily integrated into existing application code, and tested to make it ready for release. With continuous integration becoming a norm, continuous delivery <ref>http://en.wikipedia.org/wiki/Continuous_delivery</ref> is becoming a necessity. As per Martin Fowler, "Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time".
	Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.</p>		Continuous delivery demands ability to automate deployment on production and create environment that can support frequent deployments. One of the challenges of automated deployment is to take software from test environment to live production. The new update may include a change in database schema as well. Updating existing production database server without bringing application down, is an arduous and risky task. Many business domains expect a minimum downtime for such updates, while maintaining a need for continuous delivery.</p>
	Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.		Blue-Green deployment provides a solution for continuous delivery by using two nearly identical production environments. One environment, which is in production at the moment is called Blue and other environment is called Green.