Note: The contents of this article are my opinions, not the views or opinions of my employer or other entity. Please feel free to give it a clap, it helps!

What are Microfrontends?

Microfrontend architecture is an approach to breaking up your front-end into a set of independently deploy-able, loosely coupled applications and/or components. These applications are then assembled together to act as a single user experience, once deployed.

These applications tend to closely mirror a corresponding micro-service architecture as well, but its not always the case. I fully expect to see Frontend Architects who specialize in this pattern in the near future.

A lot of folks have talked about this term over the years, so allow me to show you my favorite:

Martin Fowler — Microfrontends
https://martinfowler.com/articles/micro-frontends.html

The history of microfrontend implementations.

In the interest of easy to digest information, I will touch on only the top three microfrontend implementations that I personally have used.

• Hybrid: This is the common one most people think about when somebody mentioned Microfrontends. This is the pattern of ejecting individual components as js modules and combining them all in one page or application. These modules do not even need to be the same framework, you can mix and match angular, react, vue, and vanilla js.
• Distributed/Microsites: One of the less adopted patterns, that share similar structures such as Distributed Frontends. Without going into too much detail, this is the act of writing many small isolated standalone web applications and using infrastructure to tie them together to appear to be one single application experience. I am currently writing an article about this as well, but it has far more pitfalls to consider.
• Module Federation: Module Federation (MF) is a feature that allows for the dynamic loading of multiple versions of a module from multiple independent build systems. This allows for multiple systems to share code and be dynamically updated without having to rebuild the entire application. It also enables distributed teams and applications with different release cycles to share code without needing to wait for all systems to agree to and deploy a single shared version of a module.

What is Module Federation?

When we talk Microfrontends, we generally need to load applications individually asynchronously only when requested. We do this by using a feature known as Module Federation to create a single deploy-able artifact of an application, which can be loaded on demand.

We will get deeper into Module Federation a bit later in the article, but for now, a summary will help you stay on track.

More Information: Documentation

Module Federation Frameworks

There are a handful of frameworks and technologies that are attempting to get into Module Federation such as:

• Webpack Module Federation: Documentation This is the standard in my opinion and the one with the most flexibility and development activity.
• Vite/Rollup: Documentation Inspired by Webpack and compatible with Webpack Module Federation.

Special Note: I want it to be clear, not all of these support all the variations of loading federated modules such as Dynamic Remotes. (See below)

Alright, so lets talk terms..

As you adopt Module Federation, there are a handful of terms you need to become comfortable with and where/when to use them.

• Hosts: A host is a simple parent application, which is put together during build-time or run-time from many smaller applications known as Remotes.
• Remotes: Remotes are easy, they are essentially single page applications, which are minified, bundled, and exported as javascript modules. They are wrapped in a Webpack shim, allowing a Host to know how to load and use them, and are essentially portable modules which can be used across Hosts or even by other Remotes!
• Modules: These are the parts that a Remote exposes for use inside a host or other remotes. This usually equates to components but not always!

We have different ways to federate remotes too!

When we talk about Federated Remotes, we also need to understand there are various ways you can fetch and load these modules into your host. Ill talk about just the main two strategies:

• Eager: Load all remotes up front inside the host’s configuration. Must have knowledge of all remotes at startup. Must re-deploy Host when a Remote is updated.
• Dynamic: Load a single remote using React.Lazy on demand only when requested. Must have knowledge of only the requested remote when you view that page or component. Can update Remotes without redeploying Host.

Why is this so important?

Abstraction and extensibility are constantly driving existing patterns to evolve to solve existing problems and create new patterns to aid in development experience, independent deployment, iterative development, long-term maintainability.

These focuses have become more and more of a problem as teams and applications grow in size. How do we get 50 engineers all working on a web application, owning their screens/components… while having them all operate and deploy completely independently. Now lets give the web application 100 screens and introduce scale concerns.

This problem is actually increasingly easy to solve using Microfrontends, with various added complexities and steps… But you add Module Federation into the mix and it all becomes so obviously simple.

What could a Solution Architecture look like?

Lets take a look at a simple example of a vanilla MFA Architecture.

In this example we are going to have an application with three pages. All three pages will use the same layout (header and footer) and will use react router to navigate between pages.

Directories:

• Host: This is where the primary application lives, it is responsible for fetching remotes and configuration. Hosts can also potentially be responsible for adding layout, authentication, routing, and a unified experience.
• Remotes: These are our single page applications, collections of components, or feature based remotes.
• Shared: This is a build time dependency allowing non-packaged shared code that all remotes and the host can access.
• Service (Optional): This can be a simple BFF pattern that you can offload Host responsibilities into, such as Remote Orchestration and Configuration.

Lets walk through the Deployment!

In this example we are going to have an application with five pages. All five pages will use the same layout (header and footer) and will use react router to navigate between pages.

The hosts and remotes are all built and deployed independently where a small difference is: Remotes are deployed to storage, and Hosts are deployed for Hosting.

