Americas

  • United States

Lufthansa Systems taps Portworx for stateful containers

News Analysis
Jun 27, 20174 mins
Data Center

The storage issues around containers are real. Portworx gets a high-flying customer to justify their existence.

When Docker first (re) popularized the use of container-based infrastructure, there was a bit of discussion around the storage problems related to containers. Two startups came into being to try and resolve the issue: ClusterHQ and Portworx.

While ClusterHQ flamed out, Portworx is still going strong and today announced a high-profile and interesting case study.

To clarify exactly what Portworx does, users can use it to manage any database or stateful service on any infrastructure using any container scheduler, including Kubernetes, Mesosphere DC/OS and Docker Swarm. Portworx solves the five most common problems DevOps teams encounter when running containerized databases and other stateful services in production: persistence, high availability, data automation, support for multiple data stores and infrastructure, and security. As such, Portworx technology is ideally suited for solution verticals such as databases, messaging queues, continuous integration and continuous deployment (CI/CD), big data, and content management. 

Anyway, getting back to that customer story: Lufthansa Systems, a subsidiary of the eponymously named airline, was having issues around data persistence when it came time to spawn their content management systems. This was a core requirement for its BoardConnect in-flight entertainment (IFE) and connectivity product. And, as we all know, hell hath no fury greater than a business-class passenger whose IFE isn’t working!

With new IFE user cases, such as persistence between flights for individual customers, and the ability to flow IFE preferences between the in-seat product and customers’ own mobile devices, there was a need to look for an IT infrastructure that gave Lufthansa more flexibility.

Enter DevOps

Container-based development allows Lufthansa Systems to speed up the overall development lifecycle. In addition, it allows teams to harmonize the orchestration of applications—their deployment and management—as the number of applications increases, which occurs naturally and fluidly in following a microservices-oriented approach. Orchestration is within reach when the Lufthansa Systems team can achieve flexibility in container persistence.

BoardConnect is designed with microservices in mind, and it runs in Docker Swarm environments. Lufthansa increasingly found that the BoardConnect team was building infrastructure around microservices and containers and having to bridge development and operations—the organizing principle of DevOps. As they saw the benefits of DevOps materialize, the team identified a missing link: data persistence. The team found that data persistence was still a legacy issue.

Lufthansa Systems’ CMS allows it to customize BoardConnect to suit the needs of the company’s diverse airline customers and partners. Content management systems, by their nature, follow a traditional persistence paradigm, such as saving data to disk or to a database. When IT wants to auto-instantiate those CMS environments on developer-committed projects or manage customers’ individual CMS production instances, the need for proper Docker orchestration surfaces.

Portworx to the rescue

Lufthansa Systems selected Portworx’s PX-Enterprise product to resolve the persistence issues. The key use cases that Lufthansa had, which pointed them in the direction of Portworx, were as follows:

  • The need to factor in storage or cloud vendor dependencies, which would contradict the desired universal applicability of a container persistence solution they were striving for
  • A requirement to decide ahead of time the type of storage the platform would use

The operational results

Lufthansa’s Michael Wilmes, a software architect on the project, explains the outcome:

“With Portworx PX-Enterprise, we can now spawn full-blown CMS environments in a matter of minutes—versus hours in the past—without requiring manual intervention,” he said. “For production, it further allows our operations to move CMS environments around in the cluster, and the corresponding data ‘follows along’ transparently. Once Portworx was set up in the Docker cluster, the overhead of managing stateful containers became virtually zero.”

benkepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. His business interests include a diverse range of industries from manufacturing to property to technology. As a technology commentator he has a broad presence both in the traditional media and extensively online. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the cloud. His areas of interest extend to aviation technology, enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

He is a globally recognized subject matter expert with an extensive following across multiple channels. His commentary has been published on Forbes, ReadWriteWeb, GigaOm, The Guardian and a wide variety of publications – both print and online. Often included in lists of the most influential technology thinkers globally, Ben is also an active member of the Clouderati, a global group of cloud thought leaders and is in demand as a speaker at conferences and events all around the world.

As organizations react to the demands for more flexible working environments, the impacts of the economic downturn and the existence of multiple form-factor devices and ubiquitous connectivity, Cloud computing stands alone as the technology paradigm that enables the convergence of those trends -- Ben’s insight into these factors has helped organizations large and small, buy-side and sell-side, to navigate a challenging path from the old paradigm to the new one.

Ben is passionate about technology as an enabler and enjoys exploring that theme in various settings.

The opinions expressed in this blog are those of Ben Kepes and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author