[GEECON24] Let's Learn to Identify Technical Requirements for Better Design

Have you ever heard phrases like "it must work 24/7," "I want 100% availability," only to end up with "in reality, a VM will be more than sufficient"? Or conversely, "No SLA, my platform is not critical, it just needs to run precisely at 6:54 AM on the first day of the month"? If these situations sound familiar, don't miss out! Whether these Non-Functional Requirements are explicit or not, they are the keystone of any architecture aligned with client needs.

Drawing on two fictional examples (any resemblance to reality is purely coincidental, or maybe not), we will explore how to navigate the pitfalls of overengineering and establish a pragmatic approach to identifying the right architecture for the right business need.

By the end of this presentation, we'll know how to identify those elusive NFRs that will help us design better architectures while avoiding unnecessary complexity!

Transcript

1. Let's Learn to Identify Technical Requirements for Better Design Philippe Duval & Alexandre Touret Questions: sli.do / #geecon
2. 69% Source: Standish Group Chaos Report 2020
4. ❑1 million of registered users ❑500GB of data ❑50 TPS (peak) ❑40 million active users ❑40TB secured storage ❑1200TPS Sensitive data repository Customer’s goals After 2 years…
7. You are user #1,492,573 in the waiting queue
8. Backstage… It doesn’t handle the load Unavailable It crashed again The database is dying… yet again… Latency is too high It lags The app doesn’t scale
10. ❑ Understand the technical requirements ❑ Draft the simplest design possible ❑ Adapt design costs to the business value How to be a part of 31%?... →Go beyond of the functional requirements!
11. Available 24/7 and beyond Available « We don’t know » Two projects for the following platforms
12. Alexandre TOURET Software Architect @touret_alex blog.touret.info Philippe DUVAL Cloud Architect @malkav30 malkav30.gitlab.io Who are we?
13. We design payments technology that powers the growth of millions of businesses around the world. 7000+ engineers in over 40 countries Managing 43+ billion transactions per year €250M spent in R&D every year Handling 150+ payment methods #1 European payment processor
14. Definitions
15. Volumetry Response time Data Requests per second
16. ❑INTERNAL service level objectives 99% of the web pages must be loaded in less than 2 sec Service Level Objective ❑ Indicator for checking our SLO Effective measurement of the rendering time captured from the HTTP server access logs Service Level Indicator ❑ Contractual agreement (SLA < SLO) Service Level Agreement SLO/SLI/SLA ? n ro ides eb pages nd ro ides Is The customer ho uses our application
17. Availability Authorized Interruption time (per year) 90% 36 days, 14 hours and 24 minutes 95% 18 days, 6 hours and 2 minutes 99% 3 days, 15 hours and 36 minutes 99,9% 8 hours, 45 minutes and 36 secondes 99,95% 4 hours, 22 minutes and 56 secondes ❑ Ability of a platform to be available and provide a service to users when they need it (ex. 99%) ❑It can be restricted to a specific time slot (ex. from 8AM to 8PM) Availability
18. What do we do when us-east1 is down? Disaster Recovery Site ❑ How long does it take to restore the service after a crash Recover in 1h Recovery Time Objective ❑ How much data you allow yourself to loose ? Orders from the last five minutes Recovery Point Objective RTO/RPO, DRS ?
19. Application #1: A 24/7 available (and beyond) application
20. ✓ Ordering ✓ Payment « THIS APPLICATION MUST NEVER CRASH, 24/7 100% OF THE TIME". 24/7 available application, eleven nines Inc.
23. Service SLA App Engine 99,95% Spanner 99,99%
24. The actual need…
26. Service SLA Cloud Run 99,95% Cloud SQL ?%
27. ❑Cloud SQL • 24/7, db-standard-2 instance • 10.0 GiB storage • EUR 38.65 ❑Cloud Run • CPU per request, 2 CPU 1GiB • Memory: 1 GiB • 5/7, 11h-22h, 5,000 orders/month • EUR 0.00 ❑Cloud Spanner • 100 processing units: 100 • 10 GiB storage • 50 GiB backup • EUR 72.90 ❑App Engine standard instances • 24/7, F4_1G x 4 instances • EUR 752.91 Financial impacts EUR 825,81 EUR 38,65
28. Application #2 : « W don’t now y t»
29. An online French pastry Short description of the purpose: « An e-commerce platform for French local products»
31. Architecture (V1) ma on I ate ay ambda ma on DynamoDB ma on ambda a ka Client 2 5
33. https://www.primevideotech.com/video-streaming/scaling-up-the-prime- video-audio-video-monitoring-service-and-reducing-costs-by-90
34. Architecture (V2) ma on I ate ay C2 ma on DynamoDB ma on Client 2
35. Why these failures?
36. ❑The NFRs eren’t adapted to the business model ❑The cost management asn’t considered (vs scalability) ❑The NFRs weren’ t ully aligned with the business domain Why may these platforms belong to the 31%? O , let’s ix them!
37. Our approach
38. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? » Our approach
39. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? »
40. HIPAA ome NFRs you don’t get to choose… HDS KRITIS PSD2 PCI-DSS CERD OIV
41. And what if our application #1 was an essential service?
44. Service SLA GKE Multi-Région 99,99% Spanner Multi-Région 99,999%
45. Business requirements
48. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? »
49. Technical goals Don’t take any technical requirement for granted!
50. Main characteristics of an architecture Evolutivity Modularity Cost Performance Simplicity Testability Fault tolerance
51. Evolutionary Architectures
52. Resilience
53. High Availability Auto Recovery New paradigm From « Hope it will never happen » to « recover easily »
54. What does resilience really mean ? CAP / PACELC theorem
55. Database Resiliency = two distinct problems vs
56. Timeouts “avoid resources overload / avoid w itin fo v ” Circuit breakers “do not ” Graceful degradation “wh t is my MVP” How to mitigate latency problems ? Retries “Miti t ponctual n v i bi ity” Exponentional Backoff “…whi voidin th domino ff t”
57. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? »
58. It’s more a feature of the platform than just a bunch of tools... Think about Observability by Design! Visualize Alert Metrics Traces Logs Global Dashboard Technical console for advanced logs Prometheus ecosystem Elastic ecosystem CaaS specific OpenTelemetry ecosystem Legacy
59. Adapt your technical choices to your skills (or the other way around) Operability
60. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? »
61. Risk management Source: riskstorming.com
62. Low 1 Medium 2 High 3 Low 1 Medium 2 High 3 - Database access issue Probability Impact
63. Low 1 Medium 2 High 3 Low 1 Medium 2 High 3 - Database access issue Probability Impact
64. Error budget
65. Understand the functional requirements Technical goals Know and get feedback from Ops Evaluate the risks Answer to the 1-billion-dollar question: « is it worth it? »
66. « Does the creation of pastries require a 99,95% availability? » « Is the mobile app mandatory for ordering a Kebab? Is it worth it?
67. Wrap up
68. ❑ Get clear and fitted technical goals ❑A pragmatic risk management assessment ❑Simplicity & evolutivity What did our approach bring?
69. I you already operate plat orms… Onboard the OPS Gather, pinpoint & the risks Build a knowledge base
70. To sum up Dig into the user needs Pinpoint the requirements Get down to basics! Iterate!
72. Don’t be a stranger! Follow & get in touch @malkav30 linkedin.com/in /phduval/ blog.worldline.tech @Worldlinetech Feedback Follow us: @touret_alex linkedin.com/in /atouret 72 | Follow our tech team:
73. Explore our jobs in tech: careers.worldline.com Want to shape how the world pays and get paid?