microservices

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

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

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.

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

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

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̵

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

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

This is the 3rd post in the Going the microservices way focus series. In the first post of this serie, I created a simple microservice based on a Spring Boot + Data JPA stack to display a list of available products in JSON format. In the second part, I demoed how this app could be uploaded on Pivotal Cloud Foundry. In this post, I’ll demo the required changes to deploy on Heroku.

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.

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