These are notes and commentary I have gathered while reading Building Microservices. These are usually aligned with the chapter order and topics laid out in the book. However, to respect the author and leaving you to read and consume it in your way, I have preferred my own wording around the key points. I hope you enjoy them and get the high level feeling in a way that would push you to read the book.
Definition and Benefits
This section is usually beneficial to business people in order to digest the ideas behind this architecture pattern as well as understanding the WHY part of it. It would be helpful to keep this part in mind when talking to non-technical if you are starting this journey in your organisation.
Definition
Microservices are small, autonomous services that work together in order to provide business value in face paced environments to create competitive advantages.
Infrastructure
Infrastructure design details of how microservices deployed can be a deep topic but a rule of thumb in general is avoiding deploying multiple services in small machines.
Coupling via Network
Chatty network calls between services can be regarded a form of tight coupling. The heavy load of network calls between these services creates the coupling in a way that if one service goes down, the other goes into an unhealthy state almost immediately.
Technology Freedom One of the key benefits of microservices is providing a chance to use best tool for the job so that technology heterogeneity can be achieved. This also provides accessing a bigger pool of talent respectively.
Organisational and Operational Benefits
Operational benefits such as ease of deployment, cost-effective scalability and organisational alignment in the form of autonomous teams around the services come out of box with some trade offs.
Forming Microservices
This section is to give some ideas about where to start. Especially during the design stages of the microservices from an existing monolithic software and/or for new features, ideas below could help your organisation steering around the common pitfalls.
Microservices Fundementals
Bounded Context is one of the best approaches for composing micorservices with loosely coupling and increased cohesion. This also provides autonomy in a way that some entities could mean different things in different contexts as long as they don’t leak and create conflicts between services.
Integration Between Microservices
Integration between microservices is a big challenge. One of mistakes previously identified is having a shared database and using database as the integration layer between microservices. This creates high coupling and makes changes in database layer become almost impossible. Choosing an appropriate integration between services like using RPC, REST and similar technologies are far better than having an integration at database layer.
Some microservices will have more responsibility and business logic than the others. In these services, there are two approaches. One approach is that service calling all other services and expecting immediate result. The other approach is delegating the tasks to other services and awaiting the final result in an async way. The former approach is usually brittle and could cause more harm in terms of reliability and service health. However, the latter is also more complex for monitoring and debugging purposes. So, organisations should choose them according to their domain, team, available talent and technology in hand.
REST Implications
Instead of exposing every available data from an API, APIs can expose hyperlinks, HATEOAS, to allow clients/consumers of the APIs navigate endpoints independently. This reduces the coupling but it also increases the network bandwidth consumed. So the trade offs should be considered carefully in a case by case manner.
Events To the Rescue?
Event based integration between services can reduce the coupling, increase the efficiency in latency and help scaling the systems much easier. If the team are only familiar with synchronous/HTTP based communication, this approach can introduce some learning curve and initial complexities. There are also some complexities around queuing mechanisms, dealing with dead-letters and avoiding duplicated work running on multiple workers.
Client Libraries a.k.a. SDKs
Having Client Libraries to communicate between microservices and/or clients is a good intention of applying DRY principles. However, it is a requirement to have these Client Libraries as dummy as possible and to not leak any logic outside of the given microservice. This helps moving faster and autonomously updating the microservice without breaking the promises and requiring Clients new deployments and updates.
Versioning
Avoid breaking changes whenever possible. If it is not possible then try releasing to a new deployment and redirect release a new client by redirecting traffic to new deployment. If traffic to older version hits to zero, just remove it from production. This is more like a Canary Release type of approach.
I still read and examine the book. Hopefully, I’ll share more on the upcoming chapters!
To be continued….
Mahmut Canga 
What do you think?