Applications build using microservices architecture introduce complexity of distributed systems. Each of the microservices can be independently deployed, and automation of deployment pipeline is a must. Besides that, interaction between microservices must be reliable, the system should be able to scale easy and publish metrics. Spring cloud implements patterns of distributed systems, using well known principles from Spring: declarative, non-invasive and convention over configuration. Together with Spring Boot, effectively deals with: service discovery and routing, configuration management, security and metrics. On of the possible deployment patterns for microservices is by using tools like docker where each of the services runs in it's own container. Docker offers lightweight virtualization and promise of running the same container on each environment. Although containers can be orchestrated via docker-compose, we need tools like service registry which holds up-to date information about services location. Consul is service discovery and configuration management tool, from company behind Vagrant (Hashicorp). Bullet point 1: Microservices and distributed system patterns Bullet point 2: Spring Cloud Bullet point 3: Orchestration via Docker and Consul

1. Dragan Gajic
d.gajic@levi9.com
MICROSERVICES: WHERE SPRING CLOUD MEETS
DOCKER AND CONSUL

3. MONOLITHIC VS MICROSERVICES 1/2
Web server
Web app
Web layer
Service/Business layer
Data/Persistence layer
Catalog Order
Customer
Database
Web Shop
SPA
Catalog App
Catalog
Order App
Order
Customer App
Customer

4. Maintainability
Continuous
Deployment
Scalability
Availability
Take advantage of
emerging technologies
Efficient governance
MONOLITHIC VS MICROSERVICES 2/2
 code base size increases -> decrease maintainability
 overloaded IDE -> slow IDE -> decrease productivity
 overload web server -> long start -> decrease productivity
 redeploy the entire app
 influence background tasks
 increases the risk -> discourages frequent updates
 running more copies of the same app
 different components have different requirements
 small code base size per MS
 faster IDE
 WS fast start
 each service can be deployed independently
 smaller aps are easier to deploy
 downtime
 low fault isolation
 long time commitment to technology stack
 hard to manage large teams
 agile is not scaling well
 hard to scale development
 improved fault isolation
 Increased complexity - fail fast
 scale on the level of MS
 each MS can be developed using different
stack
 each (2 pizza) team responsible for one MS
 agile is working well
 easy to scale development

6. DISTRIBUTED SYSTEMS
• Configuration
• Inter-service communication
• Discovery
• Deployment
• Orchestration
• Testing
• Distributed transactions
• Versioning
Web Shop
SPA
Catalog App
Catalog
Order App
Order
Customer App
Customer

8. TO THE RESCUE

9. DOCKER
• Lightweight virtualization
• Images vs containers
• Registry
• Compose
• Machine, Swarm,…

10. CONSUL
• Distributed key/value store
• Service discovery and health check
• Multi Datacenter support
• Optimized sync protocols (gossip)
• Alternatives
• Netflix Eureka
• Spring Cloud Config

11. SPRING CLOUD
• Implements common patterns of distributed systems
• Distributed configuration
• Service discovery
• Routing
• Service-to-service calls
• …
• Build on 12 factor app and Cloud Native principles
• Spring Boot

12. DEMO
config/appName,dev/
config/appName/
config/application,dev/
config/application
ms-demo-1:/echo ms-demo-2:/echo
ms-caller:/hello

13. LESSONS LEARNED
• US breakdown
• Keep your APIs under control
• CD
• Automated integration env
• E2E automated tests
• Don’t underestimate learning curve
• After initial phase split the team accordingly

14. RESOURCES
• http://12factor.net/
• http://projects.spring.io/spring-cloud/
• http://cloud.spring.io/spring-cloud-consul/
• https://gitlab.levi9.com/d.gajic/ms

15. ONE COMMON GOAL