vCluster is a solution for creating virtual clusters within a host Kubernetes cluster. Virtual clusters are a Kubernetes concept that enables isolated clusters to be run within a single physical Kubernetes cluster. Each cluster has its own API server, which makes them better isolated than namespaces and more affordable than separate Kubernetes clusters. — What are virtual clusters?

The ideal size of your Kubernetes clusters is a day 0 question and demands a definite answer. You find one giant cluster on one end of the spectrum and many small-sized ones on the other, with every combination in between. This decision will impact your organization for years to come. Worse, if you decide to change your topology, you’re in for a time-wasting and expensive ride. I want to list each approach’s pros and cons in this post.

This week’s post is the third and final in my series about running tests on Kubernetes for each pull request. In the first post, I described the app and how to test locally using Testcontainers and in a GitHub workflow. The second post focused on setting up the target environment and running end-to-end tests on Kubernetes. I concluded the latter by mentioning a significant quandary. Creating a dedicated cluster for each workflow significantly impacts the time it takes to run.

I’m continuing my series on running the test suite for each Pull Request on Kubernetes. In the previous post, I laid the groundwork for our learning journey: I developed a basic JVM-based CRUD app, tested it locally using Testcontainers, and tested it in a GitHub workflow with a GitHub service container. This week, I will raise the ante to run the end-to-end test in the target Kubernetes environment.

Imagine an organization with the following practices: Commits code on GitHubRuns its CI/CD pipelines with GitHub ActionsRuns its production workload on KubernetesUses Google Cloud A new engineer manager arrives and asks for the following: On every PR, run integration tests in a Kubernetes cluster similar to the production one. It sounds reasonable.

In my earlier post about moving from Kotlin Scripting to Python, I mentioned several reasons: Separating the content from the scriptKotlin Scripting is an unloved child of JetBrainsRenovate cannot update Kotlin Scripting files I was wrong on the third point. Here’s my mea culpa. First things first, Renovate does indeed manages Kotlin Scripting files - since 2022. Even better, Renovate can manage any type of file.

Last year, I wrote a post on Open Telemetry Tracing to understand more about the subject. I also created a demo around it, which featured the following components: The Apache APISIX API GatewayA Kotlin/Spring Boot serviceA Python/Flask serviceAnd a Rust/Axum service I’ve recently improved the demo to deepen my understanding and want to share my learning. Using a regular database In the initial demo, I didn’t bother with a regular database.

In a few words, the idea of canary releases is to deliver a new software version to only a fraction of the users, analyze the results, and decide whether to proceed further or not. If results are not aligned with expectations, roll back; if they are, increase the number of users exposed until all users benefit from the new version. In this post, I’d like to detail this introduction briefly, explain different ways to define the fraction, and show how to execute it with Apache APISIX.

The OpenTelemetry Collector sits at the center of the OpenTelemetry architecture but is unrelated to the W3C Trace Context. In my tracing demo, I use Jaeger instead of the Collector. Yet, it’s ubiquitous, as in every OpenTelemetry-related post. I wanted to explore it further.

Though I always worked on the Dev side of IT, I was also interested in the Ops side. I even had a short experience being a WebSphere admin: I used it several times, helping Ops deal with the Admin console while being a developer. Providing a single package that Ops can configure and deploy in different environments is very important.

With the rise of Docker came a new focus for engineers: optimizing the build to reach the smallest image size possible. A couple of options are available. Multi-stage builds: A Dockerfile can consist of multiple steps, each having a different Docker base image. Each step can copy files from any of the previous build steps. Only the last one will receive a tag; the others will be left untagged. This approach separates one or more build steps and a run step.

Kubernetes offers a lot of benefits: an enormous ecosystem with plenty of actors, self-healing capabilities, etc. There’s no free lunch, though. It also comes with downsides, chief among them its complexity and operating costs. However, the more I work with Kubernetes, the more I think its most significant asset is extensibility. If you need something that the platform doesn’t provide by default, there’s an option to develop it yourself and integrate it.

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.

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.

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.

Regular readers of this blog know that I’m using Jekyll to generate the static site. I’m using GitLab: when I push on the master branch, it triggers the generation job. However, Jekyll is Ruby-based and requires a couple of Gem dependencies. I’ve also added a few plugins. For this reason, I’ve created a Docker image with all required dependencies. Regularly, I update the versions in the Gemfile.lock via Bundler. Afterward, I need to rebuild the Docker image.

This week, I want to take a break from my Start Rust series and focus on a different subject. I’ve already written about my blogging stack in detail. However, I didn’t touch into one facet, and that facet is how I generate the static pages from Jekyll. As I describe in the blog post, I’ve included quite a couple of customizations. Some of them require external dependencies, such as: A JRE for PlantUML diagrams generationThe graphviz package for the same reasonetc.

Gone are the times when developers' jobs ended with the release of the application. Nowadays, developers care more and more about the operational side of IT: perhaps they operate applications themselves, but more probably, their organization fosters increased collaboration between Dev and Ops. I started to become interested in the Ops side of software when I was still a consultant. When Spring Boot released the Actuator, I became excited.

A couple of years ago, I wrote how one could check the version of one’s deployed application. Recent technologies such as Spring Boot makes it even easier. It’s as important for regular applications as for static sites such as Jekyll. I wanted to have this blog display some basic Git data. As I publish from the tip of master and not from tags, the data I want is the commit hash.

Last week, I wrote about how one could migrate metrics from Spring Boot 1.5 to Spring Boot 2.0. This week, it’s time to check the different metrics available in Spring Boot 2.0 and how to create them. Meter There are 4 main types of metrics available: CounterGaugeTimerDistribution summary To keep the post readable in one piece, it will be limited to Counter and Gauge All metrics inherit from the base Meter class. A Meter provides basic measurement storage capabilities.

I’ve already written about the excellent monitoring features available in Spring Boot. In Spring Boot 2.0, there has been a major rewrite regarding how the /metrics endpoint is designed. This is the subject of this post.

Some years ago, I discovered the Spring Boot actuator: Spring Boot includes a number of additional features to help you monitor and manage your application when it’s pushed to production. You can choose to manage and monitor your application using HTTP endpoints, with JMX or even by remote shell (SSH or Telnet). Auditing, health and metrics gathering can be automatically applied to your application.

Nowadays, most companies use one or another Agile methodology for their software development projects. That makes people involved in software development projects at least aware of agile principles - whether they truly try to follow agile practices or just pay lip service to them for a variety of reasons remains debatable. To avoid any association with tainted practices, I’d rather use the name 'Exploratory Development'.

This week’s post aims to describe how to send JMX metrics taken from the JVM to an Elasticsearch instance. Business app requirements The business app(s) has some minor requirements. The easiest use-case is to start from a Spring Boot application. In order for metrics to be available, just add the Actuator dependency to it: <dependency> <groupId>org.springframework.

I think Spring Boot brings something new to the table, especially concerning DevOps - and I’ve already written a post about it. However, there’s more than metrics and healthchecks. In one of another of my previous post, I described how to provide versioning information for Maven-built applications. This article will describe how this later post is not necessary when using Spring Boot.

In one of my recent post, I described how I used VMWare to create a Drupal I could play with before deploying updates to morevaadin.com. Then, at Devoxx France, I attended a session where the talker detailed how he set up a whole infrastructure for after work formations with Vagrant. Meanwhile, a little turn of fate put me in charge of some Drupal projects and I had to get better at it…​ fast. I put my hands on the Definitive Guide to Drupal 7 that talks about Drupal use with Vagrant.