Month: July 2025

Transcript

Olimpiu Pop: Hello, everybody, I’m Olimpiu Pop, and I have in front of me Luca Mezzalira, one of the forefathers of micro-frontends. Without any further ado, Luca, please give us an introduction of yourself.

Luca Mezzalira: Yes. Hi, everyone and thank you very much for having me in this episode of In InfoQ Podcasts. I’m very excited about sharing a few things around micro-frontends. My name is Luca Mezzalira. I’m a serverless specialist solution architect working for AWS at the moment, and over the past 10 years, I started to rationalize how micro-frontends or better distributed systems for frontends are working and how they should be implemented. Hence, I have delivered several talks worldwide. I’ve written a couple of editions of the Building Micro-Frontends book and tried to contribute as much as possible to the community with let’s say some specific patterns that we have implemented over the last few years, like the discovery pattern and many others.

Olimpiu Pop: Thank you, Luca. Looking at your presentation, it was like a nice aha moment. I have to admit I’m a backend guy, and one of the benefits of generative AI is that I can finally have something that looks decent. Well, it’s probably full of holes and everything, but for now, it looks great. You wrote the micro-frontend books quite some time ago, and now you’re writing your second book. What changed in the meantime? How did the ecosystem mature? Tell us your take on this period?

Microservices, microfrontends, data meshes and team topologies are interconnected [01:49]

Luca Mezzalira: Absolutely. The first edition was released at the end of 2021, early 2022 basically, and I started to write it in 2019. That is at least co-located with the findings. At the beginning, when I started 10 years ago, there wasn’t documentation or let’s say many examples that would lead me to define an architecture. I basically took the microservices’ implementation that was very well explained by different people like Sam Newman, Neal Ford, or many others, and I started to apply the principles behind to the frontend and adapted obviously for the frontend part because it’s different from the backend. Right? Since then, when I wrote the first edition, only a few companies had adopted this approach.

A few of them are pretty well known, like back in the days there was Microsoft, there was PayPal, there was Zalando that is a fashion e-commerce, Fever and many others that tried to do the first implementation of micro-frontends, but the community was relatively immature mainly because it was a new topic. Up to that point we always worked building monolithic frontend applications despite we had microservices on the backend.

During my time at DAZN, which is a live sports streaming platform, I basically mastered this idea of micro-frontends and trying to create a vocabulary around that, creating patterns and identify anti-patterns that were basically the culprit of our development. In fact, we use micro-frontends across our applications, and we work on different devices, not only web applications. Since then, to be honest, I moved to AWS, and I was able to help hundreds of teams worldwide from New Zealand to Silicon Valley migrating towards micro-frontends. What I have discovered during this year, and that’s also the reason why I wanted to write a second edition of the book, was that many of the patterns and anti-patterns that I have gathered during the previous years were common across multiple companies. But then I started to refine them and started to see commonalities across different industries, project that I follow from B2B to e-commerce, retailers, stuff like that.

I started to realize that there was more and provide more heuristics for people to embrace properly this approach because everything boils down to identify the role of platform engineering. For instance, at the beginning was more let’s say loose to a certain extent in the first edition because I tried to cover the things that I believe were important like automation pipeline, how to think about that, deployment, et cetera. But I think in this new edition I cover way more with way more opinion, and plus, the ecosystem changed drastically.

In fact, Vercel, Astro and many other well-known frameworks nowadays are starting to wire towards the micro-frontends approach. I remember React. With React 17, they embraced the idea of the possibility to have multiple React version inside the same virtual dome. That is interesting because at the beginning they were reluctant to do that. Nowadays it is normal having React available into… Having micro-frontends with React available. There was a lack of tools at the beginning in 2021.

Nowadays, we have plenty of tools that enables people to build micro-frontends properly. Recently there was let’s say a new version of Module Federation and single-SPA that are two or the main frameworks I would say for building micro-frontends on the client-side rendering. For server-side rendering, we had Vercel that did a huge investment in the last year and a half building micro-frontends as a first-class primitive inside their platform, and also democratize several of the challenges that we have experienced in micro-frontends to their customers. Not only that, I think the direction of travel is getting more interesting with these acknowledgement that there is a strong need of distributed system on frontend.

Funny enough, to be honest with you, another thing that I noticed in the architecture space that makes me extremely happy is that after the let’s say announcement or the introduction of microservices back in the early 2000, more or less at the same time when I was starting to talk about micro-frontends globally, also data mesh came along.

There was a need for different layers of a system to be distributed because we realized that with distributed teams, we can achieve more and work in parallel. If we design properly our system, we can work independently.

This is something that I witnessed firsthand with several of the AWS customers as well as with let’s say companies that have followed where teams started to be independent despite that we are cross-functional component aligned, and I think is a testimony of the good job that the micro-frontends community have done over the years where we started to be more present in different conferences, inspire people, provide documentation, provide examples, simplify the development and the developer experience specifically for developers obstructing certain concepts that before where let’s say custom for each implementation and nowadays became a commodity that they think is something that we have experienced a lot also in the cloud, if you think about that.

Olimpiu Pop: Nice. Let me try to put that in a nutshell. During this period of let’s say four to five years since the first edition of the book came across, the ecosystem matured. We don’t have to speak only about the micro-frontends per se because they are part of a bigger picture, and the whole distributed mindset moved probably… Let’s say that it grew more from that perspective because we don’t have only microservices, we don’t have only micro-frontends, but we’re discussing about data mesh. The concept of distribution in software architecture is becoming more interconnected with the way how we build also teams. That means that distribution and autonomy are the points moving forward from that perspective. Would that sum up what will be the message?

Luca Mezzalira: Yes. That’s absolutely correct. I think it’s important to realize that if you remember, we are old enough to remember the time when, I don’t know, a small team of three, four, five people, you can build a end-to-end the system. That might not be the most advanced one, but I remember building e-commerce with two, three people, or I don’t know, software inside embedded devices with a couple of people. I think that time has changed because their requests from our customers and consumers are completely different. Also, the complexity around all the different aspect that compose a software has changed. Therefore, we need to have multiple people working in the same social technical system.

In order to do that, we cannot use the approaches that we were making, we were using in the past with the monolithic end-to-end system. We need the level of modularity and granularity that has to be expressed across the system in order to make our teams let’s say moving fast towards the release process.

Do you really need a microfrontend? [08:58]

Olimpiu Pop: Thank you. I have to say that even though I saw multiple presentations, also the recordings from QCon, yours remained in a nice place. The main reason for that is that you found a way to speak the hands-on approach, even though looking, at points, at higher level concepts. The heuristics were probably the nicest thing that people would like to because it’s people are using analogies, and now you’re putting in place these nice things, the best tools for developers. But we all know that usually we don’t get a green field, most of us don’t even receive a brown field. Then I was thinking how should we as developers, as architects, whatever, as technical people look at our application with a critical eye and see if we are in a good place or not? How would you suggest we should be looking at that? What would be a checklist? A heuristic to do that?

Luca Mezzalira: First and foremost, I would start by asking: “Do you really need a micro-front end?” Sometimes I’ve seen very often trends coming in, especially in the frontend community, and people jump into these trends straight away without asking themselves if it’s needed, because the moment that you move towards a distributed system is an entirely different situation for several layers or dimensions inside the company to take into account. That’s the first thing that I would assess.

