2017 Microservices Practitioner Virtual Summit: Ancestry's Journey towards Microservices, Containerization, and Kubernetes - Paul MacKay, Ancestry
2 likes1,586 views
Ancestry's journey to Kubernetes emphasizes the transition from traditional deployment methods to using Docker and Kubernetes for microservices. The document outlines the challenges faced in adopting new technologies, the importance of pragmatic service sizing, and lessons learned from early experiments, leading to the establishment of deployment standards and practices. The company has successfully implemented Kubernetes to manage numerous services and namespaces, significantly improving deployment times and operational efficiency.
2017 Microservices Practitioner Virtual Summit: Ancestry's Journey towards Microservices, Containerization, and Kubernetes - Paul MacKay, Ancestry
- 1. Taking the Helm - Ancestry’s Journey to Kubernetes Paul MacKay, Software Engineer
- 2. Our Journey Where we come from. What we have learned along the way. Where we are in the journey.
- 3. Where we come from.
- 4. We’re a science and technology company with a very human mission.
- 5. Data drives our business • 20 billion historical records • 90 million family trees • 10 billion profiles • 175 million shareable photos, documents and written stories • 9 petabytes of data • 4 million members in the AncestryDNA® network • 37 million 3rd cousin or closer matches
- 6. Technologies Microsoft Windows ® C# .NET ® SQL Server®, IIS, MSMQ, TFS, etc. Java, Node.js, Python running on Linux Private data center 1,000s of servers/VMs running 100s of services REST-based macro to micro size services
- 7. Deployment Processes Continuous integration/deployment Deployment management tools Virtual Machines Typically one (macro/micro) service per VM Long deployment times to roll services to production 20-50 minutes
- 8. How Our Journey Started to Change Began experimenting with Docker. Docker Compose Created a “Docker agent” for remote deployment. Demonstrated how easy it is to deploy and scale up services. Deployment times drastically reduced from current methods. Easier to deploy services of any size (macro to micro) Showed greater density using current computing resources. Created and deployed our own micro services using Docker.
- 9. What we learned along the way.
- 10. Adopting New Technologies is Hard Developers are comfortable with how things are done today. We think it is faster doing it the “old” way. It is hard to see the advantages of changing to something new. Change has real cost. Change takes time away from developing new features. Change is disruptive to schedules.
- 11. Early Discoveries Many opinions about the appropriate size of a service. Normal Linux distros are just too big. Not specifically built for Docker. Too large of a footprint. Too many packages to keep updated. Docker is best supported on newer Linux kernels. Need to train Windows developers Linux concepts/tools. The size of a service cannot be dictated Container orchestration is hard to do it right.
- 12. Adopting New Technologies or Paradigms Understand current technologies, processes and paradigms. Need a “patron”. Own something “to be real”. Create a partnership with pilot teams and be agile.
- 13. Determining the Size of a Service Be pragmatic; do not break up a service just to break up a service. Remember the cost of managing many services. Network latencies Many things to worry about (e.g. monitoring, coordinated deployments, scaling) Ask, “will this really be used independently by other services?” Does it make sense for the service to exist by itself Be pragmatic, not dogmatic.
- 14. Linux Built for Containers Running containers is a first-class citizen Updates are holistic Can be automatically pushed to machines. Can easily revert back to the previous version. Less is more Fewer packages means fewer vulnerabilities Infrequent need for direct access to the machines
- 15. Kubernetes to the Rescue Created a small ”sandbox” cluster. Gathered “committed” pilot teams. Daily standups Address problems/concerns early Provided Docker and Kubernetes training Developed templates and scripts
- 16. Where we are in the journey.
- 17. Conventions/Standards Developed deployment standards Namespace for each service Naming conventions (functionalGroup-serviceName) One container per pod Start with wide privileges and narrow as needed Allow deployment all the way to production Secrets are controlled by operations/security Separate clusters for each environment (dev, stage, prod) Use intra-cluster DNS for micro-services to reduce network latencies
- 18. Production Environment Private Registry (Quay Enterprise) Monitoring (Prometheus) Logging Custom cluster-wide log forwarder Namespace Portal Authorization (webhook) Require soft resource quotas
- 19. Quick Start Tools Created tool to help teams quickly deploy Works across all cluster environments Provide ”best practices” and conventions Transparent – can generate standard resource files Created scripts to insert secrets into namespaces Labels are used to version secrets Cluster backup/restore scripts Scripts to easily create clusters in various environments Allow easy deployment of any size of service
- 20. Our Journey So Far Several clusters Private data center and in the cloud Hundreds of namespaces and services Hundreds of pods Macro to micro size services Live production traffic e.g. “We’re Related App” Made up of 14 micro services Easiest deployment path for developers
- 21. The Power of Kubernetes Programmers have REPL (Read-Eval-Print-Loop) Kubernetes now gives us CDEL (Compile-Deploy-Execute-Loop)
- 22. Unlock your past. Inspire your future
- 23. Questions