About this talk
In this talk, Nestor, a member of the Module Federation core team, discusses the evolution of software development practices, particularly focusing on micro frontends and module federation. He begins by exploring the challenges faced by developers and organizations striving for faster feature deployment amidst legacy monoliths. The conversation shifts to the historical context of containerization and orchestration with Docker and Kubernetes, illustrating the complexities that arose from these technologies. Nestor introduces module federation as a solution for front-end development that allows independent deployment of micro frontends. He outlines the launch of ZephyrCloud, an orchestration platform designed to streamline deployment processes, and discusses its evolution into a collaborative tool for various organizational roles. Nestor concludes by presenting a new product aimed at unifying workflows across teams, emphasizing the importance of open source and community involvement.
Full transcript
[music] >> Good afternoon, everybody. My name is Nestor, and I am part of the Module Federation core team. I developed this thing that many people know as micro frontends, and that's pretty much my everyday today. And today, I want to talk about something interesting, but in for me, in order to explain what all this AI jazz is, I need to take you on a little journey with
me. For you to understand where do we come from, why we built what we built, and where are we headed. So, of course, this all begins with a little story. Sometimes, we have ideas. As developers, as managers, as creators. And most of the time, these ideas comes when we are vibing, essentially. But often, when we are on our work environment, these ideas comes to us in teams.
And there is a subtle difference on this because you cannot just do implement a way when you depend on your colleagues and your co-workers. And I consider myself to be lucky because most of my customers and the people that I work with want me to ship features constantly. They want new things, they want new shiny things. But at the same time, I'm also a little bit unfortunate
because I tend to break things very often, as you can clearly see here. And you know, there is this subtle conversation that I need to have with most of the big customers that we have, which is that you are slow because you are large. You are slow because you depend on processes within your organization that slow you down, understandably. But at the end of the day, what
you really want deep down is to just have the ability to move faster. Just ship new features and test those with your customer base more often than not. But the big problem that we've been facing pretty much for the last, arguably, 20 years now is that most of the things that we develop, arguably, are something like this. Pretty much all legacy software, and I know legacy is
too much of a buzzword these days, is nothing but a monolith. You cannot split that down easily to test new things or to just decide to modernize one thing without affecting everybody else. And backends at some point or APIs went through a change around 2005-2006 that tried to modernize this. And I guess you guys probably guess where I'm going with this, which is this thing, microservices. So,
somebody thought at some point that if we split our applications into very specific domains, vertical domains, or even horizontal in some cases, depending how you look at it, you would be able to iterate faster and be able to test more features more often than not. And the very first known iteration of this was a thing named Docker that probably most of us are very familiar with these
days. And everyone thought that this was the containerized containerization would be pretty much the solution and pretty much everyone would be happy, everyone would happy finally with how this works. And that lasted for about 5 minutes until you realize the complexity that come with this. And time later, somebody else appeared and said, "Okay, how about we add orchestration on top of this?" And then of course Kubernetes
was born and said, "Sure, this time surely everything will be fixed with this. There will be no more complexities and my team of maybe 10, 15 people will be able to own one piece of my infrastructure entirely and I will be able to test without any dependencies on anybody else." And that also lasted for about 5 minutes. And said, "Yeah, because, you know, the ecosystem around Kubernetes,
this is an old picture by the way, it is so vast and there is so many ways of doing exactly the same thing. There is orchestration around that, it is a service around that, service meshes, network meshes. That, you know, now you needed one specific Well, one specific team within your organization to have like all the knowledge within the networking layer, the organization layer, and all that,
the CI/CD pipelines. That, you know, everything become a little bit more complicated than we thought at the very beginning. And front ends went through something similar at some point. Uh one way that we can describe uh micro front ends is with a picture like this. Um as you can see here, we have microservices components where you have different verticals for each one of the APIs that you
might be using, but then you have one essential monolith that you can be clearly seeing there. You say, "Okay, let's let's split those up as well into verticals so everyone can be able to deploy their UIs independently without having to affect the rest of the team." the first iteration of this, the very very very first iteration of this, was iframes. I think everybody have worked with iframes
at some point. And I'm sorry for you because I know how painful it is to understand how they behave with each other, especially if you begin coupling them together one on top of the other. These days, things are getting slightly better. Uh I would like to know something out of pure curiosity, and this is not on my slides. How many of you here have worked with the
shadow DOM? That's interesting. Okay, couple of hands back there. Nice. that's another uh isolation layer that the browser have nowadays that make working with some iframes a little bit easier, but again, we are talking about 10 years ago, roughly. This was not a thing back then, or if it was, it wasn't as commonly used as it is today, which it really isn't, but you know. And well,
this lead to this graph. I hope you've seen this before. If you don't, I think this is outdated today. This is pretty much a graph of arguably most of the front end ecosystem today and how it relates to each other. This diagram has most, if not all of the tools out there. Probably some of the logos are now outdated. I know the V ones are or they're
related to the V ecosystem and Boy Zero team, which I think somebody is around here on the Boy Zero team. this essentially is what I like to call the resume-driven development, which I at the end of the day you end up naming all of these buzzwords around technologies that you use. And you don't need to understand in the front-end ecosystem how these relate to each And I
don't know if I'm alone on this one, but I feel a little bit like this when I look into that graph. Which, you know, I enjoy what I work with, but at the same time I feel bad having to let people know that they have to understand the previous one in order to kind of grasp the entire ecosystem that you have to work with. And, you know,
at some point uh when all of those things are so vast and you have too many technologies to work with and specific teams in big organizations, of course they may want to try different technology sets without having to affect between each other. We need a central layer in order to share the context between them without having to affect each other. One of these things is module federation.
In essence, and I think it's the best way to describe it, module federation is Docker for the front end. And that is probably the simplest explanation that I can give you guys in order to understand it. You essentially compartmentalize one application. Uh well, this is a thing with whatever. Compartmentalize one application. I I am missing a slide over there. And you can distribute this application being consumed
by a different one. So, this is starting on Webpack by Sokam Tobias which now works at Versel if I recall correctly building Turbo Turbo pack. And you know, if you search for most resources online, you are most likely going to find out that most people talk about module federation webpack five. But that is not the case anymore. In fact, it hasn't been the case for the past
two and a half years or so. Module federation today is completely agnostic. It works on pretty much in everywhere including without a bundler meaning that if you were doing something like lit components or if you were doing something like um I have to remember the other framework that is bundler is remix. Sorry. Uh you can use module federation runtime without a bundler. But of course, most of
us I believe require at the end of the day beat or webpack or maybe some of you are a speck and I will love you if you do. And how many people use it, right? Because most people think that you know, module federation is a niche use case or a niche library. So, this is a picture I took yesterday. Uh today we sit at around 9 million
downloads a week. And just to illustrate a little bit of who uses module federation that we know is this beautiful picture right here managed to gather. Uh I think this is updated today. I think this is from like a year and a half ago. But all of these companies have some sort of flavor of federation within their stack on in one of their verticals at some point.
And the main reason why they need this is because they need to empower their teams to be able to ship faster without having to be blocked by anybody. And of course, if you own the domain everything becomes a lot of easier. And our first iteration of trying to make life easier for people using Medusa and module federation at scale was named Medusa. So, Medusa was born around
3 years ago, plus or minus. And it was built by the core team of module federation, Zack Jackson and Zack Chapple and all the other other people. And the whole idea was simply that we are not going to delve down into how you like to deploy your micro front-end social applications, but rather we are going to provide you with a way to make that predictable. So, you
are just going to make a observability platform around the library itself, and we are going to give you information such as which customers are pulling which version, struggling with at the time of loading a website, how are people resolving their different dependencies across the entire application as as if it were a monolith. Are you pulling a different React version that you shouldn't be pulling in one of
your leaves instead of the trunk and things like that. But, there was a big problem with this, which was that we run Medusa for around a year, more or less, and we realized that even though Medusa was powerful enough and gave interesting features to some of these people using module federation at scale, it really only made observability simple, and that was not the problem. That is not
what people needed help with. If you think about it, when you deploy one front-end application stand-alone, you deal with one piece of infrastructure, and that makes simple sense, right? The moment you begin splitting this, such as when you begin splitting a monolith into microservices, you need to have different pipelines, and you need to have different environments for each one of these federated applications. So, each piece began
having its own complexity of being deployed and later on, more importantly, being composed. So, everything is consumed as a monolith application by a browser, so you need to decide which version of which piece do you want at any given time. it have nothing have really changed in the last couple of years of how we deploy. Uh ages ago, when I wasn't a developer because I'm too young,
uh people used to FTP to the greater applications. Nowadays, we use CI/CD pipelines to push to S3 buckets. But, the same idea is the same today. We are just pushing artifacts into a storage of some sort. And there is one more important question about this, which is that, as I said, if you are trying to compose an application, what do you do when something breaks? What do
you do when you need to do this? The simple fact of you rolling back now is a quest of finding out, okay, which of my micro front-ends breaks the app? Is it the first one? Is it the last one? Is it one in the middle? And once I know where the issue is, if I roll back that one, is the composition is still workable? Are there any
dependencies on that version that I need to roll back that now makes it so I need to roll back all the other pieces? Because of this problem, and after careful consideration of my uh we decided to rerun ourselves. So, what was born afterwards is what today is ZephyrCloud. And ZephyrCloud is, in my humble opinion, an unfortunate name because we are not a cloud, per se. What we
are is an orchestration platform. We do not deploy your artifacts into a cloud that we own. What we decided to do, because that's what most enterprises require, is that we decided to be a middleman and just a deployment process within your with your software development life cycle. So, the simple thing that we do is that once you decide to adopt us, we bring compute into your cloud
account, whatever that is, it being Heroku, it being AWS, Azure, maybe some of you here even deploy on premise. We don't really care. We are just a way to upload And the later thing that we do, which is where our value resides, is that we make this orchestration easier for you. And you, of course, own the total control of it. This is basically how we understand Zephyr.
Every single time that you build your application with whatever bundler you're using, we are going to generate one of these URLs. Here is one example URL from my colleague, Shane, sitting somewhere And essentially, we understand the application in these different levels. Every person gets their own URL, so every person in the organization each one has its own number of builds, so it is incremental this every single
time that you build, whenever you're building, it being locally or it being on CI/CD, or pretty much whenever you build. That counter is going to increase by There is projects, there is applications, and there is organizations. I think that's pretty standard on any cloud platform. And all of these versions that I'm talking about is just one compilation. It's just the bundler outputting assets, together with a manifest
file that says what that version contains. And all of those are always live. So, this is how it looks like. When you build, uh this is a beta application if I recall correctly. Yeah. And essentially, every time that you build, we hook into the bundling process uh because, you know, we know how this thing works. We wait for the bundle to do something that is called a
seal, which is when they when all the assets are compiled and the bundle is about to close. We grab those outputs and we upload them directly to whichever cloud you're using without having to be an intermediary whatsoever. That comes afterwards when you want to compose your application. And we give you back a URL for the sake of sharing. And at some point, and here's when I'm switching
back to the real conversation, um this is being used by multiple enterprises today, but with all of the AI talk going on, uh most of our customers begin asking us a weird question, which is, all of this orchestration thing that you do, that you are very good at doing because of the inherent ways of how module federation works, can you apply this to agents? Like, can you
apply this to somehow? And I think, as a pretty understandable response from we went something like this and said, "Well, I guess." And we decided to do a quest about, let's talk to our friends, which we know pretty much the entire JavaScript community, what are they doing and how are they doing things?" We began talking with the people from Open Coasts. We've been talking with people like
Tanner Linsley and all of these people that are heading to AI today. And at some point in our research, we found out something that I think nobody really noticed, which was an article published by CERN early past year, I believe. Which was a simple article talking about how at CERN they use MQTT, which is an IoT protocol primarily, to orchestrate AI agents, AI agents, to investigate some
of their papers. And we decided to talk to them directly. And we kind of got into some conversation how they were applying these specifically for research across different domains within their organization. And what we ended up with the kind of thinking was that oh, we want to fix a problem in a large organization that pretty much every large organization has. They are pretty much dysfunctional to some
extent. If you go to any organization today and see between the different layers of management and engineering, you can clearly see that the bigger the organization is, the bigger a disconnection is between the product, management, design, marketing, and engineering is. we went to the question and say, "Cool. Let's build a tool around this." But what we needed to do differently is that this had not this this
couldn't be another engineering tool. This had to be something completely different. It had to take everyone into the same workflow together and we need to make everyone comfortable while using So, we kind of build kind of like a suite of tools and this is the way that I like to disclaim it. Which is This is the product that we are kind of presenting. It is a weird
mix, I have to say, between Slack that I think everybody knows here, VS Chrome, and module federation baked into it. And what this allows you is to make a composable super app. If you guys don't know what a super app is, this is a concept that in the West is not that famous, but in China and Asia in general, it is massive where applications such as WeChat,
for instance, are capable of embedding different other applications within the same one that are by third parties. So, in the same application, you could be using different functionalities force the main one into an ecosystem that they don't control. And the important bit is that it had to be catered to the flows of an organization. So, if designers work in a certain way, they have to be able
to continue to work in that certain way. marketing did another thing, so they should. And the important bit is that everyone should work in a unified platform. So, these are some of the screenshots of this thing. Uh I couldn't take more than the one I'm about to show today for the sake of, you know, keeping it lean. But you have one chat app that looks like Slack
where you can talk to the different agents that we have within the Here you can see, for example, one talking to Figma. If you are QA, you can also ask different agents in different chats to go and test websites. This is a desktop application, by the way. I didn't mention that. And one important bit component that we had is that previously, with Zephyr, everything that we did
was open source, except for the obvious platform on our So, we also wanted to bring the community into this. So, what we decided to center the application around is giving back to OSS and to open source. So, the way you build agents into this is that there is like a marketplace built in that you essentially publish agents and specialists to. And if you are an organization such
as React to put an example, and you publish one a specialist into the marketplace, you are capable of linking your Stripe back into the platform. And if people use your public agent, we are going to be back to your organization based on the amount that people use it. So, that is kind of like the way that we want to give back to OSS by catering agents that
people can use. And for instance, the last bit is that if you are an organization that require one specific type of application to be built, maybe super specific to your use case. For instance, we have people that alcohol manufacturing that have like compliance mechanisms, so they need certain processes to be within their application that they use. Because everything is federated within it, you can build one application,
publish it to your private cloud, and have the client be able to consume that application and be exposed to the organization that is using within, you know, your private workspace. So, yeah. This is the whole pitch. This is what we are building and what I think is going to be the future. Uh this is today about to be open. So, if any of you are interested trying
it out, uh the when we release it on beta it's going to be open for everybody. So, anybody can try it. Uh I encourage you to scan this QR code and give it a go. And yeah, that's pretty much everything for me. Thank you very much.
