The main ideas from the "Principles of Microservices" course

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

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)

• 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.)

• 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.

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

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

• 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 your DB!
• Think about protocols: YAML. JSON, XML, SOAP
• Be careful of client libraries

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

• 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)

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

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

• 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)

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

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