Survey says….Complexity of persistent storage is as big as cost and scale combined

TechValidate recently ran a survey, commissioned by Red Hat, of more than 300 Red Hat customers in various stages of the container adoption journey. The results were consistent with our understanding of the container space. In fact, the pain points we’re looking to solve with the Red Hat container portfolio are much bigger roadblocks than we had previously imagined. You can find the unfiltered results published here.

You can’t contain this

While the constructs that make up containers (e.g., namespaces, cgroups) have been around for more than a decade, containers moved into the mainstream about 2-3 years ago. If you compare where similar seismic shifts, such as big data and cloud, were at the same point in time, you’ll appreciate how rapidly containers have become pervasive and how sticky they are. The first result that surprised us was that almost three out of four people surveyed were interested in or actively working with containers. What wasn’t surprising was that security, scalability, and portability were cited as major bottlenecks preventing a smooth transition to containers from previous deployment platforms.

Complexity of persistent storage is a major roadblock

When asked about the biggest pain point associated with persistent storage, complexity outranked everything else by far, so much so that if you add up the number of responses that listed complexity as one of the pain points, it is almost equal to cost and scale combined. This is a pertinent result as we find enterprises with deep storage knowledge and years of success running applications on bare metal and in virtual machines suddenly struggling with persistent storage for containers. That’s why a key focus for us at Red Hat is to make it super easy to set up, provision, and manage persistent storage, not just for administrators, but developers as well.

When asked about the type of storage most customers use for stateful applications deployed in containers, the answer mainly revolved around reusing existing storage appliances and software defined storage, or a combination of both. This is consistent with the anecdotal feedback we’ve received from customers around using their existing storage investments for some container workloads and complementing that with software-defined storage such as Red Hat Gluster Storage for workloads that demand more elasticity at a lower price.

United we stand, divided we fall

Red Hat has focused on Kubernetes as the container orchestration framework given its maturity, user experience, and community. About half the respondents agreed that a single control plane for both applications and storage is optimal. In addition, a single point of support for storage and container host and open source were listed as key attributes of a vendor customers would like to partner with as a trusted advisor.

Find out more

Join us for a virtual event on January 19 in the new year that will deep dive into the recent innovations to help customers address a number of pain points and navigate the journey toward containers successfully.

In addition, Red Hat recently collaborated with Bain & Company on a survey of more than 400 executives and IT leaders on the transition to containers. You can find the results here.

Red Hat Ceph Storage 2.1 – Rolling down the tracks of Jewel

Three months after the release of Red Hat Ceph Storage 2, we’re proud to announce the first update to our Ceph Jewel-based product with Red Hat Ceph Storage 2.1.

For the 2.1 release, like version 1.3.3, we’re continuing a “train model” in software development. By fixing the release date and pushing out features that aren’t ready until later, we can deliver the latest versions of stable, upstream Ceph code to Red Hat customers on a faster, more predictable schedule and thereby empower customers to plan their upgrades with greater confidence.

What’s in it?

Red Hat Ceph Storage 2.1 is based on Ceph Jewel v10.2.3. Two new features may be of particular interest to service providers using Ceph as an object store:

  • Static web sites: Allows users to host static content, such as HTML or media objects, in RGW objects and have them served as fully functional web sites.
  • S3 payer-request API: Allows users hosting content to have content requesters pay for the network usage fees associated with delivery. This is well-suited for hosting large binary content without being penalized as the originator of the content.

In addition, users who need to keep a large number of objects in one bucket will appreciate indexless buckets. As the name implies, the Ceph Rados Gateway (RGW) can be configured not to maintain an index, which can significantly increase performance by skipping metadata operations during writes. This new feature is well-suited for situations where applications maintain their own index (as is the case with many web and big data apps). We aim to deliver more enhancements around optimizing large-bucket use cases in future releases.

iSCSI in tech preview

Finally, we’re introducing an initial set of iSCSI functionality for use with Ceph’s Rados Block Device (RBD) as part of the Red Hat tech preview program. By using a Red Hat Enterprise Linux 7.3 host as an iSCSI target, users can map LUNs to kernel RBD images with an Ansible-driven workflow that supports multi-pathing. As we evolve this feature toward general availability, we welcome feedback from users running VMware ESX, RHV, or Microsoft Windows as iSCSI initiators. Customers are encouraged to discuss potential use cases with their account managers.

Lifecycle

The Red Hat Ceph Storage 2 stream is supported until July 2019, and the next minor update is targeted for Spring 2017.