Successfully reported this slideshow.
Your SlideShare is downloading. ×

Future of Microservices - Jakub Hadvig

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
Open shift 2.x and MongoDB
Open shift 2.x and MongoDB
Loading in …3
×

Check these out next

1 of 40 Ad

Future of Microservices - Jakub Hadvig

Download to read offline

Poďme sa porozprávať prečo sú najväčší poskytovatelia webových služieb tak úspešný, aké technológie používajú, čo sú to tie mikroservisy a ako do toho všetkého zapadá nový OpenShift 3.
Jakub je vývojár OpenShift platformy, open-source nadšenec, ktorý okrem programovania v rozličných jayzkoch ako Go, Ruby, JavaScript nemá problém ani s grafikou a designom.

Poďme sa porozprávať prečo sú najväčší poskytovatelia webových služieb tak úspešný, aké technológie používajú, čo sú to tie mikroservisy a ako do toho všetkého zapadá nový OpenShift 3.
Jakub je vývojár OpenShift platformy, open-source nadšenec, ktorý okrem programovania v rozličných jayzkoch ako Go, Ruby, JavaScript nemá problém ani s grafikou a designom.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Future of Microservices - Jakub Hadvig (20)

Advertisement

Recently uploaded (20)

Future of Microservices - Jakub Hadvig

  1. 1. Future of Microservices Jakub Hadvig OpenShift Engineering
  2. 2. Microservice ?
  3. 3. Microservice ● Software architecture ● Application composed from processes ○ small and independent ○ single purpose ○ replaceable ○ isolated
  4. 4. Microservice ● Software architecture ● Application composed from processes ○ small independent processes ○ single purpose ○ replaceable ○ isolated
  5. 5. Linux Containers (LXC) ● Virtualization on a operating-system level ● Single Linux host = multiple isolated Linux system ● Containers run with host kernel (fast) ● Microservices = Containers
  6. 6. Microservices redefine the “App” ● Networked components wired together ○ Not just a “web frontend” anymore ○ HTTP frontends are just one type of component ○ Make it easy to build, manage, deploy components (tools) ● Critical: relationships between components ○ If you can’t abstract the connection between components you can’t evolve them independently
  7. 7. Docker github.com/docker/docker
  8. 8. Docker ● Containerization engine for building images ● Go ● Core functions ○ docker build = Docker images ○ docker run = Docker containers ● Dockerfile ○ DSL ○ 16 instructions
  9. 9. Dockerfile
  10. 10. !!! Remember “CMD” Instruction !!!
  11. 11. Docker images ● Immutable (read-only) ● Sharable ● 80k public Docker images (DockerHub) ● Building blocks ○ Image based deployment ○ Create once, use everywhere (Dev, QA, Prod)
  12. 12. Docker containers ● State-less ● Transient ● Cattle, no pets
  13. 13. Docker ● What do we want? ○ Full access to the existing Docker ecosystem ○ Be able to consume images from anywhere ○ Work with upstream to improve security and reliability ○ Need tools to manage the build process and security updates ● What do we expect? ○ Manage 1M+ of running containers ○ Manage containers across multiple nodes
  14. 14. Kubernetes github.com/GoogleCloudPlatform/kubernetes
  15. 15. Kubernetes ● Container cluster manager ● Manage containerized applications across a cluster of Nodes ○ Running containers at scale ○ Provide runtime and operational tools for containers ○ Provide resource management ● Google, Red Hat, CoreOS and others… ● Go
  16. 16. Kubernetes architecture (basics) ● Master(s) ○ (REST) API server ○ Scheduler for allocation of “containers” onto hosts ○ Manages replications and watches the system for changes ● Node(s) ○ Agent that relays informations between Node and Master ○ Manages containers (using Docker) ○ Proxy for local service routing and load-balancing
  17. 17. Kubernetes architecture ● Etcd ○ Simple config key-value store distributed across hosts ○ Highly reliable ○ Used for service discovery ○ Simple (CURL ball) & Secure (SSL) ○ Provide high-performance operations
  18. 18. Kubernetes work units ● Pod ○ Represents group of containers closely related together ○ 1..N containers
  19. 19. Pods
  20. 20. Kubernetes work units ● Service ○ Abstract set of Pods as a single IP and 1..N ports ○ Provides environment variable in other Pods and simple TCP/UDP load balancing
  21. 21. Services
  22. 22. Kubernetes work units (cont..) ● Replication Controllers ○ Framework for Pods that are meant to be horizontally scaled ○ Maintain number of replicas for given Pod ○ Replicas are distributed across cluster ● Label(s) ○ Common field in all Kubernetes resources ○ Represents a 'tags' you can use to couple the work units together
  23. 23. Kubernetes work units (cont..) ● Route ○ Exposed service, reachable from outside
  24. 24. So what is an new "Application"? Pods linked together by Services: ● Edge router for www.myapp.com -> Rails frontend Pods ● Rails frontend Pods -> "backend" API Service ● "backend" API Service -> Python Pods ● Python Pods -> "postgresql" database Service ● "postgresql" Service -> PostgreSQL Pod with network attached storage
  25. 25. OpenShift v3 github.com/openshift/origin
  26. 26. OpenShift v3 ● Use Docker to containerize applications ● Use Kubernetes to manage them ○ Allow for Service-oriented-Architecture (Mircoservices !!!) ● Go
  27. 27. Composition ● Kubernetes is embeddable ● Kubernetes offers us infrastructure ● OpenShift embeds it and add PaaS pieces: ○ Builds ○ ImageStreams ○ Deployments ○ Templates ○ ... others...
  28. 28. Build ● Allows to build “stuff” ○ S2I, Docker, or Custom build ● Kubernetes schedule and execute the build inside Docker container ● Triggers ○ webhooks ○ image change ○ config change ● Built image are pushed into a single ImageStream.
  29. 29. ImageStream ● Build upon Docker Registry ● Abstraction for lack of functionality ○ base image ○ notify changes ○ track history
  30. 30. Deployment ● Define the lifecycle for a single image ○ What happen when an update is pushed to Docker image? ○ What happen when application configuration is updated? ○ What happen when updated application configuration fail to deploy?
  31. 31. Templates ● For consumption by end users of standard patterns ● Describes the whole application topology
  32. 32. S2I (Source to Image) ● Don’t make developers write Dockerfile ● Providing builder images is operational responsibility ● Developers wants simple flows (From GIT repo to Docker image) ○ Push changes to Git ○ Get all dependencies installed (bundler, npm, pip, maven, etc..) ○ Commit Docker image ○ Deploy
  33. 33. S2I (Source to Image) ● Build process fundamental elements ○ source ○ builder image ○ s2i scripts ■ assamble ■ run ● Current s2i builder images: ○ ruby, php, python, nodejs, perl, jboss ● Incremental builds (kinda)
  34. 34. Source code ● Consuming external source repos (no hosting) ○ github && generic webhooks ● Support different SCM (bzr, mercurial, SVN, CVS, ...)
  35. 35. OpenShift and Images ● Need tools for Docker image management ○ Think about millions of Docker containers ○ Need good quota story - OpenShift v3 Online ○ Pruning - remove old stuff ○ Content tracking and auditing ● Security
  36. 36. Documentation, links, repos ● OpenShift 3 Technical Architecture ○ Much deeper dive into the architecture ● OpenShift 3 System Design (PEP) ● Kubernetes Repo ○ https://github.com/GoogleCloudPlatform/kubernetes ● OpenShift Repo ○ https://github.com/openshift/origin ● Sample App+Guide ○ https://github.com/openshift/origin/tree/master/examples/sample-app ● OpenShift Blog Series ○ https://blog.openshift.com/author/benparees/ ● Source-To-Image project ○ https://github.com/openshift/source-to-image
  37. 37. Thanks! Questions?

×