Friday Five — January 20, 2017

Red Hat announced the release of its OpenShift Container Platform 3.4, providing enterprises with new container management capabilities. The OpenShift Container Platform 3.4 update is based on the Kubernetes 1.4 release that came out in October 2016. "The most interesting features from Kubernetes 1.4 are around dynamic provisioning of storage and related functionality, like storage tier labeling," Joe Fernandes, senior director, product management for OpenShift at Red Hat, told eWEEK. Fernandes explained that Red Hat Gluster Storage can run in a dedicated storage cluster (outside of OpenShift/Kubernetes) and can also be accessed from containerized applications running inside OpenShift over the network. "Red Hat Gluster Storage provides a consistent storage platform for OpenShift users across the hybrid cloud," Fernandes said. Looking forward, Fernandes commented that Red Hat will continue to evaluate new features from the upstream Kubernetes releases as potential capabilities for Red Hat OpenShift Container Platform.

More organizations are taking a hard look at Linux containers, which promise the kind of speed and portability needed to maintain competitive edge. But as IT and business professionals evaluate container technologies, many are feeling overwhelmed by confusing and often conflicting information available. Evaluating containers typically starts with a fundamental question: Are containers just a faster, more lightweight reimagining of server virtualization? It's a reasonable place to start, as both technologies seem to occupy a similar space, with virtualization as the incumbent. But for 2017, it's important to consider where containers are going versus where virtualization already is. According to research from Red Hat and Bain & Company, there is high interest in moving containers beyond web applications to more traditional applications over the next three years. With all of this laid out, here's Gunnar Hellekson's [director of product management at Red Hat] prediction: Virtualization is here to stay, and containers make it more important.

Software development, particularly open source software development, has an invisible rulebook. These rules can have a significant impact on how an open source community treats a developer, especially newcomers. Before interacting with any community, open source or otherwise, you need to do your homework. For prospective open source contributors, this means understanding the community's mission and learning where you can help from the onset. Everyone wants to contribute code, but far fewer developers are ready, willing, and able to do the grunt work: testing patches, reviewing code, sifting through documentation and correcting errors, and all of those other generally undesirable tasks that are required for a healthy community. Why do this when you can start cranking out beautiful lines of code? It's about trust and, more important, showing that you care about the community as a whole and not developing only the features that you care about.

Containers and DevOps often are part of the same conversation. That's not because they are the same thing, however. They are very distinct concepts. Containers are a type of technology that makes it easier to host applications inside portable environments. DevOps, in contrast, is a set of cultural practices related to software development. It emphasizes collaboration between all parts of the IT organization and the "continuous delivery" of software. An important thing to understand is DevOps is not tied to any particular type of technology. Adopting it does not mean that you simply use a particular set of tools or frameworks to build software. You can do DevOps with any type of tool. So what, then, does DevOps have to do with containers? The answer is that, although you don't have to use containers to do DevOps, containers are a great tool for making it easier.

The "open source" concept started in the technology industry with coders looking to work together collaboratively to build new technologies at a faster pace. It was more flexible than proprietary ("closed source") software often allowed. But it doesn't stop with the IT department; your organisation can also be open—encouraging better employee collaboration and engagement, and faster innovation. An open organisation should run as a meritocracy, where leaders are a catalyst for ensuring that the business works in an aligned way, and where all employees are empowered to take initiative and enable action. Ideas shouldn't be considered the best just because they come from the chief executive or someone else near the top. Leadership shouldn't come automatically with a job title; it functions most effectively when it's earned. This may seem like common sense, but in many organisations, it's not the case. At Red Hat, we encourage employees to lead when they see an opportunity, regardless of title or role. It's about removing those levels of permission. If the best ideas are able to win—regardless of where they come from—then everyone in the organisation has the ability to make changes.