Usually, everything boils down to the number of people that are working on the same project, or if you are working on a multi-tenancy system where a part of the system is entirely standard, if you think about the signing-up of a project, and then you have a part of customization. Therefore, even with small teams of fewer than 20 people, you can reap some benefits from micro-frontends, in my opinion. That is probably the first thing that I will look at.

In case you decide that micro-frontends are the way to go, then we need to look into how to slice the monolithic system. There are a couple of recommendations that I usually provide when we are talking about that. First and foremost, many people and many teams and companies ask me if we need to have microservices to work with my frontends? But in reality, not in my experience, because at the end of the day we are consuming an API. Right? The API, it doesn’t really matter for the frontend if it’s coming from a single API gateway or multiple API gateways, microservices, there is monolith… It doesn’t really matter. The contract is what really matters. You want to use GraphQL because currently you have GraphQL, go for it. You want to use REST, go for it.

One data point that is interesting in my experience over the last few years is that every time that a company starts to look into modernizing through microservices and micro-frontends, the migration or modernization towards micro-frontends takes between a third or a half of the time compared to microservices.

If not even more sometimes because if you think about that data has gravity. Therefore, we don’t have on the micro-content side to think about, okay, so we need to take this massive table or this database, humongous database, and split it in smaller and decide if it’s SQL, NoSQL, a graph database, vector, whatever. In frontend is by far easier starting with, and then you can cascade that decision towards the backend or work in parallel, depends from the capacity of a company.

The other interesting thing that I noticed, so if we say we need just an API that at the beginning could be even what you have right now without massive changes, maybe there are some tweaks that are needed but nothing too crazy, you can start to work on the frontend side and usually my recommendation is starting from a more coarse grain approach. I created this mental model called the decision framework where I say that the first thing that you need to understand is identifying micro-frontends.

Slicing the monolith into microfrontends [12:47]

Either you can have a single micro-frontend that is loaded per time, that is a representation of a single view or multiple views, or it could be multiple micro-frontend at the same time. Majority of the time companies are starting with a vertical split, so having one single micro-frontend loaded because it’s easy to resonate. It’s easier to assign and find boundaries. The real challenge is only finding data points that enables you to say, “Okay, we are going to slice in this way.” My recommendation in this situation is to usually try to understand how your users are using your application. When I started, for instance in my previous company to rationalize how we could slice the application in micro-frontends, I identified the certain patterns that were happening inside the application.

I also described them in the book like, “Imagine that you have a million requests coming to the landing page, but then it was a drop between the landing page and the sign-in and sign-up experience. If you were an authenticated user, you didn’t pass through the landing page or the sign-in or sign-up page; you just went straight into the live video streaming catalogue.” That was fantastic because, in micro-frontends, you typically load an application shell first, which can determine whether the user is logged in or not.

This logic is very generic and can then redirect the user to the right page. Either check if there is a deep link, ensuring the user can access that specific area of the website, or if the user is already authenticated, simply refresh the token and verify that they can access an authenticated area. This approach is pretty interesting. Once we have understood how to split the application, the first step is to know how to route towards a micro-frontend application.

Now, people are afraid to start a modernization because they might think Now I need to go to the management, ask for 24 months for rewriting everything with the latest version of the frontend framework. Then slowly but steadily building everything while I need to keep the lights on, adding new feature in the monolith, and then migrate finally on the other side. But with micro-frontends, because we are splitting up the system in different chunks, it becomes easier to do the migration also and also generate value for your customer and business. Let me give you a concrete example.

Imagine that you understand that one of the key elements of your system is the catalog of your application. The catalog of an e-commerce, that everyone has at least one experience with an e-commerce. Let’s assume that in this e-commerce you have a variety of categories, and you can have furniture, and then you have toys and other stuff. Right? You don’t have to go all in and say, “Okay. We need to recreate an entire catalog, and then deploy and see if it works.” You can take a subset of the system.

You can start very easily with one small category that could be toys maybe and build the application for that and create a micro-frontend for that, and then leverage the URL for entering that specific endpoint to let’s say maintain at the beginning the old catalog alongside or the old application alongside with the new micro-frontend one.

Then understand what works, what doesn’t, if there are issues you can roll back very quickly because at the end of the day it’s just a DNS change that you need to redirect towards, again, back to the monolith. This approach, combined with the vertical split where you have one single view group of views deployed together, enables you to have results and understand how the system works end-to-end very quickly. Because the reality in the distributed system now you don’t have anymore a team that maybe thinks about the CIs, D1s and forget about that. Now you have a constant iteration through that.

You always help people to understand how the observability works, that maybe they didn’t spend too much time while micro-frontends is extremely important because you need to understand what’s going on in production when problems arise. At the same time, you need also to know what the development experience looks like because now it’s different. Right? You have way less to build, way less tests to think about, but at the same time you need to have touching points with other teams that before you didn’t have, how to update dependency and stuff like that. I think though this concern will be let’s say addressed during this iterative approach that we are going to take because we are taking one path at a time if you want.

Slowly but steadily, I’ve seen many customers implementing with these recommendation, their micro-frontends approach, and they were using for the routing part a bit of compute on the edge in wherever CDN they were using. Nowadays, every CDN I can think of, they have a bit of compute that can be leveraged on the edge. This is great because if you start writing the routing logic on the edge, it means you don’t have to pollute the code of the micro-frontend or the monolith. That means less to change and less to test. This is the only entry point that you have, and the vast majority of time nowadays, every single web application, whether server-side or client-side rendering, is front-faced with the content delivery network.

Therefore, it became pretty easy to approach in this way without polluting the code that you’re going to have. This is something that worked at scale with several companies, adding a lot of value, because you don’t want to go all in with a 24-month project without having any benefit immediately.

This is also used with some companies for migrating from an older version of the framework to another version of the framework because the nature of slicing iteratively your application without the need of ending up with a micro-frontend could be very helpful. Because if I move from, I don’t know, a old version of Angular to a new version of Angular, I can take one chunk, one URL or endpoint, and then slowly but steadily adding more stuff in the new Angular application that is monolith or micro-frontend, it doesn’t really matter. But I had customers that have done both successfully, and I think this approach should become more ingrained into the frontend community because very often I take inspiration and patterns from the backend. Those are stuff that we were doing for what? I don’t know. 20 years more or less. The frontend is still new, and sometimes it’s a struggle to make people understanding that those can be easily implemented without too much burden.

How architecture, metrics and organization structure interconnect [19:21]

Olimpiu Pop: Thank you. Usually, when discussing frontend, one of the things discussed was how heterogeneous the ecosystem was. Since we started our conversation, at least two or four new frontend frameworks have emerged in the meantime, either in .js or .ts format, and that was happening quite quickly. As you said, people were embracing them blindly at points. Then, as you touched on, a couple of points are obviously in the backend and have more visibility. Nowadays, I’m thinking about Sam Newman’s presentation, and when you say it’s okay, how do you choose the proper retry mechanism? Or the number of retries that you want to have? What’s the timeout? What can we learn when we’re discussing micro-frontends? As you mentioned, you’re talking about how your customer behaves? What kind of tangible metrics can we use, and how can we implement them.

Observability is essential these days. What can we implement immediately? That will help us move the discussion with more visibility.

