It has been a while since I’ve been designing an agile development framework that provides developers with the convenience offered by frameworks like Ruby on Rails, Laravel, and Spring Boot, while also being scalable and easy to maintain in the long run. In the upcoming articles of this series, we will follow the development of this idea and see if we can achieve a result that is at least satisfactory.
The indiscreet truth.
It is undeniable that market frameworks offer irresistible advantages when starting a new project. Their active communities provide a wide range of resources, from helper libraries to enriching discussions in online forums. Although the community is a crucial factor, we often only value it when problems arise. The true reason why developers opt for these frameworks is simplicity.
These frameworks often follow solid and consistent concepts in their architecture, such as the MVC pattern to separate application logic from models and views, or the principle of Convention over Configuration, which simplifies the configuration of application components.
The combination of these concepts provides the framework with a solid and standardized organization, facilitating the use of meta-programming for automatic generation of components.
An example of this is the Rails scaffold, which allows you to generate, with a single command line, the entire structure needed to use a resource, from the frontend to the database table.
Perfect, except not.
Using MVC frameworks in the long run can bring limitations when transitioning to a service-based architecture. These frameworks are designed to develop monolithic applications, where all functionalities are grouped into a single system. However, as businesses grow and user demands increase, there is a need for scalability, flexibility, and modularity that can be better addressed by a service-based architecture.
One of the main reasons for migrating to a service-based architecture is the ability to independently scale different components of the system. With MVC frameworks, scalability is limited because the entire application needs to be scaled even if only a part of it is under higher demand. This can lead to inefficient resource utilization and performance management challenges.
Furthermore, MVC frameworks tend to be highly coupled, which means that changes in one component can have side effects on others. This makes it difficult to perform updates and modifications in the system without causing unwanted impacts. In a service-based architecture, each service is independent and autonomous, making it easier to implement specific changes without affecting the rest of the system.
Another important aspect is the flexibility to adopt new technologies and integrate with external systems. With MVC frameworks, we are limited to the specific technologies and libraries of the framework, which can restrict our options and make integration with other systems challenging. In a service-based architecture, we can choose the best technologies for each service and easily integrate with APIs and external systems, providing greater agility and adaptability to the constantly changing business environment.
Lastly, migrating to a service-based architecture allows for greater modularity, which facilitates system maintenance and evolution. With independent services, each component can be developed, tested, and deployed in isolation, reducing the impact of changes on other components and simplifying the collaborative development process.
Somewhat updated, but not entirely.
The evolution of cloud computing has brought about a significant increase in the number of providers and tools available. The cloud computing market is dominated by technology giants such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP), offering a wide range of scalable services. The adoption of microservices has emerged as an effective approach for application development, enabling horizontal scalability, resilience, and ease of maintenance.
In the frontend realm, various technologies have emerged to enhance user experience and development efficiency. The use of JavaScript frameworks like React, Vue.js, and Angular allows for the creation of interactive and responsive user interfaces. The utilization of design tokens and the adoption of concepts like Vuex and Reactive Design have also contributed to building more autonomous, responsive, and scalable frontend applications.
However, when it comes to backend frameworks like Rails, it is important to recognize that they were developed in an era when requirements and technologies were different. While Rails has been a popular choice for web development in the past, it faces challenges in terms of scalability, complexity, and performance when compared to more modern and service-oriented approaches like micro-services.
Although these frameworks are still used in many projects and remain a valid option in certain scenarios, it is important to acknowledge their limitations in terms of scalability and complexity in modern systems. The evolution of the cloud and the advent of micro-services have driven the quest for more agile, scalable, and flexible solutions that allow businesses to quickly adapt to market demands.
That little itch
As you can see, my dissatisfaction with market MVC frameworks is not unfounded or baseless. However, what truly sparked my curiosity was an article written by Graeme Colman in June 2020. In this article titled “The New Kubernetes Native,” he discussed the development of native tools for Kubernetes (It’s a really enjoyable read, I recommend it). Why not create a framework that combines the benefits of market frameworks while also being native to Kubernetes, thereby simplifying its long-term maintenance?
In the upcoming chapters of this saga, we will explore how we can apply this in practice.
