Time for an update on the plan for my Cloud PoC. Previously the plan was pretty woolly, since the whole point of the PoC was to learn about some new technologies. But now it can be firmed up, just a little, because I know a bit more about the platforms and tools that will be most appropriate for our application.

What the application architecture will look like

As I wrote about before I expect our application to end up as a set of containerised microservices running in Docker and Kubernetes. Each service will need some kind of persistent storage (we use MongoDB so will most likely stay with that) and access to an Event (message) Bus.
Each service will host its own API that can be used by external users and other services. This will be accessed via REST over HTTP, most likely using json.
(I have had a quick look at gRPC as a serialisation format, but couldn’t get it to work any better or quicker. Maybe I just need to work on it some more).

What my plan looks like now

It’s still pretty basic! But at least there is no woolly area, I know a bit more about what I want to do.

There are two main strands to the plan which can be carried out in parallel:

1. Move to a microservice architecture
2. Host the microservices in Docker with k8s

Move to a microservice architecture

Microservices have so many benefits to our app (see some of my other posts on microservices) that we plan to move to this style of architecture regardless of our Cloud move. The things we need to tackle here include:

• Sensible service boundaries need to be defined so we can determine exactly how to compose our app into small, logical units
• Once these boundaries are decided we need to refactor the code so that services talk via their APIs, not directly to the underlying data
• We need to split the application into distinct, isolated units by adopting separate source control, build and deployment mechanisms
• Some technical changes need to be made so we can support the application better:
  • Use correlation ids while logging so we can trace requests as they flow through the system
  • Adopt different patterns that are more suited to microservices, like Circuit Breaker

Host the application in Docker

This has been the subject of several posts already, and probably several more. We are looking to:

• Host our microservices in Docker containers wherever possible, to make deployment and service management easier
• Be stateless wherever possible in order to ease service administration. (e.g. scaling up becomes as easy as adding an extra container)
• Use kubernetes for orchestration, as this seems to be the best-of-breed framework

Things to look into next

In no particular order my list of “stuff to look into” is below. It’s undoubtedly incomplete but it will help to direct my attention.

• Microservices in particular the patterns and technical changes that are best practice
• Docker and the best practices, configuration and set up needed
• k8s and the best practices for hosting microservices, config files, etc
• secrets and configuration in docker / k8s, how best to pass passwords and config
• mongo / external services and their usage from containers
• event bus and how to use one in the Cloud
• deployment best practices, and the most appropriate technologies
  • load balancing, reverse proxies
  • canaries, blue/green, etc
  • dns, vip, etc
• SSL / TLS in Docker, and how we can ensure our app is secure
• ASP.Net Core best practices, especially around
  • config files
  • ssl
  • dynamic compression
  • caching

tl;dr

There are two things to look at in parallel: microservices and container orchestration.