Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”
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”
NuGet is the .NET package manager. By default, the .NET Core SDK will use packages from the nuget.org website.
In this article, you’ll learn how to deploy a NuGet server on Red Hat OpenShift Container Platform (RHOCP). We’ll use it as a caching server and see that it speeds up our builds. Before we get to that, we’ll explore some general NuGet concepts and see why it makes sense to use a local NuGet server.
Continue reading “Using a local NuGet server with Red Hat OpenShift”
These days, microservices-based architectures are being implemented almost everywhere. One business function could be using a few microservices that generate lots of network traffic in the form of messages being passed around. If we can make the way we pass messages more efficient by having a smaller message size, we could the same infrastructure to handle higher loads.
Protobuf (short for “protocol buffers”) provides language- and platform-neutral mechanisms for serializing structured data for use in communications protocols, data storage, and more. gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. Together, they provide an efficient message format that is automatically compressed and provides first-class support for complex data structures among other benefits (unlike JSON).
Microservices environments require lots of communication between services, and for this to happen, services need to agree on a few things. They need to agree on an API for exchanging data, for example, POST (or PUT) and GET to send and receive messages. And they need to agree on the format of the data (JSON). Clients calling the service also need to write lots of boilerplate code to make the remote calls (frameworks!). Protobuf and gRPC provide a way to define the schema of the message (JSON cannot) and generate skeleton code to consume a gRPC service (no frameworks required).
Continue reading “Using a Kotlin-based gRPC API with Envoy proxy for server-side load balancing”
Observability is Key
One of the great things about Node.js is how well it performs in a container. Its fast start up time, and relatively small size make it a favorite for microservice applications on OpenShift. But with this shift to containerized deployments comes some complexity. As a result, monitoring Node.js applications can be difficult. At times it seems as though the performance and behavior of our applications become opaque to us. So what can we do to find and address issues in our services before they become a problem? We need to enhance observability by monitoring the state of our services.
Instrumentation of our applications is one way to increase observability. Therefore, in this article, I will demonstrate the instrumentation of a Node.js application using Prometheus.
Continue reading “Monitoring Node.js Applications on OpenShift with Prometheus”
.NET Core 2.2 has been released. You can try it on Red Hat Enterprise Linux (RHEL) and OpenShift. One of the new features of ASP.NET Core is the Health Checks API.
In this article, which was written for C# Advent Calendar 2018, I show an example of how the API works with OpenShift by implementing two health checks for the Kubernetes liveness and readiness probes. Since OpenShift includes Kubernetes, this example also works well with Kubernetes.
Continue reading “Using Kubernetes readiness and liveness probes for health checks with ASP.NET Core 2.2 on OpenShift”
Diving into XDP
In the first part of this series on XDP, I introduced XDP and discussed the simplest possible example. Let’s now try to do something less trivial, exploring some more-advanced eBPF features—maps—and some common pitfalls.
XDP is available in Red Hat Enterprise Linux 8 Beta, which you can download and run now.
Continue reading “Using eXpress Data Path (XDP) maps in RHEL 8 Beta: Part 2”
Red Hat OpenShift implements .NET Core support via a source-to-image (S2I) builder. In this article, we’ll take a closer look at how you can use that builder directly. Using S2I, you can build .NET Core application images without having to write custom build scripts or Dockerfiles. This can be useful on your development machine or as part of a CI/CD pipeline.
Continue reading “Building .NET Core container images using S2I”
“Truth can only be found in one place: the code,” Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.
The way we structure our code has a direct impact on how understandable is it. Code that is easy to follow with no or less hidden functionality is much easier to maintain. It also makes it easier for our fellow programmers to track down bugs in the code. This helps us to avoid Venkat’s Jesus Driven Development.
The way I write Spring applications comprises heavy use of Spring annotations. The problem with this approach is that partial flow of the application is controlled by annotations. The complete flow of my code is not in one place, that is, in my code. I need to look back to the documentation to understand the annotations’ behavior. By reading just the code, it is difficult to predict the flow of control.
Luckily, Spring has a new way to code to and it has been called Spring Functional or SpringFu. In this article, I will use Kotlin to showcase some of the benefits you get from SpringFu.
Continue reading “Writing better Spring applications using SpringFu”