Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lessons Learned from Software Modernization projects

Lessons Learned from Software Modernization projects

Presentation of the AWS "Cloud for Breakfast" event series. https://www.innoq.com/de/news/2017/04/aws-microservices-breakfast-talks/

Alexander Heusingfeld

April 26, 2017
Tweet

More Decks by Alexander Heusingfeld

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

  3. 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

    View full-size slide

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

    View full-size slide

  5. 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

    View full-size slide

  6. 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

    View full-size slide

  7. 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

    View full-size slide

  8. Architecture Consulting...

    View full-size slide

  9. “We want to have a microservice architecture!”

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  14. Architectural Decisions

    View full-size slide

  15. Architectural Decisions
    > Domain Architecture

    View full-size slide

  16. Architectural Decisions
    > Macro Architecture
    > Domain Architecture

    View full-size slide

  17. Architectural Decisions
    > Macro Architecture
    > Micro Architecture
    > Domain Architecture

    View full-size slide

  18. Self-Contained System
    (SCS)

    View full-size slide

  19. If you cut a monolithic
    system along its very
    domains …

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  24. An SCS contains its own 

    user interface, specific 

    business logic and 

    separate data storage

    View full-size slide

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

    View full-size slide

  26. 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.

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  30. 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

    View full-size slide

  31. 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.

    View full-size slide

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

    View full-size slide

  33. 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/

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  36. Close for change
    Change by extraction

    View full-size slide

  37. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Change by extraction

    View full-size slide

  38. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Create new system

    for new features
    Change by extraction

    View full-size slide

  39. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Create new system

    for new features
    Integrate and/or

    replace part
    Change by extraction

    View full-size slide

  40. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Create new system

    for new features
    Integrate and/or

    replace part
    Change by extraction

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  44. Steps for modularisation

    View full-size slide

  45. Steps for modularisation
    • identify domains
    User Management
    Payment
    Product Management

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  48. 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

    View full-size slide

  49. 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

    View full-size slide

  50. Enable Experiments

    View full-size slide

  51. innoQ Self-Service

    View full-size slide

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

    View full-size slide

  53. 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

    View full-size slide

  54. 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

    View full-size slide

  55. SCS in Real-Life:
    Insurance Portal

    View full-size slide

  56. Sample Customer SCSs
    The basic composition of a web application
    using self-contained systems 

    is pretty straightforward

    View full-size slide

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

    View full-size slide

  58. Ok, more
    than a
    little

    View full-size slide

  59. Using AWS Services
    can actually safe
    some complexity
    on your side

    View full-size slide

  60. 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?

    View full-size slide

  61. Real-world
    requirements will
    introduce some
    complexity on
    their own

    View full-size slide

  62. Latency
    • Mexiko: ~400ms

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  66. 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!!!

    View full-size slide

  67. Don't monitor hosts,
    monitor business services

    View full-size slide

  68. Summary
    > SCSs are a reasonable approach to Microservices

    View full-size slide

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

    View full-size slide

  70. 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

    View full-size slide

  71. 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

    View full-size slide

  72. 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

    View full-size slide

  73. 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/

    View full-size slide

  74. BACKUP SLIDES

    View full-size slide

  75. innoQ Mission Statement


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

    View full-size slide

  76. 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

    View full-size slide

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

    View full-size slide

  78. 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)

    View full-size slide

  79. 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)

    View full-size slide