Luca Mezzalira: Indeed, we need to tackle this question in two areas. One is how we will split micro-frontends. Two dimensions have to be taken into account. The first one, as I mentioned before, is how your project is being used. Because sometimes we think that, and I’ve seen that a few times, that the user is doing the thing in a certain way, and this may be some assumption that product managers have, while in reality, they’re using your tool differently. That’s the first thing to consider. The second one is how your organisation is structured, because we are all familiar with Conway’s Law. Therefore, we know that we need to design an architecture that enables our organization structure to move and to deliver what is needed.

Sometimes, you can design the architecture first and then rearrange the organisational structure to enable the architecture to shine. Sometimes you cannot, and therefore you need to create an architecture that mirrors what you have currently inside the trenches. It is a crucial point that is often underestimated because architecture, organizational structure, and engineering culture are three dimensions that are tightly coupled. Whether you like it or not, you can intentionally or accidentally touch one of those dimensions, and that will affect you badly or positively based on your decision. If you do it obviously accidentally, it’s a high risk that any decision would generate friction inside your organization because it’s not seen as a social-technical system but more like a technical system. That is a big problem, in my opinion.

On the other hand, when it comes to observability, several tools can help you understand how things are working. Think about, for instance, Sentry, LogRockets or even NewRelic. Nowadays, a majority of the observability tools used for backend APIs also offer solutions for the frontend. There, you can understand that logs are necessary. Still, Core Web Vitals is another key metric that we care about on the frontend to understand, especially for server-side rendering, how the application functions, whether it adheres to proper standards, and so on. But first and foremost, the key thing is understanding logs and the volume of traffic, obviously into your system, to determine what to cache and what not to cache.

All these things should be set up at the beginning of the first deployment of micro-frontends because those are definitely some key elements that compose a micro-frontends architecture. If you think about it, not having them in a microservices system means you’re blind, because when a problem arises, you don’t know where to look. You just have hunches. But specific tools enable them to plug themselves into the state management of a frontend application.

Then, when the problem arises, they are capable of replaying the different steps that the user passes through to trigger that specific problem. If you think that a simple mechanism like this can cut the time required to fix a bug from hours to maybe minutes or from days to hours, then just let’s say it can. As you can understand, those tools are incredible nowadays. All of them are suffering at the moment, or at least I’m not aware of any that are adequately designed for a distributed system.

What to test in the inner loop [23:37]

You need to work alongside your provider in order to get let’s say their approach for that. But I can tell that back in the days, we were able to make Sentry work with the distributed system, and we were talking about 2016, 2017. I presume that nowadays we need some improvements. I’ve seen companies leveraging more and more, but I believe this is definitely one other dimension that you need to invest in. The last one on metrics that I think is extremely important is on the automation part or the shift left movement, as I used to call it, where we also need to enforce specific characteristics in our system. One thing that is important when you are looking at a monolith is the budget size or the size of your artefact. Now you don’t have a single artefact anymore, you have multiple of them. Therefore, people often struggle with that.

But there are some good things that you can leverage. What you can do is, I don’t know, plug some of these characteristics into Git hooks. Before, I don’t know, making a PR or let’s say committing some code, you can build on the fly the micro-frontend, understand if the budget size is respected, and assign even a threshold of leverage for discrepancy in the micro-frontend size. That will enable you to apply certain characteristics that very often people don’t think at all. Because as architects, we want to have certain capabilities expressed inside our system, but the majority of the time without fitness functions where only let’s say guesses or dreams that we wanted to have. Nowadays, we can test certain things. I was doing recently a test with the TSArch library that basically is a porting of ArchUnit from Java. The idea of this is that you can enforce certain criteria.

I can write a test and say, “This micro-frontend can have only an external dependency that is the shared library or this design system, wherever it is.” I can test that the micro-frontend doesn’t retrieve other, let’s say, libraries, external libraries from it. As you can see, there are three dimensions that we need to consider regarding the data points we need to gather in the micro-frontends world. One is on how to slice micro-frontends, so how does the user behave? A second one is during the CI/CD cycle in the automation part, so expressing our architecture characteristics properly as well as providing certain guardrails to the team in order to behave properly.

Finally, when the system is up and running, so when the system is in production and we want to understand where the bug or the issue is arising from. Those three dimensions are obviously completely new, to a certain extent, compared to the monolith. I think those are sometimes the struggles that people either don’t think about at the beginning or overlook.

How to offer a consistent experience across multiple device types [26:21]

Olimpiu Pop: Well, listening to you, a naive question from the backend mind came. As mentioned, I started with the disclosure that I’m a backend guy, so I’m stepping into new territory. I was just thinking that we are quite lucky on the backend side because the servers are in your house, let’s say, whether it’s in a public cloud or in your data centre, you pretty much know what you’re expecting. You can tweak. While discussing the front end, you’re looking for a very heterogeneous environment, as a significant percentage, I don’t remember the exact number, but I know that it is well above 50% of the traffic is coming from the mobile world. It’s very complex, and then we’re looking at different browsers, different screen sizes, and so on. How do you handle all that complexity? The problem is that on the frontend, everybody’s an expert; everybody knows how big a button should be, how it should behave, and everything else. That’s scary from my perspective.

Luca Mezzalira: Yes. I think providing an experience that is common across multiple devices is becoming the standard even for startups to be honest. I’ve seen a lot of startups that are currently offering web and mobile and sometimes even other devices. I think micro-frontends can help on that because even on mobile, people might not know, but there are solutions like React Native, with Re.Pack that is a library created by Netlify that enables you to use Webpack with React Native. That means that Module Federation can be a first-class citizen inside your system. The beauty of this approach is that you can think about a mobile application as a group of views, like you would for a website.

If you’re using React end-to-end from website to mobile, you can have a very interesting experience and potentially even thinking about have some part shared inside the specific vertical. Ideally not across the entire application like we were used to do in the past, but if I’m responsible as a team of the UI part of a chunk of the system on web and mobile, better is likely that you can share certain part of the things. But then obviously if you have multiple teams working independently, you need to think slightly different. But that’s something that we need to take into account. Now, for the UI part, I think it’s important to leverage web standards in this case. If you think about the design system, if you need to start from scratch, having web components definitely will help you to achieve your goal better because are compatible with any framework.

Therefore, you don’t have to reinvest time every time that you change the framework for moving towards one direction or another one. I think very often we think that micro-frontends can be a very scary approach because it will impact the performance. In reality, if you think about that because you are lazy loading at runtime only the code needed for apply an action inside our system from our users. Now you discover very quickly that there are some great benefits in performance thanks to micro-frontends. Just to give you an example, the vast majority of time in e-commerce or any subscription services that require a payment method, you have to integrate with multiple payment systems. You have maybe the SDK of Stripe, the SDK of PayPal and many others.

I work in this system was global, therefore I have a lot of SDKs to integrate. Thanks to micro-frontend because we were lazy loading only what was needed, we were capable to load this SDK only when a user was signing up and they reach the payment method or if the user wanted to change the payment method. However, suppose you consider that in a monolith, you need to have them immediately, specifically on the web. In that case, it means that it will load your memory with a lot of stuff that won’t be used for majority of the time despite definitely we require a lot of more thoughts compared to let’s say monolith, I believe that can provide incredible benefit, mobile web, et cetera. If you play well on your side, you can even think to share particular part of the application across devices without too much burden, to be honest.

Continuous deployment strategies to avoid “big-bang” impact [30:27]

