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.

Last week, I wrote about putting the right feature at the right place. I used rate limiting as an example, moving it from a library inside the application to the API Gateway. Today, I’ll use another example: authentication and authorization. Securing a Spring Boot application I’ll keep using Spring Boot in the following because I’m familiar with it. The Spring Boot application offers a REST endpoint to check employees' salaries.

Before moving to Developer Relations, I transitioned from Software Architect to Solution Architect long ago. It’s a reasonably common career move. The problem in this situation is two-fold: You know perfectly well software librariesYou don’t know well infrastructure components It seems logical that people in this situation try to solve problems with the solutions they are most familiar with. However, it doesn’t mean it’s the best approach.

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 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!

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.

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.

I frequently use the Spring Boot framework in my demos. The latest one is no different. It shows how to achieve CQRS using two different code paths: the command part is implemented via Spring Data JPAthe query part via jOOQ My use case is a banking application that offers a REST layer allowing clients to call any parts.

Some libraries, frameworks, components, and architectures either encourage statelessness, or make it a requirement. While statelessness has a lot of benefits, it’s unfortunately rarely possible in the real world. In this post, I’d like to detail this stance of mine a bit. State in Functional Programming Functional Programming is based on a set of principles.

In the first post of this series, we detailed the setup of a software to automate submissions to conferences. In the second one, we configured the integration endpoints. This third post is dedicated to the deployment of the solution to production. To Cloud or not to Cloud? To decide what to do, the first step is to ask oneself whether to host: On-premiseIn the CloudOr even use my own machine First, let’s remove on-premise from the options.

In the previous post, I described a poster child for automation: managing the repetitive tasks around a conference submission workflow. I wrote about the setup, and how to use ngrok to redirect webhooks to my computer. This week, I’d like to write about some of the hiccups I encountered along the way. Registering a Trello webhook Most SaaS providers allow to register webhooks through their GUI.

Even given the current situation, part of my Developer Advocate job is to talk at (virtual) conferences. Sometimes, organizers invite me. Yet, most of the times, I need to take part in a CfP. With the sheer numbers of conferences I submit to, I need a tool to manage the status of each submission. Since I started, Trello has been my tool of choice. I’ve a dedicated board with several defined columns: backlog, abandoned, submitted, rejected, submitted and done.

So you were tasked to prepare your next software project. Already, its overall architecture is designed, you already put some code-related parts in place such as the build file, the packages, perhaps a sample use-case. Then after a few months, the project is finished, and the final result has largely diverged from what you imagined:inconsistent packages naming and organization, completely different low-level implementations e.g. XML dependency injection, auto-wiring and Java configuration, etc.

I’ve been surprised this week by a colleague’s comment regarding how a piece of software had been architectured. He found it too much procedural and not enough object-oriented, despite the fact the code was performing exactly as needed. I would have expected this from a junior developer, not from a seasoned one. Hey, guys, may I kindly remind you we’re not in university anymore?