Video size:

0:08 Miko Pawlikowski

Hello, and welcome to Conf42Cast, another exciting episode. Today my guest is Luca Mezzalira, a Principal Solutions Architect at AWS UK, and double author. My name is Miko Pawlikowski and I'll be your host. How are you doing today, Luca?

0:26 Luca Mezzalira

All good. Thank you all for having me today. So I'm pretty excited to be here today.

0:31 Miko Pawlikowski

Yeah, pretty hyped, a lot of ground to cover. So, you know, first things first, what's your favorite planet?

0:38 Luca Mezzalira

Oh, that's a good question, Planet Earth. Mainly because, you know, we are living at this amazing planet. And we are trying to make it sustainable and better every day. And probably is my favorite planet, compared to all the others.

0:52 Miko Pawlikowski

Wow, that's really smart. I've not had this one before. Planet Earth, yeah, we should probably take better care of it, given the recent heatwaves and all of that. But I guess that's for another episode of another podcast probably. So I'm really excited for this, because I think we can really extract some value for people who start their careers from the experience that you've had. And you've written two books. "Front-End Reactive Architectures", a few years ago. And the recent "Building Micro-Frontends". We would like to jump into that. But before we do, the first thing that kind of strikes when I look at your profile is that you've kind of worn a few very different hats. I've seen things from like London JavaScript community, to global sports media, and recently to Amazon. Would you like to talk a little bit about that?

1:56 Luca Mezzalira

Yeah, absolutely. I'm a self-taught person. So I started by my own, every evening, every weekend for a long, long time. I started when I was 21. So, it's in January next year, I will mark 18 years in the industry. So, it's been a while that I'm trying to, let's say, to do the 'extra mile'. And I'm still doing that. Obviously, I work smartly then hardly now with more experience. But definitely that is my way to do that. In general, because I grew by myself, learning from others, studying on books and reading blog posts and everything. And then back in the days, also participating to several forums. I'm a big believer in the community. And that's why, on top of my job, I try to do a lot for the community. I am here today in Amazon, because I had a lot of people in my journey that shared their experience, what made them successful. What was right for them, what was wrong. And I'm trying to do the same with my journey, because I believe the community is essential for the growth and sharing experience. Software development, in my opinion, is not scientific, it's empirical. Therefore, experience and trials are the key factor for learnings. So one thing that I love a lot is sharing what I'm learning every day, I'm trying to do my part for the community. And that's why, as you have said, I wear many hats. Because I truly believe in the community, I truly believe in sharing and try to help others indirectly or directly, depends on the occasion.

3:55 Miko Pawlikowski

Right. So you spent like five years, basically, building the London JavaScript community. I think that JavaScript is kind of an interesting example, because the barrier to entry is low. Everybody has a browser, you can open the console tab and start typing. But at the same time, it's also something that a lot of massive companies invest in, right? They build very serious products with it. So I find it interesting that it's kind of covering both ends. It's not an esoteric language. It's not something that's only applying to a specific domain. So it could be very inclusive. Is that kind of what your experience has been?

4:32 Luca Mezzalira

