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 Slide

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

    View 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 Slide

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

    View 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 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 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 Slide

  8. Architecture Consulting...

    View Slide

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

    View Slide

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

    View Slide

  11. A monolith

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. Architectural Decisions

    View Slide

  16. Architectural Decisions
    > Domain Architecture

    View Slide

  17. Architectural Decisions
    > Macro Architecture
    > Domain Architecture

    View Slide

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

    View Slide

  19. Self-Contained System
    (SCS)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  25. An SCS contains its own 

    user interface, specific 

    business logic and 

    separate data storage

    View Slide

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

    View Slide

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

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

    View Slide

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

    View Slide

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

    View Slide

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

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

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

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

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

    View Slide

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

    View Slide

  37. Close for change
    Change by extraction

    View Slide

  38. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Change by extraction

    View Slide

  39. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Create new system

    for new features
    Change by extraction

    View 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 Slide

  41. Close for change
    Enable integrateability

    (auth/auth, navigation)
    Create new system

    for new features
    Integrate and/or

    replace part
    Change by extraction

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  45. Steps for modularisation

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

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

  51. Enable Experiments

    View Slide

  52. innoQ Self-Service

    View Slide

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

    View 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)
    innoQ Self-Service

    View Slide

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

  56. SCS in Real-Life:
    Insurance Portal

    View Slide

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

    is pretty straightforward

    View Slide

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

    View Slide

  59. Ok, more
    than a
    little

    View Slide

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

    View Slide

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

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

    View Slide

  63. View Slide

  64. Testing

    View Slide

  65. View Slide

  66. View Slide

  67. View Slide

  68. View Slide

  69. Operations

    View Slide

  70. View Slide

  71. View Slide

  72. View Slide

  73. View Slide

  74. Latency

    View Slide

  75. Latency
    • Mexiko: ~400ms

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

  80. View Slide

  81. Don't monitor hosts,
    monitor business services

    View Slide

  82. conclusion

    View Slide

  83. Summary

    View Slide

  84. Summary
    > SCSs are a reasonable approach to Microservices

    View Slide

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

    View Slide

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

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

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

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

  90. BACKUP SLIDES

    View Slide

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

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

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

    View Slide

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

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