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
@dmhart13

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

 

Microservices

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

 

Diagram

• 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

• HTTP verbs–GET, POST, PUT, DELETE
• 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

 

Questions

 

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.