A Java geek

Whether you implement or not microservices (and you probably shouldn’t), your system is most probably composed of multiple components. The most straightforward system is probably made of a reverse proxy, an app, and a database. In this case, monitoring is not only a good idea; it’s a requirement. The higher the number of components through which a request may flow, the strongest the requirement. However, monitoring is only the beginning of the journey. When requests start to fail en

I won’t introduce Dependabot. Lots and lots of developers use it daily on GitHub. I do use it as well. However, it suffers from two drawbacks: While it’s perfectly integrated with GitHub, integrations with other platforms are less seamless.It’s limited in the list of ecosystems it supports For example, I generally use Docker Compose files for my demos. When necessary, I use Kubernetes. Dependabot supports none. Worse, Dependabot doesn’t accept contributions to add new eco

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.

Kubernetes is a colossal beast. You need to understand many different concepts before it starts being useful. When everything is set up, you’ll probably want to expose some pods to the outside of the cluster. Kubernetes provides different ways to do it: I’ll describe them in this post.

A ruthless battle occurs every day on the World Wide Web. Its goal is to decide which programming flavor is the best: OOP or FP? I assume that imperative and procedural programming are not part of the contenders. Arguments range from the factual to the irrelevant to the utterly stupid. A couple of years ago, I wanted to listen to a video of Martin Odersky (of Scala fame). I remember neither the exact talk nor the subject. What I remember is the introduction, though: he explained that FP was mor

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

API Gateways in general, and Apache APISIX in particular, provide a single entry point into one’s information system. This architecture allows for managing load balancing and failover over similar nodes. For example, here’s how you can create a route balanced over two nodes in Apache APISIX: curl http://localhost:9080/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -i -d '{ 'uri': '/*', 'upstream': { 'type': 'roundrobin', 'nodes': { '

API management solutions, also known as API gateways, are a must in the day and age of APIs. However, once you’ve set up such a gateway, you can use it for different purposes unrelated to APIs. Today, I want to show you how to improve the security of web apps. Prevent sniffing Browsers are fantastic pieces of technology that try to make the life of users as comfortable as possible. However, the balance between ease of use and security may sometimes tip on the former to the latter’

Last year, I spoke at the National DevOps Conference that took place at the British Museum. I had already visited the museum before, but speaking there was a fantastic experience. Besides, we had the museum all for ourselves for a couple of hours. If you’ve ever visited the place, you know what I mean. Anyway, I also attended a talk about Checkov: Checkov scans cloud infrastructure configurations to find misconfigurations before they’re deployed. Checkov uses a common command

If you’ve more than a couple of years of experience in IT, you probably have stumbled upon the following quote: There are only two hard things in computer science: cache invalidation and naming things. — Phil Karlton Then, because it’s such a great quote, it evolved: There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.— Jeff Atwood (@codinghorror) August 31, 2014 However, I think that the initial quote is m