Game On! Exploring Microservices with a Text-Based Adventure Game
Download as PPTX, PDF1 like706 views
This document discusses using microservices to build a text-based adventure game. It introduces microservices concepts like independent processes that communicate via APIs. Reasons for using microservices include accommodating different technologies, facilitating rapid growth, and reducing risk. The document then outlines building a basic room service and exploring solutions for scaling it, handling shared state, and managing calls between services. It also discusses security approaches like OAuth, JSON Web Tokens, and hashed message authentication codes. Finally, it covers service discovery and registration concepts needed for load balancing and scaling microservices applications.
Game On! Exploring Microservices with a Text-Based Adventure Game
- 1. Game On! Exploring Microservices with a Text-Based Adventure Erin Schnabel @ebullientworks September 2016
- 2. Microservices are used to… • compose a complex application using – “small” – independent (autonomous) – replaceable – processes • that communicate via – language-agnostic APIs Microservice MicroserviceMicroservice Microservice Microservices application Subscribe REST (JSON/HTTP) Microservice Microservice broker API Microservice Publish API REST (JSON/HTTP) Publish Service Registry API Microservice
- 3. Why? • Accommodate differences – SQL, NoSQL, Graph… – Change cycles – Scaling profiles – Security zoning • Facilitate growth – Polyglot explosion • Agility! – Bounded context (code + data) – Faster iteration cycles • Reduce risk try new things – Isolate legacy vs. unknown
- 4. https://twitter.com/adrianco/status/441883572618948608 “Twitter microservices map looks just like the Netflix one. We called this the ‘Death Star’ diagram” — Adrian Cockcroft via twitter Interaction patterns
- 5. Fallacies of distributed computing • The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn’t change • There is one administrator • Transport cost is zero • The network is homogenous -- L Peter Deutsch, 1994 https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
- 6. Eventual consistency Bounded Contexts DevOps Automation Conway’s law Testing?
- 7. Microservices Sample Apps… • Create a single service • Rebuild a pre-baked microservices application 7 Clueless No idea Confident Has read all the things! Experienced Hands-on understanding Puzzled / Realistic Challenges are real
- 8. The premise … • Hands on with microservices • Stick with ’Hello World’ simplicity • Choose your own adventure • Fast path to the hard stuff • Build something cool (to you!) • Learn as you go
- 9. /go N Retro, text-only interface Status updates Simple text commands
- 11. kafkaELK amalgam8couchdb room PlayerAuth SweepProxystatic MediatorMap Rooms are what you build.
- 12. What happens when… 1. Build a basic room 2. Scale that room (multiple instances) – Where are players? – What about items or shared state? – Latency, managing calls to additional services Exploration of solutions for caching, circuit breakers, service interaction patterns 12
- 13. Twelve Factors
- 14. Twelve factor applications • “a methodology for building software-as-a-service applications” – Created by developers at Heroku • Factors are independent of – programming language, – backing services, – cloud provider • http://12factor.net/
- 15. Git + Submodules (Factor 1: codebase) • Root repository: https://github.com/gameontext/gameon – Optional use of submodules • Key: Only builds update submodule commit levels – Prevents conflicts and confusion caused by humans 15
- 16. Containers • Encapsulation of all dependencies • Parity: dev -> test -> prod • Configuration passed in via environment • Local: Docker Compose or Vagrant – Pre-built images in dockerhub (this came later.. ) – Overlays for local editing • Independent build pipelines per service to deploy containers 16 (Factor 2: dependencies, 5: build/release/run, 6: Processes, 8: concurrency, 10: dev/prod parity)
- 17. Liberty (Factor 2, 10, 3: config, 4: backing services, 7: port binding, 9: disposability) • Java services are Liberty-based • Customizable features: Cachable Docker Layers – Explicit app server dependencies – Self-contained immutable artifact – Smaller war (smaller delta) • Environment variables in server config – Common configuration across environments – Config munging not necessary – Composable configuration w/ dropins if required <couchdb id="couchdb" jndiName="couchdb/connector" libraryRef="couchdb-lib" password="${env.COUCHDB_PASSWORD}" url="${env.COUCHDB_SERVICE_URL}" username="${env.COUCHDB_USER}"/> 17
- 19. ELK mongo room Player Proxy JSON/HTTP (REST) Concierge • Player managed ”all interactions with the player” • Concierge: tell player service which room is next (/go N) • Room (had to have one!)
- 20. ELK mongo room Player Proxy JSON/HTTP (REST) Concierge • Language separation • Scaling worries – websockets are long-running – Simple CRUD operations static Mediator
- 21. ELK couchdb room Player Proxy JSON/HTTP (REST) Concierge • Bad metaphor – Concierge just hands out keys – Room registration required knowledge of neighbors static MediatorMap
- 22. kafkaELK couchdb room PlayerAuth SweepProxystatic MediatorMap Messaging / Events Serverless (time)
- 23. Security
- 24. OAuth & JWTs • OAuth proxy – Application id w/ different front-end – Could be a gateway instead • Access token converted into signed JWT • System services deal only with JWT – game-on.org SSL certificate – Well-known public key 24
- 25. Hashed message authentication codes (HMACs) • Shared secrets – Credentials not sent on the wire – Used to verify identity of sender • Map operations – Mutable operations require HMAC signature – Hashed signature used to prevent replays • Room handshake for WebSocket – It is the game calling the room – Room answering the game • https://book.game-on.org/microservices/ApplicationSecurity.html 25 Shared Library
- 27. Service registration and discovery • Required for load balancing and scaling • Services need to find each other • Environment changes constantly • Client-side or server-side? • Client library, sidecar, or proxy? Microservice Microservice Microservice Service Registry Client library Service Proxy app sidecar
- 28. • Basics – Service registration – Service discovery – Client-side load balancing • How – Sidecar model. 2 options: • An independent process running in the same container as the app • An independent container running in the same pod as the app container
- 29. Successful?
- 31. Questions?
- 32. Thank You! Erin Schnabel | [email protected] | @ebullientworks Play – http://game-on.org Learn more – http://book.game-on.org