Olimpiu Pop: Nice. The other thing you mentioned, continuous deployment, is also related to continuous integration. Well, with continuous integration more or less it’s clear. Well, clearer. You just have your test, they are continuously running. You have your fitness functions and all the tooling that are ensuring you that everything is happening. But then I’m just thinking that with continuous deployment I would aim to have a gradual deployment, not go all in. All these kind of mechanisms, but how would you look at that from the micro-frontends? Is it more like would you like to have, I know I’m just saying now, a canary deploy where you’re just looking at part of your fleet or of your ecosystem, or you’re doing A/B testing or both?

Luca Mezzalira: Yes. That’s absolutely valid question that I receive very often when a company became more mature on the micro-frontend side. Because now you have multiple independent artifacts, you can leverage canary release and blue-green deployment like you would do for microservices. That is a practice as it consolidated over the last decade, I would say, or slightly more. Everyone is using that. On the frontend side we are still working with Big Bang. Don’t ask me why because that was the first thing that I implemented when I was working in my previous company because I think it is a safe net for developers. Right? The moment that I can say, “I want to deploy my micro-frontend just to, I don’t know, 5% of my traffic, just in a specific browser and just in a specific country,” then developers can test in production without affecting massively their system.

Now, I think there is a place for canary release and blue-green deployment as well as for feature flags in micro-frontends. The challenge with feature flags that currently people are using a monolith is that in the monolith you have your code base all in front of you. Right? You have control of everything. But in this case you are responsible only on a portion of the system, and therefore, I think now you need to combine the two in order to have the best of both worlds. By default you don’t have feature flags every single time.

If you have a feature flag that’s spun across the entire system, it becomes very complicated for micro-frontends. It’s better that you rethink your strategy because now you move a different piece. Otherwise, you’d need to coordinate massive teams that are not independent anymore, that sometimes it’s needed. I’m not saying no, but it’s not always the thing. You need to try to figure out the best way to use both.

In my opinion, I tend to use more with micro-frontends, canary releases or blue-green deployment and have just specific things that they use for feature flags. This approach honestly helped me a lot to de-risk the deployment of our system. In 2022 I worked with a group of people and maintainers of micro-frontends frameworks like Zach Jackson and Joy Dunning and Matteo Figus where we created basically a schema for doing canary release and blue-green deployment, and then they started to apply inside the frameworks. Nowadays Piral or Module Federation 2.0 and et cetera have a system for doing exactly this, so have a mechanism for doing that. Even in AWS working with Matteo, we created an open-source solution that you can deploy in AWS very quickly that enables you to notify through your CI/CD when there is a new micro-frontends version and decide how you want to deploy.

This is been because, if think about that is what we call in AWS undifferentiating heavy lifting. Now, once that you have created that there is no need to reinvent the wheel. I’ve seen a lot of teams that started to create integration inside the browser through plugins or a crazy JSON configuration for doing that. That’s not really needed. I think there are better ways to do that. Yes, there will be a place where you want to rewrite the URL of specific things. I know that there are solution that there are upcoming from the major vendors, but in reality I believe that you need to start simple. Don’t overcomplicate the process. Let’s start with the bare minimum, and then you start to add up slowly but steadily. I usually think about this system like leaving systems. It’s not something that you design once and you forget about that. You need to nurture them. You need to work and slowly by steadily implement a tiny bit more to make your life easier or better or more performant or whatever is the metric that you want to move.

This approach for me is the right way for thinking about that. Software is not set in stone. It’s something that you can evolve, and the only thing that we need to embrace in software is changing. Therefore, if you start from this mindset and you know that you can do a tiny bit better every sprint, then you probably arrive to have a very let’s say complex maybe safe net that will enable you to have multiple dimensions that you can tweak, but slowly but steadily. You don’t have to go in one go, and then ask for the business, “We need to invest six months for building that.” Do a first bid. Do the things that are bare minimum, and then you start to iterate on top of that. You will discover that very often you are overthinking at the beginning. When you start to have let’s say more data points that prove the direction of travel is correct, you will be in a better position to justify the investment to the business.

Olimpiu Pop: Thank you. That’s quite insightful. But now that you opened another door, another question. Let’s say that we do have the 24 months. I know we both know, everybody knows it’ll not be the case, but we do have the chance of rebuilding everything from scratch. What would be the point? How should we look at it? What will be the let’s say milestones? We need to start with that part, that will be the other point, so that we don’t think in terms of feature flags but let’s say milestones that are business-wise that makes sense but also from the technical perspective.

Luca Mezzalira: Okay. How I would tackle is, A, identify the first micro-frontend. Okay? It shouldn’t be something too complicated but not even something that let’s say is too easy. You need to find a sweet spot that in matter of a month or two you are in production. Then I will divide the effort into one is rebuilding whatever framework, if you want to change framework or extracting the code from the existing application from a part of the team.

Then the rest of the team should look into how routing works. That will enable you to have a simple micro-frontend that is extracted from the main application, taking care about the authentication authorization, stuff like that. I will also create with an additional group of people or team the application shell, whatever is server-side or client-side rendering. When you have one micro-frontend, an application shell that is loading just that micro-frontend, don’t create crazy complex logic for doing that, at runtime obviously loaded.

Then you have a way for redirecting traffic between monolith and micro-frontends application, you are in a good position to start with. Obviously at the beginning you need to find a way to either have time to create observability straight away or have a fast follow-up on that. You have a chunk of a system that you can operate maybe not in the best way possible because I didn’t speak about canary release or anything else. I’m just saying do the first step, and do it right and doing fast so you can learn from it. From that point on, the work streams start to be more interesting. I will start to wait a bit before immediately start with the new micro-frontend to gather information. What is working? What is not working? What we are missing? What is something that you would like to have immediately?

Then start to divide and conquer what part of the team will look into these missing parts of things that could make your life easier. Another part of the team will start to look into the next micro-frontend. If you start to take all these things iteratively, you will discover that slowly but steadily some stuff will arise. I remember vividly when we introduced let’s say the routing on the edge and then we started to say, “Okay. But if we have this, we can do canary release,” and we started to apply that. The first release was just the routing, then we did canary release.

Then we did other stuff like we realized that the developers need to have the possibility to tweak the application shell in a certain way to test their things. Therefore, we started to create a blueprint where for developers that they can have the latest version of the application shell with the JSON that was loaded at runtime baked into the application shell.

You can tweak it in the way that you want and start to iterate in the way that you want. Then from that we start to look into the CI/CD fitness function and how to improve the performance of our application. Slowly but steadily we add all pieces that are needed, but if you start with we need to analyze everything before starting, you end up with an analysis paralysis that basically will fail miserably for moving forward. The main point I believe in this system because enables you to iteratively deploy a small chunk of improvement every time is moving. It’s important that we move towards the right direction. Yes. It would be a bumpy journey because sometimes you make an assumption but the result of your data that you gather after deploying is not maybe exactly what you’re thinking about.

I believe it’s fine because that’s the point is we are working on an empirical system. Software is not scientific, it’s empirical. Therefore, we need to work with trial and error. Errors it’s just part of the journey. It’s not a negative thing how many people thinks about. It’s just I need to do an error, so I test my assumption. The assumption was wrong, and I gather error to tell me how I can tweak these next tests in order to move towards the direction. I think this is the approach that will take, and I’ve seen several companies successfully implemented that after the discussion we had. Then we tweak the direction of travel based on their findings.

