POMS

The main ideas from the "Principles of Microservices" course

Table of Contents

1. Introduction
2. Advantages of Microservices
3. Disadvantages of Microservices
4. Principles of Microservices
   • Modelled around Business Domain
   • Culture of automation
   • Hide implementation details
   • Decentralise all the things
   • Deploy independently
   • Consumer first
   • Isolate failures
   • Highly observable
5. When YOU should use Microservices
6. Useful Books

Introduction

The Microservices (M) are small, autonomous services that work together Small here means that they're doing one thing well. The Microservices are just one of the implementations of Service Oriented Architecture (SOA)

Advantages of M

• better allignment with the organization
• ship faster
• independent scaling
• enable segregation models
• adopt technologies more easily (you can use different languages/technologies for each M.)

Disadvantages of M

• lots of options (can be as the Advantage or the Disadvantage)
• it takes a lot of time to get into M.
• testing of M. is more complex
• monitoring and investigation of failures is more complex
• resiliency isn't free
• disrtibutes systems are hard! - with Monolith you have a binary state - it's up or down, with M. some of your services can be down, another - up and running.

Principles of M

1. Modelled around business domain
2. Culture of automation
3. Hide implementation details
4. Decentralise all the things
5. Deploy independently
6. Consumer first
7. Isolate failure
8. Highly observable

Modelled around Business Domain

[Presentation] -> [Business Logic] -> [Data Access] - jst a simple example.

Culture of Automation

• Continous Delivery (build -> test -> UAT -> prod)
• API - driven machine provisioning (creating a new node via API), see AWS, Digital Ocean, OpenStack, Vagrant, etc
• API - driven OS configurationm, see Chef, Puppet, Ansible
• Custom image creation, see Packer
• Declarative environment provisioning, see Docker Compose, Terraform
• Automatic testing

Hide implementation Details

• Hide your DB!
• Think about protocols: YAML. JSON, XML, SOAP
• Be careful of client libraries

Decentralise all the things

• internal open source model, see Gitlab
• orchestration
• self-service
• owner operator (each team is the main operator of their piece of software)

Deploy Independently

• One service per OS/VM/Container
• Consumer-driven contracts, see Pact
• Co-existing service versions
• Multiple enpoints (e.g. another API version of the same service)

Consumer First

• Conversations
• Consumer-driven contracts, see Pact
• Standards, see PayPal API standards for example
• API documentation, see Swagger
• Service Discovery, see Consul, etcd, DNS

Isolate Failures

• M. aren't reliable by default
• Cascading failures can hurt
• Timeouts

Highly Observable

• Standrad monitoring
• Service monitoring, see docker stats, collectd
• Health check pages
• Log aggregation, see Logstash, fluentd, kibana
• State aggregation, see Graphite
• Semantic monitoring (for example try to mock user actions each 5 minutes)
• Correlation ID (every action with ID, so you can catch it on every M. logs by this ID)

When YOU should use M

• What are you looking for?
• What kind of problem from the M. advantages are you trying to solve?

Useful Books

1. "Building Microservices: Designing Fine-Grained Systems" by Sam Newman
2. "Continuous Delivery" by Jez Humble
3. "Domain-Driven Design" by Eric Evans
4. "Service-Oriented Architecture (SOA): Concepts, Technology, and Design" by Thomas Erl
5. "I Heart Logs: Event Data, Stream Processing, and Data Integration" by Jay Kreps
6. "Infrastructure as Code: Managing Servers in the Cloud" by Kief Morris
7. "The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise" by Martin L. Abbott
8. "Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)" by Michael T. Nygard
9. "Production-Ready Microservices: Building Standardized Systems Across an Engineering Organization" by Susan J. Fowler