architecture microservices system design

Chopping the monolith in a smarter way

In my previous post Chopping the Monolith, I explained that some parts of a monolith are pretty stable and only the fast-changing parts are worth being 'chopped.' I turned the post into a talk and presented it at several conferences. I think it’s pretty well received; I believe it’s because most developers understand, or have direct experience, that microservices are not a good fit for traditional organizations, as per Conway’s Law. In the talk, I use an e-commerce webapp as a

Spring Boot architecture microservices

Spring Modulith: have we reached modularity maturity?

One of the main reasons to design microservices is that they enforce strong module boundaries. However, the cons of microservices are so huge that it’s like chopping off your right hand to learn to write with the left one; there are more manageable (and less painful!) ways to achieve the same result. Even since the microservices craze started, some cooler heads have prevailed. In particular, Oliver Drotbohm, a developer on the Spring framework, has been a long-time proponent of the moduli

system architecture microservices

Backend-for-Frontend: the demo

In one of my earlier posts, I described the Backend-for-Frontend pattern. In short, it offers a single facade over multiple backend parts. Moreover, it provides each client type, e.g. desktop, mobile, exactly the data that it needs and not more in the format required by this client type. The use-case Imagine the following use-case. In a e-commerce shop, the home page should display multiple unrelated data at once. Products: The business could configure which items are shown on the home page.

system architecture microservices

Discussing Backend For Front-end

In the good old days, applications were simple. A browser sent a request to a webapp endpoint; the latter fetched data from a database and returned the response. The rise of mobile clients and integrations with other apps upset this simplicity. I want to discuss one solution to handle the complexity in this post. The increased complexity of system architecture Let’s first model the above simple architecture. Mobile clients changed this approach. The display area of mobile clients

architecture microservices system design

Chopping the monolith - the demo

In my previous blog post Chopping the monolith, I explained my stance on microservices and why it shouldn’t be your golden standard. However, I admitted that some parts of the codebase were less stable than others and had to change more frequently. I proposed 'chopping' these few parts to cope with this requirement while keeping the monolith intact. As Linus Torvalds once wrote: Talk is cheap, show me the code! I want to show how to do it within the scope of a small demo project to

architecture microservices system design

Chopping the monolith

If you attend conferences or read technical articles, you could think that microservices are the correct and only way to build a system at the moment. Despite some pushback from cooler heads, the default architecture is microservices. In this post, I’d like to argue why it’s wrong. I’ll first get back to the origin of microservices and the fundamental reason to use them. Then, I’ll describe why microservices don’t fit most organizations' structures. Afterward, I̵

architecture microservices system design

APISIX, an API Gateway the Apache way

During the pioneer area of the World Wide Web, the content was static. To serve it, a group of developers created a web server, which is now known as the Apache Web Server. The Apache Web Server is built around a module architecture. Developers created a module to run CGI scripts to add dynamic content to the lot. Users wrote early CGI scripts in Perl. After a while, it became evident that generating a complete HTML page from scratch was not the best way and that templating - providing an HTML

Resilience microservices failsafe resilience4j microprofile

A tentative comparison of fault tolerance libraries on the JVM

If you’re implementing microservices or not, the chances are that you’re calling HTTP endpoints. With HTTP calls, a lot of things can go wrong. Experienced developers plan for this and design beyond just the happy path. In general, fault tolerance encompasses the following features: RetryTimeoutCircuit BreakerFallbackRate Limiter to avoid server-side 429 responsesBulkhead: Rate Limiter limits the number of calls in a determined timeframe, while Bulkhead limits the number of concurren

cloud foundry microservices pivotal spring boot

Going the microservices way - part 2

This is the 2nd post in the Going the microservices way focus series. In my previous post, I developed a simple microservices REST application based on Spring Boot in a few lines of code. Now is the time to put this application in the cloud. In the rest of the article, I suppose you already have an account configured for the provider. Pivotal Cloud Foundry is the Cloud offering from Pivotal, based on Cloud Foundry.

microservices spring boot

Going the microservices way - part 1

This is the 1st post in the Going the microservices way focus series. <div class='paragraph'> <p><a href='https://en.wikipedia.org/wiki/Microservices' target='_blank' rel='noopener'>Microservices</a>, are trending right now, whether you like it or not. There are good reasons for that as it resolves many issues organizations are faced with. It also opens a Pandora box as new issues pop up every now and then…​ But that is a story for another day: in the end, micr

application server microservices spring boot

On resources scarcity, application servers and micro-services

While attending JavaZone recently, I went to a talk by Neal Ford. To be honest, the talk was not something mind-blowing, many tools he showed were either outdated or not best of breed, but he stated a very important fact: application servers are meant to address resources scarcity by sharing resources, while those resources are no more scarce in this day and age. In fact, this completely matches my experience. Remember 10 years ago when we had to order hardware 6 months in advance? At that time