Definitions, principles, and how they can help you
Intro
Technical startups, by definition, aim to grow fast. The start is usually very accelerated and the focus is on product features, not on the quality of the code base. We can compare this phenomenon with fast food. They have the same urge to be ready and delicious to please all the clients in the shortest time possible. In the long run, this speed can become unhealthy. Successful projects grow fast and clients demand more and more functionalities. Developers’ focus is on implementing new features as fast as possible. That's the recipe for creating a monolithic, dinosaur project. It becomes too slow for the user experience and too big to improve in a competitive amount of time.
Tech teams and founders can avoid this problem with a good start. Consider from the beginning all the possible parts or components of the application. Even though the business plan is long-term, it helps structure the technical part so it has a good base for future features. This means using technologies like containers, serverless applications, and Kubernetes. The architectural choices are essential. Such a choice represents structuring the technical product in micro-apps, micro-services, and micro-frontends.
In this article, we’ll talk about these concepts and you’ll see how they change the game of software development.
1. Microservices
This is an architectural approach that became popular in the last couple of years. The concept is to break the big and complex applications, known as monoliths, into small and independent services. From the outside, they are black boxes that hide all the unnecessary information and implementation details.
One microservice encapsulates one business functionality. Then it makes it accessible to other services via network endpoints. Microservices communicate and send messages using APIs, event triggers, or other channels. Being completely independent, we can change and release a microservice all alone. It needs to assure backward compatibility and not affect the current consumers.
Let’s see a list of 4 key concepts of microservices as we can find them in “Building microservices” by Sam Newmann.
a. Independent deployability
A change in a microservice should not depend on or impact any other microservice. A microservice can be changed, deployed, and released every time is required. It’s a key that assures that the microservices are loosely coupled.
b. Built around a business logic
As said earlier, a microservice solves a single business scope. We prioritize the business scope over the technical one. It helps to recombine the microservices in different ways to deliver new functionality. In practice, it means moving from the 3-layer architecture (frontend, backend, and database team) to multiple independent microservices teams. Each of them takes care of a different business feature.
c. Owning their own state
It means avoiding or eliminating shared databases. Each microservice has full access to its database. In case it needs data from another microservice’s database it needs to request it explicitly. The reason behind this is to completely separate the data that can be shared from the data that cannot. It also reduces the need for backward-incompatible changes.
d. Size
There is no physical size recommended for microservices. Even though the name contains the term “micro”, it was not meant to impose any size restriction. The recommendation is to be easily understood and as small as possible.
There are 2 numbers that you can think of:
- how many microservices you can handle
- how strict you want to be in terms of their boundaries without letting them be too coupled
2. Micro-frontends
The same as microservices, micro-frontends represent an architectural concept recently developed. Before that, the norm was to build a single-page monolithic application that interacts with a set of microservices. To avoid code conflicts, usually, one single team was in charge of the development. Unfortunately, this type of architecture cannot be easily improved in the long term. Especially, it is not for products built to be used for many years with frequent releases made by distributed teams.
The new trend is to offer the best user experience and to provide an easy path to do what the users want to do—all without losing the quality of the services.
Micro-frontends break the monolithic frontend into separate frontend applications. These applications are owned by independent teams who take care of a single business aspect. The micro-frontend architecture follows the same principles as microservices. On top of that we can add 2 more:
a. The automation
A strong culture of automation eliminates a lot of problems. Each micro-frontend is a separate project that has hundreds of different parts. We need to assure continuous integration and deployment and fast response to feedback. The automation requires a lot of time but doing it from the beginning of the project it saves time later.
b. Decentralized governance
Each team working on a micro-frontend has the decision power over that micro-frontend. It allows them to choose which technologies and tools to use to do the job. The tech leadership can always offer the guidelines that align teams, but they should not be a blocker in the decision-making process. This approach empowers the teams and becomes essential for introducing new successful practicing.
3. Micro-apps
Putting together microservices and micro-frontends, we end up having the final concept of micro-apps.
A micro-app is a specialized application meant to serve a single, well-defined business task. It follows the principle of single responsibility that reduces the complexity of old fashion monolithic applications. A micro-app can include a frontend, a backend, or other services that serve a single scope.
Benefits
All three concepts follow one main principle of breaking down the big and complex applications. The scope is to make software applications easier to develop, maintain and scale.
The separation of code into micro projects splits the development across teams. It empowers them to take ownership of the project and to choose the right tools. It allows the automation of testing and individual releases without creating code dependencies.
We can also add the reuse of the same functionality in different places. Think of how you need a blog app added to each of your projects. You create a micro-app for the blog and reuse it in all projects.
How to apply?
It can be difficult and time-consuming to create the initial setup that takes advantage of micro-components. Fortunately, there are tools on the market that can help you set up quickly your app using the best practices.
One such tool is getwebstack.com.
Getwebstack.com uses composable components to build your full-stack web app. It offers a range of pre-configured stack templates that include popular technologies such as React, Angular, ExpressJs, and more. You don't need to manually configure servers, infrastructure or local environment. Additionally, you can easily manage the responsibilities inside one or more teams.