Skip to content

Latest commit

 

History

History
438 lines (244 loc) · 7.3 KB

slides.md

File metadata and controls

438 lines (244 loc) · 7.3 KB

[fit] Micro-frontends,

[fit] a migration story on the Edge




@_maxgallo


[fit] Hi 👋 I'm Max

### 🇮🇹 🇬🇧 🍝 💻 🎶 🏍 📷 ✈️ ✍️

Principal Engineer @ DAZN











twitter: @_maxgallo

web: maxgallo.io

right 30%


[.column]






#[fit] Agenda

[.column]



Context

Problem

Solution

Analysis


#[fit] Context

Problem

Solution

Analysis



@_maxgallo

^ Why that person of that team took a different decision ?

^ Reason for writing down ADR, Architecture Decision Records


Users spikes

original 40%

^ Costs of provisioning machines

^ Warm up not easily manageable with live events, for example delays


Users spikes

-> Scalability

original 40%


Company Growth

original 65%

^ Example AWS account

^ Before: We didn't know who the credit card assocciated with the account belonged to

^ After: 4 account for each team, everything managed by cli


Company Growth

-> Autonomy

original 65%


Live Events

original 70%


Live Events

-> Speed

original 70%


Two Frontend Applications

-> Two Companies

inline 50%


[.column]


Users spikes

Company Growth

Live Events

Two Frontend Applications

[.column]









[fit] Context


Context

#[fit] Problem

Solution

Analysis


@_maxgallo


original 60%

^ Same functionalities

^ Vertical Split of the whole application

^ Domain Driven Design

^ Microservices


Micro-frontends

inline

[.footer: Micro-frontends resources: https://medium.com/@lucamezzalira/micro-frontends-resources-53b1ec7d512a]

^ Independent releases


Migration Challenge 1

From Monolith to Micro-Frontends


Migration Challenge 1

From Monolith to Micro-Frontends

-> Strangler Pattern

original 43%

^ Same URL


Migration Challenge 2

Avoid big bang releases


Migration Challenge 2

Avoid big bang releases

-> Canary releases

original 43%

^ Release one MFE per time with Strangler Pattern is ok, but "catalog" MFE is quite a dangerous one to release globally in one go.


Which Frontend ?

original 45%


The Solution

[.list: #000000, bullet-character(->), alignment(left)] [.build-lists: true]

  • Auto Scaling
  • Fast
  • Frontend Independent
  • Same URL
  • Strangler Pattern
  • Canary Deployment

original 40%


Context

Problem

[fit] Solution

Analysis


@_maxgallo


Lambda @ Edge

[.list: #000000, bullet-character(->), alignment(left)]

[.build-lists: true] An extension to AWS Lambda that lets you execute functions that customize the content that CloudFront delivers.


  • No Infrastructure to manage
  • Auto Scaling
  • Pay-Per-Use

right 60%






Lambda @ Edge

Run on CloudFront

original  50%

[.footer: 205 Edge Locations and 11 Regional Edge Caches]


Lambda @ Edge

inline 50%

^ The dotted line is where CloudFront chache the items

^ What's the input and the output ?


Lambda @ Edge

CloudFront Events




inline 45%

[.footer: Full Specifications: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html ]


Lambda @ Edge Challenges

[.column]

Concurrent Limit

-> 1000 concurrent execution 1

Metrics & Alarms

-> Spread across 11 AWS regions

[.column]

Deployment Time

-> up to 10 minutes to deploy

Lambda Logs

-> Spread across 11 AWS regions 2

^ We use Kinesis Firehose to do logs aggregation, which is the method suggested in the blog post.


Context

Problem

Solution

[fit] Analysis


@_maxgallo


Costs

Around 2ms of execution time

inline 55%

[.footer: You pay for Number of Requests and GB per second of memory used (granularity at 1ms) https://aws.amazon.com/lambda/pricing/#Lambda.40Edge_Pricing]


Lambda @ Edge in DAZN

[.list: #000000, bullet-character(->), alignment(left)] [.build-lists: true]

  • Auto Scaling
  • Fast
  • Frontend Independent
  • Same URL
  • Strangler Pattern
  • Canary Deployment

original 42%


[fit] Canary Deployments & Strangler Pattern


inline 60%


Canary Deployment

Two places to store the configuration

inline 50%


Canary Deployment

External Configuration

original 40%

[.footer: External data in Lambda@Edge: https://aws.amazon.com/blogs/networking-and-content-delivery/leveraging-external-data-in-lambdaedge/ ]


Canary Deployment

Sticky Session

+ Cookies

original 40%


TakeAways

[.list: #000000, bullet-character(->), alignment(left)] [.build-lists: true]

  • Context Context Context !

  • Vertical Micro-frontends to splith the Monolith

  • Working on the CDN is possibile

  • Not only AWS (Cloudflare Workers)

  • Routing & Canary Release are just the beginning (SSR3, SEO4, Authentication, Authorization, Real-Time Image Transformation, Security & Privacy...)

^ We're not working anymore in a Client-Server world, but Client, Server and CDN.


#[fit] Thank You

[fit] github.com/maxgallo/talk-micro-frontends-migration




@_maxgallo

Footnotes

  1. It's possible to increment the limit up to 5000 per account, per region. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-lambda-at-edge

  2. Logs Aggregation https://aws.amazon.com/blogs/networking-and-content-delivery/aggregating-lambdaedge-logs/

  3. Server Side Rendering

  4. Search Engine Optimisation