Yeah, absolutely. I think JavaScript is a great language for starting your career. Also, because, as you said, the learning curve is not too steep. There is also a drawback of this approach because, obviously, because it's easy, a lot of things can run without thinking too much. And therefore best practices can be lost. And the feeling is where, let's say, senior developers can really shine understanding what is happening behind the scene on any language. I'm a big believer on sometimes taking a step back and looking behind the scene of what's happening. More often than not, I have seen developers starting their journey with the framework and thinking that only that framework can achieve what they want. In reality, I think if we take a step back, we spend a bit of time learning Vanilla JavaScript, or learning the base of the programming language, as well as design patterns and architectural practices. That is something that is not going to fade away, it is a baggage that you will take with you for all your career. And that is a great investment, because today we have React Angular Vue. Tomorrow, we will have something else. Like it happened for me back in the days with the Flash Platform that I spent 10 years with that, playing very well with several applications, that probably nowadays are easier to do in JavaScript. But definitely not as easy as it was back in 2010 with Flash. And then suddenly at some point disappear. But my transition to JavaScript was, let's say, not too complicated. I knew already what I had to look for. And therefore understanding stuff like Garbage Collector, how the Scope works, how I can create an infrastructure in my code. And that was, for me very important, because then I created already some mental models in my brain that allow me to write code in a decent way. And applying that in another language, it was less than a problem. In fact, in my career, I was lucky enough to play with JavaScript hex, with Lua, with Axios Script and Node.js and many more. Also a bit of RUST. So all of them, when you understand where they're coming from, what kind of programming paradigm they are leveraging is becoming easier if you know those mechanisms in your head to apply and start to write some code in a proficient manner. Because you already have all the mental models in your head.

7:10 Miko Pawlikowski

Yeah, that brings some memories, Flash and how brutal the killing was of it, later on. And also, as you were saying, that I was thinking that people who start with JavaScript now, it's a much more serious language than it used to be. I don't know if you know that book, "JavaScript: The Good Parts". It was pretty thin at the time. I haven't written any JavaScript for a few years now. And I looked at it and, 'Look, all this new features!' So it's nice to kind of see it evolve and be able to do more serious things. I also noticed that you made the jump from Italy to London. Was it in order to be a part of a potentially bigger community? I mean, all of the programming is a little bit Anglo-centric, was that part of the motivation? Just curious.

8:02 Luca Mezzalira

Yeah, there are several reasons why I moved to London. First of all, in Italy, I was an enterpreneur, I had my own company and I was able to work with several customers like Disney, IKEA, Adobe, and then many others. And considering that I spent a lot of time going to conferences and trying to train myself all over the worldvduring that period, I realized that the Italian market wasn't mature enough on the way how IT was treated. And outside, in foreign countries instead, not on all of them, but I found a greater maturity and understanding of this discipline. So I decided to move to London for understanding, first of all, if I could thrive in an environment that's more competitive. And secondly, I would like to experience a good way to do IT and software development. And that paid back. Now it's eighteen years that I'm here in London and I have experienced very interesting situations that I don't think I would be able to find in Italy.

9:12 Miko Pawlikowski

That makes a lot of sense. And it's interesting to say that. So, the IT wasn't taken as seriously as you would have liked. That's interesting. I would have thought it would be similar in various European countries.

9:29 Luca Mezzalira

But not always, to be honest with you.

9:31 Miko Pawlikowski

Eighteen years, that means that it's better.

9:32 Luca Mezzalira

Yeah, and it's not always the case, unfortunately. It depends a lot on the company, but also large organizations in Italy, they have often the mandate to deliver. And for instance, agile practices are not there yet. And it's starting getting better, to be honest. I spoke with quite a few colleagues there and I think it's getting better compared to eight, nine years ago. But in reality, it's difficult to find the environments similar to what they have found here in London. And also the practices, the way how you are treated as a developer and the kind of challenges that you're facing. I think all those compete to make you a better developer, because you're exposed to bigger challenges and more complicated challenges. And I'm quite happy, to be honest, over having or have done this massive change in my life. Sometimes I regret not doing that earlier. But I've experienced the differences, environmental differences of, let's say, dealing with with software development.

10:38 Miko Pawlikowski

Yeah, I can totally relate to that. I made the jump from France to London a few years ago. Well, seven years ago now. And yeah, I did discover that things are very different. In many aspects for the good. Alright, so now you are a Principal Solutions Architect at AWS. That sounds pretty serious. What does that actually mean?

11:06 Luca Mezzalira