Where to find more inspiration [39:57]

Olimpiu Pop: Thank you. You mentioned before. In the beginning you mentioned now companies that are having approaches. For the microservices world there was Netflix. For a long period of time Netflix was the bible for everything. In case of micro-frontends, are there any companies that have good public content in the technical blogs that are worth being looked at, used as inspiration?

Luca Mezzalira: There are a lot of case studies if you look into Medium from engineering blogs that are available there sometimes are in Dev.to if I remember well. There are let’s say a pocket of stories that you can find. Because I know that people are avid consumer of content, I started to do quite a lot of stuff around that because I believe that micro-frontends very often are betrayed mainly because people don’t… That maybe had a bad experience or didn’t have enough capacity for building them properly.

I started to create a few things, like I have a video podcast that’s called the Micro-Frontends in the Trenches, that is available on Spotify, Apple Podcasts and YouTube, where I basically interview people that are building micro-frontends or framework maintainers or a company like Vercel in the previous season. There I’m basically trying to surface these stories because I know some of them, but people maybe don’t have the time or the will to write down their learnings.

I’m a huge fan of community and sharing these things, so I started that, alongside also a micro-frontends newsletter that basically is a free resource that every other week I share free for information regarding micro-frontends that I believe is useful I started from scratch last year. Now there are over 3,500 people subscribe. It means that there is a community behind that that wants to know more and more. I’m trying to push hard on creating content for micro-frontends.

If you look even on YouTube, you can find tons of talks about micro-frontends that I delivered but also other people have delivered because the community of let’s say key people working on micro-frontends is not huge. We’re talking about I would say a dozen of people, 20 top. But nowadays, it became contagious. When you have a company like Vercel that I would say is probably at the forefront of frontend companies nowadays that is starting to embrace micro-frontends, and they already have micro-frontends in their website and other things and their customers as well, I think is huge.

AWS is the same. If I see how many companies I spoke with in the last even 18 months, I don’t know, the number of companies migrating to micro-frontends is doubling. It is crazy because it means that we are starting to reach maturity, and people start to see the value out of it. I think it’s a super exciting moment for micro-frontends, especially now with also the AI part that could help on the migration. I did some trials on helping company to migrate certain views from one framework, an old framework to a modern framework. You can cut the time of building views very quickly. Therefore, I believe there is no better time than now to think about migrating towards the system if the architecture makes sense for your context.

Olimpiu Pop: Okay. Thank you. A lot of very useful insights. Thank you for that. Is there anything else that I should have asked you what I missed?

Luca Mezzalira: No. I think it was a very interesting discussion on key points, and I believe micro-frontends are becoming more popular as we speak. I hope that these discussion will help other people to give a chance if they didn’t try it yet.

For other people that already practitioners, they might find some gems of information that could be helpful. The only thing I’m more than keen to offer to everyone that wants to have say some information about micro-frontends, feel free to ping me on social because as I said, I’m a big community fan. You will see on my social that I’m trying to answer everyone, obviously compatible with my time, but I truly believe in this sharing approach because I think it’s the way how I grow as engineer first and then now as a architect. I truly hope that many other people will be able to reach other people out there because there aren’t too many people that have 10 years of experience on micro-frontends and led the path on a discovery of these things. I’m extremely keen to help others nowadays if you have specific questions.

Olimpiu Pop: Thank you. Okay. Thank you, everybody. We had Luca Mezzalira sharing his knowledge about micro-frontends. If you want to get more of that, he has a YouTube channel, he has a newsletter. He’s working on a book that probably last quarter if I remember correctly it will be available.

Luca Mezzalira: It will be available at the end of November.

Olimpiu Pop: Okay. It’s a good present for Christmas if you want to give yourself something. Thank you for your time, Luca.

Luca Mezzalira: Thank you for your time, and I hope that was insightful.

Olimpiu Pop: Thank you.

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I get the privilege to sit down and chat with Tara Hernandez. Tara, welcome. Thank you for taking the time to talk to us today.

Introductions [00:50]

Tara Hernandez: Oh, well thank you so much for having me.

Shane Hastie: So my starting point for these conversations is who’s Tara?

Tara Hernandez: Oh gosh, how much time do we have for that? I have spent my career, over 30 years now, primarily focused on helping organizations evolve how they develop software. All the way back to my very earliest days at Netscape Communications Corporation where we invented the earliest web-based developer tools through today, where I’m now at MongoDB and I run an organization of developers who do all that work for me now, I just organize them.

Shane Hastie: We were chatting earlier and you made the point, you really don’t like technology.

Technology is a means to an end, not an end in itself [01:37]

Tara Hernandez: I think there’s a tendency to over-index on technology. Some people talk about how when they’re not at work, they spent their weekends investigating some new thing on the computer and I’m like, “Oh, please go ride a bike, pick up a game, walk your dog, something”.

Technology to me is a means to an end. But ultimately as an industry, I think we’re in the business of solving interesting problems and the technology that we use to solve those problems has and will change dramatically and sometimes quite swiftly. I feel like the rate of change in some ways just continuously gets faster and faster. So getting attached to one particular technology is I think a good way to paint yourself into a corner. We always need to think about the adaptation of those emerging technologies and think about is it about the technology or is it about the problem we’re trying to solve? Because at the end of the day, I think the problem we’re trying to solve is the most interesting challenge and sometimes it’s not a technical problem.

Shane Hastie: We’re in the Engineering Culture Podcast. Culture is something that we, again, from our conversation earlier, we both care deeply about. But what makes a good engineering culture?

What makes a good engineering culture? [02:53]

Tara Hernandez: That’s a fantastic question. So I’m a bit of a DevOps nerd, and I always loved how Jez Humble described DevOps as a community of practice. It’s not a tool or a set of tools, it’s an agreement to have a shared ownership to a good business outcome. And if you build out from that, you can kind of extrapolate and think about a good culture is one that enables every member of the team to have the ability to share in the ownership of the final outcome and to feel empowered to contribute to it in a very real and tangible way. In the book Accelerate, Jez and Nicole Forsgren and Gene Kim, they talked about the capabilities that describe elite organizations and they introduced a lot of us to the concept of Westrum’s culture hierarchies.

And so this concept of a generative culture that I think is so incredible because it honors the individual and the value that they can bring. And I really believe in that. I believe that a good culture fosters better outcomes, business outcomes, and if you read some of my blog posts and writings, you’ll also know that a good culture is also a diverse culture as far as backgrounds, educational histories, all the different types of ways that people’s experience can contribute to this idea of shared experience leading to innovation.

It’s always an interesting challenge to me to see where does a team struggle? And part of it could be do they have the right tools that they need? But part of it could be is do they have the right environment to thrive? And I think both of those from my perspective, are the responsibility of the leadership of that organization. So you were asking me earlier what’s my biggest passion? And it really is about facilitating good leadership development within that organization as part of that cultural evolution. So if there’s a problem, people feel empowered to fix it. If there’s an idea, people feel able to explore it.

Shane Hastie: Leadership development, there is a stereotype, and we do it and it exists because it happens. We take the best technologist, we tell them, “You’re now going to lead a team”, and we give them absolutely no guidance on what this new job is. How do we develop good leaders?

The importance of leadership development [05:28]

