This document discusses Lithium Technologies' journey to transitioning their monolithic application architecture to microservices using containers and Kubernetes on OpenStack. Some key points: - Lithium decomposed their monolith into microservices deployed in containers for simplified packaging and deployment to the cloud. - They chose Kubernetes to manage containers due to its support for Docker primitives, little engineering effort required, and ability to fill gaps left by OpenStack. - By containerizing services incrementally, focusing on complex ones first, they were able to improve code quality, deployment options, and spend more time on features rather than infrastructure.

1. Decomposing Lithium's Monolith
with Kubernetes and OpenStack
Lachlan Evenson
Cloud Platform Team Lead
@LachlanEvenson

2. Agenda
▪ Share our journey to container-based
microservices.

3. About Lithium Technologies
▪ Our platform helps brands connect, engage
and understand their customers.

4. Containers, VMs and OpenStack
▪ The issue is not Containers vs VMs
▪ Honestly - our engineering team couldn’t
care less
▪ It’s about the right tool for the job
▪ When to use which one?

5. How was the cloud being consumed
▪ Had we delivered on the promise of the
cloud?
▪ Containers offered the promise of simplified
packaging and deployment to the cloud
▪ Developer lead

6. Should you split the monolith?
▪ What did the monolith actually provide?
▪ All new services to be deployed using and
end-to-end container pipeline

7. Getting off the ground
▪ Be incremental
▪ Do not boil the ocean

8. You can’t containerize everything
▪ That’s a myth but consider what makes
sense
▪ Not just for “stateless” web front-ends
▪ Developers asked us to containerize the
most complex microservices first

9. Why Kubernetes?
▪ Little engineering effort and no additional
capex
▪ Docker primitives
▪ OpenStack filled the container gaps
provided a platform to innovate

10. Why Kubernetes cont.
▪ Cross cloud-platform support
▪ Use AWS and an AZ
▪ How did we deploy?
• AWS CloudCoreo - http://bit.ly/1M15vHB

11. The implications of running containers
▪ Demands that you rethink everything
• Logging
• Monitoring
• Secrets, config management
• Try not to create container anti-patterns

12. The results
▪ Time spent on infra versus features
▪ Single automatable pattern including CI/CD
▪ Infrastructure tools could follow the same
pattern
▪ AWS even acknowledges the problem

13. The results cont.
▪ Higher code coverage
▪ Smaller PRs
▪ Complex deployment options have been
simplified
▪ Canary releases and Rolling-upgrades and
Rollbacks

14. Thank You
@LachlanEvenson