Yeah, so as a principal architect, my role is becoming a force multiplier for, not only our customers, but also for my teammates. The role that currently I'm trying to cover is not only helping the customer and to have my experience in trying to solve challenges, but also coaching and mentoring my teammates. And trying to pull the strings of patterns that I'm seeing across the industry. I'm currently focused on the media and entertainment industry, because that was my basic last six years working on a global OTT streaming platform for sports. And I learned a lot, obviously, in the trenches. And now I would like to use my knowledge for helping the customers, as well as the industry, to move forward. Because I think, currently, we are in the middle of a huge transformation in that industry, where we are moving from linear channels to say, over the Internet, and streaming solutions. And I believe that that is extremely fascinating. It's more or less like when we move on the mobile phone from a Nokia to an iPhone. We are on the same trajectory. And I don't think it's happening in your career very often that you see this transition of an entire industry and I'm quite eager to see how it's going.

12:30 Miko Pawlikowski

Yeah, I really liked that description, being the 'multiplier'. That actually is really self-describing. And I guess that's a nice segue into what's a better way of being a multiplier of your knowledge that writing books about it, right? You wrote the "Front-End Reactive Architectures", 2018. And then later this year, the "Building Micro-Frontends" is coming out. Can you tell us a little bit about the motivation? How did you end up writing a book? What motivated you about that?

13:04 Luca Mezzalira

Absolutely, the motivation is still the same. So, big believer on contributing to the community. I started with some talks. In my career, I think I'm hitting towards 200 talks globally in my career. So, quite a few. And I had these two topics that really get the attention of the audience. And obviously, when you are in a talk, despite you can do 10 talks per year, at the end, you really reach a small audience, because you're talking about probably 1000s of people. I thought that reactive programming first, as well as micro-frontends are solving interesting problems, not only from a technology perspective, but also from an organizational perspective. And therefore, those paradigms you can really, let's say, make your organization's scale. That is one of the challenges of these years, if you want, for many organizations. The first one are reactive programming. Was interesting because it was a new paradigm in the JavaScript community, and you need to unwind it a bit. But despite it was a new paradigm, overall reactive programming for a JavaScript developer could be non-trivial. And therefore, I like taking those concepts and doing research behind them and trying to unwind them, making digestible for the mass. And the same thing happened with micro-frontends back in the day, six years ago. When it started, the challenge I had to solve was scaling an organization to hundreds of developers distributed across Europe. And the approach that I took, instead of going straight on designing architecture, was defining some principles and understanding how other architectures, not necessarily on the front end, would solve those problems. Because in reality, often we forgot that there is a link between the organization structure, the communication flow and the software architecture. The moment that we realize that there is this link, then we can design better architectures for our own context. And often I heard many times, 'Oh, yeah, but we should apply the Spotify model here and there'. Spotify had the model that they created for a reason, because they have a context and they studied their context. And they found a way for handling that, despite the wasn't fully implemented. And many other companies are trying to mimic it. The challenge for me is always trying first to understand a) the context and b) what we are optimizing for. Because when we understand those two things, then it's easier to implement an architecture and also to take the right direction for your technology strategy.

15:58 Miko Pawlikowski

Okay. So is there like, a canonical definition of what a micro-frontend actually is? I mean, what makes a bunch of frontends all of a sudden, a micro-frontend paradigm? Like, where do you draw the line? See what I mean?

16:15 Luca Mezzalira

