That Conference 2018 – Finding Your Way to a Microservices Architecture

That Conference 2018, Kalahari Resort, Lake Delton, WI
Finding Your Way to a Microservices Architecture – Dana Hart

Day 1, 6 Aug 2018

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Dana Hart
Northwestern Mutual

Executive Summary

  • Lots of good reasons for re-factoring monolithic application as microservices
  • Architecture has multiple micro SPAs talking to multiple microservices


Monolithic application

  • Browser
    • UI / Business Loic / User Logic
    • Databases
  • One application on single platform
  • Drawbacks
    • Maintenance
    • Hard to test
    • Longer deploys
    • Longer downtimes
    • Doesn’t scale
  • How we got there
    • Probably started out small
    • Features have been added


Scaling the mono

  • Development–multiple teams in one repo
  • Continuous Deployment – updates = outages, higher risk
  • Increased Transactions – ru nmore copies of application?  Scale out metal?
  • Is this good enough? Working?


Frustration is an important part of success


Software microarchitecture

  • Set of patterns used together to realize parts of a system
  • Building block for piecing together cohesive portions of an overall architecture



  • Structure application as collection of loosely coupled services
  • Enables continuos delivery and deployment of large, complex applications



  • UI talks to various microservices
  • Each microservice talking to one database


Reasons to convert

  • Decomposes complexity
  • Developed independently
  • Deployed independently
  • Scaled independently
  • Smaller deploys
  • More frequent deploys
  • Lower deployment risk


How to start

  • Find piece that can exist independently
  • Don’t just convert, but re-factor


REST review–constraints

  • Uniform interface
  • Client-server
  • Stateless
  • Cacheable
  • Layered system
  • Code on Demand


Define your subdomain


REST review

  • Sensible resource names
  • XML and JSON
    • Recommend JSON over XML
    • Easier to consume by browser
  • Fine-grained resources
    • Simple resources that you can apply CRUD to
  • Idempotence
    • Get same response every time if inputs are the same
  • Safety


Micro SPAs

  • Take original monolithic UI
  • Split into separate pages, each being a SPA
    • /store
    • product
    • /order


Deployment Patterns

  • Multi service instances per host
  • Service instance per Host / VM / Container
  • Serverless deployment
  • Service deployment platform
    • Automated infrastructure


Move everything to cloud


Reverse proxy

  • URL goes thru reverse proxy (external request)
  • Look up services, find target address
  • E.g. use NGINX


API Gateway

  • SPA Containers send requests
  • To API Gateway
    • Could implement security
    • Load balancing
  • Farms out to API Containers


Micro Application platform–diagram

  • Request
  • Reverse Proxy
  • SPAs
    • Can talk to one or more services
  • API Gateway
  • Services
  • Databases


At end

  • Multiple SPAs
  • Multiple services
  • No deployment downtime
    • Pre-production environment
    • Kubernetes handles this




Q: When do you decide to create an API that might combine logic from two sub-domains?

A: We wouldn’t combine the services, but let the UI do the model translation between the two services. But sure, you could add a service that aggregates data from multiple services.


Q: How do you handle versioning?

A: Many opinions around versioning. We have pattern of “v1”, “v2” in front of API. “No breaking changes” unless it’s a major version chance.


Q: How do you decide what goes in what database?

A: We still have one large database. If the entities have relationships, we’d be hesitant to split them out.


Q: How do you manage to get common look/feel across the SPAs

A: It’s not easy. We had designers to create common UI Sketch components. Then devs create UI framework around these common elements. Partnership between Engineering and Design.


Q: How did you avoid applying legacy change management techniques (monolithic) to new architecture. Had to educate various teams to demonstrate that we’re now running with lower risk. Dev team “owns” the result of a deployment, responsible for it. We use New Relic for monitoring.


Q: We have 3rd party integration with a service that is not stateless.

A: Sometimes you do get stuck with a vendor’s implementation. Could give examples to vendor of what work better for you.


Q: Where do you pull stuff from multiple services together?

A: We do it in UI layer, model translation, pulling stuff together.