Splitit Cuts Failed Deployments by 45% With Komodor

About Splitit

Splitit [ASX: SPT] enables e-commerce merchants to offer interest-free monthly installment payments to their customers at the point of sale.

Customers do not have to apply for a new credit line or qualify for a new credit card. Splitit works on their existing credit cards so customers also enjoy all of their regular credit card benefits such as points, cash-back, and mileage.

For businesses, having this additional payment option can mean increased conversion rates, higher average tickets, increased customer satisfaction, and reduced barriers to purchase.

The Challenge

Splitit has hundreds of customers, processing millions of transactions each day. It is also a fast-paced and agile cloud-native company that requires a streamlined CI/CD pipeline, and a robust monitoring stack, powered by a ‘best of breed’ toolset.

They needed a solution that would help them further increase the speed and frequency of their deployments, without causing additional issues. They were also looking for a tool that would fit their shift-left approach and help more developers to troubleshoot deployment issues.

The Problem

Splitit’s engineers use Jenkins for CD and NewRelic for monitoring. However, the DevOps team required deeper visibility as they occasionally experienced buggy deployments that caused issues in production, but appeared to be successful on the Jenkins dashboard.

From the team’s perspective, they saw crashed pods but couldn’t correlate the pod status to any deployment failure, since these were ‘invisible’ to them. They wanted to alert the relevant teams when a deployment failed, and quickly pull pod logs after they crash for a deep drill-down.

The Solution

Komodor complemented Splitit’s existing stack with enriched data and a unified platform that aggregated all troubleshooting metrics. This enabled Splitit to:

1. Track all deploys and monitor their individual impact on pod health status. When a deployment failed, Komodor immediately alerted the relevant team via Slack and provided a link to easily access relevant pod logs. Making it easier for them to quickly understand and remediate the service health issue.
2. View historical data about deployments and health issues, which helped conduct a comprehensive postmortem and identify repeated problems, thereby preventing them from occurring.
3. Easily observe & comprehend the health status of microservices and pods in the cluster, promoting a holistic understanding of the Kubernetes environment. This encouraged developers to independently troubleshoot K8s issues without involving additional middlemen or escalating up the flagpole.