Responsible Autonomous Teams.

So in real world practice, we want to ensure our teams have total control over their code-base having a say in how its built. This is always a noble goal but how to you ensure the teams don’t go off and build completely incompatible modules because somebody said “well I don’t like webpack.”

Well, in order for these pieces to be compatible, we need to ensure they are using the same framework and export types right? This is in direct conflict with the statement above. So what do we do?

Well, its about being Autonomous in a responsible way.

We build a solution architecture around Module Federation and say, you can build whatever, however within the confines of this framework. Initial reaction to this statement might be pretty jarring, or downright disagreement, but is that not the exact strategy of opinionated frameworks such as Angular?

One can be Autonomous in an Opinionated architecture, because they are free to focus their creativity and innovation in their product, or even making the opinionated framework better! But the important part is that innovation is shared with the rest of the organization so that we all grow and better each other, together.

Hot Take: Monorepo or Polyrepo?

So this is where folks tend to go off the rails. You can obviously go either way here, but you must understand the pros and cons before making this decision.

Thankfully I have an article where I outline the differences, the benefits, and ultimately my recommendation.

Monorepo vs Polyrepo: The great debate.

If you would like to get to my preference without digging into the meat of another article, here it is;

Personally, i feel its important to start with a mono-repo and graduate to a poly-repo when you absolutely need the flexibility of distributed code as the pattern proposed allows independent deployments of remotes. For me, its really that simple.
~ Chris Fryer

How does this benefit developers or an organization?

Webpack module federation is a technique that allows you to share code between applications at runtime without requiring a build step. It allows multiple applications to work together as a single, integrated system, while still being developed and deployed independently. This can be particularly beneficial for organizations with autonomous teams and independent deployments.

Here are some benefits of webpack module federation:

1. Improved developer productivity: Developers can work on their individual applications without worrying about how they will interact with other applications. They can focus on writing code for their application without having to think about the broader system architecture.
2. Faster time-to-market: With module federation, teams can release their applications independently and still have them work together as a single system. This can speed up the time-to-market for new features and products.
3. More flexible architecture: Module federation allows for a more flexible architecture where applications can be composed and re-composed dynamically at runtime. This can enable organizations to adapt more quickly to changing business needs.
4. Reduced duplication of code: With module federation, teams can share code between applications, reducing the need to duplicate code across multiple applications. This can lead to a more efficient use of developer resources and reduced maintenance costs.
5. Improved scalability: Module federation can help improve scalability by allowing applications to share resources dynamically. This can enable organizations to scale up or down based on demand without having to worry about resource constraints.

Overall, webpack module federation can benefit organizations by enabling more efficient and flexible development and deployment practices, which can lead to faster time-to-market, improved scalability, and reduced maintenance costs.

Bundlers, I can pick my own right?

Currently at the time of this writing we have a few options with a few limitations; Web pack is obviously the most feature rich, but we also have RSpack and Vite. Vite does support module federation, but only eager loading as it does not have a browser runtime.

RSpack is currently in development with the immediate goal of full support of module federation with both eager and dynamic remote support.

In the coming months, module federation will supply a browser runtime that will enable Vite, RSpack, and other bundlers, to support dynamic remotes, but this may take some time to roll out to the general public.

I would expect to see many bundlers, supported in module federation by the first of the year, but we will see how that timeline shakes out.

So its like perfect, right?

Well, not really. There are still a lot of operationally important problems to solve such as:

• Style mutation and bundling
• Code Sharing (in-directory vs npm-package)
• Workspace solutions
• Pipeline triggers
• Remote Versioning

In Conclusion…

If you are interested in creating a frontend development experience that scales with the size of your organization while still allowing you to deploy independently, this is where you need to be in 2022. Its not a perfect pattern, which I don’t believe one exists, but this framework provides the most flexibility of anything I have seen yet.

I do fully believe that this will be the standard organizations use to create modern experiences at scale in the very near future.

Key Players I Recommend Following

• Zach Jackson: https://twitter.com/ScriptedAlchemy
• Russell Canfield: https://x.com/RussellCanfield

Source Code:

https://github.com/cfryerdev/microfrontends-react-js-typescript

The landscape of container technology has been undergoing a significant transformation, particularly with Docker’s recent changes to its licensing model for enterprise users. This shift has prompted many organizations to reevaluate their container management solutions, driving a substantial migration towards Podman (Pod Manager).

This happened to me recently and a lot of my underlining tooling uses Docker under the hood. I don’t want to rewrite my tooling or wait for updates, so I want to install Podman, and use a docker alias so all my existing tools “just work”.

Embrace Podman, for reals

Skip this section if you dont care about why Podman is better than Docker. Its cool.

Podman encapsulates containers in a way that is both seamless and compatible with Docker, while also addressing some of the key challenges and limitations faced by Docker users. It’s designed to offer an easier transition for those accustomed to Docker, thanks to its similar command line interface and support for Dockerfile standards.

