This document summarizes a large fintech company in the Philippines' journey to Kubernetes. It faced challenges of legacy systems, static vs dynamic infrastructure, on-prem vs cloud, and security. It adopted a microservices architecture running on Kubernetes with Docker containers. It started with multiple small clusters but consolidated to a single large cluster with namespace isolation for improved cost and manageability. Automations were implemented for operations. Monitoring and logging were set up with ELK and Prometheus/Grafana. A10 was selected for traffic management and security between services. The final deployment provides north-south load balancing and security and east-west traffic security and visibility between microservices.

1. Reliable Security Always™
K8s Journey of a
Large FinTech
of Philippines

2. 2
Motivation for Change

3. 3
Who is biggest Influencer?
Users
They demand a lot!
And They need it yesterday!

4. 4
It’s not the strongest
of the species that SURVIVE
nor the most intelligent but the one
MOST RESPONSIVE TO
CHANGE.
“ Charles Darwin (1809-1882)

5. 5
APP/IT
TEAMS
NEED
Speed Roll-out
Of Revenue-
Generating
Services
Team Agility
Self-Service
BUSINESS
NEEDS
Data Security
& Privacy
Protection For
Customers
Prevent
External Attacks
& Access Control
Between
Distributed
Microservices
Ease-of-
Operations &
Improved Team
Efficiency
Ensure
Excellent &
Consistent User
Experience

6. 6
Challenges of running at Scale
• Dealing with Legacy (Technical Debt)
◦ Rewrite the application with microservices architecture
• Static vs Dynamic Infrastructure
◦ Select dynamic Infrastructure with K8s
• On-prem vs Cloud
◦ Select cloud but keep portable
• Security
◦ Implement high security because the application deals with monitory
transactions and other sensitive information

7. 7
Kubernetes journey

8. 8
Dealing with various stakeholders
• CISO office
• Developers
• Project Managers
• Network Admins
• Operations Team
• Partners and Vendors

9. 9
Software Architecture
• Every module as microservice
• Clear separation of stateless and stateful
microservices
• Microservices have REST APIs with JSON data
exchange
• All microservices identified by KubeDNS FQDN
• Strict access control of data exchange
between microservices
• No use of cloud specific features to ensure
portability

10. 10
Deployment Architecture
• Microservices are deployed in Docker
containers
• Containers are managed by Kubernetes
• Each group of services is deployed in separate
namespace
◦ Started with multiple small clusters and ended
into single large cluster
◦ A few services are still out of K8s
• Services of different group sending traffic via
Gateway

11. 11
Cluster Design: Multiple small clusters
• Security and compliance require
monitoring traffic between
microservices
• In absence of policy enforcement,
company isolated clusters
◦ Small machines are used
• Pro: Each Team had its own area
• Con: Cost of infrastructure and
management was very high
Kubernetes Node
Kubernetes Node
Kubernetes Node
Kubernetes Node

12. 12
Cluster Design: Single large cluster with namespace isolation
• Separated microservices via
namespaces
◦ Large machines are used
• Controlled traffic flow via
application gateway
• Pro: Optimized cost and
manageability
• Pro: Some E/W traffic info from
app-gw
• Con: Load on app-gw and NW
• Con: Slow response
Kubernetes Node Kubernetes Node
Kubernetes NodeKubernetes Node

13. 13
Operations Automations
Also helps in dealing with failure
• Complete infrastructure remains as code in SCM system (GIT)
• Entire cluster is deployed/destroyed via CI/CD tools (Jenkins and Ansible)
• Support system tools (controllers, log collectors etc.) follow same
principles
• K8s rolling update along with readiness and liveness probe
◦ Entire application is redeployed in UAT on every code commit by any developer
• Sometimes rolling update happen multiple times in a min

14. 14
Monitoring and Log Collection
• Huge ELK deployment in K8s (separate cluster)
collecting logs for every component/service
• Prometheus and Grafana for monitoring
container infrastructure
• A10 Harmony Controller (separate cluster) for
traffic observability

15. 15
Selection of Traffic Management Solution
vs
Kubernetes NodeKubernetes Node
Sidecar Proxy Deployment Hub-Spoke Proxy Deployment
Resource intensive
Expensive TCO
Low overhead
Lower TCO

16. 16
Application Security and Traffic Management
• North-South Traffic
◦ AKAMAI cloud is taking care of SSL offload and WAF
◦ Additional security policies are implemented by A10 Lightning
ADC
◦ A10 Lightning ADC takes care of traffic distribution between
microservices
• East-West Traffic
◦ A10 Lightning ADC works as transparent service proxy
◦ Access control, Mutual TLS and transparent encryption by
Lightning ADC eliminated requirement of external GW
• Harmony Controller provides observability on both N-S
and E-W traffic

17. A10 Secure Service Mesh
This Highly-Scalable Solution Provides the Following Capabilities
o North-south traffic load balancing,
service discovery and application
security
o East-west traffic security and policy
enforcement between
microservices
o Centralised application traffic
visibility and control

18. 18
Final Deployment Diagram
POD
Service-1
POD POD
Service-2 Service-3
POD
Service-1
POD POD
Service-2 Service-3
Node 1
POD
Service-1
POD POD
Service-2 Service-3
Kubernetes
Connector
Harmony Controller
Node 2 Node N

19. Thank You
Reliable Security Always™