Tweet
Tweet

Slide 1

Slide 1 text

When theory meets real life Jerry Preissler Alexander Heusingfeld Lessons Learned in Software Modernization projects

Slide 2

Slide 2 text

Alexander Heusingfeld [email protected] Senior Consultant @ innoQ @aheusingfeld Gerald Preissler Senior Consultant @ innoQ [email protected] @jerrypreissler

Slide 3

Slide 3 text

About innoQ > Software Architecture Consulting & Software Development > Around 120 Consultants/Engineers in Germany and Switzerland > Offices in Düsseldorf, Berlin, Frankfurt, Munich and Zürich > Customers: 90% of Customers in “Fortune 1000” Segment. Finance, Industry, Telecommunications, Public Sector

Slide 4

Slide 4 text

Some of our AWS projects... (partially anonymized due to NDAs)

Slide 5

Slide 5 text

Heraus Kulzer > Designed and developed a cloud based platform in AWS for order management of dental products of Kulzer, Mitsui Chemicals Group. (03/2015 - 12/2015) > innoQ team (4 engineers) developed complete software and defined cloud architecture in AWS > innoQ achieved complete automation of infrastructure provisioning (VPC, network, servers, services) and deployment with CloudFormation. > Start planned for North America, runs in AWS US zones. Currently in Validation phase (not yet in production). Other regions can follow with minimal efforts thanks to Cloud automation. > Technologies used: EC2, Beanstalk, S3, RDS (Postgres), CloudFormation, Spring Boot

Slide 6

Slide 6 text

Global Availability > eCommerce platform to deliver content to consumer devices in global markets using AWS technology (2015/2016) > innoQ team (5 engineers) defined and implemented Microservices architecture, cloud infrastructure and processes for provisioning and monitoring. > Implementation of an “Edge Layer” (similar to technology of Netflix) to enable regional caching of content using AWS services. > innoQ’s Cloud Architecture reduced latency to API endpoints and traffic. > Technologies: VPC, EC2, ECS, Docker, S3, CloudFormation, Beanstalk, AutoScaling, Route53 > Regions: Europe, North America, Pacific, Australia

Slide 7

Slide 7 text

Insurance Portal > Reimplementation and modernization of German customer’s portal of a large insurance company. Migrated platform from internal data center to AWS cloud (04/2015 - 02/2016). > innoQ team (7 engineers) was responsible for software and cloud architecture, developed web and integration software and designed scalable cloud infrastructure. > Use of Hardware Security Module (Cloud HSM) for encryption of traffic and data to comply with strict German data protection act, especially regarding health data. > Currently only German market, runs in AWS Frankfurt. > Technologies used: VPN/VPC-Peering, EC2, S3, CloudFormation, Elasticache, CloudHSM

Slide 8

Slide 8 text

Architecture Consulting...

Slide 9

Slide 9 text

“We want to have a microservice architecture!”

Slide 10

Slide 10 text

“We want to have a microservice architecture!” — Every Customer, since 2015

Slide 11

Slide 11 text

A monolith

Slide 12

Slide 12 text

When reviewing monolithic applications … © innoQ/Roman Stranghöner

Slide 13

Slide 13 text

…and taking a look into the black box… © innoQ/Roman Stranghöner

Slide 14

Slide 14 text

…you’ll likely find it consists of multiple business domains. © innoQ/Roman Stranghöner

Slide 15

Slide 15 text

Architectural Decisions

Slide 16

Slide 16 text

Architectural Decisions > Domain Architecture

Slide 17

Slide 17 text

Architectural Decisions > Macro Architecture > Domain Architecture

Slide 18

Slide 18 text

Architectural Decisions > Macro Architecture > Micro Architecture > Domain Architecture

Slide 19

Slide 19 text

Self-Contained System (SCS)

Slide 20

Slide 20 text

If you cut a monolithic system along its very domains …

Slide 21

Slide 21 text

… and wrap every domain in a separate, replaceable web application …

Slide 22

Slide 22 text

… then that application can be referred to as a self- contained system (SCS).

Slide 23

Slide 23 text

On its outside, an SCS is a decentralized unit that is communicating with other systems via RESTful HTTP or lightweight messaging.

Slide 24

Slide 24 text

Therefore self-contained systems can be individually developed for different platforms.

Slide 25

Slide 25 text

An SCS contains its own 
 user interface, specific 
 business logic and 
 separate data storage

