This is the third of a series of three articles based on a session I held at EMEA Red Hat Tech Exchange. In the first article, I presented the rationale and approach for leveraging Red Hat OpenShift or Kubernetes for automated performance testing, and I gave an overview of the setup. In the second article, we looked at building an observability stack. In this third part, we will see how the execution of the performance tests can be automated and related metrics gathered.
An example of what is described in this article is available in my GitHub repository.
Continue reading “Leveraging OpenShift or Kubernetes for automated performance tests (part 3)”
People associate running pods with Kubernetes. And when they run containers in their development runtimes, they do not even think about the role pods could play—even in a localized runtime. Most people coming from the Docker world of running single containers do not envision the concept of running pods. There are several good reasons to consider using pods locally, other than using pods to naturally group your containers.
For example, suppose you have multiple containers that require the use of a MariaDB container. But you would prefer to not bind that database to a routable network; either in your bridge or further. Using a pod, you could bind to the
localhost address of the pod and all containers in that pod will be able to connect to it because of the shared network name space.
Continue reading “Podman: Managing pods and containers in a local container runtime”
Nowadays technology companies are adopting the API as one of the most valuable pieces of their business.
What does it mean when we talk about API-first development? We already know the benefits of using an API-first approach:
- Reduced interdependencies
- Earlier validation
- Early feedback with the freedom to change
- Improved efficiency
This article describes what it means to use the API-first design approach. It also walks through an example of using this approach with the OpenAPI Specification and with oas-tools as the Node.js back-end application, which enables you to care only about the business logic. All the validation of incoming requests are done by the
oas-tools library (based on the OpenAPI Specification file provided).
Continue reading “Building a Node.js service using the API-first approach”
The fall C++ meeting was held in San Diego, CA. As usual, Red Hat sent three of us to the meeting: myself from the Concurrency and Parallelism Study Group (SG1), Jason Merrill from the Core Language Working Group, and Jonathan Wakely from the Library Working Group (LEWG).
SG1 had a fairly full plate but finished the week with a bit of breathing room to spare. This article describes the major topics discussed this week in SG1.
Continue reading “Fall 2018 ISO WG21 C++ Standards Committee meeting trip report”
Migrating from one software solution to another is a reality that all good software developers need to plan for. Having a plan helps to drive innovation at a continuous pace, whether you are developing software for in-house use or you are acquiring software from a vendor. In either case, never anticipating or planning for migration endangers the entire innovation value proposition. And in today’s ever-changing world of software, everyone who wants to benefit from the success of the cloud has to ensure that cloud innovation is continuous. Therefore, maintaining a stack that is changing along with technological advancements is a necessity.
In this article, we will take a look at the impact of moving to OpenJDK and the results will aid in drawing further conclusions and in planning. It’s quite common to be using a proprietary version of JDK, and this article addresses how to use Red Hat Application Migration Toolkit to analyze your codebase to understand the impact of migrating to OpenJDK.
Continue reading “Using Red Hat Application Migration Toolkit to see the impact of migrating to OpenJDK”
Open vSwitch (OVS) can use the kernel datapath or the userspace datapath. There are interesting developments in the kernel datapath using hardware offloading through the TC Flower packet classifier, but in this article, the focus will be on the userspace datapath accelerated with the Data Plane Development Kit (DPDK) and its new feature—partial flow hardware offloading—to accelerate the virtual switch even more.
This article explains how the virtual switch worked before versus now and why the new feature can potentially save resources while improving the packet processing rate.
Continue reading “Speeding up Open vSwitch with partial hardware offloading”