Micro Frontend Architecture - Luca Mezzalira, DAZN

[Music] thank you very much Joe it's working can you hear me perfect great okay so first of all thank you for choosing this session over the other it's a pleasure having you here today I'm very excited to be on the stage today because it's the first time I'm delivering this talk and to be honest it's also very challenging because I'm trying to summarize in two years of work in 30 minutes that is really really interesting so today I want to introduce you on my vision of a micro from x architecture it's not a new topic but there are many approaches that we can have I would like to give you mine as joe said my name is Luca I'm chief architect at the zone the zone a is an OTT platform it's available in seven countries we are already we already have hundreds of developers we have millions of customers is a really interesting challenge because we have 30 devices that we have to keep on track and deliver our applications we have a delivery video delivery pipeline is very complex that's basically the Netflix source port I'm a Google developer expert on web technologies and I'm organizing in London a lot of meetups with my community so if you are in London and you're looking for a meet-up but usually we organize one per per month so feel free to join us so what we are going to cover today so first of all we will do a journey from a monolith to micro anything and then we were talking about what is a microphone 10 we will define some principles around them and we will end oh and we will end up with some technical implementation or let's say different option that we can have in order to embrace this new architecture first of all and foremost obviously this one is as I said the first time that I do this talk but in order to arrive to these ideas and and concept I had to be very open mind and questioning all the best software developer practices that I studied in the past so please be open-minded during this talk and think at scale because this is one of the way that you will embrace better the DS architecture okay so I joined the zone four years ago we started we are still a startup in a certain way despite the number of people that are working on the zone and I remember the one of by the first day that was there and the CPU came to my desk said listen look up I know that you are the second tech person that was hired inside this company but at the same time I would like that you think broadly and you start to think at scale because what we would like to have in the zone is having undress of developers that are working on the same platform and the same codebase and to be honest in a certain way as an architect I was a bit scared because if you think about that you know you are the second that joined the company as a tech person and suddenly you discover that you already have to this huge challenge to think about an architecture that could empower developers both distributed teams across the world working on the same code base so it is a big challenge so beard that in mind let's start to this journey that was basically the journey that I did in order to move forward towards the micro world as I call it so when we start the usually when you start a new project or if you work in a startup usually what what you really care about at the beginning is retrieving quickly a feedback from from your potential customers right so the tech stock is important but not essential what we usually what you do is you tend to obviously the time to market is more important therefore you - you tend to maybe cut some corners but usually 90% of the time what you hand up having is I say a database that is shared across multiple api's you have an NPI layer that is storing what they call a monolith that basically contains all your API is integration with third-party companies and so on and then on the client side you have a single page application single page application a peak that that architecture just because obviously there are several several others that you can pick it could be server-side rendered you can have single pages but single page application is one of the most used where you download that the entire code base and basically then you just consume sub you API is in order to view the rendering rendering the view and and then when when you validate your ideas and the company starts to grow you identify what are the areas that has to grow with the company and the organization so what you start to do is taking your monolith breaking it up in multiple micro-services you start to have one database for microservices because otherwise it's an anti-pattern using a shared database for a multiple micro service you have your infrastructure that is dedicated for that and then you start to divide your teams following and they say the way how the business works but what what do you do on the client side on the client usually what you have is a I don't know tens of developers that are working on the same codebase how they started and it's becoming more difficult every time every iteration because if they're not very prescriptive in the way that they are working you need to have let's say a code base that is exploding and it's way more difficult if you start to have distributed teams because we distributed teams is very very hard part from Puglia having two requests that you can check what is the outcome of you of your codebase so the import with your team so usually on the front hand side we as we said we have a unique code base that is managed by multiple teams what we need to manage a lot is the communication overhead between different parts of the organization and particularly if you have if you have a distributed team on instead if you check what is happening on the infrastructure side so the website and and back inside they start to have a structure that allowed them to scale independently some part do I have they have some strong boundaries around what they are delivering and everything became easier in a certain way because if they design properly they're microservice in the api's they just define a contract and they stick with that and then they are completely autonomous to deliver a new micro service a new version they can there are some a lot of engineering engineering practices that you can use in order to ensure that your micro service is not breaking up the entire platform also in production so a lot of these things but on the client side it wasn't exactly the same things right so as we said this is our situation and I would like to - that you stick that in mind because this is how often these kind of things are working but what if we change this thing what if we start to take the principles of microservices and apply to the client side what if we start to say okay so domain driven design is not only for for the back end it could be applied those on the front end at the end of the day if you think about that we have a monolid we break it apart and we start to have multiple api's that are managed by multiple containers or I don't know lambdas or whatever you prefer to deal with and then you start to have let's say an infrastructure that is dedicated for certain micro service and you can have votes on the front end you can break apart the SP a monolith I have English saved some challenges obviously because obviously you need to find a way to work it straight which client which a microbe microphone tank you won't load but at the end of the day you can do that and you can end up on something under an architecture like that obviously is a simplification but why not so if we if we let's say start to begin a little bit further with that we can start to see something very interesting so first of all the impact to the team because we don't think often as architects or too much on the process of how we structure the team but we have to do that because if we want to scale your company that is probably one of the most important thing in particular for the front-end front-end if you scale the front and you don't have to scale infrastructure because we are delivering vast majority of the time static files so CD s are doing that for us what we need to scale and think about that is it are the teams because that is the complicated part but it with micro front ends we can start to introduce a way to speed up the throughput of our teams because we can have cross-functional teams that are managing the Microsoft API layer the infrastructure layer and the front-end layer in our in autonomy they don't have to let's say communicate with other teams as long the contracts are respected they start to have freedom responsibility because they own the force at hand - and for the first time they they can innovate as we know one of the best one of the pleasure working with micro services is the fact that you can have multiple technology stock on when you are designing your Europe eyes we can do the same on micro front ends why you can have you cannot have like the no part of your application written in beauty yes in part with react and redux and part with angular it's totally feasible so let's talk about what is a micro friend from front end now so this is my definition obviously you cannot find much on on the web so I'm working hard in order to provide some information so starting from a DD perspective micro front ends are a technical representation of a business domain subdomain and they provide strong boundaries with clear contracts and they avoid sharing logic with other subdomains that for me is a let's say and a definition that is providing clarity on what we are trying to achieve with microphone tents and I would like to check the key part of this sentence so representation of business subdomain with strong boundaries and clear contracts and avoid sharing logic so domain a subdomain is not a new concept is something that is applied in domain driven design for a while and often domain driven design is is thought mainly for for back-end layers but we should do users on the front end so let's see what what is a domain a domain is the problem to be addressed with the software effort so if you think about Netflix I hope that everyone knows what Netflix is the domain for them is an OTT platform that is trying to deliver movies with streaming okay but obviously if you we take all this domain or together is very complex because there are a lot of things inside there that we have to think about subscription came and catalog and so on and therefore we did it is tending to say okay so if we have a domain you can split it up in multiple subdomains and usually if you do that very well and you master the domain you can start to map your subdomains also with teams and that is very important because obviously you can start to have light another payment team and you have like the infrastructure team and your front and the back end team and the cross-functional team working together with the product and that is something very very important because when you have that it means that the communication where I'd start to diminish a lot another key concept of micro front ends for me is share nothing and I know that it's very painful at the beginning because the first thing that we tend to do on the front end is okay so I have to create my application there are some components that are available in multiple area of my application let's create a component library and trust me I spend a lot of time working with on this topic with developers and they know what are the pros and cons of this I know that there is a lot of resistance at the beginning but the fact that you are so if you think about the microservice usually with the macro service you you share really a little bit that usually are logs and monitoring and often are not even inside your code what if we can do the same on on the front end honestly what we have done so one of the things that usually we have in the zone a lot of people are saying okay we have multiple microphone tents and we have the header and footer that are replicated I don't know five six times copy and paste and then changed and a lot of people are saying oh yes but that that is a bad practice because we are copying code and every time we need to change we need to change five times but the question is how often the header and footer is changing during the lifecycle of a platform so I checked that that thing and we changed twice in three years so is it really a problem the fact that we are adding a new label inside the header or we are changing the color of the font I don't think so I think that the throughput is way more important and then thinking on okay we have to to deal with this duplication of code and if it's well address is not a big deal so how we can approach microphone tents because there are several ways that to do that it's not as I said it's not a new concept but we are trying to find the right way to do that so for instance modify in the desktop application they they work with iframes it's a massive application that is based on web technologies for the UI and the C++ behind the scene and what they are doing basically are creating multiple iframes that are their minor front ends and inside the view there is I don't know the microphone time for it for the music player they ever I don't know what your friends are listening there is the least catalogue microphone Tennison and they communicating together via an even that is injecting inside microphone tan that is one option obviously the question here is how we can let's say assemble these views in a proper way probably there is another team that is doing that probably the reserves responsibility of a specific team but still there is a lot of communication at this going on open table another large organization they have distributed teams in Australia London and San Francisco Furman well they created after so they started this journey of microphone tans in 2014 if I remember well and they they basically created a developer experience team that the delivered is open components as an open source project where basically when we define a component is a front-end back-end and style and everything server-side render the component that the store inside the registry think about doctor if you're familiar with that and each single team can pick up from this registry the components that they want and they compose the application without much communication at the end because if there is a team in Australia that is creating I don't know header then it could be used anywhere else obviously there is some coordination that has to happen on this side that cross region but at the end is really an interesting and interesting approach that is another another approach for microphone tans as well obviously for smooth for making a smoother the experience for developers they created also CLI but that means at the same time that a new joiner in in open table has to learn all these things and start to use all the tools that are available inside the company the first example that is the one that is closer to my my ideas is the landed these fashioning comers and several several years ago I attempt to talk made by one of their engineers and the interesting bit there is that they basically created an open-source framework or mosaic and there there is a specific part called Terry Taylor Jes and what Taylor does is basically created at runtime that your pages basically there is a tiny layer that every time you request a page they are assembled HTML fragments on the go obviously they are highly cacheable because when you have like I don't know tracksuit from adidas it would be always that you don't have to serve something specific but in that case they can do that they can work at scale they produce these pages they cash on and CDN and that that's it the tailor is written in in go it was one of the first experiments that they so pretty brilliant for forefront and written in gold they were inspired by a big pie from Facebook so you can see a big Python on Facebook pages it's more or less similar but to so in this case we are talking about components that are assembled at runtime on the server we took a different approach in this case because one thing that I was thinking when when I was designing this architecture is okay so now we have like one or a small team of developers start working on one platform that is web but we need to target 30 platforms we need also to have a distributed distributed teams that are sharing the same codebase because they have to work on same codebase and who else who knows what could happen next so the first thing that I did I take our application that if you think about Netflix is very similar and I I work with the domains so I started to slice and dice my my application in multiple domains subdomains so we have the landing page subdomain we have the authentication that contains sign in/sign up retrieve email every pass for payment altogether we have discover in playback where we have basically the core of the zone where we have the catalog we have a search functionality we have a scheduled functionality and we have the playback then we have the customer support where we have the help and the chart the contact hours and so on and we have my account where you can basically change a few of the things so those are the let's say the key domains that we have subdomains that we have inside the zone domain and those are mapped one to one with our product team so we have a product team that is managing payment we have a product is managing I don't know the acquisition we have a prior protein for managing the landing page sometimes the product team is composed by one person only some I'm gonna say compost more people discover in playback is pretty huge for instance but this is how we restructure things and each single of these areas are represented in technically speaking with a single page application so each of them is a single single page application some of them they are not even sharing the same stuff technology stuff some of them are based on react demo backs some other just react we are doing some tests with other technologies but all of them are completely different projects managed by different tips and they know that work is straightest because that the complexity of this is not creating multiple single page applications is how we deliver to the client and I spend a lot of time thinking about that and at the end what they came up from in order to avoid scalability issues because the problem that we have compared to the Rando is we need to create something that is highly scalable that is completely customized for for the user therefore we cannot use too much the CDN right now for serving our content because there are too many permutation so I created this layer this called the bootstrap and is the first thing that is downloaded when you type [Music] www.hp.com the applique user is watching the zone and and retrieving the configuration for that specific country then is obstructing the input-output operation for all the other single page application or microphone tents because one of the problems you have when you work on on TVs in particular is that the API for writing something on on the Bradys is there completely different between manufacturer or in the same manufacturer between different Smart TVs editions so if you have a Samsung course I and Samsung Tizen there are completely different API is to write that so therefore if if each single microphone tenders should know this kind of permutation it means that we need to create one for each single platform but honestly we can abstract that and the bootstrap is doing this the other thing is the doing the routing between microphone tans so he understands in which which state is in which state the user and then based on that is retrieving them the right microphone tense so you understand if the user is signed in and if it's signed in it will go straight to the delivering playback if it's not signed in it will really start of serve the landing page unless there is a deep link and that case is going to the authentication page for instance the last thing is it's sharing configuration across multiple microphone test so in that case because it's a vanilla just layer that is just exposing some stuff we are just exposing things that are happening in in one area in one microphone tense and making available for other microphones and to listen to that also for instance I don't know marketing pixel or analytics like Google tag manager stuff like that are living inside the bootstrap and the bootstrap is the key of our of our strategy because obviously if you think about that we need to deliver around 20 Smart TVs application and if I start to have like the less a specific code the domain-specific code inside each single microphone 10 therefore if it's impossible for us because we need to have so much effort in order to make it right that is very difficult we said if I obstruct that on the bootstrap is very interesting because it became very natural I can reuse authentication everywhere without changing anything the other interesting thing of this is that we can do on the delivery side we can do something that is unique right because we can for instance maintain the current application deliver just a subset of the functionality of this new architecture without impacting the user so potentially we can say 30% of our users are receiving the discovery in playback microphone 10 instead of the previous application that is a single page application but at the same time I can reuse all the rest for maintaining the other note the authentication landing page stuff like that so it's a lot this architecture allows us to deploy wherever we want when we want in a specific country and is gradually the the new the new version of a malcontent like we can do with microservices if you think about I don't know Bluegreen deployment or Canada releases we can do exactly the same thing with this architecture so if we think about this what we have we have gained with with a microphone and so first of all and foremost microphone 10 is not a component is a representation of a sub-domain that is matching exactly the structure of our organization its technology and framework agnostic as I said where I can develop a one microphone tending one technology and use another one for another microphone then each microphone tend expose a lifecycle method that is used by the bootstrap when we want to unload the micro front end or mount amount from tenon doing some things inside that each team inside the microphone can can share components code style any other stuff like that but they cannot do that outside the microphone tent because that is going to slow down everything I work in a lot of large organization managing hundreds of developers and when you start to abstract and have a team that is centralizing code is where the throughput is a going nuts because we you start to have a centralized version of your code and every time if you need to change you need to do a number and additional abstraction the code became more difficult to maintain and the six-month time the throughput is gone we studied this way we can isolate the team that can pick the data can take their own decision and they can innovate inside that the other interesting thing with this we can test different building systems one microphone 10 could be brick there could be let's say build with I don't know web pack or another one with parcel and and so on so we can really have a less a granularity of choice that we can do with as this is brilliant so what we achieve so first of all that is for me pretty interesting we were able to to onboard five teams unless in a couple of weeks time so after the first week they were able immediately to contribute the codebase because they are completely independent they don't have to wait for understand deeply the architecture they have like their own single page application that is really tiny and small the domain is more they can understand the domain deeply and then they can they can go and I start to work on that we have currently over a hundred of developers that are working on the same code base that is brilliant because I also in a distributed way because we have people in in Poland we have people in London and we are we are opening right now and you dev Center in after them and and that is one of the power of this finally that the developers have the freedom as possibility to innovate and owning the code end-to-end and not just part of that because often too often architects are thinking just on the API layer but it's not the API layer that is that the complex one because currently we have a lot of let's say way and and patterns and architecture that could help us to to scale it up but forefront and we don't have much so if you want to start to look deeply on microphone dance I pick these two products there aren't many as I've seen as I've showed before you can have like an open components there are other ways to do that like Taylor which is but the two things that for me are closer to my mind's that are are these two framework one is single SBA that is not well known but is providing a structure that is very similar to what we are built unfortunately discover that too late in the process process like a year or a year after that we started to work on this but it is a really interesting one and then flimsy as fringes provides a slightly more flexibility and then freedom we compared to single SBA but is still another interesting one is leveraging reactive programming behind the scene and you can create components with different with different frameworks and the fringe is will let's say collect them and show them inside their ask a folder so this is an interesting one as well in order to wrap up I would like to just summarize what we have seen till now so when we scale from 10 application the problem is not scaling infrastructure is scaling the teams and we have to take in consideration this because it's very very important to have the right fruit put to reduce the communication of rather between teams last but not least often developers are moving from one company to another one and I don't know how is the the the industry here but in London they they are changing more or less every year year and a half mainly because they want to try something new but we microphone talents you are basically providing them what they are looking for inside the organization and also it could be a good way to retain people last but not least I'm working right now on if you're interested to know more about microphone tents obviously because in 30 minutes it's very difficult to summarize everything I'm writing right now a report for a Riley that would be a free report probably will be available by the end of the year I'm doing some a learning session one will be the 18 of October online that is fully free you can check out my social profile and hopefully from a next year I will be able to dedicate some of my time on writing a full book on on microphone tense that's it for me I know that we have some time for for questions but if we are not able to speak right now and question anything I'm around for their own two days so please feel free to stop me and challenge all the ideas that they share because as I said at the beginning is two years work and we are we are going to the past and having a fresh point of view it could only out thank you very much [Applause] [Music]

Channel: UXDX

Views: 49,611

Rating: 4.8933825 out of 5

Keywords: MicroFrontend, Architecture, Luca Mezzalira, DAZN, Developer, UXDX, UXDX18, UXDX2018, Execution, Chief Architect, Dublin

Id: BuRB3djraeM

Length: 27min 46sec (1666 seconds)

Published: Tue Jan 08 2019