• Changes in Docker Licensing: With Docker altering its licensing model, enterprises are looking for cost-effective, open-source alternatives that don’t compromise on functionality or security.
• Daemonless Architecture: Unlike Docker, Podman doesn’t depend on a central daemon, which enhances its security profile and reduces potential attack surfaces.
• Rootless Operations: Podman’s support for running containers without root privileges addresses major security concerns, making it a favorite amongst system administrators and DevOps professionals.
• Seamless Docker Compatibility: Podman supports Docker’s commands and Dockerfiles, making the transition less daunting for teams accustomed to Docker’s ecosystem.

Installing Podman

Windows & Macos

For those using non-Linux platforms, Podman Desktop offers a unified experience, bridging the gap with a user-friendly graphical interface for managing containers. It simplifies container development and deployment across platforms, ensuring that transitioning from Docker Desktop is as smooth as possible. Use this method, it installs Podman Desktop and it will also setup Docker Compose and Kubernetes support if you need it.

Linux

Podman is native to Linux and supports a variety of distributions. Here’s how you can install it on some of the most popular ones:

# Add Podman's repository
sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_$(lsb_release -rs)/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list"

# Download the GPG key
wget -nv https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable/xUbuntu_$(lsb_release -rs)/Release.key -O Release.key

# Add the GPG key
sudo apt-key add - < Release.key
sudo apt-get update -qq

# Install Podman
sudo apt-get -qq -y install podman

Note: You will need to setup Podman Desktop yourself here too.

Setting up a terminal Alias

To further ease the transition, you can alias Docker commands to Podman in your shell profile. This allows you to continue using familiar Docker commands, which Podman will interpret and execute.

MacOS / *Nix

1. Open your terminal.
2. Add the alias to your .zshrc or .bash_profile file:

echo "alias docker='podman'" >> ~/.zshrc
source ~/.zshrc

Windows

1. Open PowerShell.
2. Create a new alias:

Set-Alias -Name docker -Value podman

Update: SSL And Certificate Errors

Where I work, I need a company zscaler cert to access https resources such as dockerhub so that I can actually pull down container images. I get SSL errors and it just fails. Here is an example error:

Trying to pull docker.io/library/keydb:latest...
Error: initializing source docker://keydb:latest: pinging container registry 
registry-1.docker.io: 
Get "https://registry-1.docker.io/v2/": tls: failed to verify certificate: 
x509: certificate signed by unknown authority

You have two main options to move past this, use a tls ignore flag or install the certificate to Podman:

Use the Flag

Podman has a flag you can include to ignore ssl errors called tls-verify which is used like so:

podman run -d --tls-verify=false postgres

Install the Cert:

Podman supplies some good documentation for this that I wont bother duplicating here: https://github.com/containers/podman/blob/main/docs/tutorials/podman-install-certificate-authority.md

Update: Podman 5.1 and ARM Compatibility

Podman’s continued evolution brings an exciting development with the release of Podman 5.1, particularly for developers working on ARM-based systems, such as the Apple M series CPUs found in the latest Mac computers. This version introduces ARM compatibility, a significant enhancement that allows running x86 containers on ARM architectures seamlessly. Docker has had this feature for a while, and it worked great.

Why is this Important?

This development is a game-changer for developers and teams working across a variety of hardware ecosystems. It essentially resolves compatibility issues that were previously a challenge when moving containerized applications between x86 (common in desktops and servers) and ARM-based systems (increasingly popular in laptops and edge devices due to their efficiency).

Running x86 containers on ARM with Podman 5.1 doesn’t require any additional configuration. Podman automatically detects the architecture mismatch and uses QEMU to run the containers. However, you should note that while this feature greatly enhances flexibility, performance might not be on par with running containers natively due to the overhead introduced by emulation.

To take advantage of this feature, ensure you have Podman 5.1 or later installed on your ARM-based system. If you’re using an older version of Podman, refer to the installation instructions provided earlier in this article to upgrade to the latest version.

Conclusion

Transitioning from Docker to Podman should help you use the same tooling and commands you know and love, without the added Docker license headache.

The introduction of ARM compatibility in Podman 5.1 marks a significant milestone for containerization technology, offering broader flexibility and supporting a more inclusive range of computing environments.

Stay tuned to the Podman release notes and documentation to keep abreast of new features and improvements, ensuring you’re leveraging the most out of your container management tool.

Note: The contents of this article are my opinions, not the views or opinions of my employer or other entity. Please feel free to give it a clap, it helps!

Introduction

In my travels as an engineer and consultant, one topic comes up repeatedly that has created some spirited and passionate discussions. Alright, lots of arguments and opinions. It is an important part of application development at scale or at the enterprise level so we should really understand our options before making an emotionally based decision.

Before we get too deep into it… lets understand our two main options:

Mono-Repositories

Monorepos, or repositories that contain multiple projects, have become increasingly popular in recent years. There are several benefits to using a Monorepo for your projects.

