- Microservices architecture breaks applications into small, independent services that focus on specific tasks and communicate over well-defined interfaces. This improves scalability, flexibility and allows for independent development and deployment of services.
- The architecture promotes separating concerns, with each small service handling a single "verb" of the application and teams owning service groups. Services are stateless and communicate asynchronously over lightweight protocols.
- Automating deployment through containerization allows for easy rollout of new versions with zero downtime and elastic scaling of services based on demand. Monitoring provides visibility into technical and business metrics of the distributed system.
2. ● SA at EPAM Systems
● primary skill is Java
● hands-on-coding with Groovy, Ruby
● trying to learn some Scala and Erlang
● passionate about agile, clean code and devops
Izzet Mustafayev@EPAM Systems
@webdizz webdizz izzetmustafaiev
http://webdizz.name
3. Agenda
● What is this?
● Architecture
● Case study
● Existing tools
● Summary
● How to get there?
● Q&A
7. ● Small (10-100 LOC)
● Lightweight (run several per box)
Overview
8. ● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
Overview
9. ● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
Overview
10. ● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
● Stateless (everything persisted in DB)
Overview
11. ● Small (10-100 LOC)
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
● Stateless (everything persisted in DB)
● Monitored (health and business value)
Overview
24. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
25. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One developer independently produces a
microservice
26. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One developer independently produces a
microservice
● Each microservice is it’s own build
27. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One developer independently produces a
microservice
● Each microservice is it’s own build
● Stateful cached data access layer
28. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One developer independently produces a
microservice
● Each microservice is it’s own build
● Stateful cached data access layer
● Lightweight mocked dependencies
29. Separate Concerns
● Inverse Conway’s law – teams own service groups
● One “verb” per single function microservice
● One developer independently produces a
microservice
● Each microservice is it’s own build
● Stateful cached data access layer
● Lightweight mocked dependencies
● Easy to run locally
37. ● Business aware metrics
● A/B testing metrics
Business monitoring
38. ● Increased traffic velocity makes individual events
less important
● More vertical components requires more
measurement
● Failure Rate is more informative than individual
failures
Stats matter on scale
54. ● Speed wins in the marketplace
● Remove friction from product development
Lessons learned
55. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
Lessons learned
56. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and responsibility culture
Lessons learned
57. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and responsibility culture
● Simple patterns automated by tooling
Lessons learned
58. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and responsibility culture
● Simple patterns automated by tooling
● Microservices for speed and availability
Lessons learned
59. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and responsibility culture
● Simple patterns automated by tooling
● Microservices for speed and availability
● Use statistics to monitor behavior
Lessons learned
61. Dropwizard http://dropwizard.github.io/dropwizard/
Java framework for developing ops-
friendly, high-performance, RESTful
web services.
- pulls together stable, mature libraries from
the Java ecosystem into a simple, light-weight
package
- has out-of-the-box support for sophisticated
configuration, application metrics, logging,
operational tools, and much more
62. Spring Boot http://projects.spring.io/spring-boot/
Takes an opinionated view of
building production-ready Spring
applications.
- favors convention over configuration and is
designed to get you up and running as quickly
as possible.
- production-ready features such as metrics,
health checks and externalized configuration
63. Vert.X http://vertx.io/
● Lightweight, reactive, application
platform
● Superficially similar to Node.js -
but not a clone!
● Inspired also from Erlang/OTP
● Polyglot
● High performance
● Simple but not simplistic