Slide 26

Slide 26 text

Besides a web interface a self- contained system can provide an optional API.

Slide 27

Slide 27 text

The business logic part only solves problems that arise in its core domain. This logic is only shared with other systems over a well defined interface.

Slide 28

Slide 28 text

The business logic can consist of microservices to solve domain specific problems.

Slide 29

Slide 29 text

Every SCS brings its own data storage and with it redundant data depending on the context and domain.

Slide 30

Slide 30 text

These redundancies are tolerable as long as the sovereignty of data by its owning system is not undermined.

Slide 31

Slide 31 text

This enables polyglot persistence, which means a database can be chosen to solve a domain specific problem rather than to fulfill a technical urge. Neo4J CouchDB Oracle

Slide 32

Slide 32 text

Inside of a self-contained system a bunch of technical decisions can be made independently from other systems, such as programming language, frameworks, tooling or workflow.

Slide 33

Slide 33 text

The manageable domain specific scope enables the development, operation and maintenance of an SCS by a single team. Team 1 Team 2 Team 3

Slide 34

Slide 34 text

Self-contained Systems
 should be integrated over their web interfaces to minimize coupling to other systems. https://www.innoq.com/en/talks/2016/02/microxchg-2016-microservices-frontend-ui/

Slide 35

Slide 35 text

http://scs-architecture.org/ more information on self-contained systems (SCS) can be found at

Slide 36

Slide 36 text

Improvement Approaches http://aim42.org for Software Modernization

Slide 37

Slide 37 text

Close for change Change by extraction

Slide 38

Slide 38 text

Close for change Enable integrateability
 (auth/auth, navigation) Change by extraction

Slide 39

Slide 39 text

Close for change Enable integrateability
 (auth/auth, navigation) Create new system
 for new features Change by extraction

Slide 40

Slide 40 text

Close for change Enable integrateability
 (auth/auth, navigation) Create new system
 for new features Integrate and/or
 replace part Change by extraction

Slide 41

Slide 41 text

Close for change Enable integrateability
 (auth/auth, navigation) Create new system
 for new features Integrate and/or
 replace part Change by extraction

Slide 42

Slide 42 text

> Define external, “ideal” interface > Adapt to existing codebase > Transform system to match interfaces Outside-in interfaces

Slide 43

Slide 43 text

> Define external, “ideal” interface > Adapt to existing codebase > Transform system to match interfaces Outside-in interfaces

Slide 44

Slide 44 text

> Define external, “ideal” interface > Adapt to existing codebase > Transform system to match interfaces Outside-in interfaces

Slide 45

Slide 45 text

Steps for modularisation

Slide 46

Slide 46 text

Steps for modularisation • identify domains User Management Payment Product Management

Slide 47

Slide 47 text

Steps for modularisation • identify domains • group teams by domain User Management Payment Product Management

Slide 48

Slide 48 text

Steps for modularisation • identify domains • group teams by domain • agree on macro architecture User Management Payment Product Management

Slide 49

Slide 49 text

Steps for modularisation • identify domains • group teams by domain • agree on macro architecture • first delivery pipeline, then end-to-end features User Management Payment Product Management

Slide 50

Slide 50 text

Steps for modularisation • identify domains • group teams by domain • agree on macro architecture • first delivery pipeline, then end-to-end features • team decides migration approach case-by-case User Management Payment Product Management

Slide 51

Slide 51 text

Enable Experiments

Slide 52

Slide 52 text

innoQ Self-Service

Slide 53

Slide 53 text

Steps to publish an app to the web: innoQ Self-Service

Slide 54

Slide 54 text

Steps to publish an app to the web: 1. Implement app (adhere to template)
 2. Package app in DockerContainer
 3. Publish to ECS (Auth against Company-LDAP) innoQ Self-Service

Slide 55

Slide 55 text

Steps to publish an app to the web: 1. Implement app (adhere to template)
 2. Package app in DockerContainer
 3. Publish to ECS (Auth against Company-LDAP) Too complicated? Just use our self-build CLI to take care of steps 2 and 3. innoQ Self-Service

Slide 56

Slide 56 text

SCS in Real-Life: Insurance Portal

Slide 57

Slide 57 text

Sample Customer SCSs The basic composition of a web application using self-contained systems 
 is pretty straightforward

Slide 58

Slide 58 text

As always, when design meets real life, things get a little more complicated...

Slide 59

Slide 59 text

