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

1. μServices Architecture

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

6. ● Small (10-100 LOC)
Overview

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

12. ● Design
● Implementation
● Delivery
● Monitoring
Architecture

13. Design
● What ab SOA?
● Externalize Configuration
● Versioning
● Communication Contract
● Asynchronicity
● Reusability
● Scalability
● Availability

14. What ab SOA?
● Sensible idea
● Combat challenges of large monolithic
applications
● Lack of guidance

15. Externalize Configuration
● Support for X > 1 environments
● Run-time changes

16. Versioning
● Leave multiple old microservice versions running
● Fast introduction vs. slow retirement asymmetry

17. Communication Contract
● Own service - own client
● Thin transport

18. Asynchronicity
● Non-blocking
● Reactive model
● Messaging to send and forget

19. Reusability
● Each service does one dedicated thing
● Utilize suitable components/frameworks

20. ● Cohesive
● Stateless
● Independent
Scalability

21. ● Fault-tolerance
● Introduce failures
Availability

22. Implementation
● Separate Concerns

23. Separate Concerns
● Inverse Conway’s law – teams own service groups

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

30. Delivery
● Disposability
● Containerisation

31. ● Build
● Run
● Destroy
Disposability

32. ● Container as deployment artifact
● Environment agnostic
● New version - new container
● All dependencies built in
Containerisation

33. ● Blue-green pattern
● Feature toggle
● Database migration/versioning
Zero-down-time

34. Frequency
● Fast rollouts
● Fast rollbacks

35. ● Technical
● Business
● Stats
Monitoring

36. ● Hardware monitoring
● Resources utilisation
● Health checking
Technical monitoring

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

39. Benefits

40. ● Polyglot technology stack
● Polyglot persistence
● Frameworks
● Thin transport
Toolset unchained

41. ● HTTP stack
● Independent provisioning
● Fine tuning
● Elasticity
Scalability

42. ● Development
● Testing
● Deployment
● Reliability
Independence

43. Shortcomings

44. ● More responsibility from Devs to support Ops
Shortcomings

45. ● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
Shortcomings

46. ● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
● Orchestration
Shortcomings

47. ● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
● Orchestration
● Costs
Shortcomings

49. Twitter before

51. Twitter now*

52. Twitter requests

53. ● Speed wins in the marketplace
Lessons learned

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

60. Toolset
● Dropwizard
● Spring Boot
● Vert.X
● More...

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

64. More...
● Ratpack http://www.ratpack.io/
● Sinatra http://www.sinatrarb.com/
● Webbit https://github.com/webbit/webbit
● Finagle http://twitter.github.io/finagle/
● Connect http://www.senchalabs.org/connect/
● XDropWizard https://github.com/timmolter/XDropWizard

65. Summary

66. Summary
● Speed wins in the marketplace

67. Summary
● Speed wins in the marketplace
● Separated concerns at app level

68. Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated

69. Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated
● Elastically scalable

70. Summary
● Speed wins in the marketplace
● Separated concerns at app level
● Focused and automated
● Elastically scalable
● Polyglot architecture

71. ● Automate repeating activities
● “Run what you wrote” – root access and duty
● Freedom and responsibility for developers
How to get there?

72. References
● http://martinfowler.com/articles/microservices.html
● http://yobriefca.se/blog/2013/04/28/micro-service-
architecture/
● http://goo.gl/4dOVjj
● http://goo.gl/RGgnd3
● http://goo.gl/TmZ4Ee
● http://12factor.net/
● http://goo.gl/tnPxLP

73. Q&A

75. Izzet Mustafayev@EPAM Systems
@webdizz webdizz izzetmustafaiev
http://webdizz.name