MuleSoft Manchester Meetup #4 slides 11th February 2021

1. 11 February, 2021 Manchester MuleSoft Meetup #4 (online) Bobby James Solution Architect The Co-operative Bank Francis Edwards Integration Analyst Saint-Gobain Building Distribution Justin Saliba Solution Architect EPAM (Ricston)

2. 11/02/2021 – Bobby James Manchester MuleSoft Meetup Group ‘I Hate Layers’ - A Presentation of Apologies

3. 3 ●About the presenter: ○ Mulesoft Solution Architect at the Co-Operative Bank ■ MuleSoft Certified Integration Architect - Level 1 Certificate ○ Barclays, API Design ○ 25 Year in IT ■ ‘Developer in an SA Cloak’ ○ http://uk.linkedIn.com/in/drbobbyjames Introductions A SHOW OF HANDS: Who is new to this Meetup?

4. API ●Application Programming Interface ○ Layer of Abstraction ○ RESTful / Stateless services ● From a MuleSoft Development Fundamentals (Mule 3)… 4

5. The Application Network 5

6. ‘The’ Layer Slide 6

7. Layer Application Follies ● Application Architecture ● Statements Made ○ Every Layer has to be used ○ Semantics of Names ○ Unknown User, known application ○ Create Customer / Stateless API’s ■ the oxymoron 7

8. 3 Tier Web Architecture 8

9. Message Integration Patterns 9

10. 10 ● Think ○ Functionality ■ Channel API (Consumer / Provider) ○ Layer of Abstraction ○ Security ○ Re-Use ○ Micro-Services-ish ● Define the API and then the Layer (and name) becomes self descriptive “Imagine…..There’s no Layers It’s easy if you can”

11. All contents © MuleSoft, LLC Evolving an App using API Led Design Francis Edwards, Integration Analyst / Developer

12. All contents © MuleSoft, LLC Introduction 1. I’m an Integration Analyst / Developer, I create MuleSoft APIs and applications, deploying and supporting them in on premise and cloud environment 2. I work for Saint-Gobain Building Distribution, the building materials, retail & wholesale arm of Saint- Gobain in the UK 3. I enjoy playing rugby and swimming and perfecting my MuleSoft usage! 12 Francis Edwards, MuleSoft Ambassador

13. All contents © MuleSoft, LLC Agenda ● Show a simple workflow that is not API Led ● Demonstrate how this can be decomposed into the three layers of the API-Led Structure ● Make these APIs not just decomposed, but more RESTful & Reusable ● Outline the coding considerations required for each of the system, process & experience layers ● Highlight the benefits of designing APIs in this manner ● Take questions and share code to those interested in futher investigation 13

14. All contents © MuleSoft, LLC What makes them brittle Point to Point Integrations Many simple application flows mix and match mule scopes and functionality. This can cause performance problems as well as permenantly using more resources than required • Batch scopes are useful for processing a lot of data, but take time to load into memory and disk and require that same memory and disk even when not being used, ie for once a day etl processes • Filtering of streams may involve reading into memory all the input data & require a large vCore • Unit testing or functional testing are usually the same thing, measuring end to end functionality • Processing is usually one-way with little scope for checking output, post processing • Iterations to functionality usually involve added complexity using choice routers and involve complete re- testing of integration • The application usually contains a number of referenced libraries, so is a large deployable archive 14 Process Integration CRM Customer Object Integration

15. All contents © MuleSoft, LLC API Led Applications Separating and Describing the APIs I’ve remodelled an example application, using multiple flows, into separate applications that are optimised for the purpose of each flow • Applications are decomposed using HTTP transports and Anypoint MQs • Each is made independent using RAML to control the datatype of the ingress payload • The process layer has a ‘loosened’ contract to enable future functionality • Extra RESTful functionality is built to make sytem layers more functional 15 Process APIs System APIs Experience APIs Customer Object Interface CRM v2 Replacement CRM Interface New CRM v1.1 CRM v1

16. All contents © MuleSoft, LLC What the Extra Work Has Achieved Benefits The benefits are of decomposing and making the worflow API-Led are; • Smaller experience and process layers (microservices) that are quicker to deploy • Smaller experience and process layers that are also easier to adapt and iterate forward with additional functionality • A more RESTful system layer that can be re-used and offer more functionality • Contracts for the process and system layers that better define functioanlity and aid unit testing • Taking advantage of default and fast exception handling provided by the APIkit Router • Controlling payloads and responding quickly to bad data inputs • Better use of resources such as limited time windows for resource hungry dataloads, but small efficient orchestration • The ability to apply relevent policies, to each layer, specific to the API needs 16

17. All contents © MuleSoft, LLC Using Studio Components in a RESTful way Key Considerations In summary, to be API led, each API needs to be managed independently. The • Use HTTP Listeners to receive payloads, to ensure RESTful interaction and provide http.status and reason responses • Describe the API in RAML, to enable the validation of payloads and loosely define query parameters to enable future functionality • Use the APIKit Router to direct messages into the functional flows and provide default error handling • Use Anypoint MQs to handle messages in a performant manner and separate the handling, orchestration and processing of the input payload • Use query parameters as JSON objects to not tie the process layer to any particular system layer • Make system layers as RESTful as possible, transforming responses and resources where required and creating new methods where possible • Use an auto-discovery global configuration element to enable the application of policies, via API Manager, such as the managed client-id and client-secret enforcement policy 17

18. All contents © MuleSoft, LLC Thank you Any Questions or Comments?

19. © Ricston Ltd. 2021 A normal day in Air Malta’s IT operations team Justin Saliba

