How Postman adopted Docker
Download as PPSX, PDF2 likes762 views
Postman, utilizing Docker since early 2017, adopted a centralized and standardized approach for their microservices architecture to improve operational flexibility and reduce overhead in deployments. Their strategy involves using a common base image for all applications, facilitating a seamless integration of code through CI processes, and ensuring zero downtime during deployments. The document emphasizes the importance of starting with Docker to unlock long-term value and suggests keeping individual Docker files in source code while enhancing security and logging configurations gradually.
How Postman adopted Docker
- 1. least friction and overhead to getting started and adopting docker in production
- 2. About Postman 3+ million users 1.5+ million mau 30+ member team
- 3. Our Stack 25+ micro services 10+ mill peak req/hr 140+ gb in/day nodejs docker jan 2017
- 5. early adopters late 2014 ⇢ small team ⇢ frugal operations early goal was to ship and validate and spend less time on operations
- 6. why docker? cloud is vm ⇢ no chef/puppet expertise ⇢ exactness since cloud is a VM in some form, no guarantee that VM based system will work if a startup needs to switch cloud provider
- 7. operational flexibility centralised (hub) ⇢ code coupled ⇢ maintainable ⇢ unobtrusive common base image for all applications image per application is stored alongside code docker image file is treated as code (goes through PR, etc) common server setup and standardisation is moved to base image and remaining overrides to per-service image å
- 8. developer prepares code and environment ci tests code using centrally inherited image image is orchestrated into production services
- 9. zero downtime hot reboot ⇢ live deployments ⇢ live rollback no need to reboot entire server build and deploy applications as a secondary image and then swap
- 10. auto instrumentation log stream (volumes) ⇢ system tuning written once in base image and then re-used across all services
- 11. public network segment private network segment server 1 server 2 server n load balancer orchestrator public network segment private network segment server 1 server 2 server n load balancer orchestra service one service two communication bus | shared resources | service discovery and registration we use Beanstalk for orchestration and conceptually this can be Kubernetes or anything else
- 12. production emulation faster debugging ⇢ portable configuration (env) any system (even a local machine) can be connected to any load balancer and hence facilitate debugging
- 13. security surface centrally controlled ⇢ managed updates
- 14. Summarising • Just “choose” docker to get started (even if using minimal features) and see value in long run • Start using docker in deployment keeping individual docker files in source code. • Use a single source image (to inherit from) for all deployments • Configure security, logging and other basics in the source environment and keep on improving it.
- 15. our window to developer freedom
- 16. fun and freedom billing notification ⇢ team setup ⇢ one-click docker do not bother how much cost your team is raking up until s**t hits the roof once the service has been tested here (or locally), we move it to production instances in AWS
Editor's Notes
- #2: - shamasis heading engineering at Postman skeptical to talk, in this highly technical setup, many may walk away but thanks aditya maybe our real world use case will get you started and solidify starting off with docker or migrating to it for long-term benefits
- #3: Postman is an API Development tool helping build apis collaborate on api development continuously test publish APIs
- #6: as a small team we had to be efficient we had to focus / refocus based on direction where our ecosystem takes us wanted to create value and not spend time over-engineering or cleaning early tech debt being on js, we wanted to leverage Node ecosystem and as such also faced the downsides of it
- #7: we knew that we might have to switch cloud provide none of us were super expert with chef/puppet (good thing) and we knew that we needed freedom as we grow we knew that as a small team, we wanted to ensure exactness of system
- #8: we have a common operations stack for all our micro services this helps us re-use components from all services and push common changes across stack unobtrusive to developers until they want to add something to the stack
- #10: with realtime needs, downtime impacts the org it is difficult to ensure minimal downtime
- #11: common aspects of the stack is built in microservice owners have their own layers that is later federated
- #12: stack is simple simple at large scale is a different kind of simple 1 bn+ log lines per day
- #13: we run tests in production environment to ensure reliability canary testing
- #14: - managing central aspects