Monolithic applications with microservice ambitions

Microservices are not always the right choice, Consol is convinced. Especially in the case of relatively small software projects, a development approach that starts monolithically and, if necessary, can also take advantage of microservices offers certain advantages.

Microservices are perfectly structured, scalable, resource-efficient, easily scalable and support agile software development in teams – Consol Consulting & Solutions Software GmbH is aware of this. However, in some cases, monolithic applications are a better choice than the microservice architecture.

For example, highly distributed microservice architectures could result in administrative and communication costs. Oliver Weise, a software architect at Consol, explains how programmers combine the two worlds and develop flexible, cloud-ready software "at once":

Principle 1: Structure the source code properly according to the functionalities

Even in the monolith, it is wise to separate vertically depending on the features, which are loosely coupled via interfaces. Modularization frameworks such as OSGi or Jigsaw can help programmers maintain this separation in the source code. Components are deployed together (deployed), run in a common process, and are scaled only in one operation, that is, with other instances of the overall deployment.

For many applications, this scalability is quite sufficient. If, during operation, it should prove more difficult, during operation, that the software component temporarily requires high scaling, it can still be extracted and operated as a separate microservice.

Principle 2: Avoid excess resources

The famous surplus resources of existing monolithic applications are more likely due to obsolete platforms and legacy concepts than architecture. In many cases, monoliths can also be economical in terms of resource consumption, provided that they use modern platforms and development principles, such as the use of external caching services such as than Redis.

They can also be deployed on cloud platforms, such as Kubernetes, and easily moved between cluster nodes. Provided that software developers focus from the beginning on a conscious management of resources and on a fast start and stop. If a component eventually turns out to be a resource, it can be extracted fairly easily and resource consumption reduced.

Principle 3: Review the best practices of the 12-factor application methodology

The 12-factor application methodology brings together best practices for developing software applications as services for private and public clouds. The essential components of the recommendations are a clear encapsulation of the individual components of the source code and clear interfaces with the operating systems and services.

The methodology recommends avoiding implicit dependencies on libraries and system tools and explicitly declaring all existing dependencies. While software developers consistently adhere to best practices in 12-factor application methodology, even monolithic container-based applications will be flexible, agile, cloud-ready, and resource-efficient.

Principle 4: Make the monolith dance

Modern publishing processes with fully automated testing, unchanged deployments, and infrastructure automation are also suitable for monolithic architectures. As you only need one process, compared to a microservice environment, which requires many processes, a monolith even saves time. Although it is necessary to test more on a monolith than on a microservice, this process is long. However, this can usually be overcome by parallelization.

In addition to taking into account the best technical practices, the development of flexible monoliths is also a prerequisite for dismantling organizational barriers in the company. Slow release processes for versions or the use of modern software development platforms, lack of communication, and lack of trust between development and operations have often disrupted monolithic applications. A monolith must never be used as an excuse to neglect or completely prevent the DevOps principles.

"A flexible and mobile monolith can still exist today in modern computing and often remains the best choice for small projects," says software architect Weise.

%d bloggers like this: