hands-coffee-smartphone-technology.jpg

Kubernetes: The Bet Pays Off

July 22, 2019

Ramping up a business is always a challenge. In 2016, we decided to rebuild our backend architecture in order to support the scale and maturity we knew we would need down the road. We evaluated a number of platforms and decided to go with Kubernetes based architecture.  The decision was a bit of a gamble since the Kubernetes project was in its early stages as well. 

We’re pleased to say that our wager paid off: Our backend cluster handles hundreds of thousands of concurrent sessions without a hitch, providing friction-free worldwide real-time fraud detection solutions that continuously analyzes and verifies users’ behaviors and activities.

Choosing Kubernetes, or K8s, was an important decision, reflecting both our vision for SecuredTouch and our confidence in K8’s approach to containerized microservices architecture. Let's take a look at our thought processes as we made this critical decision.

Read More: The Secret to Reducing Transaction Abandonment

 

Deciding on K8s

After winning an important funding round, we began to focus our development efforts on what would be needed to take our company forward. One of our most important decisions was about system architecture. We knew it was time to replace our “one-man-show” Java-based Monolith  backend with something more robust that would enable us to build a mature product and to handle large scale customers. 

Specifically, we wanted a solution that supports the following:

  • ~ 100 million users
  • “Five 9s” (99.999%) availability
  • On-Premise deployment as an option  
  • Would not force us to fork the architecture in order to support on-premise deployment (i.e. single architecture for both Cloud and On-Premise)
  • Horizontal scaling (adding more machines & services, as opposed to increasing a machine’s power)
  • Keeping Java as the main backend stack
  • Supporting future Python modules

On the whiteboard, it looked something like this:

unnamed

As we developed our ideas, we decided to use containers, rather than deploying our application on a host. It was important for us to take advantage of containers’ many advantages, especially their support of smaller, faster, and more portable virtualization. Once we decided on using containers, we needed to choose an orchestrator. After researching the possibilities, our short list included Kubernetes, Docker Swarm, and Mesos. 

We decided on K8s because of the company’s rapid internal development, the platform’s wide range of features, including support for on-premise deployment, and scalability - and the fact that Google was backing it didn’t hurt either.

 We finally decided on the following architecture:

  • K8s-based architecture
    • On-premise support
    • Did not lock us into a specific cloud
    • Scalable 
  • Microservices 
    • Started with Java, based on the existing codebase
    • Later, added Python and nodeJS services 
  • Idempotent event-based
    • No duplication of records
    • Support for dynamic scalability and high availability

After benchmarking and selecting the relevant middleware, we reaffirmed our decision to make K8s an orchestrator of SecuredTouch’s complex architecture. This does not mean we didn’t have any questions. At the time, there were not enough production-grade K8s case-studies for us to learn from as we would have liked. In fact, support for some key features were missing or in alpha or beta testing, including stateful components support (e.g., database, event bus, and others), deployments, and ingress. Despite these complications, we deployed our first production K8s cluster in early 2017, running K8s version 1.4. 

We'd Love to Show You How We Prevent eCommerce Fraud- Schedule a Demo Today!

Three Years Later 

Fast-forward to 2019:  We’re running all of our production environments on Google Cloud Platform Kubernetes Engine, successfully operating at scale, serving hundreds of thousands of concurrent sessions, on average, worldwide. Getting the most out of K8s was a learning process for all of us, with plenty of trials and errors. 

Along the way, we had our share of iterative improvements and our strong engineering team moved in parallel with K8s; from replication-controllers to deployments, from nginx based daemon-sets to ingress, using K8s CronJobs etc. 

Looking back, it’s clear we made the right decision in 2016. Kubernetes has more than met our expectations; based on it, we built a solid, robust platform that will support SecuredTouch’s needs for the foreseeable future. With this solid architecture supporting us, we can focus on doing what we do best: turning fraud detection into a business enabler. 

Recent Posts

An eCommerce Showdown: Account Takeover VS Behavioral Biometrics
Breaking Down Fraud Flows: Credential Stuffing
The Rising Fraud Tsunami: Account Takeover
Is Loyalty Fraud the Latest eCommerce Nightmare?
You Heard It Here First: The Inside Scoop Into Transaction Fraud Prevention

Follow Us