anchor.diff:  ## Demystifying microservices
   
  -Except you spent the last year in a cave, you probably have heard about _microservices_.
  +Unless you spent the last year in a cave, you probably have heard about _microservices_.
   So what are _microservices_? To answer this questions, let's quote from a veteran:
   
   [quote, Martin Fowler, http://martinfowler.com/articles/microservices.html]
  
positive.code: 
  1. split the application into a set of decoupled components providing defined `services` (_defined_ means with a
  known interface or API)
  2. allow the components communicate with whatever protocol the choose, often REST, but not necessarily
  3. allow the components use whatever languages and technologies they want
  4. allow each component be developed, released and deployed independently
  5. allow the deployments be _automated_ in their own _pipeline_
  6. allow the orchestration of the whole application be reduced to the barest minimum
  
  In this lab, we won't address point 5, but you should know that Vert.x does not restricts how you deploy
  your components. You can employ whatever technology best suites your environment. whether it is ssh, ansible, puppet, docker, cloud, fabric8, or even floppy disk.
  
  Point 6, however, is interesting, and often misunderstood. It's pretty cool to develop independent pieces of software
  that magically interact at runtime. Yes, I said _magically_ but in technology we don't believe in magic. To make this happen, what we need is some form of service _discovery_ at runtime. The service discovery mechanism can achieve it's goal with any number of suitable means. These range from: hardcoding the service location in the code (which is generally a bad idea), using a DNS lookup service, or some more advanced techniques.
  
  Having a service discovery mechanism allows our system components interact transparently amongst each other regardless of location or environment. It also allows us to easily load-balance amongst our components through a round robin alogorithm, for example, thereby making our system more fault-tolerant (by locating another service provider when one breaks down).
  
  Although by definition, microservice applications are not required to be distributed, there usually are in practice. This comes with all the distributed application benefits and constraints: consensus computation (FLP), CAP theorem, consistency, monitoring, and many other reasons to fail. So microservices applications need to be designed to accommodate failures from their early implementation stage.
  
  Before we go further, there are a couple of points I would like to mention. _Microservices_ are **not** new and the concept is not rocket science. Academic papers from the 70's and 80's have defined (using different words) architectural styles very
    close to this. Also very important point to understand is: microservices are not a silver bullet. (Unless well managed) it has the capacity to increase the complexity of your application due to its distributed nature. Lastly, a microservice architecture will not fix all your issues.
  
  The major concerns when it comes microservices are rapid delivery, adaptation, independence and replaceability. Every microservice is made to be replaceable by another providing the same _service / API / interface_ (at the core, it's basically an application of the https://en.wikipedia.org/wiki/Liskov_substitution_principle[Liskov substitution principle]).
  
  If you have been a developer for about 10 years, you might want to ask what difference is between microservices and SOA. For a lot of people it's about size. This is not always true because services don't necessarily have to be small which makes the term "microservice" quite misleading. Microservices and SOA differ purpose but the basic concepts are similar:
  
  * service : a defined feature accessible by an API, a client, a proxy, anything
  * service provider: a component implementing a service
  * service consumer: a component consuming a service
  * service discovery: the mechanism used by a consumer to find a provider
  
  Both approaches inherit from the _service oriented computing_, aiming to decompose and manage independent pieces of
  software. You may have never heard about this even if you used it: COM, Corba, Jini, OSGi, and web services are all
  different implementations of _service oriented computing_.
  
  Finally, there is a common misconception that microservices must be RESTful by nature. This can't be farther from the truth. Microservices can employ any number interaction style that best fit their purpose: RPC, events, messages, streams etc. In this lab we will using RESTful services, async RPC, and message sources.
  
  It tends to not be easy to use service discovery when we are not used to. So, let's do a few exercises about it. To continue introducing
  Rx Java constructs, these exercises use the RX Java 2 API offered by vert.x
  
  ### Exercise 1 - Publishing a service
  
  In this first exercise, we are just going to publish a service. A service is described by a `record` containing
  enough metadata for a consumer to select the right service and create a _client_.
  
  Open the `io.vertx.workshop.exercise.microservice.Exercise1Verticle` class from the `microservices-exercises` project
  . This class already contains some code to create an HTTP endpoint using Vert.x Web, exposed on the port 8080.
  Once ready to serve, and to let the other parts of your system consume this service, we need to advertise it. This is
  achieve in the `publish` method that you need to write.
  
  First you need to create a `record` for the service. The `io.vertx.reactivex.servicediscovery.types.HttpEndpoint`
  class contains methods to create `records` for HTTP endpoint. Once you have the record, you call `rxPublish` on the
  Vert.x service discovery. This stores the record and let the other parts of your system be aware of its availability.
  
  [.assignment]
  
negative.code: ----
  private Single<Record> publish(HttpServer server) {
      // 1 - Create a service record using `io.vertx.reactivex.servicediscovery.types.HttpEndpoint.createRecord`.
      // This record defines the service name ("greetings"), the host ("localhost"), the server port and the root ("/")
      Record record = HttpEndpoint.createRecord("greetings", "localhost", server.actualPort(), "/");
  
      // 2 - Call the rxPublish method with the created record and return the resulting single
  