Tweet
Tweet

Slide 1

Slide 1 text

A Question of Size Stefan Tilkov, stefan.tilkov@innoq.com, @stilkov Java Forum Nord 2017

Slide 2

Slide 2 text

Reviewing architectures

Slide 3

Slide 3 text

Generic Architecture Review Results Building features takes too long Technical debt is well-known and not addressed Deployment is way too complicated and slow Replacement would be way too expensive Scalability has reached its limit Architectural quality has degraded “-ility” problems abound

Slide 4

Slide 4 text

So let’s start with this …

Slide 5

Slide 5 text

… and cut it apart: Voilà, Microservices!

Slide 6

Slide 6 text

“Microservices” are building blocks of an architectural style that uses deployment boundaries as a first-class software architecture principle

Slide 7

Slide 7 text

How big shall each individual service be?

Slide 8

Slide 8 text

Just make things the right size

Slide 9

Slide 9 text

High Cohesion Loose Coupling

Slide 10

Slide 10 text

Vocabulary http://vanderburg.org/blog/Software/Development/cohesion.rdoc inherent: existing in something as a permanent, essential, or characteristic attribute adhesive: able to stick fast to a surface or object; sticky: cohesive: characterized by or causing cohesion cohesion: the action or fact of forming a united whole;
 in physics: the sticking together of particles of the same substance

Slide 11

Slide 11 text

Separate separate things Join things that belong together

Slide 12

Slide 12 text

Building blocks procedures functions libraries modules units objects classes images dynamic libraries shared objects components services microservices VMs containers lambdas

Slide 13

Slide 13 text

Commonalities dependencies boundary interface environment implementation

Slide 14

Slide 14 text

Information Hiding “[I]t is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.” David L. Parnas, 1971 http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf

Slide 15

Slide 15 text

Single Responsibility Principle “A class [or module] should only have one reason to change. […] The SRP is one of the simplest of the principles, and one of the hardest to get right. Finding and separating those responsibilities from one another is much of what software design is really about.” “There is a corrolary here. An axis of change is only an axis of change if the changes actually occur.” Robert C. Martin, 1995/2003 http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Slide 16

Slide 16 text

Indicators of strong cohesion simple to understand simple to explain one reason to change one stakeholder difficult to split (re-)used as a whole

Slide 17

Slide 17 text

Indicators of weak cohesion hard to understand difficult to explain many reasons to change multiple stakeholders obviously divisible partially re-used

Slide 18

Slide 18 text

Forces for separation Different environments (scale, performance, security, …) Parallel/isolated runtime Crosscutting concerns Frequency of change Parallel/isolated development Need for reuse Technical dependencies Domain dependencies Implementation Weight

Slide 19

Slide 19 text

Multiple Dimensions Different Priorities

Slide 20

Slide 20 text

System Layered system Logic Data UI Module Module Module

Slide 21

Slide 21 text

System System System System of systems Logic Data UI Logic Data UI Logic Data UI

Slide 22

Slide 22 text

Let’s talk about Microservices

Slide 23

Slide 23 text

Microservices – Common Traits > Independent deployment > Focused on “one thing” > Autonomous operation > Isolated development > Localized decisions

Slide 24

Slide 24 text

Benefits 1. Isolation 2. Autonomy 3. Indidual Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replaceability 10. Ecosystem

Slide 25

Slide 25 text

Example: Pricing Engine > Default product prices > General discounts > Customer-specific discounts > Campaign-related rebates Event Bus/Infrastructure →FaaS

Slide 26

Slide 26 text

FaaS – Function as a Service > As small as possible > A few hundred lines of code or less > Triggered by events > Communicating asynchronously Characteristics: As seen on: > Any recent Fred George talk > Serverless Architecture(*) > AWS Lambda (*) https://leanpub.com/serverless

Slide 27

Slide 27 text

FaaS – Function as a Service > Close collaboration – common goal > Shared strong infrastructure dependency > Common interfaces, multiple invocations > Close similarity to actor-based environments > Well suited to decomposable/“fuzzy” business problems Consequences:

Slide 28

Slide 28 text

Example: Product Detail Page > Core product data > Prose description > Images > Reviews > Related content Orchestration →μSOA

Slide 29

