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.
- Lots of good reasons for re-factoring monolithic application as microservices
- Architecture has multiple micro SPAs talking to multiple microservices
- UI / Business Loic / User Logic
- One application on single platform
- 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
- 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
- Uniform interface
- Layered system
- Code on Demand
Define your subdomain
- 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
- Get same response every time if inputs are the same
- Take original monolithic UI
- Split into separate pages, each being a SPA
- Multi service instances per host
- Service instance per Host / VM / Container
- Serverless deployment
- Service deployment platform
- Automated infrastructure
Move everything to cloud
- URL goes thru reverse proxy (external request)
- Look up services, find target address
- E.g. use NGINX
- SPA Containers send requests
- To API Gateway
- Could implement security
- Load balancing
- Farms out to API Containers
Micro Application platform–diagram
- Reverse Proxy
- Can talk to one or more services
- API Gateway
- 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.