Getting To Know Microservices – Architecture

I went back to the drawing board and produced a sketch of how I envision Harvee’s architecture with its first real microservice.

I could however not ignore that I currently sit with a system, which might rather follow the monolithic application dilemma and I won’t be able (maybe I should say I don’t want) to change that completely. But the idea is for every new feature that I will add for it to follow the microservice pattern. Existing features will work as they are now. As I was writing in an earlier post one new technology component which I want to (actively) evaluate and which I will hopefully be put into my target architecture is the API gateway.

So what is it that I came up for the moment:

Some explanations on the above diagram:

• As mentioned I will continue using my two existing webservices and most of the current requests into the backend will still be served by those
• I want to get rid of the Apache webserver which is serving the UI and I initially thought to replace it with NGINX. I changed this again though and want to get rid of a webserver container completely and instead have the frontend being served by AWS CloudFront connected to S3 buckets.
• There will be one new microservice and it will deal with SEO related features. I might still use Django (combined with the REST framework extension) to build it. In fact the SEO functionality is already in the old microservice (but not completely working currently) so I want to extract it from there
• For both the frontend and the new, microservices-based containers I expect to have more than just one version going forward. I want to be able to do blue/green deployments and maybe even canary deployments. When it comes to the frontend this will just be multiple S3 buckets. When it comes to the microservices this will be multiple containers
• An API gateway will be introduced, which is orchestrating the calls both to the frontend and to the webservices. So far the frontend called explicit versions of the webservice and this will change with the new microservices as with those the API gateway will know, which service (in which version) to call. This behaviour I won’t change however for calls going into the existing, monolithic webservices
• For the API gateway itself I want to focus on three things: frontend to backend authentication (so that I control better who is calling my webservice), proxying of requests (going to the frontend or any of the services) and supporting different styles of deployments (switching between blue and green and support canary by applying weights)

With that being said I am now able to add a few more To Dos to my list which should become user stories in my epic. These are the To Dos I can see now:

• Evaluate and select the API gateway
• Build the API gateway and give special focus to the process of services registering at the gateway (or the gateway finding the services)
• Migrate the frontend part to S3 buckets
• Add client auth for UI calling the backend
• Add API gateway proxies for the existing webservices
• Build (extract) SEO microservice and have an iteration to add at least one additional feature
• Testing (deployment patterns)

Wow, did I just add another 7 user stories ? It sounds like I will be busy enough for the next 3 months for sure !