Update from Capgemini/blog-private@1bea671

_posts/2014-10-17-microservices-reality-check.md

@@ -12,7 +12,7 @@ share: true
 
 It's reached the point where it's even a cliche to state "there's a lot written about Microservices these days." But despite this, here's another post on the topic. Why does the internet need another? Please bear with me...
 
-We're doing Microservices. We're doing it based on a mash-up of some "Netflix Cloud" (as it seems to becoming known - we just call it "[Archaius](https://github.com/Netflix/archaius) / [Hystrix](https://github.com/Netflix/Hystrix)"), a gloop of [Codahale Metrics](https://github.com/codahale/metrics), a splash of [Spring Boot](http://projects.spring.io/spring-boot/), and a lot of [Camel](https://camel.apache.org), gluing everything together.  We've even found time to make a bit of open source ourselves - [archaius-spring-adapter](https://github.com/Capgemini/archaius-spring-adapter) - and also [contribute some stuff back](https://github.com/Netflix/Hystrix/pull/281).
+We're doing Microservices. We're doing it based on a mash-up of some "Netflix Cloud" (as it seems to becoming known - we just call it "[Archaius](https://github.com/Netflix/archaius) / [Hystrix](https://github.com/Netflix/Hystrix)"), a gloop of [Coda Hale Metrics](https://github.com/codahale/metrics), a splash of [Spring Boot](http://projects.spring.io/spring-boot/), and a lot of [Camel](https://camel.apache.org), gluing everything together.  We've even found time to make a bit of open source ourselves - [archaius-spring-adapter](https://github.com/Capgemini/archaius-spring-adapter) - and also [contribute some stuff back](https://github.com/Netflix/Hystrix/pull/281).
 
 Lets be clear; when I say we're "doing Microservices", I mean we've got some running; today; under load; in our Production environment. And they're running nicely. We've also got a lot more coming down the dev-pipe. 
 

_posts/2015-03-06-why-microservices-are-right-for-us-pt1.md

@@ -33,7 +33,7 @@ mvn spring-boot:run
 
 We set up our code so that, when the Microservice starts up, it's automatically in stub-mode, by which I mean it's downstream Microservice and other dependencies are stubbed out. The range of requests you can send in, and the various valid and failure states you'll mimic as a result are specified in standard README.md files at the top of each Microservice git repo.  
 
-This, plus the bundled and served [Swagger](http://swagger.io/) docs, [Hystrix Dashboard](http://github.com/Netflix/Hystrix/wiki/Dashboard) and [Spring Boot](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html) / [Codahale Metrics](http://dropwizard.github.io/metrics/3.1.0/) monitoring JSON feeds, means everyone is a lot more self-supporting and doesn't need to depend upon shared server environments with the associated time-slicing and wait for the next release.
+This, plus the bundled and served [Swagger](http://swagger.io/) docs, [Hystrix Dashboard](http://github.com/Netflix/Hystrix/wiki/Dashboard) and [Spring Boot](http://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html) / [Coda Hhale Metrics](http://dropwizard.github.io/metrics/3.1.0/) monitoring JSON feeds, means everyone is a lot more self-supporting and doesn't need to depend upon shared server environments with the associated time-slicing and wait for the next release.
 
 ## Microservices are Laptop-Sized
 Picking up right where our last point left off is our next benefit; adopting Microservices has allowed us to throw out a lot of the heavyweight-and-rarely-used shared development infrastructure, allowing us to get a lot more as individual developers out of the grunt of our development and test machines.  Running [Tomcat](https://tomcat.apache.org/) (we're not on [Jetty](http://eclipse.org/jetty/) yet, but we will be eventually - its inevitable) and possibly an in-memory-db (or even a local [Redis](http://redis.io) or [MongoDB](http://www.mongodb.org/)) is a LOT lighter on resources and quicker to turnaround after a change than a traditional Java EE app server.  Despite this, we've lost none of the monitoring or configurability we've come to expect from the more "full-featured" EE cousins; none that we're missing anyway (see above).  And if we do need to run up more than one Microservice locally? Nae bother.

_posts/2015-04-16-microservices-gotchas.md

@@ -47,7 +47,7 @@ What helped us was to identify the right Microservices that could be externally
 By their very nature Microservices are a distributed architecture. This brings its challenges when debugging issues; Where do you look? You get told one of your APIs is throwing an error. With the Java "monolith" you had a had a stacktrace that you could work your way down and find the line of code that caused the error. But with Microservices it could be anywhere, especially when your service calls multiple down-stream services, and in some cases in parallel. 
 
 ### So where do you start? 
-Something simple that developers can overlook is logging and logging the right details, you need to be able to trace a message from it's entry point to everywhere it gets routed, so having some key data that makes a message unique and "searchable" is a major plus point. Additionally don't just log on errors, you want to know to where it went and how it got to be there. Monitoring is also a big winner for us; knowing if services are running and performing within norms helps identify issues. We're using [Codahale metrics](http://godoc.org/github.com/codahale/metrics) outputting to [Graphite](http://graphite.wikidot.com/start) and [Grafana](http://grafana.org/), but to get a runtime view we're moving towards implementing [Netflix's Hystrix](https://github.com/Netflix/Hystrix/wiki) Dashboard with [Turbine](https://github.com/Netflix/Turbine/wiki) in order to see how all our Microservices and their dependencies are behaving.
+Something simple that developers can overlook is logging and logging the right details, you need to be able to trace a message from it's entry point to everywhere it gets routed, so having some key data that makes a message unique and "searchable" is a major plus point. Additionally don't just log on errors, you want to know to where it went and how it got to be there. Monitoring is also a big winner for us; knowing if services are running and performing within norms helps identify issues. We're using [Coda Hale metrics](http://godoc.org/github.com/codahale/metrics) outputting to [Graphite](http://graphite.wikidot.com/start) and [Grafana](http://grafana.org/), but to get a runtime view we're moving towards implementing [Netflix's Hystrix](https://github.com/Netflix/Hystrix/wiki) Dashboard with [Turbine](https://github.com/Netflix/Turbine/wiki) in order to see how all our Microservices and their dependencies are behaving.
 
 ### Extra Reading
 Some additional reading if you get time: