Microservices at Gigya

Microservices at Gigya

Slides from the first meetup about Microdot, Gigya's open source microservices framework in .NET.

Ed52a75c8cf2f4cb1c2e9d8d161ca771?s=128

Rotem Hermon

July 04, 2017
Tweet

Transcript

  1. By Meetup #1 - Introduction

  2. Microservices @

  3. About Gigya • Customer Identity Management Platform • Multiple products

    • Hundreds of (big enterprise) customers • 1.3 billion user profile managed • 5 Data centers • 10K API calls/sec (with X10 peaks)
  4. We started small

  5. A couple of years later…

  6. We had problems • One code base, multiple teams •

    Archeological code layers • Technical debt (not enough unit tests, weird hacks) • “All or nothing” deployment • Looooooooong release cycles
  7. None
  8. Microservices Benefits • Scalability (organizational and technical) • Agility •

    Resiliency • And also… (easier to understand, easier to deploy, easier to change, easier to experiment, multiple technologies)
  9. Microservices – Not a free lunch! Modularity System Complexity

  10. Microservices – Not a free lunch! • System complexity •

    Operational complexity • Performance and latency • Reliability • Consistency • Debugability
  11. None
  12. And we had another problem

  13. Concurrency

  14. Distributed Concurrency

  15. None
  16. (A is for Actors)

  17. The Actor Model • Simpler concurrent programming model • Write

    single-threaded code (easier to understand) • Concurrency and scale via actor instances • Maximizes CPU utilization • Easy to distribute
  18. Virtual Actors • Started in 2008 at Microsoft Research –

    Project Orleans • In production since 2011 (Halo 4 cloud services) • Open sourced and moved to Microsoft Studios at 2015 • A port to Java – Orbit (by EA)
  19. Virtual Actors • Goals: • Make distributed application programming easier

    • Prefer developer productivity and transparent scalability • “A programming model and runtime for building cloud native services”
  20. Virtual Actors • A Virtual Actor: always exists and never

    fails
  21. Virtual Actors Actor types: • Worker • An auto-scaling processing

    unit – multiple instances created by framework as needed • Single Activation • Guaranteed to have a single active instance in the cluster • A Stateful application middle-tier
  22. Virtual Actor Framework • A runtime providing virtual “actor space”,

    analogues to virtual memory • Handles Actor placement, activation and GC when needed • Balances resources across the cluster, provides elastic scalability
  23. Simplified Programming Model • An Actor is a class, implementing

    an interface with asynchronous methods • The caller of an Actor uses the actor interface via a proxy • Messaging is transparent and handled by the runtime. Programmers deal with interfaces and methods
  24. Simplified Programming Model

  25. Simplified Programming Model

  26. So can we use Actors as microservices?

  27. A Microservice • “Small” (developed by a single team) •

    Solves a problem (single responsibility) • Interacts with other services over well-defined interfaces • Independently deployed • Remains consistent and available in presence of failures
  28. Actors as Microservices ? • “Small” (developed by a single

    team) • Solves a problem (single responsibility) • Interacts with other services over well-defined interfaces • Independently deployed • Remains consistent and available in presence of failures
  29. Actors as Microservices ? • “Small” (developed by a single

    team) • Solves a problem (single responsibility) • Interacts with other services over well-defined interfaces • Independently deployed • Remains consistent and available in presence of failures (?)
  30. Actor based microservices Service A Service B ServiceB Interface Actor

    IMyServiceB
  31. Actor based microservices Service A Service B ServiceB Interface Actor

    IMyServiceB ServiceB HTTP Listener
  32. Actor based microservices Service A Service B ServiceB Interface Actor

    IMyServiceB ServiceB Client ServiceB HTTP Listener JSON over HTTP
  33. None
  34. None