The document discusses the principles and implementation of microservices architecture, emphasizing its benefits such as speed, availability, and scalability. It covers best practices in design, deployment, and operation, as well as tools like Dropwizard, Spring Boot, and Vert.x that facilitate this architecture. Additionally, it highlights the need for a culture of trust and responsibility among developers, while acknowledging the complexities of polyglot infrastructure and operational responsibilities.

1. μServices Architecture
@ EPAM WOW 2015

2. ● SA at EPAM Systems
● primary skill is Java
● hands-on-coding with Groovy, Ruby
● trying to get in touch with Erlang/Elixir
● 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 (100s LOC)*
Overview

7. ● Small (100s LOC)*
● Lightweight (run several per box)
Overview

8. ● Small (100s LOC)*
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
Overview

9. ● Small (100s LOC)*
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
Overview

10. ● Small (100s LOC)*
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
● Stateless (everything persisted/not persisted)
Overview

11. ● Small (100s LOC)*
● Lightweight (run several per box)
● Takes strength of platform/language (polyglot)
● Independent (development/deployment)
● Stateless (everything persisted/not persisted)
● Monitored (health and business value)
Overview

12. ● Design
● Implementation
● Delivery
● Operation
Architecture

13. Design
● What ab SOA?
● Domain-Driven Design
● Versioning
● Integration
● Reusability
● Scalability
● Availability
● Asynchronicity
● Externalization of Configuration

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

15. Domain-Driven Design
Set of principles and patterns that
● are closed to business
● are closed to developers
● to craft elegant object systems

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

17. Integration
● Own service - own client
● Client load balancer
● Thin and efficient transport/protocol

18. Reusability
● Cohesive logic
● Usage of Components/Frameworks

19. ● Statelessness
● Independency
Scalability

20. ● Fault-tolerance
● Fast and small failures
Availability

21. Asynchronicity
● Non-blocking operations
● Reactive principles
● Messaging

22. Externalization of Configuration
● Support for X > 1 environments
● Run-time changes

23. ● Separation of Concerns
● Caching
Implementation

24. Separation Concerns
● Inverse Conway’s law – teams own service groups

25. Separate Concerns
● Inverse Conway’s law – teams own service groups
● Each service is it’s own build

26. Separate Concerns
● Inverse Conway’s law – teams own service groups
● Each service is it’s own build
● Lightweight mocked dependencies

27. Separate Concerns
● Inverse Conway’s law – teams own service groups
● Each service is it’s own build
● Lightweight mocked dependencies
● Easy to run locally

28. Caching
● Stateful cached data access layer

29. Caching
● Stateful cached data access layer
● Expensive computational data

30. Caching
● Stateful cached data access layer
● Expensive computational data
● Static resources/CDN/Mirroring

31. ● Immutability
● Disposability
● Containerisation
● Zero-down-time
● Frequency
Delivery

32. ● Build
● Infrastructure
● Infrastructure-as-code
Immutability

33. ● Build
● Run
● Destroy
Disposability

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

35. ● Blue-green
● Multi-phased
● Feature toggle
● Database migration/versioning
Zero-down-time

36. Frequency
● Fast rollouts
● Fast rollbacks

37. ● Service Discovery
● Technical Monitoring
● Business Monitoring
● Stats
Operation

38. ● Services use services
● Each service has own version
● Decoupling still matters
● One-the-fly parameterisation
Service discovery

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

40. ● Business aware metrics
● A/B testing metrics
Business monitoring

41. ● Increased traffic velocity makes individual events
less important
● More vertical components require more
measurement
● Failure Rate is more informative than individual
failures
Stats matter on scale

42. Benefits

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

44. ● Independent provisioning
● Fine tuning
● Elasticity
Scalability

45. ● Development
● Testing
● Deployment
● Reliability
Independence

46. Shortcomings

47. ● More responsibility from Devs to support Ops
Shortcomings

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

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

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

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

52. ● More responsibility from Devs to support Ops
● Polyglot infrastructure (if any)
● Orchestration
● Costs
● Dependency management
● Distributed applications are complicated
Shortcomings

54. Twitter before

56. Twitter now*

57. Twitter requests

58. ● Speed wins in the marketplace
Lessons learned

59. ● Speed wins in the marketplace
● Remove friction from product development
Lessons learned

60. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
Lessons learned

61. ● Speed wins in the marketplace
● Remove friction from product development
● High trust, low process
● Freedom and responsibility culture
Lessons learned

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

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

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

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

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

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

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

69. More...
● Ratpack http://www.ratpack.io/
● Sinatra http://www.sinatrarb.com/
● Spark http://sparkjava.com/
● Compojure https://github.com/weavejester/compojure
● Webbit https://github.com/webbit/webbit
● Finagle http://twitter.github.io/finagle/
● Connect http://www.senchalabs.org/connect/
● XDropWizard https://github.com/timmolter/XDropWizard

70. Summary

71. Summary
● Speed wins in the marketplace

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

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

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

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

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

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

78. Q&A

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