Beyond the Checkout: Creating Next-Gen Point-of-Sale Solutions with Continuous Delivery and Habitat

Continuous delivery to your retail environment without refactor? Take a look at a modern application delivery model that fits both legacy and next-gen POS software.

Point-of-sale (POS) systems in 2018 are effectively no different than multi-tiered IT applications from the datacenter or cloud. So why can’t we innovate at the same speed as our mobile teams or other web leaders? Furthermore, we should be able to do this without jeopardizing – in fact, even improving – the security of these mission-critical environments.

In the below presentation, we joined Michael Hedgpeth, Director of Software at NCR to learn about some of the challenges with running software in retail environments across the world. We follow it up with an example of using modern application delivery and lifecycle management approaches to resolve these challenges — regardless of the underlying operating system configuration, hardware characteristics, or network reliability that often adds to retail difficulties.

Habitat is an application packaging tool which does not require virtualization or container run-times, allowing your applications to run without dependencies on system libraries or configuration and resulting in a “clean-room” environment even on aging retail machines. This clean-room approach, combined with modern approaches to lifecycle monitoring and release management, lead to decreased downtime, improved mean time to recover (MTTR) from incidents, and an improved rate of change delivery.

Q&A

It seems like I’m adding another layer of complexity? How difficult is all this to manage?

Because Habitat doesn’t have opinions about what the application is, it means the scope of what needs to be learned becomes simply the core principles and features. This is something that takes about an hour to get familiar enough with to start packaging an application. The effort to learn habitat has a massive ROI when measuring the value added by platform-wide standardization or declaring both library and external dependencies, information about runtime hooks, and artifact driven release management. In an organization where habitat is the de-facto choice for application packaging, a developer working on a kubernetes based microservice can easily read and understand a legacy application’s dependencies and hooks, and vice versa!

Is this like a container?

Habitat doesn’t virtualize or containerize. It is just a framework that allows your application to run from a specific directory on a machine. The framework makes it dead simple to produce a build of your app which depends not on system libraries, but on statically compiled dependent libraries managed nearby in a relative directory to your app. The point is to produce an artifact completely independent of anything installed system-wide. Habitat artifacts can be exported to containers if appropriate. And the explicit dependency declaration means no container bloat, and a crystal clear understanding of exactly what lives on the container.

How is this different from Docker?

Docker is a great tool to manage applications running in containers. Habitat supports exporting applications packaged in Habitat to Docker for use with Docker’s scheduling and runtime utilities. There are some applications out there that cannot or will not (i.e. ISV support) run in Docker containers. You can still take advantage of Habitat’s packaging interface and leverage the Habitat supervisor to run those applications in the same consistent, repeatable and reliable way.

Next Steps with Habitat:

Author Jeff Vogt

Jeff is on the Solution Architecture team at Chef, helping organizations improve the ROI of their automation technology investments through the combination of industry best practices, and by prioritizing work based on business value metrics. Jeff has worked in the enterprise as an automation architect & engineer for the last 12 years.