How to Deploy Services:
Deploying or upgrading services is risky, Let’s understand different deployment services :
Multi-Service Deployment
In this strategy, all nodes within a target environment are updated with multiple new services simultaneously. This strategy is used for application services that have service or version dependencies or deploying off-hours to resources that are not in use.
Pros:
Deployments are simple, fast, cheap not so risky
Cons:
Deployments are slow to roll back and not outage-proof. Using this deployment strategy also leads to difficulty in managing, testing, and verifying all the service dependencies.
Blue-Green Deployment
This strategy utilizes two identical environments, a “blue” (aka staging) and a “green” (aka production) environment with different versions of an application or service.
Quality assurance and user acceptance testing are typically done within the blue environment that hosts new versions or changes.
User traffic is shifted from the green environment to the blue environment once new changes have been tested and accepted within the blue environment
Pros:
it is simple, fast, well-understood, and easy to implement. Rollback is also straightforward because you can simply flip traffic back to the old environment in case of any issues. Blue-green deployments are therefore not as risky compared to other deployment strategies.
Cons:
Cost is a drawback. Replicating a production environment can be complex and expensive, especially when working with microservices.
Canary Deployment
A strategy that releases an application or service incrementally to a subset of users. All infrastructure in a target environment is updated in small phases
it’s the lowest risk-prone, compared to all other deployment strategies, because of this control.
Pros:
it allows organizations to test in production with real users and use cases and compare different service versions side by side.
It’s cheaper than a blue-green deployment because it does not require two production environments. it is fast and safe to trigger a rollback to a previous version of an application.
Cons:
it involves testing in production and the implementations needed. Scripting a canary release can be complex
A/B Testing
Different versions of the same service run simultaneously as “experiments” in the same environment for a period of time.
Commonly, user traffic is routed based on specific rules or user demographics to perform measurements and comparisons between service versions. Target environments can then be updated with the optimal service version.
Pros:
Easy, and cheap method for testing new features in production.
Cons:
It involves the experimental nature of its use case. Experiments and tests can sometimes break the application, service, or user experience. Finally, scripting or automating AB tests can also be complex.
Known issues
When using the Dynamic Driver Provisioning (DDP) feature on a WDS server running Windows Server 2012 if you attempt to add a driver to a Windows 8.1 or Windows Server 2012 R2 boot.wim you may receive the following error when running the “Add driver packages to image” wizard:
An error occurred while trying to execute the command. Error Code: 0xc0000135
This is a known issue related to the DISM version included with Windows Server 2012 that is used by WDS to service images. This version of DISM supports servicing Windows Server 2012 and earlier boot images but does not support later versions of boot images. You can resolve this issue by upgrading your WDS server to Windows Server 2012 R2 which contains a DISM version that supports servicing Windows 8.1 and Windows Server 2012 R2 boot.wim’s or you can install the Windows 8.1 ADK and manually add the driver to the boot.wim. For instructions on how to add drivers, see Add and Remove Drivers Offline Using DISM
credits:https://lnkd.in/diW8VCb5