First, a Monorepo allows for easier sharing of code and resources between projects. This can save time and reduce code duplication, as developers can easily reference and reuse existing code. Additionally, a Monorepo can make it easier to manage dependencies and versioning, as everything is located in one central location.

Another advantage of a Monorepo is that it can help to improve collaboration between teams. With all projects housed in one repository, it is easier for different teams to work together and share their work. This can lead to improved communication and collaboration, as developers can easily see what others are working on and make suggestions or provide feedback. In addition, it can help to ensure consistency across projects, as all code is located in one place and can be easily reviewed and approved.

However, there are also some potential drawbacks to using a Monorepo. One potential issue is that a Monorepo can become quite large and complex over time, which can make it difficult to manage and maintain. Additionally, it can be challenging to ensure that all code changes are properly tested and reviewed, as there may be many projects and teams working in the same repository. Finally, some developers may prefer to work on smaller, more focused projects, rather than having to navigate a large Monorepo.

Summary of Monorepos

• Easier sharing of code and resources between projects
• Reduced code duplication and improved code consistency
• Easier management of dependencies and versioning
• Improved collaboration between teams
• Better communication and knowledge sharing
• Increased visibility into what other teams are working on
• Monorepos can become large and complex over time
• Difficult to ensure all code changes are properly tested and reviewed
• Some developers may prefer to work on smaller, more focused projects
• Higher risk of merge conflicts and build failures
• Longer build times due to larger codebase, without proper pipeline targets
• May require more discipline and organization to manage effectively

Poly-repositories

Polyrepos, or repositories that contain a single project, have their own advantages and disadvantages compared to Monorepo. One of the primary benefits of a Polyrepo is that it promotes independence and autonomy for each project. Developers can work on smaller, more focused projects, which can be more manageable and easier to navigate. Each repository can have it’s own build and deployment processes, allowing for greater flexibility.

Another advantage of a Polyrepo is that it can make it easier to enforce code quality and review processes within individual repositories. Each project is independent and has it’s own repository, which can make it easier to manage and maintain. This can lead to improved code quality and consistency within individual projects.

However, there are also potential drawbacks to using a Polyrepo. One potential issue is that it can be more difficult to share code and resources between projects, which can lead to duplication and inconsistency. Additionally, communication and collaboration between teams can be more challenging, as they are working in separate repositories. Managing dependencies and versioning can also be more complex, as each repository may have it’s own dependencies and versioning requirements. Ultimately, the decision to use a polyrepo or a Monorepo will depend on the specific needs and goals of your organization.

Summary of Poly Repositories

• Each project is independent and has it’s own repository, making it easier to manage and maintain
• Developers can work on smaller, more focused projects, which can be more manageable and easier to navigate
• Each repository can have it’s own build and deployment processes, allowing for greater flexibility
• Lower risk of merge conflicts and build failures due to the smaller codebase
• Easier to enforce code quality and review processes within individual repositories
• More difficult to share code and resources between projects, which can lead to duplication and inconsistency
• Increased overhead in managing multiple repositories, including managing dependencies and versioning
• Communication and collaboration between teams can be more challenging, as they are working in separate repositories
• Greater risk of inconsistencies and versioning issues across repositories
• Can be harder to ensure consistency and enforce standards across all projects

Making your decision

When making your decision, you should factor in two important concepts. Team Maturity and the Importance of Collaboration.

• Team Maturity: Monorepos are often a better fit for mature and experienced teams who can handle the complexity of managing a large codebase. These teams may have established communication and collaboration processes in place, as well as robust testing and review processes to ensure code quality. On the other hand, Polyrepo may be a better fit for newer teams or teams with less experience, as they can help to promote independence and autonomy for each project. These teams may benefit from the simpler structure of a Polyrepo, which can make it easier to manage individual projects and enforce code quality standards.
• Collaboration Importance: Monorepos are often a better fit when collaboration and code sharing are important, as they provide a central location for all code and resources. This can make it easier for developers to share ideas and collaborate on projects, leading to improved communication and collaboration. Additionally, with all code in one place, it’s easier to ensure consistency and enforce standards across all projects. On the other hand, Polyrepo may be a better fit for projects where collaboration and code sharing are less important, as they allow for greater independence and autonomy for each project.

My Recommendation

Personally, I feel it is important to start with a Monorepo and graduate to a Polyrepo when you absolutely need the flexibility of distributed code as the pattern proposed allows independent deployments of remotes. For me, it is really that simple.

If you have teams who are strong but do not collaborate, actively refuse, or do not share solutions… a Monorepo may be a good choice to create that environment and create a “we all win together, we all lose together” situation. It can also level up some of your more junior engineers, who may not have exposure to projects that more senior folks work in.

Both options are viable solutions that solve different problems in different ways. You can easily create a mess in any technology or pattern. So with that in mind, lets crank out some code!

In conclusion

But remember, There is no one-size-fits-all solution and it really has to be decided as a team based on whats important to your company culture and organizational objectives. Have the conversation, keep an open mind, be respectful, and also understand that most seasoned engineers have had positive and negative experiences in both patterns.

