Learn to implement microservices across a range of common tech stacks.

Scalability & System Design for Developers

In this module, we’ll look at some fundamental concepts for implementing microservices. Within each concept, learn about the different technologies used to implement it. The technologies include front-end integration with Edge Side Includes (ESI), asynchronous microservices with Kafka and REST feeds, synchronous microservices with the Netflix stack, and Consul, Docker, Kubernetes, Cloud Foundry. Each technology is described and then demonstrated with real code.

Microservice Architecture: Practical Implementation


[Consul](http://www.consul.io) is a service discovery technology that ensures microservices can communicate with each other.


# Distinguishing features
Consul has
some features that set it apart from other service discovery
solutions.

## HTTP REST API & DNS support

 Consul has an *HTTP REST API* and supports **DNS**. 

- [DNS](http://www.zytrax.com/books/dns/) (Domain Name System)
  is the system that maps host names such as www.innoq.com to IP
  addresses on the Internet.
- In addition to returning IP addresses, it
  can return ports at which a service is available.
-  This is a feature of the SRV DNS records.

## Configuration file generation

With [Consul Template](https://github.com/hashicorp/consul-template), Consul can generate configuration files.

- The files may contain IP
  addresses and ports of services registered in Consul. 
- *Consul Template* also provides Consul’s service discovery to systems that cannot access Consul via the API.
- The systems
  have to use some kind of configuration file, which they often
  already do anyway.

## Health checks
Consul can perform **health checks** and exclude services from service
  discovery when the health check fails. 

- For example, a health check
  can be a request to a specific HTTP resource to determine whether
  the service can still process requests. 
- A service may still
  be able
  to accept HTTP requests, but it may not be able to process them
  properly due to a database failure. 
- The service can signal this
  through the health check.

## Replication
Consul supports **replication** and can ensure high availability. 

If a Consul server fails, other servers with replicated data take over and compensate for the failed server.

## Multiple data centers

Consul also supports **multiple data centers**.

- Data can be replicated between data centers to further increase availability and protect Consul against the failure of a data center. 
- The search for services can be limited to the same data center. 
- Services in the same data center usually deliver higher performance.


## Service configuration
Finally, Consul can be used not only for service discovery, but
  for the **configuration of services**.  

- Configuration has different
  requirements.
-  Availability is important for service discovery. 
- Faulty information
  can be tolerated. 
- If the service is accessed and is not available, it doesn’t matter. You can simply use another instance of the service.

- However, if services are configured incorrectly, this can
  lead to errors.
- **Correct information is more important** for configuration than for service discovery.


In this lesson, we'll study service discovery with Consul.


Service Discovery

Distinguishing features

HTTP REST API & DNS support