MICROSERVICES WHAT, WHY & DONT'S

key concepts for evaluation

effect

free!

…WHAT’S THAT MICROSERVICES THING?

– Torsten Winterberg, Oracle ACE Director

“Microservices are the kind of SOA we have been talking about for the last decade”.

– Eberhard Wolff, adesso AG head of the technology advisory board

“Microservices must be independently deployable, whereas SOA services are often

implemented in deployment monoliths”.

PSSSST! TELL NO ONE(SOA failed)

ARE MICROSERVICES BETTER?• Greater simplicity

• The "micro" difference

• Cloud infrastructure

• New container technology

• Faster, more reliable networks

• Less politics

THE (SOMETIMES EVIL) MONOLITH

✓simple to develop

✓IDEs & development tools support

✓easy to test

✓simple to deploy

✓works well for relatively small apps

- growth overloads everything

- difficult to adopt new technologies

- often stuck with the starting choices

- doesn’t scale to long-lived-application

IN COMPUTING, MICROSERVICES IS SOFTWARE ARCHITECTURE STYLE IN WHICH COMPLEX APPLICATIONS ARE COMPOSED OF SMALL, INDEPENDENT PROCESSES COMMUNICATING WITH

EACH OTHER USING LANGUAGE-AGNOSTIC APIS.

THESE SERVICES ARE SMALL, HIGHLY DECOUPLED AND FOCUS ON DOING A SMALL TASK, FACILITATING A MODULAR

APPROACH TO SYSTEM-BUILDING

DATASTORE

DEPLOYMENT

• suite of small services• running in its own process• communicating with lightweight mechanisms• built around business capabilities • independently automated deployable • minimum of centralized management• technology agnostic

MICROSERVICES

✓each microservice is relatively small

✓easier for a developer to understand

✓easier to scale development

✓improve fault isolation

✓develop and deploy independently

✓no long-term commitment to a tech-stack

✓allow a fine-grained performance tuning or scaling

- additional complexity of a distributed system

- tools/IDEs are monolithic applications oriented

- testing is more difficult

- must implement the inter-service communication

- increase memory consumption

WHO HAS USED THEM?

IS A GOOD CHOICE FOR THE SYSTEM YOU'RE

WORKING ON?

• Strong Module Boundaries

• Independent Deployment

• Technology Diversity

• Distribution

• Eventual Consistency

• OperationalComplexity

COSTSBENEFITS

YAGNIdo a monolith first

MARTIN FOWLER

“you shouldn't start a new project with

microservices, even if you're sure your

application will be big enough to make

it worthwhile”

PRODUCTIVITY vs COMPLEXITY

• ensuring the team has the skills needed

• taking a pragmatic approach

• adapting to teams and customers capabilities

TAKEWAYS

Thank you.

@realfuzzyMichele Franzin

CREDITSslides 7,15 - http://www.infoq.com/articles/microservices-introslides 11,12,13,21,23 - http://martinfowler.com/bliki/ slide 5 - http://apsblog.burtongroup.com/

http://martinfowler.com/bliki/microservices.htmlhttp://www.infoq.com/articles/microservices-introhttps://en.wikipedia.org/wiki/Microserviceshttp://martinfowler.com/microservices/

RESOURCES