How to scale your ASP.NET Core application without worrying about session issues between instances

One of the things I like most in modern software development is the facility to build nice and complex things in a short period of time (and with a few lines!). Back in the past, it was more complicated to build an infrastructure that was capable to run many instances of a web app and share the session between them.

Nowadays some developers are going to say that using Session isn’t a good approach to deal with ephemeral data (data with short existence), and they are right.

But what if Sessions, for some reason, is a valid approach for your app? In that case it is important to prepare your app to scale horizontally with instances.

Before start doing anything, I draw what I expect as a result of my experiment:

The main goal here is to share Session through Redis to persist our data, what only makes sense with two or more web app instances. To take advantage of multiple instances, we are going to setup a kubernetes service as load balancer and entrypoint. To finish, we setup a Redis commander web client to verify what’s happening inside the Redis database.

It’s relevant to expose that every mentioned software is running inside its own Docker container, represented in the diagram above as little boxes (I will not dig into Docker subject, but there are plenty of articles explaining about it). For the containers, we will make use of kubernetes.

Tools used to code:

  • Docker with Kubernetes

Necessary tools to run:

If you want to go directly to the code, here is the repository.

In this first part of my article, I’ll explain how we can build a simple WebApp by setting our development environment. In the following parts we will modify the app to save session in Redis service and then wrap all parts together running in kubernetes.

Creating our app in VS Code + Docker:


First, let me introduce you to the Remote Development in VS Code. It’s an extension that allows VS Code to use an external environment (in our case, a container) to develop software. The benefit of this approach is that you don’t need to install any SDK in your local machine (because everything is inside the container), and if you need to change something in the environment, it’s very easy, just adjust the Dockerfile. But we will not go into that in deep.

Open the VS Code and click on the double-arrow button located at the left bottom of VS Code:

After you did that, a dropdown menu will appear, with many available commands. Click on “Add Development Container Configuration Files”.

There are many configuration “templates” for multiple technologies, but we are only interested in C# dotnet core 3.0. You can type “C#” in the search box:

After you have selected the 3.0 version, a folder and two files are going to be created: .devcontainer folder and inside it, there will be a devcontainer.json and a Dockerfile.

The Dockerfile that came with the template is more complex than we need, so we will rewrite the Dockerfile with the following:


In the devcontainer.json file, uncomment or type the following attribute in order to expose container ports to host the machine:

“appPort”: [5000, 5001]

Now, we can re-open the VS Code in the container. Click again on the double-arrow button and select.

*Make sure you are running the docker daemon.

If everything is working fine, the Docker will download the image. You can see the details by clicking on the word:

After the download is completed, choose the bash option in the terminal window dropbox:

Now, we have an environment with dotnet core 3.1 installed:

And we are able to create our app with dotnet cli (command line interface). In this same terminal, type:

dotnet new mvc –name app

This command will create a simple MVC app in a current directory:

Let’s verify if everything is correct? Type in terminal the following:

cd app
dotnet run

Your application will run:

After that, open your browser and go to http://localhost:5000 , where you should be able to see our app running:

Cool, everything is working just fine! Our development environment is OK, and the next step is to create some pages to test our Session storage. But we are good for now. In the next part of this series, we will write the app code and setup up our running environment. Stay tuned!

About the author

Luiz Adolphs is a Software Engineer at Poatek.