20. © Ricston Ltd. 2021 Air Malta - challenges ● High competition - entry of low cost carriers and relatively small ‘homebase’ for Air Malta ● Economies of scale are practically non-existent ● Efficiencies and Sustainability - cost cutting and profitability ● Legacy dependent - both internal and external ● Vendor driven - driven by large players ● Monolithic - lacking of integration prospects

21. © Ricston Ltd. 2021 IT’s role within Air Malta • Bringing services and information together • Analyse and understand what a customer really wants • Optimising without disruption • New ways of applying technology • Launch products to market quicker • Increase distribution coverage • Be one step ahead of what the business needs Opening new revenue streams Innovate customer & employee experience Operate more efficiently

22. © Ricston Ltd. 2021 Achieving the vision through API-led economy Data Governance - Be in control of data and information Visibility and reusability Market options and capability to shift Explore new trends, technologies and frameworks Robust, resilient and adaptive Maturity through iteration Provide means and opportunities Becoming core Become as vendor agnostic as possible

23. © Ricston Ltd. 2021 Point of origin

24. © Ricston Ltd. 2021 Forming a team CHALLENGES ● No IT development capabilities ● Previous solutions delivered by external partners - lost of key knowledge and agility ● Lack of development tools ● Lack of delivery experience DECISIONS ● Introduce an Air Malta Platform architect ● Clear executive stakeholder ownership and sponsorship (CIO) ● Form a new development team with Ricston consultants ● Introduce all required tools for development. Git, artifact repository, CI/CD, etc. ● Experience through iteration

25. © Ricston Ltd. 2021 Consistent delivery ● Reduce Human effort → Reduce human errors ● Deployment of Microservices in a Hybrid solution ○ Avoid issues due wrong configurations ○ Encrypt properties through an encrypted Vault ● Delivery/Maintenance of IT infrastructure ○ Depletion of human interaction ○ Setup connectivity/configuration for new VMs ○ Keep all tools healthy ● Tools introduced ○ Atlassian products (Jira, Confluence, Service Desk…) ○ Source Control, Artifact Repository, Database version control ○ CI/CD server, Ansible, Docker ○ Log Management/Analysis tool ○ Alerts

26. © Ricston Ltd. 2021 Surviving without QA team ● Lack of manual testers ● Tests became a critical part of our daily delivery ● No tasks are completed without Unit tests and Integration Tests: ○ Unit test: Munit ○ Integration Test: Wiremock, RestAssured, JsonAssert, Docker ● CI/CD closed the gaps ○ A pipeline to deliver artifacts: Build, Test, Package ○ A pipeline to deploy deliverable artifacts

27. © Ricston Ltd. 2021 Maintenance and support ● Log management and log analysis service ● Infrastructure monitoring tool ● Air Malta Logger connector ● Continuous feedback providing Continuous improvement ● API Documentation and Versioning ● Usage of Log Alerts / Anypoint Alerts

28. © Ricston Ltd. 2021 A normal day of an API developer in Air Malta ● Morning stand up ● Focus on developing solutions (when there are no meetings…) ● Single team working in parallel deliveries across several projects ● One click deployment. Automated processes are ready for you ● Tests are a top priority. No Test = No Party ● Feature not completed until documentation is in place

30. © Ricston Ltd. 2021 Use Case 1 - Unlocking the Reservation System Booking Workflow Build a technical understanding of how the reservation system works, rather than relying on prebuilt solutions Adapt booking workflow depending on business needs Adapt to new needs and demands without involving third parties.

31. © Ricston Ltd. 2021 Use case 2 - Brand Identification Check-in Changes in luggages policies Retain control Move to real-time Increase Agility/Flexibility

32. © Ricston Ltd. 2021 Use Case 3 - Flight Crew Management Flight Operations Integration Improved crew satisfaction Additional observability Reusability Operational efficiency

33. © Ricston Ltd. 2021 Results METRIC 1 Up to 5 times faster time-to-market API MVP available for Salesforce integration partner within 2 weeks down from 8 weeks Flight Reservation API project completed in 8 weeks, instead of the estimated at 9 months Flight Operations project complete in 6 months, instead of the estimated at 18 months METRIC 3 95% code-reuse METRIC 2 One-click deployments METRIC 1 Up to 5 times faster time-to-market

34. © Ricston Ltd. 2021 METRIC 3 95% code-reuse METRIC 2 One-click deployments METRIC 1 Up to 5 times faster time-to-market Deployment range from two-nodes on CloudHub to 8 hosts on premises and load balancers Codified deployments included are Mule apps, reverse proxies, database schemas, integration, load and end-to-end testing Zero downtime deployments Results

35. © Ricston Ltd. 2021 Heavy use of out-of-the box Mule connectors and libraries Custom logging connector re-used across applications Re-use of the APIs Tried and tested, highly-available, low-latency, 99.99% up-time METRIC 3 95% code-reuse METRIC 2 One-click deployments METRIC 1 Up to 5 times faster time-to-market Results

MuleSoft Manchester Meetup #4 slides 11th February 2021

MuleSoft Manchester Meetup #4 slides 11th February 2021

Recommandé

Contenu connexe

Tendances

Tendances(20)

Similaire à MuleSoft Manchester Meetup #4 slides 11th February 2021

Similaire à MuleSoft Manchester Meetup #4 slides 11th February 2021(20)

Plus de Ieva Navickaite

Plus de Ieva Navickaite(6)

Dernier

Dernier(20)

MuleSoft Manchester Meetup #4 slides 11th February 2021