This article is the first in a series of three articles which share my experience with troubleshooting the performance of Vert.x applications. The first article, originally posted on Ales Nosek – The Software Practitioner, provides an overview of the Vert.x event loop model, the second article covers techniques to prevent delays on the event loop, and the third article focuses on troubleshooting of event loop delays.
Programming with Vert.x requires a good understanding of its event loop model. From what I saw in practice, delayed or blocked event loop threads are the number one contributor to performance problems with Vert.x applications. But don’t worry. In this article, we are going to review the event loop model.
Continue reading “Troubleshooting the Performance of Vert.x Applications, Part I — The Event Loop Model”
Disclaimer: the high-level architecture solution and the related demo code is an opinionated implementation to solve the problem described here. The author believes that DevOps is not about tools and frameworks, but a mindset and cultural change for teams. This is an implementation that aims to help a team on the DevOps journey of increasing shared understanding within traditional Development and Operation teams.
There are some challenges while adopting a PaaS Platform like OpenShift in an organization. Traditional IT teams have operated in silos where responsibilities for different parts of the Product lifecycle were distributed to different teams, for example, a development team and a release or production team. The teams’ domain of knowledge is, traditionally, limited to the activities they perform for their part of the chain of work and communication between these teams lacked flow or was done using ticketing systems that increase handoffs.
Continue reading “How to use Everything as Code to create a shared language between Product and Platform teams driven by Ansible Tower and Self Service models”
This post was originally published on the ETI blog here.
So – you want to stop your OpenShift cluster? There are many reasons why you may want to stop your OpenShift cluster. Maybe you have an annual disaster recovery test where you shut down a whole datacenter. Perhaps you want to do some maintenance to your infrastructure or the hypervisor or storage that your cluster is hosted on. It’s not an uncommon to need to be able to do this, so I have collated some of the best practices I have experienced across a multitude of environments, both large and small.
Here is the process that I recommend to use as a best practice in order to stop and start your OpenShift cluster(s). Following this process will give you the best chance of a trouble free maintenance window. As with all things, you should exercise care with this process on your important clusters. Try it on an unimportant environment first and see if it is a good fit for you.
Important: This process will cause an outage to any application workload running on the cluster until the cluster is fully started. The cluster itself will be unavailable until manually started. Care should be taken to run this process only on appropriate environments. It is recommended to have backups available of your environment.
Continue reading “How To: Stop and start a production OpenShift Cluster”
With the release of Red Hat Enterprise Linux 8, the Training and Certification team also announced its launch of offerings to coincide with the new version. Courses and exams contributing to the Red Hat Certified System Administrator (RHCSA) title are available on redhat.com and in the Red Hat Learning Subscription.
Continue reading “Red Hat Enterprise Linux 8 training and certification now available”
Previously published on She ITs and Giggles.
Frequently when I’m on site I am not directly asked but I am expected to provide answers to my customers how to get the best use of a technology. In this post I’m examining a recent scenario around providing structure around deploying OpenShift in order to provide a collaboration environment that would aide the use of this technology. We were also deploying OpenShift but writing about OpenShift deployment is a well covered subject across the board.
Continue reading “OpenShift – From Design and Deploy to Deliver and Transform: Optimising Distributed Teams with Agile Practices”
Every solution starts with sharing a problem. At Red Hat, when we talk about “open source,” we’re talking about a proven way of collaborating to create technology. The freedom to see the code, to learn from it, to ask questions and offer improvements. This is the open source way. However, bringing together people in your organization to collaborate is often easier said than done.
At Red Hat, we’ve created “Communities of Practice” (CoP) to help our own people collaborate, especially on new and emerging technologies–including automation.
Continue reading “Communities of practice: Straight from the open source”
This diagram represents the reference architecture for a full high availability and disaster recovery solution. This solution can be individually tailored to address a single availability solution. For example, if only disaster recovery is needed the configuration supports exclusion of the HA replica.
Continue reading “Ansible Tower High Availability and Disaster Recovery”
The pace of innovation has shortened expectations for time to market, placing pressure on IT teams to keep up with the rate of change. Organizations need just-in-time, prescriptive resources to enable their teams to leverage innovation to solve business problems. The Red Hat Learning Subscription (RHLS) delivers unlimited, on-demand, modular access to Red Hat’s entire training portfolio including cloud based labs for a full year. The Early Access feature of RHLS enables subscribers to learn from real-time publishing of courses and labs currently in development.
Continue reading “Start learning Red Hat Enterprise Linux 8 and Red Hat OpenShift Container Platform 4 through Early Access”