Slide 1

Slide 1 text

Architecting for Innovation Stefan Tilkov, @stilkov
 innoQ Deutschland GmbH

Slide 2

Slide 2 text

Problems Some People Have 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 3

Slide 3 text

If you barely manage to keep systems running …

Slide 4

Slide 4 text

… how can you drive innovation?

Slide 5

Slide 5 text

Microservices
 (a.k.a. “the solution to every problem”)

Slide 6

Slide 6 text

“Monolithic” Applications See https://www.innoq.com/en/links/self-contained-systems-infodeck/

Slide 7

Slide 7 text

Layers

Slide 8

Slide 8 text

Contexts

Slide 9

Slide 9 text

Internal components

Slide 10

Slide 10 text

Multi-dimensional complexity

Slide 11

Slide 11 text

„Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.“ — Melvin Conway, 1968

Slide 12

Slide 12 text

Conway’s Law illustrated

Slide 13

Slide 13 text

So let’s start with this …

Slide 14

Slide 14 text

… and cut it apart: Microservices

Slide 15

Slide 15 text

“Flavors” of Microservices > “Microservice” is a very ill-defined term and means different things to different people > Three mainstream interpretations of the term: > “Proper” microservices (where “micro” means “really, really small”) > Collaborating “service graphs” (Netflix-style), medium-sized > Self-contained systems (SCS), complete autonomous systems
 (see http://scs-architecture.org)

Slide 16

Slide 16 text

Self-contained Systems(*) (SCS) UI Logic DB UI Logic DB UI Logic DB Shop system Shop system Products Checkout Search UI-level integration UI Logic DB Products Checkout Search data replication Business domain broken down into vertical slices (*) see: https://scs-architecture.org

Slide 17

Slide 17 text

Finer-grained Microservices UI Shop system Products Checkout Search Logic DB Logic DB Logic DB Logic DB Logic Logic Logic Logic Shop system UI Logic DB Products Checkout Search Checkout Products Search Business domain broken down into UI and services

Slide 18

Slide 18 text

Some equations 1 Service = 1 Deployment Unit
 (“can be deployed independently”) 1 Service = 1 Team
 (“one team is responsible for building it”) 1 Service = 1 Bounded Context
 (“does only one thing, but does it well”)

Slide 19

Slide 19 text

1 project ≠ 1 system
 (“modularize from the start”)

Slide 20

Slide 20 text

Conway’s Law revisited –
 Can architecture have an impact on organisation? ? ?

Slide 21

Slide 21 text

Continuous Delivery > “If it hurts, do it more often” > Enable pushing changes into production as quickly as possible > Continuous Deployment vs. Continuous Delivery > Requires high degree of automation

Slide 22

Slide 22 text

Release Delivery pipeline Manual Testing Capacity Testing Acceptance Testing Commit Stage

Slide 23

Slide 23 text

Delivering monoliths vs. microservices Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release > separate deployment pipelines per team > services can be released and deployed independently > smaller and more frequent releases > whole system is released and deployed in one go > requires significant coordination within the team(s) > large, infrequent releases

Slide 24

Slide 24 text

Prepare to change your DC strategy … > Move from hardware towards software > Automation and self-service > New economics in networking, storage, memory, CPU > Not for the faint of heart > Essentially, become a Cloud provider

Slide 25

Slide 25 text

… or use services of someone who has done so. > Dramatic change in acceptance of Public Cloud offerings > Regional support
 (e.g. AWS in Frankfurt a.M., Germany) > Improvements in legal aspects
 (e.g. Microsoft/T-Systems trustee arrangement) > No silver bullet

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Local effects of changes > Reduced risk of side-effects > High cohesion

Slide 28

Slide 28 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Independent decisions > Separate schedules > Meeting avoidance

Slide 29

Slide 29 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Scale up or down locally > Cost-efficiency

Slide 30

Slide 30 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Less centralization > Reduced effects of failures > Higher overall availability

Slide 31

Slide 31 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Reduced delivery latency > Higher throughput > Faster changes

Slide 32

Slide 32 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Business strategies > Technical implementation

Slide 33

Slide 33 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > DevOps > “BizDev”? > “BizDevOps”? > Metrics for measuring results

Slide 34

Slide 34 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Diversity as asset > No forced single choices > Build, buy, outsource

Slide 35

Slide 35 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Reduced need for 10-year decisions > Replace instead of reuse > Focus on immediate needs

Slide 36

Slide 36 text

Benefits for Innovation 1. Isolation 2. Autonomy 3. Scalability 4. Resilience 5. Speed 6. Experimentation 7. Rapid Feedback 8. Flexibility 9. Replacability 10. Ecosystem > Supports for partners > Internal and external collaboration

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Summary

Slide 39

Slide 39 text

Architecture Organization Agility Innovation

Slide 40

Slide 40 text

Stefan Tilkov
 [email protected]
 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 Thank you. Questions?
 Comments? @stilkov