Using Containerization to Enable Your Microservice Architecture
•
1 like•870 views
Presentation from the technology track at I Love APIs London 2016 featuring Greg Brail, Apigee and Jonathan Bennett, Zooz With the meteoric rise of microservices and many organisations such as Amazon, Netflix and others praising them for their driving parts of their success, delivering microservices in a stable, consistent and managable way in the enterprise ways customers have come to expect is becoming more important than ever. This session discusses the perceived benefits and efficiency gains from delivering a microservice achitecture, lessons learned from migrating and running a microservice architecture within application containers along with practical examples of how to enable fast application deployment using containers.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Using Containerization to Enable Your Microservice Architecture
Similar to Using Containerization to Enable Your Microservice Architecture (20)
More from Apigee | Google Cloud
More from Apigee | Google Cloud (20)
Recently uploaded
Recently uploaded (20)
Using Containerization to Enable Your Microservice Architecture
- 1. 1 Using Containerization to Enable Your Microservice Architecture! Jonathan Bennett, Zooz Greg Brail, Apigee
- 2. Have you Heard of Docker?
- 3. Have you Heard of Docker? 3 ©2015 Apigee. All Rights Reserved.
- 4. What are Containers? • Just lighter-weight virtual machines, right? • Not exactly? 4 ©2015 Apigee. All Rights Reserved.
- 5. Virtual Machines Separate kernels (any OS) Separate device drivers Memory isolation Filesystem isolation CPU usage restrictions Boots in minutes Tens per physical machine Containers Shared Linux kernel Shared device drivers Memory isolation Filesystem isolation CPU usage restrictions Boots in seconds Hundreds per physical machine Virtual Machines vs. Containers 5 ©2015 Apigee. All Rights Reserved.
- 6. Virtualization O/S-level isolation Proven; Secure; Resource-intensive Containerization Process-level isolation Fast; Compact; Developer-friendly Virtualization vs Containerization 6 ©2015 Apigee. All Rights Reserved. Hardware Device Drivers Hypervisor Kernel Filesystem O/S Daemons App App Kernel Filesystem O/S Daemons App App Hardware Device Drivers Filesystem O/S Daemons App Kernel F/S App F/S App F/S App F/S
- 7. What is Docker? • Built on core Linux stuff • CLI • API • Layered filesystem • “Docker Hub” of images 7 ©2015 Apigee. All Rights Reserved. By User:Maklaan (Based on a Docker blog post) [Public domain], via Wikimedia Commons
- 8. Docker Usability Let’s start up Cassandra, Zookeeper, and Postgres on a host… docker run –e POSTGRES_PASSWORD=realsecret –d 5432:5432 postgres docker run -‐d -‐p 2181:2181 -‐p 2888:2888 -‐p 3888:3888 jplock/zookeeper:3.4.6 docker run -‐d -‐-‐net=host -‐p 9160:9160 -‐p 9042:9042 -‐p 7000:7000 -‐p 7001:7001 -‐p 7199:7199 -‐e CASSANDRA_LISTEN_ADDRESS=192.168.99.100 -‐e CASSANDRA_BROADCAST_ADDRESS=192.168.99.100 cassandra:2.0 8 ©2015 Apigee. All Rights Reserved.
- 9. What Makes Docker Exciting? • Standard packaging format – Docker image may be run on any Docker-enabled host • Each container is self-contained – Container has its own filesystem and files – Contract specifies ports and persistent disks required – Not much else – Vastly less “versionitis” • Standard installation process – Specifics of packaging and installation are inside the container • Less “versionitis” 9 ©2015 Apigee. All Rights Reserved.
- 10. The Real Promise of Docker • Start with those standardized containers • Deploy them to an elastic pool of hardware • Scale them up and down • Switch versions without downtime • Wire them together and to the Internet via APIs • and more… 10 ©2015 Apigee. All Rights Reserved.
- 11. Who I am Jonathan Bennett VP Architecture & Data @ Zooz @jldb http://me.jldb.co.uk/linkedin http://me.jldb.co.uk/github 11 ©2015 Apigee. All Rights Reserved.
- 12. Who we are Online Payments Platform bringing together many financial institutions, integrating acquirers, gateways, 3rd party solution providers all through a single integration 60 Employees in 3 locations, USA, UK and Israel 1000s of merchants globally, trading 24x7 12 ©2015 Apigee. All Rights Reserved.
- 13. A brief history of us Started as a “Pay at Table” restaurant service… Pivoted to single-line integration checkout… Pivoted again to API driven platform 13 ©2015 Apigee. All Rights Reserved.
- 14. Our code base… 14 ©2015 Apigee. All Rights Reserved. Tactus Tactus+ Tactus+++++++
- 15. And this is what we ended up with… 15 ©2015 Apigee. All Rights Reserved. Tactus.ear
- 16. Something needed to change… 16 ©2015 Apigee. All Rights Reserved. Source: https://ruxit.com/
- 17. The challenge Strict security requirements due to Level 1 PCI Strict “no downtime” policy for API services Lots of legacy code across the system which was hard to diagnose and find problems Large parts of testing not automated - long regression test period (frequently 5 business days) Deployments to 10 app servers took over 8 hours. 17 ©2015 Apigee. All Rights Reserved.
- 18. Our customers Internal R&D teams “We need to build faster” QA teams “We need to test faster” Infrastructure & operations teams “We need to test faster” 18 ©2015 Apigee. All Rights Reserved.
- 19. Things we tried Agile will solve all of the problems. AUTOMATE ALL OF THE THINGS! 19 ©2015 Apigee. All Rights Reserved.
- 20. “Traditional” Continuous Integration The single .ear file deployment was cumbersome and impossible to properly introspect Large amount of running infrastructure with large overlap 20 ©2015 Apigee. All Rights Reserved.
- 21. Just break it up Tactus was broken down into “components” A spewing of libraries, “common.jar” and overlap happened Everything still compiled into “tactus.ear” in the end 21 ©2015 Apigee. All Rights Reserved.
- 22. 22 ©2015 Apigee. All Rights Reserved. https://ilovemicroservices.com/ Microservices
- 23. Microservices, a primer… • API Services are created around specific capabilities, such as front ends, proxies etc • Typical Microservice orientated architectures may comprise of many different languages • Architectures tend to be of a producer / consumer model • Tends to work well in continuous development environments Main criticisms: • Shifts the complexity from a monolith to other things, such as network, Load balancing and fault tolerance (Basic distributed computing problems) • Deployment gets more complicated (as we’ll discuss later) 23 ©2015 Apigee. All Rights Reserved.
- 24. µ all of the things Took the basis of our common libraries and rationalised our codebase Approached the project like an onion - taking layers off gradually - approaching the core as we speak 24 ©2015 Apigee. All Rights Reserved.
- 25. Our steps 1. Instated martial law on “old ways of working for new projects” - introduced bounties to those who turned others in (for fun, of course…) 2. Refactored API Façade to be a service layer above other system APIs transparently to customers 3. Moved onto new processor code (business logic and API integrations) 4. Refactoring internal APIs last 25 ©2015 Apigee. All Rights Reserved.
- 26. Our new architecture 26 ©2015 Apigee. All Rights Reserved.
- 27. Deployment considerations Managing / monitoring / scaling this many “application servers” would be a nightmare Servers needed to be identical for predictability All deployment should be automated, and scaling should be instant 27 ©2015 Apigee. All Rights Reserved.
- 28. That’s where containers came in Resource and process isolation Quick to start with little system overhead Predictable - build once use everywhere (even for QA!) 28 ©2015 Apigee. All Rights Reserved.
- 29. Main considerations Monitoring - A 24/7 system needs substantial monitoring Deployment - We need to be able to deploy quickly - Need to be able to deploy reliably - Need to move towards continuous deployment 29 ©2015 Apigee. All Rights Reserved.
- 30. What we look like now 30 ©2015 Apigee. All Rights Reserved.
- 31. What we learned 31 ©2015 Apigee. All Rights Reserved.
- 32. 32 “If I had asked people what they wanted, they would have said faster horses.” - Henry Ford
- 33. Get a scheduler Finding a scheduler that works for us will be the key to our continued microservice-with- container success Experimented a lot, Lattice, Kubernetes, ECS and now running experiments with Nomad 33 ©2015 Apigee. All Rights Reserved.
- 34. More emphasis on monitoring Emphasis on monitoring tightly coupled with the container integral to continued success 34 ©2015 Apigee. All Rights Reserved.
- 35. More automation 35 ©2015 Apigee. All Rights Reserved. If you haven’t already automated - make it a priority
- 36. Blue/green deployments as a standard Increase in speed of deployment gives more flexibility for partial deploy (and rollback) Found problems in minutes that would usually surface way too late 36 ©2015 Apigee. All Rights Reserved.
- 37. Conclusions • Microservices are awesome • Containers help with not only the running of the applications, but also the delivery process as well • Great schedulers are coming – finding one ASAP will be key 37 ©2015 Apigee. All Rights Reserved.