Note: The contents of this article are my opinions, not the views or opinions of my employer or other entity.

Note: This article is a self-made challenge to myself, to write an article, diagram, review, edit, and publish it within three hours, and be OK with the outcome. Putting yourself out there on the internet can be stressful, but its a wonderful experience.

When determining how to scale a service cluster, you have two main knobs to turn: Scaling up or Scaling out. It is important to understand how and when to use each to avoid over provisioning in your cluster and incurring surprise costs and traffic latency.

It is critical to understand how the services in your cluster will behave and what type of traffic they will see on a regular basis. But sometimes, in greenfield development, you won’t know until the traffic is live, so we have to prepare for that as well.

Without proper scaling strategies, your cluster can grow out of control!

Scaling Directions

• Scaling Up/Down: Increasing or decreasing the resources (processors or memory) of a instance. This requires a new instance to be provisioned and the new scale becomes available, and requires no outage.
• Scaling In/Out: Increasing or decreasing the count of instances in your cluster. This requires a new instance to be provisioned and the new scale becomes available, and requires no outage.

Workload Traits

There are several types of workload traits commonly seen in clusters, a few to be aware of are:

• Traffic Volume: (How many requests) The most common workload is traffic volume. When more and more clients are hitting a service in your cluster, the traffic will drive up CPU, and maybe even Memory usage, in a linear manner.
• Transaction Time: (How long a request takes) In rare cases, you will see long running transactions. This could be something as simple as a bulk task that is used to process data each night. This type of workload may drive up CPU and Memory usage, for a period of time, in a flat manner.
• Transaction Size: (How much the request has to do) You may also see larger transactions when a resource is requested. This can be anything from scheduled background processing or an expensive set of calculations from multiple systems. This type of workload may drive up CPU and Memory usage, for a period of short time, in a spiked manner. This can also cause issues in relation to traffic volume and transaction time which may be harder to spot.

Below, we will be going through an example cluster, provide some scenarios, and see how the cluster could react in the real world.

Our Simple Cluster

In this example, we have a cluster which contains an instance with 2 cores and 2gb of ram. With normal traffic, this instance has about 35% of the resources in use, and the scale point set to 70%. The overall goal is to find the perfect balance between scale peaks and valleys, while being strategic around how we will scale the cluster for the unforeseen.

Note: When you have more than one instance in a cluster, you can divert traffic either equally across instances (Balanced) or at a scale point. For this example, we will just use the scale point.

Lets go through an example scenario and see how the cluster reacts and why…

Here we are, default state, everything is running smoothly, and traffic is behaving as expected. My only note here is, are you are probably spending slightly too much on the instance size; You could scale down here.

But wait, we just had 10x the users hit our service all at once, and we didn’t anticipate the need to scale out! We now have a completely maxed out instance and requests to the server are timing out…

Lets scale out to two instances, quickly!

Alright, we scaled out to two instances of the same size, so we have traffic waiting for the other instance to spin up before we load balance traffic. This can take a couple minutes. Lets see what happens to the cluster once that instance is live…

Interesting, the traffic died down a little, but is hovering right above our scale point. Oops, we have accidentally introduced a new problem… We are now paying for two instances but really only using the resources of about than one. We have three options: scale up, wait it out, or raise the scale point.

Sometimes, incurring this additional cost is acceptable, and the right solution is to simply wait out the traffic spike, and learn from it. Sometimes its expected and accepted that we have two instances always available, because we know these services will see regular spikes above the 70% mark.

Scaling-Up will solve the problem and raise the scale point as it’s merely a percentage of the total resources, but will also incur more monthly costs each month.

Raising the scale point will solve the problem in the short term, and not incur any new monthly costs, but may only put off the problem you had should you start to see moderate traffic regularly.

Really to fully solve this, you have to find a good balance that incurs costs only in extreme cases, does not regularly overly spend on non-utilized resources by running too many instances, while provisioning only the smallest instance size needed.

This is an art.

Can’t we scale automatically?

Well, yes. This is called auto-scaling, and is built in to most cluster solutions, but for this example its easier to pretend that doesn’t happen so we can talk through the pros and cons of each strategy.

Break it apart…

Something you should always ask yourself as you start to see trends in traffic: Should this service be broken up, so different parts of the logic can be scaled differently? This is easily the most important question you should be asking yourself as you see new data from your cluster logs.

If your service sees varying types of traffic and workloads, break it up and make each service smaller. This will also dramatically change your scaling strategy. Eventually over time, each service will get broken up into small, independently deploy-able, services that serve a simple purpose.

This is the natural evolution of services and clusters. Embrace it!

Speaking of small…

Strive for the smallest

When building out your service, or your cluster, you should strive for the smallest footprint possible. Here are some more questions to ask yourself throughout the development and deployment process:

1. Whats the minimum number of CPU cores the service needs to handle the average daily workload?
2. What’s the minimum amount of memory to sustain the service?
3. Can the service be refactored to maintain memory better?
4. What is the minimum number of instances needed to handle the traffic?