Yes, totally. Often there is this overlap of definition that a component is a micro-frontend. We already use components, we are just lazy-loading that and everyone is doing micro-frontend. In my opinion, it's not exactly that thing. So, micro-frontend for me is a representation of a piece of sub-domain. So if we take domain-driven design, and we look also microservices, for instance, we see that one of the first principles that we have behind microservices is the fact that they are doing one thing and one thing only, specific to a domain. And that should be the same thing to micro-frontend. Secondly, they should be independent. And that's another key characteristics. Because the moment that you find yourself of deploying multiple micro-frontend at the same time, probably you need to go back to the whiteboard and start to review how your boundaries work. Then, often you hear, 'Micro-frontend is the way to mix and match different Yii frameworks'. The reality is, technically speaking, you can do the same with a single-page application. But what you want really is creating performance application, therefore you don't mess around with too many frameworks. Because you know that your JavaScript bundles will be too big and the performance will take a hit. One thing that usually you do though, is when you are migrating your legacy application to micro-frontends is you create a micro-frontend, you deploy in production. And you start to have a situation where you have the legacy application leaving alongside a bunch of micro-frontends. And that is basically applying the strangler pattern, that we are familiar with microservices, that will allow you to slowly but steady, cannibalize the legacy application and get feedback with the code that is going in production and understanding deeply. Let's say, that the impact of your decisions and architecture towards the users. And also you always have a fallback to go the legacy application if something is not working properly. So it's a good strategy. The other important characteristic of micro-frontends is them sharing, so often we have developers that are complaining on the fact that there is some duplication on micro-frontends. Again, it depends what you're optimizing for. Sre you optimizing for consistency or are you optimizing for speed? And if you think about microservices also, there are some parts that has to be consistent. Logging library, for instance, is one. In the case of micro-frontends it's the design system. But often having external dependencies could lead the development team to have frustration, because they cannot deliver what they have in mind, what they are assigned to. So, sometimes a bit of duplication won't hurt at all. And usually my rule of thumb is start with duplication. And then, if you see that there are multiple occurrences, sit down and understand what is the benefit of obstruct that part. Because if you do the other way around is way more difficult than moving back to duplicated code or trying to break an obstruction. And open obstruction, many times I've seen them that are quite premature. Therefore you are maintaining some more complicated code that is not needed, because maybe it's used twice inside the code base and you thought that it could be used across the entire code base. So, sometimes you need to be pragmatic and then revise and refactor when needed. The last thing that's characteristic that I identify in micro-frontend is the ownership part. So usually, I love the DevOps model, you build it, you own it, you run it. And they really want to apply that also on the frontend, and I think is a great model for handling that. So micro-frontend should be owned by a single team. It doesn't mean that no one else can contribute. But it means that this team, because it operationalize the micro-frontend, has the last say on how the micro-frontend should be deployed and if to merge the code or not.

20:08 Miko Pawlikowski

Okay, so I feel like almost convinced that this is a good idea to at least try out. But then from product owners point of view, I think I would be a little bit concerned about just a visual consistency of the specs. Like in the old legacy systems when each one looks different and behaves different. And here, we have to click a drop down list. And here, the center of the index looks the same but behaves differently. What's the best way of dealing with that aspect of this? Is that where things like bootstrap and the kind of frontend frontend, reusable breaks help to make them at least look a little bit more consistent?

20:55 Luca Mezzalira

Consistency in micro-frontend is totally achievable. Usually, one suggestion I have is using web components for having the possibility to apply in multiple frameworks. That means if you need to change also the legacy application for a portion of time, you will be able to do that writing the code once and just use web components that is running on the new framework, and then the legacy application. Now obviously, there are different level of consistency that you can achieve. But if you're using, for instance, specific CSS that in the legacy application, the challenge it would be sitting down, understand what is assigned to what and then lazy-load them within the new framework. Again, there are several patterns, depends on the context that you operate in. But having consistency is totally achievable. Then sometimes for, let's say, for a matter of time, you want to go with the newest and greatest in the new application. And I have seen, as a consumer, but also as architect, when I was designing some applications that it could be that you have a bit of discrepancies on the UI during the porting. But that usually is for a small amount of time, then the consistency will come when you are fully with the new architecture. In my opinion, the beauty of this approach is that you don't have to go in stealth mode for several months before showing something to your business and generate value for your business. You are quickly iterating, deploying, learning from what you deploy, learning how to personalize your micro-frontend. And then create value for your users that usually overcome the small discrepancy. If you have done a good job, that you can find in the UI.

22:47 Miko Pawlikowski

