Came across this post on the Red Hat Services blog about some solid practices for “doing” DevOps. I liked Mr. Hoffman’s simple explanation of what DevOps is. I also liked that he points out how just using a tool (or a set of tools) does not equal “doing DevOps.” Check it out and make sure you leave some comments here or there about what you think.
This is part 1 of a 2-part article about Advanced Integration with RHEV-M.
RHEV-M is a Large scale, centralized management for server and desktop virtualization. It is based on leading performance, scalability and security infrastructure technologies, focusing on KVM for best integration/performance. It provides an alternative to Center/vSphere, providing end-to-end IaaS platform.
In this post I’ll show you how you can integrate with the RHEV-M engine, covering both new and cool features, as well as some “old” useful features. Let’s start with the REST-based APIs. These APIs allow you to perform different operations on the engine externally. You can do anything using the REST APIs, even operations that aren’t exposed through the different UI interfaces.
Continue reading “Advanced integration with Red Hat Enterprise Virtualization Manager (RHEV-M) – Part 1 of 2”
DevOps is all about culture, right? Yeah, it’s developers and operators working more closely, but it’s more than that. DevOps is a culture that exudes the principles of Agile, Lean, and Open Source, to deliver higher quality products and services faster, more continuously, and more predictably.
So, if we accept DevOps is a culture, and your CIO gives you a mandate to transform his or her organization to a DevOps organization, you’re now effectively responsible for an organizational culture change initiative. That’s the situation I found myself in recently, when Red Hat CIO Lee Congdon asked me to lead a DevOps enablement team in his IT organization. At a few weeks in with our new team, called Inception, I’d like to share our approach:
1. Build culture through practices. Culture is the sum of the habits and behaviors of a group. I don’t believe culture can be changed through mandates. But, Inception’s mission is to change the organization’s culture. So, how?
Continue reading “Red Hat IT Begins Its DevOps Journey”
Countless products uses XML files, whether it is for data persistence, serialization or mere configuration. This is even more true when it comes to the Red Hat middleware portfolio, the JBoss projects having always been keen on using this format for configuration files – on top of the ones specified by JEE such as the famous (or infamous ?) web.xml. While the XML format has some definitive qualities, it is not the easiest format to parse, and this often causes issues when integrating product inside an RPM or designing an automated installation procedure.
Continue reading “XML editing with Bash script”
Hi, I’m Steve, a member of the Inception team at Red Hat. The Inception team was pulled from different parts of IT to foster DevOps culture in Red Hat. Though we’ve only been a team for a little over a month, we’ve been trying to do some early projects to make everyone’s lives easier.l
We spent quite a bit of time in our early meetings identifying pain points in the current processes. We talked with a few developers, ops folks, noted historical issues and ran with general brain storming. We heard a lot about configuration management, lack of information, redundant and time consuming tasks, and many more of what one expects when asking tech people what pains them.
Of course, Tim (another Incepticon) and I were itching to write some code so once the team identified a common issue for both developers and ops engineers we jumped in head first.
The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.
Continue reading “Feeling Developer Pain”
In an earlier post we looked into using the Performance Co-Pilot toolkit to explore performance characteristics of complex systems. While surprisingly rewarding, and often unexpectedly insightful, this kind of analysis can be rightly criticized for being “hit and miss”. When a system has many thousands of metric values it is not feasible to manually explore the entire metric search space in a short amount of time. Or the problem may be less obvious than the example shown – perhaps we are looking at a slow degradation over time.
Continue reading “Performance Regression Analysis with Performance Co-Pilot “
Investigating performance in a complex system is a fascinating undertaking. When that system spans multiple, closely-cooperating machines and has open-ended input sources (shared storage, or faces the Internet, etc) then the degree of difficulty of such investigations ratchets up quickly. There are often many confounding factors, with many things going on all at the same time.
The observable behaviour of the system as a whole can be frequently changing even while at a micro level things may appear the same. Or vice-versa – the system may appear healthy, average and 95th percentile response times are in excellent shape, yet a small subset of tasks are taking an unusually large amount of time to complete, just today perhaps. Fascinating stuff!
Continue reading “Exploratory Performance Analysis with Performance Co-Pilot “
A few short months ago, I was managing an operations team at another firm. There had been a sea change in executive leadership over the summer, and the DevOps transformation that I’d helped to kick off was quickly being unraveled by the sorts of executive shenanigans that can ensue when a C level departs and leaves an opening. I was open minded to a change in scenery and got the call of a lifetime from a Red Hat recruiter.
You see, I’ve been involved in the Linux community since around 1998. I helped grow the Triangle Linux Users Group in its early years, and served a term on the steering committee as Vice Chair. When the community was looking for an enterprise class Linux distribution without the cost of a subscription model, I joined the cAosity project (now gone) and helped deliver CentOS to the Linux community. Open Source was in my DNA, and living in the Raleigh area the success of Red Hat was always right there for me to admire. “Someday I’d like to work there,” I often thought to myself.
This DevOps thing has gotten a lot of traction with me. I’ve been a volunteer co-organizer at Triangle DevOps, and have even given a few public talks on the subject, too.
Continue reading “Incepting DevOps at Red Hat”
At JUDCon 2013 in Boston, Scott Cranton and I presented a talk entitled Resilient Enterprise Messaging with Fuse & Red Hat Enterprise Linux. This technical article is the follow up work from that presentation.
JBoss A-MQ is built on ActiveMQ which is a robust messaging platform that supports STOMP, JMS, AMQP and modern principals in Message Oriented Middleware (MOM). It’s built from the ground up to be loosely coupled and asynchronous in nature. This provides ActiveMQ with native high availability capabilities. An administrator can easily configure an ActiveMQ master/slave architecture with a shared filesystem. In the future this will be augmented with Replicated LevelDB.
Red Hat Enterprise Linux is the popular, stable and scalable Linux distribution which has High Availability and Resilient Storage add-on support built on CMAN, RGManager, Corosync, and GFS2. High Availability and Resilient Storage expand upon the high availability capabilities built into ActiveMQ and provide a robust, and complete solution for enterprise deployments that require deeper clustering capabilities.
There are two main architectures commonly used to provide fault tolerance to a messaging server. The first is master/slave which is easy to configure, but as it scales, it requires 2X resources. The second is made up of active nodes and redundant nodes. The redundant nodes can take over for any one of the active nodes should they scale. The active/redundant architecture requires more software and more initial configuration, but uses N+1 or N+2 resources as it scales.
This article will explore the technical requirements and best practices for building and designing a N+1 architecture using JBoss A-MQ, Red Hat Enterprise Linux, the High Availability Add-On and the Resilient Storage Add-On.
Continue reading “Resilient Enterprise Messaging with JBoss A-MQ & Red Hat Enterprise Linux”
Interested in DevOps but not sure where to start? How about getting started in 3 steps?
Continue reading Guerilla Improvement: Getting Started in DevOps Without Buy-In