µServices Architecture @ EPAM WOW 2015

μServices Architecture@ EPAM WOW 2015

● 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 izzetmustafaievhttp://webdizz.name

http://webdizz.name

http://webdizz.name

Agenda● What is this?

● Architecture

● Case study

● Existing tools

● Summary

● How to get there?

● Q&A

● Small (100s LOC)*

Overview


● Lightweight (run several per box)

Overview



● Takes strength of platform/language (polyglot)

Overview




● Independent (development/deployment)

Overview





● Stateless (everything persisted/not persisted)

Overview





● Stateless (everything persisted/not persisted)

● Monitored (health and business value)

Overview

● Design● Implementation● Delivery● Operation

Architecture

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

What about SOA?

● Sensible idea● Lack of guidance● Combat challenges of large monolithic

applications

Domain-Driven Design

Set of principles and patterns that● are closed to business● are closed to developers● to craft elegant object systems

Versioning

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

Integration

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

Reusability

● Cohesive logic● Usage of Components/Frameworks

● Statelessness● Independency

Scalability

● Fault-tolerance● Fast and small failures

Availability

Asynchronicity

● Non-blocking operations● Reactive principles● Messaging

Externalization of Configuration

● Support for X > 1 environments● Run-time changes

● Separation of Concerns● Caching

Implementation

Separation Concerns

● Inverse Conway’s law – teams own service groups

Separate Concerns


● Each service is it’s own build

Separate Concerns



● Lightweight mocked dependencies

Separate Concerns



● Lightweight mocked dependencies

● Easy to run locally

Caching

● Stateful cached data access layer

Caching


● Expensive computational data

Caching


● Expensive computational data

● Static resources/CDN/Mirroring

● Immutability● Disposability● Containerisation● Zero-down-time● Frequency

Delivery

● Build● Infrastructure● Infrastructure-as-code

Immutability

● Build● Run ● Destroy

Disposability

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

Containerisation

● Blue-green● Multi-phased ● Feature toggle● Database migration/versioning

Zero-down-time

Frequency

● Fast rollouts● Fast rollbacks

● Service Discovery● Technical Monitoring● Business Monitoring● Stats

Operation

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

Service discovery

● Hardware monitoring● Resources utilisation● Health checking

Technical monitoring

● Business aware metrics● A/B testing metrics

Business monitoring

● 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

Benefits

● Polyglot technology stack● Polyglot persistence● Frameworks● Thin transport

Toolset unchained

● Independent provisioning ● Fine tuning ● Elasticity

Scalability

● Development● Testing● Deployment● Reliability

Independence

Shortcomings

● More responsibility from Devs to support Ops

Shortcomings


● Polyglot infrastructure (if any)

Shortcomings



● Orchestration

Shortcomings



● Orchestration

● Costs

Shortcomings



● Orchestration

● Costs

● Dependency management

Shortcomings



● Orchestration

● Costs

● Dependency management

● Distributed applications are complicated

Shortcomings

Twitter before

Twitter now*

Twitter requests

● Speed wins in the marketplace

Lessons learned


● Remove friction from product development

Lessons learned



● High trust, low process

Lessons learned




● Freedom and responsibility culture

Lessons learned





● Simple patterns automated by tooling

Lessons learned






● Microservices for speed and availability

Lessons learned






● Microservices for speed and availability

● Use statistics to monitor behavior

Lessons learned

Toolset

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

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

http://dropwizard.github.io/dropwizard/

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

http://projects.spring.io/spring-boot/

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

http://vertx.io/

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

http://www.ratpack.io/

http://www.sinatrarb.com/

http://sparkjava.com/

https://github.com/weavejester/compojure

https://github.com/webbit/webbit

http://twitter.github.io/finagle/

http://www.senchalabs.org/connect/

https://github.com/timmolter/XDropWizard

Summary

Summary● Speed wins in the marketplace


● Separated concerns at app level



● Focused and automated




● Elastically scalable




● Elastically scalable

● Polyglot infrastructure

● Automate repeating activities● “Run what you wrote” – root access and duty● Freedom and responsibility for developers

How to get there?

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

http://martinfowler.com/articles/microservices.html

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



Q&A

Izzet Mustafayev@EPAM Systems@webdizz webdizz izzetmustafaievhttp://webdizz.name

http://webdizz.name

http://webdizz.name

µServices Architecture @ EPAM WOW 2015

Technology