Conclusion

Understanding how clusters behave based on traffic, workloads, and resource usage is paramount to creating a cost effective and performant solution. Even if we do not know how the cluster will be used or what type of traffic we will see, you can be proactive and use the experience to become a master at tuning clusters.

It can be extremely fun and rewarding to crack this nut, and I hope I have inspired you to dive in with both feet and enjoy yourself. As I said, this is an art, be a cluster artist.

Before we begin, if you need a bit of a refresher on Micro-services, I wrote an article that should get you up to speed: Micro-service Architecture and Design

What are we trying to accomplish?

So, you were asked to break down a monolith into micro-services while keeping the monolith alive. Yikes. You also learned the business plans on adding features to the product while you are breaking it apart! Double Yikes. Oh, and one more thing, do not touch the front end…

For many of us, it can feel like this:

Ugh, how do we break it down?

In many cases, “just rewrite it” will just not work for the business and you may need to break down a monolith iteratively while supporting existing development. This can be a really tricky process, and includes a ton of risk if you attempt it without a plan. When putting your plan together, break down everything the monolith does and group them in self contained modules. These modules may also include items the product needs to do in the future.

Module: A functional chunk of an application that services a single or small subset of features.

Defining the list of modules that encapsulate all the functionality of the monolith is extremely important, as the business will need to make some tough decisions around feature freezes, priorities, timelines, and more:

• Timelines: When you define your modules, take some time and T-Shirt size the modules relative to each other. This will give you a VERY high-level estimate of how much total work is required to replace the monolith. Don’t worry if its not super accurate, its a swag, but weekly updates from each team will help leadership understand where they are in the process.
• Pay Twice vs Waiting: You can’t ask the business to suspend all feature development on the product, but if they want some new feature, you could tell them to wait and have it built in the new system, or build it in the monolith, and then again in the new micro-services. Twice the cost.
• Dependencies: You should look at all the modules and their inter-dependencies and clearly communicate/document them. This determines the technical order they should be rebuilt in.
• Feature Freeze: When a module is being rebuilt, I recommend a monolith feature freeze on this functionality while the micro-service is being built to replace it. This serves two purposes: 1) Protect from feature drift, don’t chase a moving target, you will never catch it. 2) Allows you to take your time and understand WHY the module does what it does.

Alright, got it, what’s the plan?

If we look at the example below, we have three main states that have to take place when iteratively breaking a monolith down:

• Current State: You’re currently on the monolith, it’s big and slow and sometimes you cry in the shower. (possibly unrelated)
• Middle State: You support both platforms in this state, where you may or may not have refactored the frontend. Depending on where you are in the frontend, you may talk to the micro-services or you may still need to talk to the monolith. Not ideal, but the gateway handles all of the mixed routing for you. For the databases, we ETL data from the existing database to a new optimized structure.
• End State: You’re off of the monolith, yay. Feel free to print the monolith’s source code and literally burn it. Enjoy it, you’ve earned it.

Typically, we move from left to right in this example chronologically, and 90% of the time, we are in the Middle State. We will repeat the Middle State for each module we are rebuilding.

To keep from having to update code in the frontend, or rewrite it, we create a Gateway between the frontend and all of our services. All this serves is a way to hold on to http routes, and send the request to the correct service. This makes it easier to move services around without touching your frontend.

During the Middle State, the gateway will have legacy routes to support the frontend functionality that still needs to talk to the monolith, while also storing optimized routes for talking to the new micro-services. Some folks like to create two gateways to keep the new optimized gateway clean. Personally, I like that.

Note: I plan on writing an in depth article on Middle State.

What if I am allowed to replace the frontend too?

In the interest in making the problem harder, I opted out of replacing the frontend on top of a monolith. This makes things more straight forward to explain, but what if you are actually allowed to replace that?

Well, simply put, it’s really all about the gateway in the example earlier in the article. If you opted for two gateways, your new frontend should talk to the optimized gateway. If you have one gateway with mixed routes, simply put, both frontends will talk to the same gateway.

OK, what exactly do we do in the Middle State?

Typically we have many teams running in parallel during the Middle State, each team managing the development of a single module. That team should have a backlog, roadmap specific to that module, and a release plan. Each team should be responsible for weekly status updates to the business so they can track the total progress of the project at a high level.

Cross team dependencies and blockers should be communicated often and escalated up if it effects the sprint, roadmap, or another teams ability to deliver. The business will understand!

Things like this will happen, and communication is key. As long as the business can plan around issues and still feel in control, they will understand. They are there to make the tough decisions, and you are there to give them the data to make those decisions.

How about the database? ETL?

Often times, the monolith’s database is just as crufty as the code base, so we should probably think about refactoring that as well. We will want to identify which tables support which module in our monolith and migrate what’s needed from each.