That makes sense to me. So, just kind of like with the microservices, you know, one of the selling points is that you have this little bricks, and they do just one little thing. And then they can interconnect when they need to get information from one another. So with micro-frontend, I could potentially have like one frontend to manage users. Then I would have a different frontend to manage some other resource. And then I will have another one to manage, for example, logging and stuff like that. Right? That's probably already happening, because most places are going to have some kind of SSL, that's kind of their own separate thing. And then we just kind of interconnect them the same way that we do with the microservices, right?

23:29 Luca Mezzalira

That's correct. The idea there is basically you can either communicate between micro-frontend, you can have multiple micro-frontends in the same view or a unique micro-frontend and it depends how you are going to slice your dream. And in that case, if you have multiple micro-frontends in the same view, you can also have imagined that you have, for instance, one micro-frontend dedicated to your user details and another one on the payment details. And are two different domains, because one is belonging to the user. And the other one is belong into to the payment aspect of the user. So potentially, what you could do is if you have both in the same view, you can communicate between them. The first is a instinct that a developer would have is creating a global state, but that is definitely an anti-pattern. Because you are basically coupling by design, your your micro-frontend transit is exactly what you are moving away from. Instead, what you should do is using event emitter or custom events or an observable, or those, let's say mechanism that are behind the pub sub pattern. And that in this case, we will basically decouple your system and will allow especially your teams to work in parallel with an API contract, that basically is the events that you are describing. When instead you want to store something more meaningful like the JWT token or the session. You use cookies or local storage or session storage in that case, because are accessible by any micro-frontend. And therefore, you don't have to pass them around micro-frontends, you just say, 'This is where you can find them. And they take that, and they just use for consuming some APIs.

25:12 Miko Pawlikowski

Exciting. So where's the official manifesto? Where do people go to to find out more about that?

25:19 Luca Mezzalira

Yeah. So currently, on Medium, I wrote quite a few articles. There is one that is collecting all the different publications that they have done so far on the topic. It's now almost three years that I'm doing talks, collaborating with universities around researching on micro-frontend, talking with the other than the other people that are researching around micro-frontend all over the world. And we are developing great things. So I'm trying to gather everything in that, let's say, article on Medium. And moreover, if you follow me on on socials, you will find very often that I talk about micro-frontend and the new articles and new approaches. There are also few books that are already available. Currently, there are two of them. One is "Micro-Frontends in Action". And the other one is "The Heart of Micro-Frontends". My book will be, as you said, ready by October, so Q4 this year, it was two years of research. So it was quite a long time for writing it. It's around 300 pages. So but the thing is, I didn't want just to share my experience. I wanted to speak with a lot of companies and understanding how they operate and to see if my assumptions and my suggestion could have an impact in their architecture. And they saw that happening. And that's why I took longer, but I'm more confident on the content that is inside the book. Because they know that this testing is working.

26:53 Miko Pawlikowski

That's a good testimony. So for everybody who's just heard about this for the first time, it's buildingmicrofrontends.com, the landing page for the book, with links to where you can preorder. No dashes, just everything one word. And I'm curious about writing during the pandemic, and in general, how did you enjoy doing that, while things were definitely not normal?

27:17 Luca Mezzalira

Thanks. And I spent the last two years, a lot of personal time, weekends and evenings, thinking, writing, testing, speaking with people in US, in Canada, in Australia, to understand how to apply certain things. Overall, I think it was extremely rewarding. But I have to say, there are some days that you really just want to go to bed. Because you have like a really tough week. And then you you maybe already wrote for a couple of nights. And it's not easy. But luckily, I'm pretty good on running marathons. And therefore two years for bringing this project towards the end was a long time for many. But for me, it was needed for really providing the right insights. I don't want just to say, 'This is how you implement micro-frontends'. I want to explain what is the reasoning behind that, because if today there is a framework, tomorrow there will be another one, but you will be able to apply the same reasoning and you know that is going to work. And that's, for me, the most important and valuable thing that you can teach to a perso. Because if you just say, 'This is the way how you build the micro-frontends', you will learn that, you don't dig further for looking at the rest. For me, was more important focusing on the principles, focusing on how to take all organizational problems CICD and defining the architecture, that patterns that you should apply based on different contexts. And you won't find too many lines of code in my book, but you will find a very dense book of concepts and patterns and way to interact in different parts. Not only on the technical side, but also on the organizational side and how your decisions are impacting the communication flow inside the organization.

