Gain insights into real-world microservice implementation, exploring tech stacks, Kafka, Docker, Kubernetes, and more. Learn about synchronous and asynchronous integrations with hands-on coding demonstrations.

docker_ms2_v3.tar.gz

scs-esi

kafka

atom

links

netflix

consul

atom-kafka-scs-netflix-up

links-up

Microservices are one of the most important software architecture trends, but it’s one thing to define an architecture and quite another to implement it. 

This course focuses on the nitty-gritty details of real-world implementation. You’ll learn recipes for tech stacks that can be used to implement microservices, as well as the pros and cons of each. 

You’ll start by exploring some fundamental concepts for implementing microservices. Within each concept, you’ll learn about the different technologies used to implement it. The technologies include: Frontend 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 you learn about is described and then demonstrated with real code. 

By the end of this course, you’ll be a microservice pro. Whether you’re a software engineer or an engineering manager, this course will prove useful throughout your career.

Microservice Architecture: Practical Implementation

# Introduction

The microservices have code dependencies to the Consul API for **registering**. This is not necessary, a [Registrator](https://github.com/gliderlabs/registrator) can register Docker containers with Consul without the need for code.

When the Docker containers are configured in such a way that they use Consul as a DNS server, the lookup of other microservices can also occur without code dependencies. This eliminates any dependencies on Consul in the project.


The drawing above shows an overview of the approach.

* **Registrator** runs in a Docker container. Via a socket, Registrator  collects information from the Docker daemon about all newly launched Docker containers. The Docker daemon runs on the Docker host and manages all Docker containers.

* The **DNS interface of Consul** is bound to the UDP port `53` of the
  Docker host. This is the default port for DNS.

* The **Docker containers** use the Docker host as a DNS server.

# Configuring DNS access
The `dns` setting in the `docker-compose.yml` is configured to use the
IP address in the 
environment variable `CONSUL_HOST` as the IP address of the DNS
server. Therefore, the IP
address of the Docker host has to be assigned to `CONSUL_HOST` before
starting `docker-compose`. Unfortunately, it is not possible to
configure DNS access from the Docker containers in a way that does not
use this environment variable.

# Consul

Registrator registers every Docker container started with Consul; not only the microservices, but the Apache httpd server or Consul itself can be found among the services in Consul.

Consul registers the Docker containers with `.service.consul` added to
the name.  In `docker-compose.yml`, `dns_search` is set to
`.service.consul` so that this domain is always searched. In the end,
the order microservice uses the URLs `http://msconsuldns_customer:8080/`
and `http://msconsuldns_catalog:8080/` to access the customer and
catalog microservices.


 Docker compose creates the prefix `msconsuldns`
for the name of the Docker containers to separate this project from other projects. This name is also used by Consul Template to configure the Apache httpd for routing.


In this setup, Consul is responsible for load balancing. If there are
several instances of a microservice, Registrator registers them
all under the same name. Consul then returns one of the instances for
each DNS request.

The executable example can be found at
<https://github.com/ewolff/microservice-consul-dns> and the
instructions for starting it, at
<https://github.com/ewolff/microservice-consul-dns/blob/master/HOW-TO-RUN.md>.

As a result of this approach, the microservices **no longer contain any
code dependencies on Consul**. Therefore, with these technologies, it is
no problem to implement microservices with a programming language
other than Java.


Preface

Self-contained Systems

Concept: Frontend Integration

Recipe: Links and Client-side Integration

Recipe: Server-side Integration using Edge Side Includes (ESI)

Concept: Asynchronous Microservices

Recipe: Messaging and Kafka

Recipe: Asynchronous Communication with Atom and REST

Concept: Synchronous Microservices

Recipe: REST with the Netflix Stack

Recipe: REST with Consul and Apache httpd

Concept: Microservices Platforms

Recipe: Docker Containers with Kubernetes

Recipe: PaaS with Cloud Foundry

Appendix

DNS and Registrator

Introduction #