Slide 29 text

μSOA – Microservice-oriented Architecture > Small, self-hosted > Communicating synchronously > Cascaded/streaming > Containerized Characteristics: As seen on: > Netflix > Twitter > Gilt

Slide 30

Slide 30 text

μSOA – Microservice-oriented Architecture > Close collaboration – common goal > Need for resilience/stability patterns for invocations > Often combined with parallel/streaming approach > Well suited to environments with extreme scalability requirements Consequences:

Slide 31

Slide 31 text

Antipattern: Decoupling Illusion Stakeholder Stakeholder Stakeholder Platform Person

Slide 32

Slide 32 text

Example: Logistics Application > Order management > Shipping > Route planning > Invoicing Frontend →DDDD Event Bus/Infrastructure

Slide 33

Slide 33 text

DDDD – Distributed Domain-driven Design > Small, self-hosted > Bounded contexts > Redundant data/CQRS > Business events > Containerized Characteristics: As seen on: > (undisclosed)

Slide 34

Slide 34 text

DDDD – Distributed Domain-driven Design > Loose coupling between context > Acknowledges separate evolution of contexts > Asynchronicity increases stability > Well-suited for to support parallel development Consequences:

Slide 35

Slide 35 text

That UI thing? Easy!

Slide 36

Slide 36 text

Assumption

Slide 37

Slide 37 text

Reality

Slide 38

Slide 38 text

Example: E-Commerce Site > Register & maintain account > Browse catalog > See product details > Checkout > Track status →SCS

Slide 39

Slide 39 text

SCS – Self-contained Systems > Self-contained, autonomous > Including UI + DB > Possibly composed of smaller microservices Characteristics: As seen on: > Amazon > Groupon > Otto.de > https://scs-architecture.org

Slide 40

Slide 40 text

SCS – Self-contained Systems > Larger, independent systems, Including data + UI (if present) > Able to autonomously serve requests > Light-weight integration, ideally via front-end > No extra infrastructure needed > Well suited if goal is decoupling of development teams Consequences:

Slide 41

Slide 41 text

Web UI Integration: Links System 1 System 2

Slide 42

Slide 42 text

Web UI Integration: Redirection System 1 System 2

Slide 43

Slide 43 text

Web UI Integration: Transclusion System 1 System 2

Slide 44

Slide 44 text

Building Block 0..1 *

Slide 45

Slide 45 text

So what?

Slide 46

Slide 46 text

Summary & Recommendations

Slide 47

Slide 47 text

1.
 Explicitly design system boundaries

Slide 48

Slide 48 text

2.
 Start front-to-back instead of
 top-down or bottom-up

Slide 49

Slide 49 text

3.
 Modularize systems using the appropriate approach, including monoliths

Slide 50

Slide 50 text

Stefan Tilkov
 stefan.tilkov@innoq.com
 Phone: +49 170 471 2625 innoQ Deutschland GmbH Krischerstr. 100 40789 Monheim am Rhein Germany Phone: +49 2173 3366-0 innoQ Schweiz GmbH Gewerbestr. 11 CH-6330 Cham Switzerland Phone: +41 41 743 0116 www.innoq.com Ohlauer Straße 43 10999 Berlin Germany Phone: +49 2173 3366-0 Ludwigstr. 180E 63067 Offenbach Germany Phone: +49 2173 3366-0 Kreuzstraße 16
 80331 München Germany Phone: +49 2173 3366-0 @stilkov That’s all I have. thanks for listening!

Slide 51

Slide 51 text

About Stefan Tilkov > CEO/Co-founder & principal consultant
 at innoQ > Focus on architecture, REST, Web > Messing with technology since 1993 > stefan.tilkov@innoq.com, @stilkov

Slide 52

Slide 52 text

About innoQ > Offices in Monheim (near Cologne), Berlin, Offenbach, Munich, Zurich > ~125 employees > Core competencies: software architecture consulting and software development > Privately owned, vendor-independent > Clients in finance, telecommunications, logistics, e- commerce; Fortune 500, SMBs, startups www.innoq.com

Slide 53

Slide 53 text

Image Credit Alice Popkorn, https://flic.kr/p/5NsmsK hairchaser, https://flic.kr/p/aqNWyV