Self test endpoints aka healthcheck for microservice

The more and more microservices we build, the more work needed around maintaining them. Need to know how are they performing, whether the service is up/down, is that service ready to serve request etc. Hence the monitoring becomes crucial and it needs to be automated. So heartbeat/ping can answer if a service is up/down but we need another endpoint which can tell if the service is healthy enough to serve a request. Not every microservice depends on each other, so sorting out the dependency tree via a healthcheck can be quite helpful too.

Healthcheck can be quite simple to build and easy to integrate with a deployment tool like Octopus, which will then give us more visibility around the state of the service and whether it’s healthy to serve request or not, as soon as deployment is done.

To add a healthcheck endpoint into the microservice, we can implement a contract as simple as this,


A simple get request to know the overall status and the status of the dependent services. The dependency tree should only include the bare minimum for the service to function. Like, in case of dataquery microservice, we need the service to be able to communicate with the underlying databases like Datawarehouse and any dependent service like Identity service or any other external service used.

So if the service failed to talk to database, the overall status will be 503 (service unavailable) or a 200 (OK), if all the underlying service call returns a success.

We can also add additional configuration details, which can help to troubleshoot some issues e.x. knowing the location of the log files can help to get more details of the error been displayed in the healthcheck response.

Then we can add a separate step in octopus deployment which fires off a healthcheck call right after the corresponding microservice deployment is done.

Based on the result, it can be either a successful deployment Or a failed one!

Not only we know the state of the service at any point of time, we can build monitoring around that and also as soon as we deploy our microservice, the first warm up call is already made (smile)



Lets docker your entire app suites – Part 1 (adaptive api)

So in my current workplace, just finished a greenfield project where we built a few application components (microsite, adaptive api, microservice, datawarehouse etc). When I started, I had to go through a somewhat ridiculous process of running a bunch of powershell scripts to setup my dev machine. Its still better than what I did in my previous company, but can’t ignore the fact that every new developers is wasting so much of their time trying to setup their machines, which ideally should be a few lines of scripts to keep things sane.

Anyway, as docker is already out there to solve all these crazy issues, I was wondering rather than just doing a hello-world lets try to docker the entire app buckets to different containers, so that anyone can just download the repo, install docker for windows and then run a single command to setup the entire app. It seems really easy to achieve but as the greenfield have a fair bit of dependencies over the legacy app (the word greenfield in that context makes no sense, right?), I have to be really carefull to handle it case by case.

So this blog I will share my experience how I have been able to containerize the app in my recently finished dev works.

I started with the adaptive api, as that’s built in node js, rather than C#, because if  you use C#, either have to choose dot net core or need to use windows container. Also the adaptive api somehow lives way far from the legacy apps, it seems to be an easy one to start with.

So after a few days of struggle, finally come up with this docker file:

FROM node:4-onbuild
MAINTAINER Ankan Sircar <>
RUN apt-get update \
 && apt-get install -y net-tools

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

COPY package.json /usr/src/app/
RUN npm install

COPY . /usr/src/app

CMD [ "npm", "start" ]

This is basically inspired from the blog : . What this docker file does, is quite self explanatory. It bascially creates an app directory where all the source code been copied, then it just goes through the package installation. and finally it runs the command to start the app.

So to get this docker file going, all I need to do is to run the following commands,

//to build the image
docker build -t asircar/adaptive-api

//to run the image as a container
docker run --add-host=<enter your host name>:<host ip address> -p 49161:8089 -d asircar/adaptive-api

That’s all! Your app is now ready to run in your host computer as a container. and you can access it via http://localhost:49161 . So now my microsite can talk to Adaptive Api and then adaptive api can talk back to microservice running on my host, as I have not containerized that yet, hopefully coming soon in windows container! That add-host command is allowing me to add the host name associating with the ip address, without that my node app can’t talk back to my microservice.

Alright! that was quite easy. Will come up soon with the microservice being hosted in a windows container and how the service and the api can talk to each other.

Android rotation issue : Landscape left only

While working on a game called Drainpipe, we had a requirement to display the game always in Landscape left mode. We set proper attributes in our AndroidActivity class :

[Activity(Label = "DrainPipe",
Icon = "@drawable/icon",
ScreenOrientation = ScreenOrientation.SensorLandscape,
MainLauncher = true,
LaunchMode = LaunchMode.SingleTask,
ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]

And also in the constructor,

this.DefaultOrientation = WaveEngine.Common.Input.DisplayOrientation.LandscapeLeft;
this.SupportedOrientations = WaveEngine.Common.Input.DisplayOrientation.LandscapeLeft;

And also in manifest file,

<activity android:name="" android:configChanges="keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize" android:theme="@android:style/Theme.Translucent" />

All these changes, made sure that the game is only playable in Landscape mode but still when you tilt the phone it still allows the app to rotate it to Landscape Right. Since the game heavily depends on user movements based on accelerometer, it was kind of ruining the experience. When too much tilt happens screen rotates back to Landscape right and make the game not playable any more. Even disabling the rotation in android phone does not help.

To stop that finally found a hack, where you need to override the RequestedOrientation and set that to Landscape.

public override ScreenOrientation RequestedOrientation
return base.RequestedOrientation;
base.RequestedOrientation = ScreenOrientation.Landscape;

This seems to work like a charm. Now no matter how much user tilt the phone, it never goes back to Landscape right.

Its never too late to give it a go!

Howdy! It’s me Ankan Sircar. I am originally from Bangladesh but living in Auckland for last 3 years. Still exploring and getting amazed by new places, people and the lifestyle.

Professionally, I have been a software developer for last 9 years! Always thought of starting my own blogs, but never managed to get that started. Now being married for 4 years and having an amazing kid of 15 months, seems like I have all the time in the world to go for it. Not really, but its never too late to start new things. Hopefully will come up with some useful experience from my regular life, technical or hobby, whenever I learn something new will share that in this blog for sure.

As a developer I was mostly experiencing C#, ASP.NET, SQL Server  for last 4-5 years, before then was exploring WPF, Silverlight, Windows Forms application.  Worked in  quite a lot industry, from healthcare to banking, sports betting domain to accounting, always keen for exploring new domain and new country. Recently working in SaaS industry, developing cloud based accounting software.

I love to take photographs either using a D7000 or a Go pro or an IPhone, will share some of those here too!

Till then ….. Good night!