Split the Monolith: What, When, How

Overview

Monolith imageMonolith splitting has to chase some goals: not just splitting, but splitting to achieve some benefits. Some other ways, such as application scaling or database hardware update, may be preferable if considering the cost of splitting and possible benefits.

Another example of a benefit to achieve may simply be application modernization. Nevertheless, here is the more or less formal way to monolith splitting, which is trying to take into account the reason and goals of splitting.  Of course, this is not dogma, and you can find several approaches to splitting. This migration roadmap is designed to migrate monolith applications to microservices and get microservice benefits, without (or minimal) application unavailability. 

COBOL: A 1959 Idea and 2022 Technology

COBOL, the unassuming technology that has been around since before IT was even a term, is sometimes the subject of a heated state government debate, occasionally makes headlines at industry events, and it was even featured among the top 10 technology topics on an IEEE Twitter poll from 2020. But how did it become a part of the modern zeitgeist? 

COBOL is now into its seventh decade of usage as a global programming language and continues to be hugely important as a system language for great swaths of the global economy. Age aside, COBOL’s defining characteristics include running systems of record applications in worldwide organizations; supporting all sectors vital to the global economy including banking, transportation, government, and healthcare; comprising billions of lines of application code worldwide; and remaining ubiquitous in the mainframe world.

The Migration Path To Microservices and Security Considerations

While the move to microservices-based architecture is relatively new, it is already mainstream. A majority of companies are choosing it as their default architecture for new development, and you are not cool if you are not using microservices.

With regards to migrating legacy apps and breaking them down to microservices, companies are showing more conservatism, and rightly so. While the move creates a lot of value, mainly around new features, time to market, and scalability, it also has its complexities and trade-offs. 

Migrating a Legacy Spring Application to Spring Boot 2

Out with the old, in with Spring Boot 2

Recently, we decided to monitor the metrics of legacy Spring applications we were running on our production systems. While searching around, I realized that a nice way to not reinvent the wheel was to integrate my app with the Spring Boot Actuator. By using the actuator, we have many tools like Grafana and Prometheus for easily monitoring our applications. However, in order to integrate such a legacy Spring application with the Spring Boot Actuator, you need to make it Spring-Boot-ready first.

You may also like:  How to Deal With Legacy Code

Since Spring Boot 1.5 reached the end of its life at the beginning of August, I decided to move to Spring Boot 2 and start playing with it.

Three Traps That Stifle Modern Enterprise Integration

A string of good decisions can easily propel a garage-born startup to greatness. But a few bad ones can bring even the most formidable organization to its knees. The key to minimizing costly decisions while maximizing profit-yielding ones is to make data the bedrock of your decision-making.

Top companies have been making data-driven decisions for a long time. Amazon, Box, Workday, Adobe, and other industry leaders have enjoyed huge success as a result of putting their faith in data over instinct.