Microservices with Go

Gendo Ikari (aka Daniele Maccioni)

 Monolithic App

The default scenario

What is a microservices architecture?

Let's gather few general ideas...

• Split the monolith into different components
• Components are small (single responsability)
• Every component is a single independent service
• Components as services
• "Smart endpoints and dumb pipes"
• Design for failure
• Decentralization (functionality and data)

• One language to communicate across microservices: RPC/IPC
• One consistent and established contract of interaction
• Redundancy of small services
• Isolation (avoid chain reactions)

Components:

• independently replaceable

• independently upgradeable

Dumb pipes:

• all the routing logic goes in the nodes

• the "smart" part of the system is the endpoint not the connection

• Happy example: internet

Design for failure:

• No single point of failure

• Failure will happen: code around it, isolate and handle it

• Happy example: again, internet

Decentralization:

• Functionality are structured in separated microservices (redundancy)

• Separated machine and processes

• Different databases: do not communicate through database but through APIs

Who's using microservices?

• Amazon
• Netflix
• Ebay
• Uber
• Zalando
• ...
• a shittons of companies

Why microservices?

Monolithic is not inherently bad

microservices solve organizational problems

microservices cause technical problems

Organization problems

• Scalability
• Reliability problems
  • Redundancy
  • Resiliency
• Team problems:
  • teams too large
  • teams deadlocked
• Deployment speed
• Innovation speed

scale up vs scale out

Conway's Law

Functional Teams

Technical problems

• System testing
• API design
• Communication
• Deploy and post deploy testing
• Overall complexity
• Shared memory, shared databases: synchronization and coherency
• Service scheduling
• Caching
• Monitoring, logging, telemetry...
• ...

Why Go?

• Parallelism "for free"
• Efficient goroutine scheduler
• Huge and robust standard library
• Fast and reliable
• Amazing tools
• Super easy deployment

Example

Spotlights

small

pulling (or service discovery)

moving the focus from common technology to common interfaces, APIs and protocols.

"buy" is better than "build"

using the right tool for every job

data consistency

stateless

filesystem

Some Guidelines

Microservice Guidelines

• Sufficiently small to be design and maintained by a small team (one developer)
• Single bounded context (one software for one well defined domain)
• Single logical database per service
• Continuos integration
• Workers faster than producers
• Watch out for bottlenecks

thank you

Questions?