1. Learning Microservices in the open with Game On!
Erin Schnabel @ebullientworks
Kate
October 2016
Erin

2. Microservices are used to…
API
compose a complex application using
“small”
independent (autonomous)
replaceable
processes
that communicate via
language-agnostic APIs
Service
Registry
Microservice
REST
(JSON/HTTP)
REST (JSON/HTTP)
API
Publish
Microservice
Microservice
API
Microservice
Microservice
Publish
Subscribe
broker
Microservice
Microservice
Microservice
Microservices application
Erin
Reminder of what microservices are

3. Conway’s law Bounded Contexts Eventual consistency DevOps Automation
Erin
People wanting to learn start by reading books, these are some good examples, and hearing all these words
Testing?

4. Microservices Sample Apps…
Create a single service
Rebuild a pre-baked microservices application
Microservices are so easy!
Clueless
No idea
Confident
Has read all the things!
Experienced
Hands-on understanding
Puzzled / Realistic
Challenges are real
Erin
Next step is to go online and try some samples
Initial impression is that microservices is easy, but once you go beyond the samples it gets hard quite quickly
We wanted to smooth out this learning curve

5. 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
Erin

6. Rooms are what you build
static
Proxy
Sweep
room
Rooms are what you build
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Erin

7. This is what we run static Proxy Sweep room Auth Player Map Mediator
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Erin

8. Game On! in action

9. Retro, text-only interface
Simple text commands
Kate
First room
Text-based, forces creativity
/go N

10. New microservice serving content
Status updates
New microservice serving content
Kate
Change rooms
Status updates to show what is happening
New microservice serving content
Sick room – fault tolerance

11. Demo: Creating a room
Kate

12. Github project to get started, other languages available too

13. Deploy the room
mvn package docker-compose build docker-compose up

15. docker-compose.override.yml gojava: container_name: kateroom networks:
default:
external:
name: gameon_default
Want to register our room to a local running version of the game. Game On can’t access the app at localhost so use container names and add the container to the same network as Game On is running on.

16. ws://kateroom:9080/room
Now they are on the same network can register the room using ws://kateroom:9080/room

17. Now can see the room running

18. Update the room docker-compose.override.yml: mvn package gojava:
volumes:
- './gojava-wlpcfg/target/servers/gojava-room:/opt/ibm/wlp/usr/servers/defaultServer'
Update the room code. Instead of having to restart the docker container, because we attached a volume that linked our local servers directory to the container we can just run mvn package.

19. See room is updated

20. What next?

21. What happens when… As a player, navigate from room to room
Notice latency?
What is impact of calls to additional services?
Fallacies of distributed computing! Gotcha!
You have the most popular room ever!!
How do you scale this thing?
What about items or shared state?
Where are players?
Exploration of solutions for caching, circuit breakers, service interaction patterns
Erin

22. Service composition

23. First pass Proxy room Player Concierge ELK mongo
WebSocket
JSON/HTTP (REST)
Player
Concierge
Player managed ”all interactions with the player”
Concierge: tell player service which room is next (/go N)
Room (had to have one!)
ELK
mongo
Erin: talk about fact that we had a hotel idea, concierge in charge of moving players

24. Now.. static Proxy Sweep room Auth Player Map Mediator ELK couchdb
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Why the change:
-Erin - Language separation, other Kate didn’t want to use Java, created angular front end, player got separated
-Erin - Scaling worries
websockets are long-running
Simple CRUD operations

25. Now.. static Proxy Sweep room Auth Player Map Mediator ELK couchdb
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Why the change:
-Kate - Bad metaphor
Concierge just hands out keys
Room registration required knowledge of neighbors
Domain driven design -> ubiquitous language
Brought in alongside Concierge

26. Now.. static Proxy Sweep room Auth Player Map Mediator ELK couchdb
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Erin:
About these references to couchdb.
Player and Map are definitely in charge of their own data, however…
When running locally on our laptops, they share the same backing container for couchdb, because it’s simpler, of course.
But when we’re running in Bluemix, couchdb is replaced with Cloudant... And we don’t really know how many instances that is. In fact, Cloudant runs multi-tenanted, which means many of us share Cloudant instances, even though we don’t share data.
How many of you remember to also map your calls to your datasource with circuit breakers? I will confess that we don’t, yet. We know we need to, and I’ve seen the failures to prove it...

27. Twelve Factors

28. 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
Kate
Doing this will make your life easier, but you may have to make environment level choices
Won’t go in detail, but will cover what we have done in this area

29. Git + Submodules (Factor 1: codebase)
Root repository:
Optional use of submodules
Key: Only builds update submodule commit levels
Prevents conflicts and confusion caused by humans
Erin
One repository or many repositories? There are arguments going both ways for how to manage microservices.

30. Containers
(Factor 2: dependencies, 5: build/release/run, : Processes, 8: concurrency, 10: dev/prod parity)
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
Kate – containers covers a lot of factors
Vagrant is a scripted way to start docker containers (automates virtual machine provisioning), single command to start everything
Provided both so other Kate was happy
Overlays -> with volumes
All services deployed in different containers so we can update them independently

31. 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}"/>
Erin

32. Security

33. 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
Erin

34. 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
Shared Library
Erin

35. Service discovery

36. static Proxy Sweep room Auth Player Map Mediator ELK couchdb kafka
WebSocket
JSON/HTTP (REST)
Auth
Player
Map
Mediator
ELK
couchdb
kafka
amalgam8
Kate - Remember this picture, think what this means
Was hard coded endpoints – needed to change that

37. 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
Client library
Microservice
Service
Proxy
Service
Registry
Microservice
app
sidecar
Kate
Options: registry, proxy
Proxy: client or server side
Client side: side car or library

38. Client-side load balancing
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
Kate – polyglot sidecar (independent process in same container) – language agnostic, very small

39. Successful?

40. Example rooms Map room Weather room Liberty car Pi-Cam Kate
Some cool rooms have been created, using GameOn services (e.g. map room), external services (e.g. weather room) and IoT (e.g. Liberty car and Pi-cam)

41. Erin
Now have external contributors

42. Thank You! Play – http://game-on.org
Learn more –
Erin Schnabel | | @ebullientworks
Kate Stanley | | @KateStanley91