Hello, my name is ...

Xavier Fornés (@xfornesa)

http://www.xavierfornes.com

myTaste.com

myTaste - World Wide

About the content...

New blog use case

What’s the problem?

Problem● Shared functionality across two applications

Solution● Duplicate implementation● Share a library

Our CTO said...

What’s the problem?

Problem● Shared functionality across two applications● Independently deployable

Solution● Duplicate implementation● Share a library● Implement a micro-Service

Hands on...

Specialist team (focused on technology layer):● UI Teams● Server-side logic teams● Database teams

...

Conways law

Conways law

Any organization that designs a system (defined broadly) will procedure a design whose structure is a copy of the organization’s communication structure.

-- Melvyn Conway, 1967

Cross-functional teams

Development Build Deploy Maintenance

A-Team Ops-Team M-Team

Project model

Develop products

Development Build Deploy Maintenance

A-Team

Product model

It’s about freedom

Tip: Use the right tool for the job

But…Just because you CAN do something, doesn’t

mean you should!

Service boundaries

It’s useful thinking on bounded contexts from DDD

Let’s each service manage its own database

Decentralizing data

Downsides: Manage updates

Shared model● Use transactions● Temporal coupling of data

Decentralized model● Transaction less coordination between

services● Compensating operations

Downside: Allocating responsibility

Problems● No clear boundary responsibilities● Move responsibilities across components

Communication patterns

Change of mentality

Problem● Naive conversion from in-memory method

calls to RPC leads to chatty communications● Remote calls costly

Solution● Coarser-grained communication

Pipeline

Design for failure

MonitoringTo be sure all is working fine

Types:● Architecture elements (# queries to db)● Business metrics (#users registered)

Evolutionary design

Problems● Versioning problems● Evolute monolith core to micro-services● Service cohesion

Summary

Micro-service architecture

A no definition:

“A particular way of designing software applications as suites of independently deployable services.”

Monolith apps vs micro-service

Single logical executableThree parts:● Client-site (UI)● Server-side (app)● Database (data)Problems:● One change => Full app deployment● Good modular structure hard to keep● Scaling full application

Characteristics

Common characteristics:● Componentization via services● Organization around Business capabilities● Products not projects● Smart endpoints and dump pipes● Decentralized Governance● Decentralized Data Management● Infrastructure automation● Design for failure● Evolutionary Design

Componentization via services

Something independently replaceable & upgradeable

Remote calls are expensive

Micro-service:● Own services● Own domain● Own database

Teams organized around Business capabilities

Segregation of teams:● Specialists teams (by technology)● Cross-functional

Application architecture:● When siloed application architecture● When cross-functional teams

Products not projects

Team responsible of one product in each step:● Development● Build● Deployment● Maintenance

“You built it, you run it”

Smart endpoints & dump pipes

Communication patterns

Avoid chatty communications

Unix approach => Well defined services

Pipes act as filters

Decentralized Governance

Choose best technology for each problem

“It’s about freedom”

Decentralized Data Management

Bounded Contexts

Each micro-service with its own database

Avoid transactions (distributed trans.)

Compensation operations instead

Infrastructure automation

Deployment should be boring

Trust your pipeline:● Unit & functional tests [dev]● Acceptance tests [build]● Integration tests [staging]● User acceptance tests [UAT]● Performance tests [Pre-prod]

Design for failure

Monitoring● Architecture elements

○ ex: # of database queries● Business metrics

○ ex: # users registered

Evolutionary design

Versioning problem, as a last resource

Monolith core but evolution with micro-services

Split components into services

Service cohesion => merge services when changing together

Links & bibliographyhttp://es.memegenerator.nethttp://martinfowler.com/articles/microservices.htmlhttp://www.infoq.com/articles/CCC-Jimmy-Nilssonhttp://alistair.cockburn.us/Hexagonal+architecturehttp://davidmorgantini.blogspot.com.es/2013/08/micro-services-introduction.htmlhttp://domaindrivendesign.org/http://yow.eventer.com/yow-2013-1080/practical-considerations-for-microservice-architectures-by-sam-newman-1389

What about Silex?

Sorry, no time left

No code, no mentions, but I promise to publish something on github :)

But ...http://www.slideshare.net/hhamon/silex-meets-soap-resthttp://sleep-er.co.uk/blog/2013/Creating-a-simple-REST-application-with-Silex/https://github.com/vesparny/silex-simple-rest… and so on ...

Thank you

Questions?

Don’t you prefer a beer instead?