Although MicroServices Architecture is the de facto approach in building many complex applications, it introduces numerous abstractions which in contrary to a traditional monolithic application makes it complex to understand, which is directly proportional to the number of introduced abstraction. But having said that, MicroService Architecture provide a huge incomparable advantage to monolithic applications.
Performance, scaling, separation of concern, encapsulation at the architecture level, along with developer level advantages include modular components hosting into dedicated containers, where each distribute Agile team concentrates on one part of the module for development which can be independently hosted and scaled as per requirement.
Such advantages are Game Changer approach to many companies like Microsoft, Amazon, Online Shops etc. to host and upscale their application to cater to end users need.
In this article, I would like to explain the basics of .NET Core console application for a MicroService architecture with Docker support, Volume mounts and Environment Variables config files which will be deployed into Kubernetes cluster for container orchestration.
At the time of writing this article .NET Core SDK and runtime are on version 3.1 which includes the latest version of C# 8.0. The standard console application has a simple console.writeline(“Hello World”) in the main method of Program.cs. We need to wire up the ILogger and IConfiguration which help us in exposing the .NET Core logging and app config/ environment variables respectively. Furthermore to instantiate a custom repository and to pass the ILogger & Configuration within the constructor, we need to add a scoped dependency within the startup of the application using the ConfigureServices which preconfigured via the Microsoft.Extensions.Hosting.HostBuilder.
The inheritance of your custom function with the IHostedService or BackgroundWorker has a predefined Entry and Exit from the repository via the StartAsync and StopAsync respectively.
If you inherit only the BackgroundService you would have the predefined starting point which can be overridden to conduct your specific business logic.
To introduce docker support we need to install Docker Desktop for Mac in my case, similarly there is support for Windows OS as well. After installing try the docker version command as below.
Now let us introduce a new Dockerfile at the csproj level without any file extension which helps us build an image in our locally running docker instance. There are two forms of building an image from the Dockerfile, one is a single stage build where the building of an image all happens in one stage, which in other words mean the SDK and Runtime for the application are included in the build process making the Image comparatively large. The below example is a multi-stage build which only builds the application with the bare minimum binaries required to run the application
To build an image we need to use the docker build command, in my case I providing an example to build the image using the proxy server as the environment variable under the created container which in our case Linux. The final parameter is the path where the docker file is located, which in our case the current folder hence the dot at the end. HTTP_PROXY and HTTPS_PROXY are keys both in windows and linux where you can set your proxy server as below
Docker images should list you all the images that are existing in your docker deamon, this is how it looks
To run an existing image, you can just call the docker run command, mostly you can run an image in two formats
- Interactive (-i)
- Detached (-d)
Below is an example of running the application in interactive mode, where we can open the secure shell SSH or bash inside of the container. The -t is used to call the name of your image which is the tag name and version.
The follow up to this article, I would introduce Kubernetes for container orchestration with ConfigMaps, Secrets which are specifically used in OpenShift which is a custom abstraction developed by RedHat on Kubernetes for container orchestration.