Ok, more than a little

Slide 60

Slide 60 text

Using AWS Services can actually safe some complexity on your side

Slide 61

Slide 61 text

Don't build your own PaaS DIY PaaS means you have to > self-host, self-configure, self-deploy, self-update and self-maintain needed infrastructure components > maintain knowhow of all the nuts and bolts Do the calculation: Is this your businesses' core?

Slide 62

Slide 62 text

Real-world requirements will introduce some complexity on their own

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

Testing

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

Operations

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

Latency

Slide 75

Slide 75 text

Latency • Mexiko: ~400ms

Slide 76

Slide 76 text

Latency • Mexiko: ~400ms • Australien: ~450ms

Slide 77

Slide 77 text

Latency • Mexiko: ~400ms • Australien: ~450ms + At peak times ~8% packet loss from Sydney to Frankfurt!

Slide 78

Slide 78 text

Latency • Mexiko: ~400ms • Australien: ~450ms + At peak times ~8% packet loss from Sydney to Frankfurt! Implement Stability Patterns!!!

Slide 79

Slide 79 text

Latency • Mexiko: ~400ms • Australien: ~450ms + At peak times ~8% packet loss from Sydney to Frankfurt! Note: Packet loss is much better today! Implement Stability Patterns!!!

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Don't monitor hosts, monitor business services

Slide 82

Slide 82 text

conclusion

Slide 83

Slide 83 text

Summary

Slide 84

Slide 84 text

Summary > SCSs are a reasonable approach to Microservices

Slide 85

Slide 85 text

Summary > SCSs are a reasonable approach to Microservices > aim42 provides structure for software modernization

Slide 86

Slide 86 text

Summary > SCSs are a reasonable approach to Microservices > aim42 provides structure for software modernization > Not everyone who wants microservices is immediately capable to establish them

Slide 87

Slide 87 text

Summary > SCSs are a reasonable approach to Microservices > aim42 provides structure for software modernization > Not everyone who wants microservices is immediately capable to establish them > Don’t overwhelm people, change one thing at a time

Slide 88

Slide 88 text

Summary > SCSs are a reasonable approach to Microservices > aim42 provides structure for software modernization > Not everyone who wants microservices is immediately capable to establish them > Don’t overwhelm people, change one thing at a time > AWS can enable "small experiments" - we don't have excuses anymore

Slide 89

Slide 89 text

Thank you! Questions? Comments? Alexander Heusingfeld, @aheusingfeld [email protected] Gerald Preissler, @jerrypreissler [email protected] 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 Ludwigstraße 180 E D-63067 Offenbach Germany Kreuzstr. 16 D-80331 München Germany https://www.innoq.com/en/talks/

Slide 90

Slide 90 text

BACKUP SLIDES

Slide 91

Slide 91 text

innoQ Mission Statement
 
 innoQ helps its clients to use modern, leading-edge methods and technologies to implement pragmatic software solutions that match actual requirements.

Slide 92

Slide 92 text

Customers (excerpt) Allianz Alcatel - Lucent AXA Bank-Verlag Barmer, GEK, KKH, DAK Bertelsmann Norisbank CredaRate Credit Suisse Deutsche Bank Deutsche Post Deutsche Telekom Digital River DVB Bank Federal Reserve Bank Gothaer Systems Groupon Heraeus Kulzer HolidayCheck HP IBM LVM Microsoft Nokia Siemens Novartis O2 Otto RWE Systems T-Labs T-Systems Typesafe Software AG UBS XING Vodafone Zurich Financial Services

Slide 93

Slide 93 text

Key Focus Areas > Pragmatic Software Architecture > Intelligent creation and use of model information > Effective software development > Efficient operations concepts

Slide 94

Slide 94 text

Focus in engineering Focus of employees in Germany and Switzerland 5 backoffice employees 4 Managers C-Level 10 Consultants with special expertise in project management, requirements analysis and agile development 50 Consultants with main focus in software engineering and development 30 Consultants with main focus in system architecture, platform engineering and DevOps 6 Principals (sales & aqusition)

Slide 95

Slide 95 text

General services > Strategic technology consulting > Project management & requirements analysis > Targeted, focused support by experts > Contracting in customer projects
 (conceptualization, implementation) > Creating of PoCs and prototypes > Reviews, analyses, risk management, continuous quality assurance > Consulting, training, coaching > Delivery of complete solutions (T&M and fix-price)