Updated with new structure

Author: AndyWardle

source/_posts/2015-01-12-rewrites-and-big-bang-deploys.markdown

@@ -9,11 +9,11 @@ author: Andy Wardle
 
 Developers love to rewrite code:
 * It's always more exciting to work on Greenfield development. 
-* The code you are working on was written by someone else and it is poorly written, hard to understand, or worse * case, it doesn’t do what the business requires. 
+* The code you are working on was written by someone else and it is poorly written, hard to understand, or worse case, it doesn’t do what the business requires. 
 * There are always shiny new things which developers want to use (reactive extensions, event sourcing etc. etc.) and it's not usually feasible to implement these in an existing service 
-(note: I am not advocating rewriting a service just for sake of some new technology or style).
 
 <!-- more -->
+(note: I am not advocating rewriting a service just for sake of some new technology or style).
 
 Most of the time, the business will not let developers spend months rewriting a service on a whim. Why spend a small fortune in developer time refactoring, with no tangible business value added?
 
@@ -29,17 +29,18 @@ Now that we have a bit of experience in performing these rewrites, we have honed
 We have two ways we can combat this to minimise impact to our players:
 * Feature Switching
 * Side by side running
- 
-###Feature Switching
+
 Feature switching is a widely known topic and a lot of information about it is available across the internet. Within this blog post, I want to cover side by side running in a bit more depth, as I feel this has given us huge confidence in knowing how our new services will react when released into Production.
 
+
 ###Side By Side Running
 {% img center /images/tee.png 'Request flow using Tee' 'Request flow using Tee' %}
 
 The diagram above shows the flow of traffic. The request Tee is a very small application sitting beside NGINX that takes the incoming request and duplicates it. The main request carries on to the existing service and the response that is returned is sent back upstream as per normal. The duplicated request is then asynchronously sent to the new version of the service, the response back from the new service is logged and then sent to /dev/null. This allows us to test the new service, with real production traffic, without impacting the existing service.
 
 Sitting in front of the new service is a micro service (Mapper). Its job is to take the incoming request, map it to the contract of the new service before sending it to the new service. It then does the same for the response, mapping from new contract to old contract. Having this mapper service in place allows us to switch to the new service without having to update all upstream clients in one go. We can update them as and when the resource is available. Once all upstream clients are updated to communicate directly with the new service, we can delete the mapper service.
 
+
 ###Data Comparison
 The next benefit from doing side by side running is we can do data comparison between both services to make sure that data between services match. As the services within our platform all publish messages asynchronously, we created an application which consumes messages from both versions of the service and then compares the data. Any discrepancies are logged, which allows us to then find and resolve the issue.
 
@@ -48,5 +49,5 @@ We have used this method for our most recent service and it has given us the con
 * The new service performs as expected (response times, memory / cpu usage etc) 
 * We can release the new service with no impact to upstream clients
 
-
 Going forward, if we ever need to do another service rewrite, we will be using both feature switching and side by side running to give us a high degree of confidence that we won’t negatively impact the gaming experience for our players.
+