Skip to content
All posts

The Farewell Brew: Saying Goodbye to Briggo

DALL·E 2024-09-10 10.26.21 - A vibrant and futuristic landscape hero image for a blog post about saying farewell to a futuristic coffee machine and cloud software system. The BRIG

It was almost six years ago when Scott Snyder invited me to the Briggo offices to talk about a development project.

“The coffee machines at the airport?” I had asked when he said he worked for Briggo.

How was I to know then how deep down the robotic coffee rabbit hole we would go? Here we are almost seven years and some amazing transformations of a sophisticated mobile, cloud, web, and IoT system later and it's time to say goodbye.

The first project was pretty limited - they wanted help implementing a new UI design. One to replace the wood paneled hexagon aesthetic inspired by founder Chas Studor’s grandfather’s machine shop.

briggo-wood-panel

That project went from pure development to managing the UX project, then managing the backend development, then to redesigning and operating the software infrastructure and beyond. We were all-in on Briggo through the highs and the lows, and we stayed in the boat through their acquisition by Costa Coffee. We met, worked, argued, drank beer, drank coffee, mindlessly chatted during 2 AM software releases, and got to know a lot of truly great people.

briggo-team

But this week, after years of tireless continued service, it’s time to bid farewell. The last remaining kiosks of our beloved Briggo system have been retired and removed from the Austin Airport and 3M. And as we wave goodbye to this caffeinated cacophony of cogs and computing, I’d like to reflect on some of the things that our SevenPico crew accomplished in service of the team at Briggo. Being a legacy system take-over, I will put this in the context of our methodical approach to taking over legacy systems.

Stabilize

Job one is always to stabilize the system. We had good familiarity with the functionality of the backend from our work on the user interface but knew very little about how it was designed, built, or deployed. First, we redesign and rebuilt the underlying AWS infrastructure using Terraform, giving us firm command of the infrastructure and an ability to deploy multiple environments, e.g. development, qa, beta, and production, in a repeatable and reliable way.

Next we turned to the application build, which had up to that point been done manually by connecting to the running instances, pulling the latest code, and executing build commands. We abstracted the secrets and environment variables to AWS and implemented Docker builds for the artifacts. We also broke the deployment up into three pieces, representing different functional components of the system, from a single monolithic build and deploy.

Finally, we put some energy into the database, specifically implementing automated backups and database change management with Liquibase to give us better control over schema versioning, easier management of database fixtures, and, crucially, the ability to reliably rollback deployments.

briggo-borgia-spice

“One does not simply ENJOY a Borgia Spice Latte”

Make It Easier to Operate

One of our key goals when modernizing the legacy system was to streamline operations for both engineers and system administrators, since we were filling both roles on the project. To achieve this, we implemented several critical improvements:

  • Automated Build and Deploy: By introducing continuous integration and deployment (CI/CD) pipelines, we automated the build and deployment process. This not only reduced human error but also ensured faster, more reliable updates to the system.
  • Live Deployments with Zero Downtime: We re-engineered the deployment architecture to support live deployments without bringing the system offline. This allowed us to introduce new features and fixes seamlessly, ensuring uninterrupted service for users.
  • Content Management and Admin Tools: A user-friendly content management system (CMS) and admin dashboard were developed, making it easier for non-technical teams to manage content and settings without needing to rely on engineers.
  • Observable System: We built in robust observability, ensuring that every component of the system was transparent and easily monitored. Engineers could quickly trace issues, optimize performance, and maintain system reliability with comprehensive logging and analytics tools.

These improvements significantly enhanced the operational efficiency and scalability of the legacy system, allowing our team to focus more on innovation and less on maintenance.

Pay Down Technical Debt

The most significant piece of technical debt in the system was a continuously deferred migration from Python 2 to Python 3. It had been viewed as risky due to lack of deep knowledge of the deep inner workings of the system and limited resources to dedicate to migration, testing and validation. But we reached a point where we could defer it no longer. This effort resulted in a much deeper understanding of the system design and forced replacing some dependencies and implementations. More importantly, however, it forced the implementation of a more rigorous QA and testing strategy.

The other big effort was transitioning from the risky PCI exposure of magstripe readers to a more secure payment process by integrating Stripe for auth and capture. This upgrade enhanced security, reduced fraud risk, and enabled seamless, contactless prepaid pickups. By leveraging Stripe’s infrastructure, we minimized PCI compliance concerns while providing a safer, more efficient payment experience for our users.

Modernize

With the hard work done we were able to turn to the fun stuff! One of the main reasons we’re committed to AWS, not just as cloud infrastructure, but as an application platform, is the ability to rapidly introduce new functionality, through managed services or through application development tools like AppSync and StepFunctions. Here are a few of the fun things we were able to accomplish:

  • Operating cost streamlining: Once we had a better sense of how things were operating and had stabilized the system, we were able to identify a number of areas where we could reduce some of the operational costs of the AWS system itself. The two most significant were right-sizing all the instances and managed services like database, and right-sizing the number of application environments we were managing (e.g. dev, staging, qa, beta, production).
  • Incident management with AWS: Later in the project, once we had tooled the system with CloudWatch alarms and alerts in Slack we implemented an incident management process using the AWS Incident Manager which is part of the Systems Manager package. It’s not as full-featured as things like PagerDuty, but it’s well-integrated with CloudWatch alarms so it was easy to get automated incident creation running right away, and it provides typical on-duty, on-call, contact point, and escalation features.
  • Themeable apps: One of the requirements during the acquisition by Costa was to be able to easily theme all of the user interfaces. Implementing a theming system onto the applications was a fun project that allowed us to turn around design change requests very quickly - sometimes in a matter of minutes - to impress both existing and new management.
  • Touchless payments: And who can forget the heady days of 2020 when the world went touchless! We implemented a novel touchless approach that didn’t require an app installation but still allowed customers to use the tap payment terminal on the machine.

By this point we had a rock-solid system that ran for years with very little maintenance and need for oversight. We rarely had issues with the cloud system and on those occasions our ability to quickly identify root causes and remediate kept the coffee flowing freely!

The Story Continues: Costa Coffee

Thankfully this is not the end of the Briggo story. Although the original machines and software system have been retired, the legacy lives on in Costa Coffee with all new machines and software systems in place.

We were fortunate enough to have a hand in the concept, design, implementation, and for a while the leadership of the new software systems. Here are a few of the things additional things we’ve done in service of that project:

  • Domain driven design
  • Modular domain model
  • Event driven architecture
  • Microservices architecture
  • Observable infrastructure and system
  • Remote machine API
  • Remote machine monitoring
  • Remote machine software deployment and maintenance

And so, we say goodbye. Briggo’s retirement is a victory lap. We’re incredibly proud of how far we brought it, and we’ll carry those lessons into the future. The new system will have big shoes to fill, but it’ll also stand on the shoulders of everything we learned from our trusty old friend.

So here’s to Briggo. We’re going to miss your quirky codebase. You were more than just a coffee maker—you were a testament to our team’s ingenuity, determination, and the power of a good cloud infrastructure.

briggo-final-cup

We’ll miss you, Briggo. Thanks for all the caffeine.