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

Lessons Learned from Software Modernization pro...

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. 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
  2. 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
  3. 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
  4. 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
  5. On its outside, an SCS is a decentralized unit that

    is communicating with other systems via RESTful HTTP or lightweight messaging.
  6. An SCS contains its own 
 user interface, specific 


    business logic and 
 separate data storage
  7. 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.
  8. Every SCS brings its own data storage and with it

    redundant data depending on the context and domain.
  9. These redundancies are tolerable as long as the sovereignty of

    data by its owning system is not undermined.
  10. 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
  11. 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.
  12. The manageable domain specific scope enables the development, operation and

    maintenance of an SCS by a single team. Team 1 Team 2 Team 3
  13. 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/
  14. Close for change Enable integrateability
 (auth/auth, navigation) Create new system


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


    for new features Integrate and/or
 replace part Change by extraction
  16. > Define external, “ideal” interface > Adapt to existing codebase

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

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

    > Transform system to match interfaces Outside-in interfaces
  19. Steps for modularisation • identify domains • group teams by

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

    domain • agree on macro architecture User Management Payment Product Management
  21. 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
  22. 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
  23. 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
  24. 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
  25. Sample Customer SCSs The basic composition of a web application

    using self-contained systems 
 is pretty straightforward
  26. 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?
  27. Latency • Mexiko: ~400ms • Australien: ~450ms + At peak

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

    times ~8% packet loss from Sydney to Frankfurt! Implement Stability Patterns!!!
  29. 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!!!
  30. Summary > SCSs are a reasonable approach to Microservices >

    aim42 provides structure for software modernization
  31. 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
  32. 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
  33. 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
  34. 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/
  35. innoQ Mission Statement
 
 innoQ helps its clients to use

    modern, leading-edge methods and technologies to implement pragmatic software solutions that match actual requirements.
  36. 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
  37. Key Focus Areas > Pragmatic Software Architecture > Intelligent creation

    and use of model information > Effective software development > Efficient operations concepts
  38. 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)
  39. 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)