Modern HA applications in nowadays are developed with set of small focused and discrete Microservices. It's a trending concept and opens/solves questions like maintenance, scaling, live-deployments, security, fault-tolerance etc.

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