Tara Hernandez: Oh my goodness, I have so many thoughts about this. You’re right. It is so prevalent. We think someone is a stupendous developer. Clearly they must be put in charge. So full disclosure, I became a manager quite early in my career. I was still at Netscape. I think I was the ripe old age of 26. And someone decided, “Oh, we’ll put her in charge”. The fools. But I loved it. I found that I loved it more than anything else because I found my greatest satisfaction in defining my success through the success of those who work for me.

And so when people tell me that they wanted get into management, that’s the first thing I ask them, “Why do you want to get into management?” In a lot of cases, they think it’s because they think that is the easier path to promotion. And so we talk about that, and I’ve talked many people out of going into people management for that reason. And in fact, I take that as a signal that we have not done our due diligence as an organization to provide good career paths for the individual contributors. But going back to your original question of how do we develop leadership skills for people who are put in a leadership position? I think we do have to quickly answer, is this actually the right thing for that person, first of all? And if the answer is yes, and they say, “Yes, I really love coaching”, that’s a very good way to get started. I love the concept of mentoring. Maybe they had interns that they worked with. That’s a good answer.

Another good answer is “I want to be able to have more influence in what happens to my team”. That was actually my answer, and I think those are all good reasons to get into leadership.

And then you absolutely must invest. When I was at Netscape, I actually was sent to a two-week course with three ring binders, the whole thing, and that was the last time I ever saw anything like that happen. Most companies might have some kind of learning and development video course that you might watch, but that’s kind of about it. And so I think, again, as senior leaders, then we have to be on the lookout. If we’ve recently put someone in a new management role, how are we supporting them? Do they have a mentor? Do they have clarity about what the expectations are? Do they get reminded on the regular about what expectations have changed? Do they understand that rather than being perhaps in many cases, the one who implemented the most features and fixed the most bugs, and now they need to be the one who enables that in their reports?

And some people discover, “Wow, I hate that”. In fact, I have someone right now who is I think coming to that realization and may decide to go back. Charity Majors, if you’re familiar with her, she writes a great blog on leadership and she has that whole concept of the engineering pendulum, which I love. I think people can and should go back and forth. Sometimes they want to do it, sometimes they don’t. And I think that should be also a supported thing. Another aspect of good culture is to not put people in a box. That variability, that flexibility, that agency can extend to role, it can extend to organizational structure and the whole nine yards.

But I think that the other most important thing about the development of people management in leadership roles is that it’s not a point in time. There’s no point when all of a sudden you’re done, you know everything. It’s recognizing that it’s an endless cycle of learning and you’ll do well and you’ll do poorly, and you just have to learn from doing poorly and build on doing well and have an environment around you that recognizes that process and doesn’t overly penalize you for it.

Shane Hastie: How do we create that environment?

Creating supportive learning environments [09:11]

Tara Hernandez: It starts at the top. In most cases, I think culture should be bottoms up because it can’t be imposed, but a value proposition around leadership has to be led from the front. If the CEO is saying, “Yes, we have a good culture”, all of these things, but is seen to be punitive and angry and all the things that are negative and holding people in accountable in ways that are disrespectful or otherwise negative, the culture doesn’t persist. You have to reward it and incentivize it at all levels. I am a vice president, I’ve been doing this for 30 years. I make plenty of mistakes. I could not be successful at my job if I didn’t give myself grace and I didn’t work in an organization where I was given grace. Right now that’s different than perpetually being incompetent. I also expect and should be held to a very high bar of accountability and performance.

But going back to Westrum’s generative culture, mistakes are not the death penalty. Mistakes are learned from. I think it’s true for projects, if you do as any good organization I think should do and have things like blameless postmortems. That’s also true for people. The very important difference of course, is there’s a difference between screwing up software and screwing up a human. So I think that they’re not exactly equivalent, but a good culture recognizes and can be safely forgiving of mistakes versus a culture where HR is the enemy, the managers are the enemy, us, them, every man for himself, so to speak. Those are terrible and those businesses will not succeed in my opinion. I think there’s some data, but I can’t quote you right off the top of my head.

Shane Hastie: One of the things that we do see is organizations want to adopt new technologies, new ways of working, and the knee-jerk reaction to the sort of modernisation is to go and hire and often the incumbents are left behind.

Modernisation without leaving people behind [11:23]

Tara Hernandez: I think there is just an element of human nature that we come to understand something and then that understanding has a hard time evolving. And it’s interesting because at the same time, I’ve seen this many times in senior leadership at companies, we also tend to think of our engineering organizations or employees as interchangeable, which is sort of in conflict of that. So both of them are not ideal, but I think that part of what it means to give agency and to empower and promote the concept of a shared ownership to a common outcome is to invest particularly in your high performers and to give them the opportunity to grow their skillsets, presumably because they’ve proved that they can.

Here at MongoDB, MongoDB has been around for a while. The core database is in C++. The number of companies that work in C++ is steadily going down. At some point we may decide we want to do Rust or we want to do a language that somebody hasn’t fully produced yet. And it is completely, I think, reasonable even if that time is not now, that we would give space for some of our performers, especially our top performers, to go experiment. At Google, you call it a 20% project perhaps, to go do an experimentation for a product. But I think even doing experimentation for skills growth, this is something that I’ve done certainly when containers were starting to become a thing. I was like, well, who knows anything about containers? Not much. Let’s go figure it out.

AI is another one. Who knows anything about AI? Well, not much. Let’s go figure it out. I think the AI thing has the added difficulty though, where there’s so much hype around it and so many people saying very ridiculous things like, “Oh, well, you’ll never need software developers again if you just use our AI agents”. And I don’t think that incentivizes some suspicious developers to want to participate, which is unfortunate. But it’s again, humans are humans and our business as people managers and as leaders is to recognize that fact and then figure out how to build on it. Because humans are also ambitious or motivated or curious or any of these other things that could really lend them to taking opportunities and just going crazy with them.

And I think that’s the thing that you really want to inspire because they could turn around. I don’t know, somebody right now might be thinking, gosh, I think we could take this module out of the core database and replace it with Rust and get a 40% performance intake. No leader worth their salt is going to say, “That’s a terrible idea. Why would you waste your time on that?” We want people to think about things like that.

Shane Hastie: One of the things that you mentioned earlier on is the more diverse the team, the better the outcomes. And yes, there are studies that have definitely shown that. It also is hard to create that diversity or it can be hard to create that diversity.

The business case for diversity [14:35]

Tara Hernandez: It absolutely can. And it has been so politicized, especially in the United States where the idea of diversity is equated with under-qualified. And I will not go down that path. I will not bore you with my rants there, but I will say that studies going back to, I think the seminal McKinsey study was back in 2012, over a decade ago, and Boston Consulting and Google actually did studies about this. So many studies have proved this over and over again that a diverse employee base that is supported by an inclusive culture. Now that’s a really important concept. We talk about diversity and inclusion, and there’s many phrases around it. Diversity is asking everybody to the dance, but inclusion is asking them to dance is one fun way I’ve heard it described. But think about an example of a diverse employee base could include retired members of the armed forces.

If I have a team that is struggling to get organized, they have not figured out a structure that allows them to succeed, well, gosh, who gets a lot of very proactive, consistent training around leadership and structure? Non-comms and officers. So there’s an example. If you’re trying to sell into a new customer demographic, I give this example a lot. I talk about the racist soap dispenser. I don’t know if you’ve ever seen this video. It’s on YouTube.