One pattern in micro-services is to have a single database per micro-service. This very often complicates the migration process, so to handle this, we introduce a process called Extract Transform Load. (ETL) In this process, we identify which fields/tables are required with the new micro-services and what is the optimum data structure. Might as well clean it up while we are here!

Once the database and required data/structure are in place, you should be free to route traffic to your new micro-service via the gateway. This database is now the source of truth. Off to the races!

Conclusion

When you break down the plan, it’s actually quite simple and easy to follow. As long as you have weekly updates to stakeholders, hold the business accountable for decisions, and communicate blockers, it should go pretty well for everyone!

Go get em.

Part 1: Dependency Injection — A general breakdown

Note: The contents of this article are my opinions, not the views or opinions of my employer or other entity.

The Composition Root Pattern

The composition root pattern is (in my opinion) the next evolutionary step after learning dependency injection. Once you fully understand dependency injection, you are able to introduce the next logical steps; predictability and structure around how dependencies are managed. Composition Root brings this to the front of the line, and gives engineers confidence around the structure of their application and how data flows. This is one of those patterns that give you the feeling “oh my god, why didn’t I think of this, why isn’t this how everything is structured?”.

All dependencies are defined, constructed, and injected into the container as soon as possible in a process. This may slow down the init of your service by a few seconds, but it gains you one incredible positive: On request, the dependency chain is 100% pre-calculated and in some cases, pre-constructed. This keeps response times incredibly low and consumes very little memory. You also fail fast, in the sense that you will know before users are brought into the service, if something is not working correctly.

Depending on the container you chose, there are additional features that become available to you when you adopt this solution. One of these is circular dependency detection. This may be difficult to catch or debug when you simply keep a running list of registers in a cs file. Heck, a whole new level of unit testing becomes available to you which we will also cover below.

Note: There is an example github project at the bottom.

Through the course of this post, keep one thing in mind:

The API knows about the container, and nothing else. The container knows about everything else.

Principals

• Single location for object construction: Entire dependency graph is discover-able in one location.You can reference installers from other assemblies.
• Assembly Scanning allows the container to discover your dependency graph for you: Ensures all dependencies of a certain type are located and constructed identically.
• Build a Lean Container: The composition project is a map of how your dependencies are constructed, how they interact, and how they are resolved. Do not register items in your container that may be optionally consumed. Avoid auto-wires if possible.
• As close to Init or Entry Point as possible: As soon as we have an active process, we want to construct the container. The only dependency construction allowed before Composition is logging.
• Pass configuration to the container for object construction: The container has all configuration necessary to build ALL dependencies.
• Predictable Dependency Graph: All calls to the project should have a pre-constructed, pre-discovered dependency chain. No dependencies are built on the fly.

Things to avoid

• Stick to constructor injection: Do not mix injection strategies. Where you cannot use constructor, use a Dependency Resolver.
• Avoid one-off registrations: Register using an installer or builder. (depending on your container)
• Never register an item in your container outside of your Composition Root project. Certainly not during units of work.

Lean Architecture

A predictable dependency graph is incredibly important when you start building lean and scalable services. Just knowing how/when your dependencies are constructed and how their dependencies behave is crucial. A valuable piece of knowledge is having visibility into how newly added dependencies are co-mingling with pre-existing dependencies, and if they are not, failing fast if dependencies fail to resolve correctly or are registered incorrectly.

The biggest gain is upon request, a good portion of your dependency graph should be pre-constructed and ready for your consumption. Resolving is expensive, especially if you have a lot of components registered.

Assembly Scanning

A common practice in (DI) Composition Root is assembly scanning. This means reading the assemblies in your solution for concrete implementations that match a specific signature so the container can register them automatically. Example: Instead of registering all of your managers individually, you register all classes that implement IManager. Any engineer who creates a new manager, as long as they use the correct interface, the container will handle everything for them. No need to go add a registration for that class!

One common issue when using Assembly Scanning is fighting JIT. When a .net process is running, it does some clever stuff to save memory and optimize itself. One of those things is how JIT handles referenced assemblies. Only assemblies that have a physically referenced class will be loaded into memory. So if you reference another assembly in your project, unless you call something within it, it will not be present in memory for Assembly Scanning to find it. Below is an example of Assembly scanning which also takes into consideration the JIT issue.

Unit Testing

One of the benefits to the Composition Root pattern testing your code, the same way its implemented. A cost to mocking out methods, dependencies and objects is you may make a mistake in your mocking that allows the test to pass, without accurately testing the functionality. Having a single point of registration, as well as following the Installer/Builder pattern allows us to unit test our code with the same exact container in the same state as the application we are testing. This eliminates (for the most part) false passes due to poorly mocked tests.

You also have the freedom to replace registrations in your container, with mock versions. For example, instead of using my IDbContextFactory to resolve Entity Framework DB Contexts, I may want to replace it with one that always returns a Mock DBContext or one with the default provider to to InMemory.

Another aspect to unit testing that becomes available to you, is unit testing the dependency graph and/or the container itself. Imagine testing that the container is able to construct the entire graph, in the correct order, and resolves dependencies in an adequate amount of time.