29:47 Miko Pawlikowski

Fantastic. I am looking forward to seeing the book. And to prop things up, I wanted to extract a little bit of golden nuggets for our readers from you. So I have two questions. The first one is, if you were to pick the single highest return on investment thing, and that's going to be anything, that did the most for your career in technology, what would you pick?

30:14 Luca Mezzalira

I would say, think about the economy of scale. And when I'm saying that is, what I'm saying is trying to identify how your actions can have an impact. Not only for a small amount of people, but the variety of people. For instance, the moment that I prepare a talk, for instance, I'm already thinking, 'Okay, but with this material, I can also write a blog post, I can also do another demo, I can plug it. Maybe this customer can be interested to listen to this specific thing'. So I'm trying to figure out how I can really be a force multiplier. But considering that time is something that I cannot create, is optimizing that your time is the key. And one book that really helped me to think about that is called "The Spirit of Kaizen". Kaizen in Japanese means 'continuous improvement'. And this book is basically, for me, was the pivotal moment of my career where when I read it, I understood that small and iterated tasks that are happening every day, will allow you to achieve great goals in the long run. And that's what I'm trying to do with myself. And that's also why economy scale is helping a lot, because if you start to have to modularize your tasks, you will see how you can pivot specific tasks towards different goals. And you don't have to start from scratch every time, you just reuse what you have built.

31:41 Miko Pawlikowski

That sounds awesome. I haven't read that one. But you're not the first one to sing praises. So I think it's probably time to go and jump on that. And that kind of also goes to my second question. So I'm going to tweak my second question then, to make it about the technology aspect. If there was one technology to look out for in the near future, outside of micro-frontends, what would you recommend?

32:07 Luca Mezzalira

I think, and that's a personal opinion, Serverless is extremely interesting, not only from the technology perspective, but also for the benefits that are bringing in. If you think how currently fast we need to move and how difficult is in any industry nowadays, because we need to innovate very fast. And at least the direction of business very quickly, the fact that we can focus on the real differentiator, that is basically the business logic running on our application, and you delegate the infrastructure to a cloud provider, I think that is a fantastic way to think for the future. Therefore, considering few years ago, how it was, the first implementation of Serverless and how it changed in the recent past. I truly believe the next five years will be extremely interesting for following that paradigm. Because you can really unleash many situation and many projects that maybe before could take months to build. And nowadays, it could take less, for how it works. It's really great and can feed a lot of use cases. Think that will be, for me, where I put my bag of money for the next few years.

33:24 Miko Pawlikowski

That's fair enough. I always smile a little bit when people say 'serverless', because it's just someone else's server now. But yeah, the speed that it helps achieve is quite remarkable and difficult to compare to what it used to be. All right. So before we wrap up, can we just say where to find you? Where's the best spot where you hang out? For those who want to talk about any of these things more with you.

33:55 Luca Mezzalira

Yeah, absolutely. If you want to reach me on LinkedIn or Twitter, I'm extremely active there. So you can drop me a line, send me a message. I answer to everyone. I really love talking with the community, probably as you understood them, I truly believe in the community. So feel free to reach me out anytime. And I'm more than happy to chat with you.

34:17 Miko Pawlikowski

Lovely. So there you go. That's where you find Luca. Thank you once again, this was a treat. And all the best with your book and the daughter on the way.

34:26 Luca Mezzalira

Thank you very much.