This poor man who has very dark skin is trying to use an automated soap dispenser to wash his hands in a bathroom, and he can’t because keeps putting his hand under it and nothing happens. And then his co-worker, who happens to be Caucasian, puts his hand under and it works just fine. So eventually he gets a paper towel, a white one, and puts his hand in so he can get soap because the sensor cannot understand dark skin. Imagine if there was one person with dark skin who tested that sensor, and then this company would not have made a product that cannot be used by billions of people. I mean, that’s an example of diversity.

Another example that I’m personally familiar with is virtual reality hardware. You think like an Oculus or any of the rigs, even Apple’s product, I tried it. A study came out that estimated that as many as 78% of women would be subject to motion sickness because their physical structure and their physiology was just different enough that it gave them a significantly harder experience than the average man. These are examples of where diversity is fundamentally critical to your eventual success. All these companies made products that basically ruled out half of their potential customer base. That’s not good business.

If you’re selling a lot of B2C consumer software, there’s a million different demographics that could come into play. Location, country, cultural norms. There was a big thing that you probably remember about how certain emojis started coming out. And in some countries it’s like, oh, that’s an emoji. In other countries, that’s a deadly insult. And if you don’t have representatives of those cultures, you’re going to make those mistakes. Imagine being all Americans and trying to sell in Taipei or Japan. No company of course would do that now. We’ve learned our lesson the hard way. We hire local people to help us with language and culture.

Shane Hastie: Circling back around to developer trust and developer experience, how do we improve the relationships in our organizations, in our teams?

Building developer trust and relationships [18:21]

Tara Hernandez: Oh gosh, there’s so many answers to that. But to me, the thing that I was always reached to first is transparency. So my job in my view is to make sure that my team is crystal clear on what we need to get done, and that when we do it correctly, they are rewarded. And when they do it incorrectly, they’re coached. And that if somebody is choosing or unable to actually do the job, then they’re respectfully managed out. And feedback loops are constant and circular. I always accept feedback. It’s that investment that you have to make every day that starts to build the human trust. And with the human trust, then you can start feeling more ambitious about everything else.

Going back to Westrum generative culture, now you’re willing to take risks. What Google described as psychological safety is the first of five key things that make for successful teams. Psychological safety is also very critical to having an inclusive culture. The willingness to take risks because you know that you’ll not be unduly penalized, and that comes through transparency and consistency. And it sounds simple and it’s terribly difficult to maintain.

Especially one of the things I love about where I work now with MongoDB is we are still committed to our hybrid and remote workforce. The people who report up to me go from Sydney to Berlin, and most of them are not based in a central office. And so it is exceedingly critical that I over-communicate and I don’t think I communicate enough. So this is always a challenge that I have. Am I being as transparent as I need to be? Am I passing down the information? Am I reinforcing the messages and the values that I want to make is something I worry about all the time. And I think any good leader should be thinking about that. You never want to take your people for granted because then eventually they’ll notice and then you lose that trust.

Shane Hastie: Another thing that we were chatting about before we started recording was you build it, you run it, you use it, the dogfooding approach, although I much prefer drink our own champagne to eat our own dog food.

The value of dogfooding your own products [20:37]

Tara Hernandez: Yes, we’ve tried to use that one too. It hasn’t stuck quite as much, but I think it’s just because very rude. Eating your own pizza is another one. Yes. One of the things I really love about working at a company that makes developer tools is exactly that. My very first company was a company called Borland. It was compilers and databases, and Netscape of course was browsers that was very easy to dog food, but a lot of the companies I’ve worked at have made products that we could use, and I think it serves two purposes. Well, maybe more than two, but definitely it serves two purposes.

The first one, of course, what I think is the most important is it helps develop customer empathy. We should be using as much as possible the products that our customers are using so that we can understand what our customer pain points are. And we actually recently, one of my engineers got a blog post posted for our engineering blog talking about how the most recent version of MongoDB was … We have a proprietary continuous integration system. Don’t judge us. It is purpose-built to test a distributed document database. It’s very specialized and runs 10 engineer years worth of compute volume of tasks every day. That’s how much we test.

And so it’s built on top of MongoDB, it’s on Atlas, and we rolled onto version eight and we found two stopship bugs on that. And because I’m like, if it’s good enough for our customers, it’s good enough for us and vice versa. And my engineers had previously not had been as aware of that value opportunity. But boy, after we found those bugs, everybody was just walking around chest out, proud. We helped the business, we did something valuable.

And the other thing is, which I think is also important, but maybe a little more subtle, is it keeps the business honest. When AWS was still very early, a lot of people would ask them, a new service would come out, “Well, what is Amazon running on this service?” And for a while the answer was, “Not much”. I think Google is rightly asked something similar. How much of Google is run on Google Cloud? How much of MongoDB is run on Atlas? I think any business that’s providing those types of services should expect to be asked and we should be able to provide that answer.

Otherwise, what’s the point? If you’re not building something that you yourself would use, you’re clearly doing something wrong. Your priorities are not correct for this category. Obviously that doesn’t work for … I would not personally find any use for most of Salesforce, for example. Slightly different.

Shane Hastie: What’s the important question I haven’t asked you?

The future of software engineering and AI hype [23:21]

Tara Hernandez: I think the one that everybody is asking right now is what is the future of our industry? What is the future of the world in the face of AI? Personally, I think that’s giving AI a little bit too much credit, to be honest. I live on LinkedIn quite a bit. I’m always hiring. So keeping an eye out for folks. I remember seeing some posts someone shared about how Marc Andreessen, who I actually know from my Netscape days, we’re not friends or anything, but he was commenting that AI is going to become so dominant that the only humans that will still need to be involved are the venture capitalists. Everybody was like, “Okay, Marc”. But then not two days later, there was another article where a venture capital firm was using AI to do the evaluation. So if you have AI generating the ideas and AI doing the evaluations, what’s the point of humans?

And I think it’s that level of silliness. We can’t help ourselves. We as humans I think are inclined to be fascinated by the fantastical, but I do think that there’s an element of the quote that’s coming to mind was from the first Jurassic Park movie, Jeff Goldblum’s character. “You were so busy thinking about how you can do a thing, you never stopped to think about whether or not you should”. Now, I think a lot of people could argue dinosaurs are cool, all right, they eat a couple of people, but still dinosaurs. But I think there’s this element of what is our purpose as an industry? What is our purpose as a human? What problems are we solving? And I think going back to what I was saying earlier, the technology is an interesting implementation detail.

If AI goes in the direction that some people say it’s going to go, are we solving a problem or are we just making humans irrelevant? And in which case your business probably isn’t going to go very far. You’ve lost your customer base. We’re all just going to be gone.

So I think it’s important to remember the human element. We talk about those who think in these terms. The most important thing about a company is its culture, but you could also say, is the culture that you’re facilitating through your products good? Can you be proud of it? Are you contributing to our existence? Are you solving amazing things? When we were at Netscape, we speculated so much about information freedom. People can know anything anywhere. And then we started to realize, but what if the internet turns into TV but worse? And well, one could argue that kind of happened, but still, I’ll never forget when during the Arab Spring, people were putting the Google DNS server as graffiti on walls, 8.8.8.8, because countries were trying to shut down the internet and people bypassed it and were able to talk to each other and communicate and get information.