Controlling Configuration

One of the coolest functions of this pattern is controlling how configuration is handled in your application. You can easily use it to standardize how configuration is handled, or who has access to it. Your container should have access to configuration to construct all the necessary dependencies and register them. The challenge, only include configuration in memory for a handful of milliseconds:

Once your configuration is handed to your container and the dependencies are constructed… Why not just dispose of your configuration in memory? Always protect any internal variables that contain keys, connection strings, or sensitive configuration. If you cannot protect the variable (you don’t have src access to the object), abstract it behind a factory.

There is no silver bullet, but this is a fun challenge I love to solve or watch others solve!

Conclusion

As I said earlier, the composition root pattern is (in my opinion) the next evolutionary step after learning dependency injection. It takes your understanding of Dependency Injection and builds on those principals without changing directions. This pattern should approachable to those who have a real interest in creating lean structures.

This pattern gives engineers an easy to adopt framework where things “just work” while also providing a depth at which they choose. If they want to learn how a dependency is constructed, how changing a dependency creates a ripple effect, or how two dependencies may work together; they can choose how deep they want to go.

Here is an example project for you to explore on your own: GITHUB

Note: The contents of this article are my opinions, not the views or opinions of my employer or other entity. This article is a precursor for my Composition Root article.

What is Dependency Injection?

Dependency injection is a form of Inversion of Control which focuses around supplying dependencies to a class explicitly as opposed to constructing them, or requesting them. My favorite definition of Dependency Injection is as follows:

Dependency Injection (DI) is a pattern that helps developers decouple different layers of an application. It provides a mechanism for the construction of dependency graphs independent of the class definitions.

This pattern also allows an engineer to inspect a class constructor and determine the dependencies required to use or test the class. In a fully dependency injection application, all object construction should be handled by the container. The container will also manage nested dependencies which we call the Dependency Chain. The make-up of one of more dependency chain in an application is known as the Dependency Graph.

Object Construction Methods

There are many ways to skin a cat, but for this example I will break it down to three main solutions for object construction in the context of a .net application. For this example, we will keep it simple and consume a UserDbContext which has a (string) dependency of a connection string. We want to consume this class in a Manager and expose two operations from the UserDBContext.

Whats inside a Container?

Have you ever debugged an container and looked inside? You should, it is incredibly fascinating! A container is made up of two main functional parts: I have heard them called many things, in Windsor they are Services and Components. In AutoFac they are Sources and Registrations. I am sure there are many more definitions, but the concept is the same across containers.

Services / Sources: The “contracts” for constructing an object, the life-cycle of the object, how it is disposed, and what dependencies that object has.

Components / Registrations: The physical instances of objects constructed by a Service/Source.

Life-cycles: The circle of life…

When working with a container, you get a really cool feature called Life-cycles. This allows you to control how an object is constructed, how it is distributed, and when it is disposed. The three main types are…

Singleton: Singleton lifetime services are once and every request will use the same instance.

Transient: Transient lifetime services are created each time they’re requested. This lifetime works best for lightweight, stateless services.

Scoped: Scoped lifetime services are created per request.

Service Locator (anti)Pattern

There are a ton of articles that break this down better than I could, so in the interest of focus for this article, I will only bullet point my main concerns on the pattern.

• Conceals the dependencies of a class
• Conceals the construction of nested dependencies
• Makes mocking quite hard!

Property Injection (anti)Pattern

There are a ton of articles that break this down better than I could, so in the interest of focus for this article, I will only bullet point my main concerns on the pattern and supply an alternative.

• Conceals the dependencies of a class
• Conceals how a property is hydrated
• Allows engineers to overwrite a property that was constructed via Property Injection
• Makes mocking quite hard!

Alternatives? Use a dependency resolver. In some cases, you cannot use constructor injection and must use another pattern. Many containers including the .net core container supply you with a dependency resolver for this reason.

Preferred Containers

I prefer AutoFac as my container of choice. I generally stay away from containers that “auto-wiring” items for you in an attempt to help you out. These can slow down your container, for example automatically registering classes for you can slow down the init of the container, OR worse… Make resolving super slow because of the many items within it. I really prefer explicit registration of items in a container so I know exactly what is in the container. When using Assembly Scanning, be as specific as possible or you may accidentally do this.

Really, the pattern should more or less apply to any container you chose and vary in functionality. Start of with something that you are familiar with and then branch out.

Conclusion

Dependency Injection should be an every day part of your development life. It was one of those “no turning back” moments for me. This pattern can be used to develop easy to understand architectures, super lean services, or solutions where everything is tied together for the engineer. You can use your container to control what engineers how and where engineers can construct classes. Dependency is a great pattern I think everyone should learn, and encourage others to learn.

When an engineer finds a solution easy to work with or simple to understand; feel proud and happy. But when that same engineer wants to dig deeper and learn more and challenge themselves; That is the best feeling in the world.