Microservices

Cloud Native Architecture: Monoliths or Microservices?

Experts from Grafana explore the core challenges of building Cloud Native microservices applications.

In this video, Goutham Veeramachaneni and Edward Welch, Grafana Labs, talk about Cloud Native architecture, and the unique characteristics of the monolithic and microservices architecture.

Goutham is a Prometheus maintainer. He also worked on CFCN projects like Cortex, Loki, and Biker. Edward prominently works on Loki, Cortex, and used to build Java monoliths. In this video, the speakers will talk about monoliths, microservices, and mono-microliths.

In this session, the speakers also brief on the advantages, disadvantages and benefits of using each of these architectures while building applications.

Monoliths and microservices architecture

At 1:28, Edward puts forward a short definition for the concept of monolithic architecture. The monolithic architecture is basically a unified model for designing software. The monolithic software will be self-contained. Different components of software will be interconnected and interdependent instead of being loosely coupled.

Monolithic applications are simple to develop when compared to the microservices architecture. Deployment becomes very easy with this type of architecture as only one single jar/war file is deployed. Problems related to security and network latency are less with this architecture when compared with the microservices architecture.

Two of the commonly faced challenges revolving around monolithic architecture is that achieving scalability and reusability will be quite difficult. In addition, this architecture is never reliable as even a single bug can bring down the entire monolithic application in no time.

At 4:47, Goutham puts forward a short definition for the idea of microservices architecture. This type of architecture helps in achieving a great level of scalability. The principles of microservices include single responsibility, design for failure, and building around business capabilities.

Microservices break up the monolithic code into small chunks of code that can easily be maintained by the users. In this type of architecture, services will exist as independent deployment artifacts and can be scaled independently without relying on the availability or the performance of the other services.

This architecture follows an approach where an application is composed of plenty of independently small services that can be deployed. If the different interfaces of the microservices are being exposed by means of a standard rule, say, a REST-ful API, then they can be consumed easily by the other services. In this case, direct coupling is not required.

Mono-microliths and mono-repositories

At 9:41, the speaker briefs on the other type of architecture, which is ‘Mono-microliths’. Applications built through this type of architecture will be the future. A mono-microlith is a single binary monolith composed of microservices.

The Thanos CFCN project follows this model of architecture. It is necessary to follow modular coding whenever you are building a mono-microlith architecture application. The single binary application can be scaled horizontally. Read and write paths are heavily modulated so that they are isolated. Some teams prefer using multiple repositories while some prefer mono-repo.

A mono repo is a single repository that will have all the code and assets for the project stored. With mono-repo it is easy to share the code and also to refactor the code. The speaker re-emphasizes that a mono-repo is a single repository while a monolith is a massive codebase.

A mono-repo is used whenever visibility, collaboration, and speed are required while building the code-base. Atomica changes can be made easily where only one action is required to perform a change across different projects. With a mono repository, you can ensure that there is only a single source of truth. In the case of multiple repository scenarios, developers need to build or download dependencies multiple times.

With a mono repo, the build can be efficiently optimized as all dependencies which are referred exist in the same codebase.

Conclusion

At 17:29, the speaker states that gRPC is a way to enable modularity and achieve horizontal scalability easily. gRPC is a high-performance, open-source universal RPC framework. The major functionality of this framework is to connect services across data frameworks in an efficient manner.

This framework also offers pluggable support for tracing, load balancing, health checking, and authentication. At 24:09, the speaker re-emphasizes that having a mono repo will be very effective. He adds that it is very important to make the onboarding process easy for the new developers. Running a huge number of services on Kubernetes on their own name-spaces will be difficult for the newly joined developers.

Open source projects should be incremental when scaling is applied. Once the Cortex is moved from the microservices to the mono-microlith world, the number of blog posts, the adoption shot up. It is important to have the development and adoption process super seamless. In this video, the speakers discuss the ideas behind the three different types of architecture and how they could be followed seamlessly while building applications.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button