Part 0.1 - 1000 foot overview

Part 1 - Things to consider when containerizing an app

Part 2 - Running MySQL in a container

Part 3 - Updating legacy code

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.