And despite everything terrible that can happen on the internet, I’ll never forget that because the internet, much like many technologies, is just enabling people to be more who they are, but faster and at scale. And I think that ethical companies remember that and think about the products that they develop and why are they developing and what problems are they actually solving. At least I hope that they are. I like to think that we are, and others I worry about, but we can never forget. And it comes into our leadership values and how we bring up the leaders behind us. I think if we’re doing it right, now, you’ve got me really going off on a tangent here.

Shane Hastie: A lot of deep good conversations in here. If people want to continue the conversation, where do they find you?

Tara Hernandez: Well, I definitely am on LinkedIn. I’ve kind of gotten off most of the other social media just because they’re deadly places. I’ve promised myself to start writing again. I’ve got some blogs on Medium, mostly talking about engineering, management, leadership and diversity and inclusion. I love doing things like this. I love nerding out with people about these types of topics and I hope they find those as well and maybe think about their own message and what they bring. Because if the tech industry has taught us anything in the past decades is that everybody has the potential of having a huge impact. A lot of it is luck, but there’s a lot of really smart people who get into this space, and I think everybody has the opportunity to do something amazing, and I hope they feel the responsibility of doing it amazingly good.

Shane Hastie: Inspiring words. Thank you so much for taking the time to talk to us today.

Tara Hernandez: Thank you so much for having me.

Mentioned:

Victory Capital Management Inc. lessened its holdings in MongoDB, Inc. (NASDAQ:MDB – Free Report) by 4.1% during the first quarter, according to its most recent disclosure with the SEC. The institutional investor owned 55,157 shares of the company’s stock after selling 2,347 shares during the period. Victory Capital Management Inc. owned 0.07% of MongoDB worth $9,675,000 as of its most recent SEC filing.

Other institutional investors and hedge funds also recently made changes to their positions in the company. 111 Capital purchased a new stake in shares of MongoDB in the fourth quarter worth $390,000. Park Avenue Securities LLC raised its position in shares of MongoDB by 52.6% in the first quarter. Park Avenue Securities LLC now owns 2,630 shares of the company’s stock worth $461,000 after buying an additional 907 shares in the last quarter. Cambridge Investment Research Advisors Inc. raised its position in shares of MongoDB by 4.0% in the first quarter. Cambridge Investment Research Advisors Inc. now owns 7,748 shares of the company’s stock worth $1,359,000 after buying an additional 298 shares in the last quarter. Sowell Financial Services LLC purchased a new stake in shares of MongoDB in the first quarter worth $263,000. Finally, Farther Finance Advisors LLC raised its position in shares of MongoDB by 57.2% in the first quarter. Farther Finance Advisors LLC now owns 1,242 shares of the company’s stock worth $219,000 after buying an additional 452 shares in the last quarter. Hedge funds and other institutional investors own 89.29% of the company’s stock.

Insider Buying and Selling at MongoDB

In other news, Director Hope F. Cochran sold 1,174 shares of MongoDB stock in a transaction that occurred on Tuesday, June 17th. The shares were sold at an average price of $201.08, for a total transaction of $236,067.92. Following the completion of the transaction, the director directly owned 21,096 shares in the company, valued at approximately $4,241,983.68. This trade represents a 5.27% decrease in their ownership of the stock. The transaction was disclosed in a document filed with the Securities & Exchange Commission, which is accessible through the SEC website. Also, CEO Dev Ittycheria sold 3,747 shares of MongoDB stock in a transaction that occurred on Wednesday, July 2nd. The shares were sold at an average price of $206.05, for a total transaction of $772,069.35. Following the transaction, the chief executive officer owned 253,227 shares of the company’s stock, valued at $52,177,423.35. The trade was a 1.46% decrease in their ownership of the stock. The disclosure for this sale can be found here. In the last three months, insiders have sold 33,746 shares of company stock valued at $7,725,196. 3.10% of the stock is currently owned by corporate insiders.

Analyst Upgrades and Downgrades

A number of equities research analysts recently issued reports on the company. Mizuho lowered their price objective on MongoDB from $250.00 to $190.00 and set a “neutral” rating on the stock in a research report on Tuesday, April 15th. Truist Financial lowered their price target on MongoDB from $300.00 to $275.00 and set a “buy” rating on the stock in a research report on Monday, March 31st. Redburn Atlantic upgraded MongoDB from a “sell” rating to a “neutral” rating and set a $170.00 price target on the stock in a research report on Thursday, April 17th. UBS Group raised their price target on MongoDB from $213.00 to $240.00 and gave the company a “neutral” rating in a research report on Thursday, June 5th. Finally, Stifel Nicolaus lowered their price target on MongoDB from $340.00 to $275.00 and set a “buy” rating on the stock in a research report on Friday, April 11th. Nine analysts have rated the stock with a hold rating, twenty-six have assigned a buy rating and one has issued a strong buy rating to the company’s stock. According to data from MarketBeat, MongoDB currently has an average rating of “Moderate Buy” and a consensus price target of $281.35.

Read Our Latest Analysis on MongoDB

MongoDB Stock Performance

MongoDB stock opened at $235.16 on Friday. The stock’s 50 day simple moving average is $205.47 and its two-hundred day simple moving average is $212.72. The stock has a market cap of $19.21 billion, a price-to-earnings ratio of -206.28 and a beta of 1.41. MongoDB, Inc. has a fifty-two week low of $140.78 and a fifty-two week high of $370.00.

MongoDB (NASDAQ:MDB – Get Free Report) last posted its quarterly earnings data on Wednesday, June 4th. The company reported $1.00 earnings per share for the quarter, beating the consensus estimate of $0.65 by $0.35. The business had revenue of $549.01 million for the quarter, compared to analysts’ expectations of $527.49 million. MongoDB had a negative return on equity of 3.16% and a negative net margin of 4.09%. The business’s revenue was up 21.8% on a year-over-year basis. During the same period in the previous year, the firm posted $0.51 EPS. On average, analysts predict that MongoDB, Inc. will post -1.78 earnings per share for the current year.

MongoDB Profile

(Free Report)

MongoDB, Inc, together with its subsidiaries, provides general purpose database platform worldwide. The company provides MongoDB Atlas, a hosted multi-cloud database-as-a-service solution; MongoDB Enterprise Advanced, a commercial database server for enterprise customers to run in the cloud, on-premises, or in a hybrid environment; and Community Server, a free-to-download version of its database, which includes the functionality that developers need to get started with MongoDB.

Featured Stories

This instant news alert was generated by narrative science technology and financial data from MarketBeat in order to provide readers with the fastest and most accurate reporting. This story was reviewed by MarketBeat’s editorial team prior to publication. Please send any questions or comments about this story to contact@marketbeat.com.

Before you consider MongoDB, you’ll want to hear this.

MarketBeat keeps track of Wall Street’s top-rated and best performing research analysts and the stocks they recommend to their clients on a daily basis. MarketBeat has identified the five stocks that top analysts are quietly whispering to their clients to buy now before the broader market catches on… and MongoDB wasn’t on the list.

While MongoDB currently has a Moderate Buy rating among analysts, top-rated analysts believe these five stocks are better buys.

View The Five Stocks Here

MarketBeat’s analysts have just released their top five short plays for August 2025. Learn which stocks have the most short interest and how to trade them. Enter your email address to see which companies made the list.

Get This Free Report

Like this article? Share it with a colleague.

Link copied to clipboard.