Legacy to containers to serverless microservices - part 5 (Site analysis)
Part 1 - Things to consider when containerizing an app
Part 2 - Running MySQL in a container
Part 4 - Further legacy site work
Part 5 - Site analysis
Previously…
We implemented some auth. logic and some session logic. Auth. using Azure B2C, and a secure client-side session, which de-couples our required infrastructure design by a substantial margin.
This post, we will begin dissecting our app, given how small it is this will be a pretty boring post.
(Relaxed) Site analysis
Function boundary
I’m going to do this extremely fast and loose so we can get to the fun stuff :).
We can start by mapping all of the business functions and their connections, in a chart like so:
Few key things here:
- The site is focused around wifi hotspots, so that’s a key domain
- The site is focused around reviews for hotspots, so that’s a key component
- The site is focused around users submitting reviews for hotspots, so that’s a key component
Each of the 3 above key components have ‘auxilliary’ functional components; that facilitate the process of a user finding hotspots and submitting reviews.
We can identify “bounded contexts” (roughly) where a single model applies:
Services
I’m skipping entities entirely and looking at the service. We will assess the following criteria:
- Each service has a single responsibility
- No chatty calls between services
- No two (or more) services are required to be deployed in lock-step
- Services aren’t tightly coupled
Given we have common functionality (search for a hotspot, search for reviews) we will use the following services:
- A search service, which retrieves hotspots/reviews
- A few entity-management services:
- Review Update
- Review Delete
- Hotspot Update
- Hotspot Delete
- User-management auth/auth service, which will handle authentication, authorization and shadow-identity management of a user
Given we are focusing on 0/low cost, we will be utilizing platform and serverless services where possible. This means no Kubernetes.
We’ll be deploying this into multiple regions, and creating our own custom sync-logic for the blob storage. This ensures we can be active/active or survive in the event of a regional disaster with full site functionality.
We could use cosmos to do this much more easily, but that would cost money :)…
Service steps in rough order:
- Search
- Hotspot (update)
- Review (update)
- Identity
- Secondary region - storage sync
- Rewrite front-end
Next up, initial data seed with search service work.