This document discusses strategies for breaking up monolithic applications and transitioning to microservices. It outlines two main strategies - strangling the monolith by adding new features in microservices while maintaining the monolith, or building a parallel new product. It then provides details on various approaches within these strategies, such as identifying seams to separate components, developing a common governance model, and starting small by extracting simple services before undertaking a larger "big bang" migration. The document emphasizes that architectural design should come before the technical implementation and that a bite-sized iterative approach relying on automation helps reduce risk when defeating the monolith.

1. ©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
“Difficult Roads Often
Lead to Beautiful
Destinations.”

2. ©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
Break up Monoliths
and lay them to REST
API EXPERIENCE

3. Arun Narayanaswamy
Director - Platform Engineering
A bit about me

4. Amadeus in a few words
4
_ We are the leading technology
company dedicated to the
global travel industry
_ We are present in 190+
countries and employ 20,000+
people worldwide
_ Our solutions enrich travel for
billions of people every year
_ We work together with our
customers, partners and other
players in the industry to
improve business performance
and shape the future of travel
7th consecutive year
included in the DJSI
Recognized as world leader in the
Software & Services industry sector
in the Dow Jones Sustainability
Index in 2018
In world’s top 10
Software companies
Forbes 2020 global
rankings
1.8+ billion
Passengers boarded
in 2018 with
Amadeus and
Navitaire solutions
640+ million
Total bookings
processed in 2018
using the Amadeus
distribution
platform
Euro Stoxx 50
Entry in 2018
Recognition as
one of the largest/
best performing
public companies
in Europe

5. ©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
5
MONOLITHS /
MAINFRAMES
MONOLITHS
SOA + API’s
MICRO / MACRO
SERVICE - CLOUD
Enterprise evolution so far – Internal and External Platform
TTY
EDIFACT
SOAP
REST
TTY
EDIFACT
… ?

6. Defining Monoliths
•Application monolith
•Joined at the database
•Monolithic builds
•Monolithic releases
•Monolithic thinking

7. Choosing which one to break?
TECHNICAL
•Codebase
•Suitable framework
•Footprint
•File system dependencies
•Usage / workload
BUSINESS
•Business criticality
•Risk tolerance
•Change frequency
•Lifecycle stage
•Domain expert availability
ECONOMIC
•Licensing costs (HW / SW)
•Time-to-market implications
•Revenue impact-fullness

8. 8
©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
{ Idealistic } Approach

9. Strangling
New features in new model
Shrink the monolith
•Split Frontend and Backend
•Extract services
Breaking
Build a parallel product
9
{ Two } Strategies for defeating the Monolith
:: Common Governance model ::
Common languages, tools, contracts
Smart Routing
Dynamic Routing
Service Migration
Load Shedding
Traffic Management
Canary Testing
Picking Seams
Team Organization
Business Processes
Verbs & Operations
Nouns & Resources
Models for read/ write

10. 10
©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
{ Case 1 } Monolith to a microservice
Operation
al

11. _Monolith has all modules/
components/ UI co-deployed
_Identify the seams
_Identify hidden coupling
_Don’t ignore the DB
_Note:
• It’s a hard journey!
• Organizations will change too!
11
©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
{EMBRACE} The Monolith
Inspired by Christian Posta blogs

12. _Detail the seams
_Decouple the presentation logic into
a remote UI with API access
_Start small
12
Start with the {Seams}

13. _Consider macro services
_New code with toggles and flags
_Increased surface of security
_Note:
• Vision (of simplifying) is important and
so is the target
• Flags are complex
• API’s need to be secured and flexible
13
Start with the {Seams} – Part 2

14. _Separate the UI
_Every conversation is API based
_Initiate inner-sourcing
_Note:
• Opportunities to run hackathons
• Fast track API usage
• Limited downtime
14
Start {Small}

15. _Re-write the monolith
_Break the data components
_Focus on the API design
_Note:
• The old components are still
operational in the monolith
• Components are work in progress
15
Break the {Monolith}

16. _Focus on API design
_Connect the Data side
_Note:
• Monolith’s API’s are hard to crack
• Work around workarounds
16
Connect the {Dots} & open the {API’s}

17. _Direct the traffic
_Opportunity to test the waters
_Canary loads – Segment the traffic
_Note:
• Double the infra (scale it wisely)
• Double the operations
• Keep the temporary holes plugged
• Works best with new services
17
Start the {Switch}

18. _Autonomous service
_Decouple
_Open the API’s further
_Note:
• Resist the urge to use the monolith
• DevOps & Agile are important
• Move fast, be nimble
18
Enter the {New World}
one-time ETL

19. 19
{ Case 2 } Monolith to a new service (Big Bang!)

20. Where we are today? (6-12m journey)
_Release 200x faster
_API help inner sourcing – Million+ pull requests
_API help backward compatibility – Almost zero rollbacks
_Architecture comes first
• Loosely coupled architecture
• DevOps and API first
_Trust in automation
• Bite-sized and iterative approach

21. ©
Amadeus
IT
Group
and
its
affiliates
and
subsidiaries
Integrated API {Platform}
https://developers.amadeus.com

22. Thank you!
linkedin.com/in/arun-n