Gain insights into real-world microservice implementation, exploring tech stacks, Kafka, Docker, Kubernetes, synchronous and asynchronous integrations, and more 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

# Summary

## HTTP
REST and the Atom format offer an easy way to implement asynchronous communication. **HTTP is used as the communication protocol** which has several advantages:

- HTTP is well understood.
- HTTP has already proven its scalability many times.
- Most of the time HTTP is used in projects to transfer other content like JSON via REST or to deliver HTML pages.
- **Most teams have the necessary
experience** to implement scalable systems with HTTP.
-  HTTP caching is supported hence, **polling of Atom resources can be implemented very efficiently**.

## Old events

Having old events still available helps because another microservice with event sourcing can rebuild its state by processing all events again.

With an Atom-based system, a microservice must also provide old events. This can be done easily in some cases.


If the microservice has stored the old information anyway, it only needs to provide it as an Atom feed. In this case, access to old events is easy to implement.


The data in the Atom Feed comes from the same source as all other
representations. Therefore, the data is consistent with the data that
can be queried via other means. All these services show different representations of the same data.


## No guaranteed delivery
Atom cannot guarantee the delivery of the message. Therefore, the microservices in which the messages are processed should be implemented idempotently and try to read the message several times to ensure that they are processed.

## All microservices can receive messages
Atom has no way to limit the reception of a message to just one
microservice. Therefore, the microservice must select
an instance that then processes the message, or else you have to rely on
the idempotency.

## Guaranteed order of messages
Atom can guarantee the order of the messages because the feed is a
linear document so the order is fixed. However, this requires that
the order of the entries in the feed does not change.

**Atom is a very simple alternative for asynchronous
communication**.

We'll conclude this chapter with a quick summary of what we've learned.

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

Create and Integrate Flask 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

Deploying a Web Application over Kubernetes

Appendix

Chapter Conclusion

Summary #

HTTP #