I recently wrote articles on deploying an Express.js application to OpenShift, how to debug your Node.js application on OpenShift with Chrome Dev Tools and a short series on deploying modern web applications to OpenShift. All of those articles used a node module called Nodeshift, but I did a Jedi, hand-wavy thing when talking about it. This next series of articles takes a deeper look at what Nodeshift is and how it is used to ease the deployment of Node.js apps to OpenShift during development.
Continue reading “Easily deploy Node.js applications to Red Hat OpenShift using Nodeshift”
Before anything like an Android device or iPhone existed, desktop computers were the battleground for the browser wars. The battle involved billions of dollars invested by a number of companies, all based on the premise that whoever ruled the desktop browser market would own the internet. Today, mobile devices account for nearly half of all website traffic. Back in the 1990s, however, almost all of the action on the web came from desktop machines, and the vast majority of those desktop machines were running some flavor of Microsoft Windows.
In the browser world, the first-mover advantage belonged to Netscape Communications Corporation. They built the Netscape Navigator browser that made the web accessible to millions for the first time. Netscape had more than 80% of the market, but they also had no shortage of competition. IBM had a browser for OS/2. Oracle had the Powerbrowser, a Netscape-compatible product that included something called the Database Markup Language. The real danger to Netscape, of course, came from the company that owned more than 80% of the world’s desktops: Microsoft.
Strategically, Netscape realized that the web needed to move past static web pages to reach its full potential. Even if they were created dynamically by something like a CGI script on the web server, pages didn’t change once they arrived in your browser. If you wanted to see even a slightly modified version of a page, you had to send a request back to the server and wait for a response. For all its sophistication, a web browser felt a lot like a dumb terminal attached to a mainframe. What web developers needed was a programming language that would run in the browser, taking advantage of the processing power of the desktop machine to give users a richer experience.
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”
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”
In the previous article, we took a quick look at a new source-to-image (S2I) builder image designed for building and deploying modern web applications on OpenShift. While the last article was focused on getting your app deployed quickly, this article will look at how to use the S2I image as a “pure” builder image and combine it with an OpenShift chained build.
Continue reading “Modern web applications on OpenShift: Part 2 — Using chained builds”
In this multi-part series, we will take a look at how to deploy modern web applications, like React and Angular apps, to Red Hat OpenShift using a new source-to-image (S2I) builder image.
Continue reading “Modern web applications on OpenShift: Part 1 — Web apps in two commands”
Recently, I wrote a post called Zero to Express on OpenShift in Three Commands, which shows how to get started using Node.js, Express, and OpenShift together as fast as possible using the Node.js s2i (source-to-image) images that were recently released as part of Red Hat OpenShift Application Runtimes (RHOAR).
This post will add to the last one and show how we can start to debug and inspect our running code using the Chrome Developer Tools (DevTools) inspector.
Continue reading “How to Debug Your Node.js Application on OpenShift with Chrome DevTools”
This guide is designed to help you integrate your Red Hat Single Sign-On server with the OpenAPI (OAI)-based ActiveDocs in your 3scale developer portal. Although it has only been implemented with this particular Identity & Access Management solution (IAM), you could in theory make some customizations where necessary to integrate with another OpenID Connect-based solution.
Continue reading 3scale ActiveDocs and OAuth 2.0
Over the past few weeks I have been learning and enhancing my skills around the new buzz word “serverless” and trying to understand what this buzz is all about. As an ardent open-source developer, I was looking for a platform where I can develop and deploy the serverless functions, which is when I stumbled upon Apache OpenWhisk.
In this blog I will demonstrate how to build a simple nodejs function that can do reverse geocoding using Google Maps API, and how to deploy the functions on to Apache OpenWhisk.
Continue reading “Whisking Functions with Promises using OpenWhisk”