Reasons you should use Microservices to build your next application

You’re looking for a new architecture for your next software project, and you’ve heard about this thing called Microservices.  It sounds cool, but you’re not sure if it’s a fit for your next project.  Use this handy checklist to decide if using Microservices are right for you.

  • It’s a dynamic new paradigm that drastically increases complexity; what’s not to love?
  • Networks are fun to troubleshoot.
  • You can now use Brainfuck in a production application!
  • You missed the XML wave and the Actor model wave; you’re not missing this one.
  • Scaling out is so much more fun than worrying about application server performance. Throw more hardware at it!
  • You have a friend who works in the server sales business and you owe them some favors.
  • How else are you going to get to put “Docker” on your resume?
  • Event-driven, disconnected, asynchronous programming was way too easy in a monolith.
  • You also have a friend in the server logging and metrics business (Is it New Relic or Spleunk?) and you own them favors (you owe a lot of people favors, don’t you).
  • You’ve taken Spolsky‘s “Things you should never Do part 1” as a challenge.  After all, you’re not rewriting the app, you’re reimagining it.
  • The Single Responsibility principle needs to go to its fanatical conclusion to finally become a reality: One line of code per service.
  • Your DI container has pissed you off for the last time.
  • Complex deployment processes mean job security.
  • “DevOps experience” makes a great resume booster.
  • 100 git repositories means never having merge issues.
  • How else would you get around the Mythical Man Month? 9 women can have 9 babies in 9 months, and they don’t even need to talk!
  • Contract testing sounds way cooler than “integration testing”.
  • What’s better than 1 REST API? 100 of them.
  • You can now force your teammates to learn Haskell (They’ll thank you).
  • You can now use the best tool for the job, even if it requires you to go through a few months of training to learn that new tool, and did I mention they only do training on Cruise ships to Tahiti? (it’s not your money you’re spending, after all).
  • Whenever someone asks how you’ll solve an architecture issue, you can always say, “That’s a future us problem”. TAKE THAT, MONOLITHS.
  • The grand total of documentation is a README in the root of each git repository.
  • Monoliths generally only have one codename; with Microservices you can have hundreds. Time to bust out that greek mythology.
  • Of course your application needs to be able to support a distributed event queue; why is that even a question? You need to obviously scale out to billions of operations per speed.


Microservices don’t sound like your cup of tea? Try Reasons you should Build a Monolith.

Reasons You Should Build a Monolith

You’re building a new software project! Congratulations! You’ll make millions and people will love you. It’s going to be awesome.

Your first question (of course) is: Should you build a monolith or use Microservices?  Great Question!

You should build a monolith if you:

  • Have only a hammer and can see everything as a nail.
  • Have the language you’re going to use, right or wrong.
  • Know no one on the team can possibly learn a new language. That’s insane.
  • Enjoy contorting your language/framework to solve problems it was never meant to.
  • Enjoy building a new  library or framework because of the above.
  • Believe wholeheartedly in the idea of one code repository.
  • Can’t imagine how people would ever deploy multiple code bases.
  • Enjoy the simplicity of one, getting progressively longer, build?
  • Code merges are so much fun.
  • Enjoy spelunking through your code to find out where you’re supposed to make that bug fix.
  • Enjoy writing the reams of documentation that will show people how to navigate the project.
  • Believe what’s good enough for Ruby on Rails, Django, and ASP.NET is good enough for your team.
  • Can’t imagine why anyone would want to write tests against an HTTP API.
  • Scoff when someone mentions a new language.
  • Are pretty sure the business requirements aren’t going to change
  • Have been bitten way too many times by new languages and frameworks that just don’t work out
  • Think the idea of containers is nuts. A computer inside of a computer inside of a computer? Craziness.
  • Think the network is obviously the slowest part; Keep all the calls in process.
  • Love complicated branching strategies; maybe even owning a gitflow T-shirt.
  • Love process! Process is your friend. Code freeze, QA, UAT, deployment, Change requests. no one’s getting code in without being reviewed!
  • Believe in Scaling up.  Scaling out is just expensive, and the network is slow!
  • Believe people that allow data to be duplicated throughout the system are reckless. One authoritative place for data!
  • Simple implementations are the best; no need for microservices; they’re complex.

Enjoy your newly minted monolith! It’s going to be fast. It’s going to be simple to modify. It’s going to be awesome.

How do I publish a .NET Core 1.1 application in a Docker container?

With the advent of Microsoft embracing Docker; it’s now possible to release .NET Core apps in Docker containers; and it’s a first class citizen. This means instead of creating custom Docker images, Microsoft has released multiple docker images you can use instead.

The cool thing about these Docker images is that their Dockerfiles are on Github, which is quite amazing if you like to create custom Docker images.  Without more ado, here’s how I set up the project’s Dockerfile, and I created a file so that I could script this repeatedly.


FROM microsoft/dotnet:1.1.0-runtime
ARG source=./src/bin/Release/netcoreapp1.1/publish
COPY $source .
ENTRYPOINT [“dotnet”, “MyProject.dll”]

Let’s take it line by line:

FROM microsoft/dotnet:1.1.0-runtime says to create a new image Microsoft’s dockerhub against the dotnet repository, against the tag named 1.1.0-runtime.

ARG source=./src/bin/Release/netcoreapp1.1/publish says to create a variable called source that has the path of ./src/bin/Release/netcoreapp1.1/publish (the default publish directory in .NET Core 1.1).  This path is relative to the project.json file.

WORKDIR /app means to create a directory  in the docker container and make it the working directory.

COPY $source . says to copy the files located at the $source to /app, since that directory was previously defined as the working directory.

EXPOSE 5000 tells docker to expose that port in the container so that it’s accessible from the host.

ENTRYPOINT ["dotnet", "MyProject.dll"] says the entrypoint for the container is the command: dotnet MyProject.dll.

This would be the same as:

CMD "dotnet MyProject.dll"

So that’s the docker file, but there are a few other steps to get a running container; first you have to make sure you’re running ASP.NET Core applications against something other than localhost, and then you still have to publish the application, create the docker image, and run the docker container based on that image. I created a file to do that, but you could just as easily do it with PowerShell:

# change directory to location of project.json
pushd ./src 
# run dotnet publish, specify release build
dotnet publish -c Release
# equivalent to cd .. (go back to previous directory)
# Create a docker image tagged with the name of the project:latest
docker build -t "$SERVICE":latest .
# Check to see if this container exists.
CONTAINER=`docker ps --all | grep "$SERVICE"`
# if it doesn't, then just run this.
if [ -z "$CONTAINER" ]; then
  docker run -i -p 8000:5000 --name $SERVICE -t $SERVICE:latest
# if it does exist; nuke it and then run the new one
  docker rm $SERVICE
  docker run -i -p 8000:5000 --name $SERVICE -t $SERVICE:latest

My ASP.NET Core directory structure is set up as follows:

- src
    - project.json
    - //snip..
- tests
- Dockerfile
- build.ps1

This let’s me keep the files I care about (buildwise) as the base of the directory; so that I can have a master bootstrap file call each directory’s build files depending on the environment. You may want to mix these, but this also allows me to keep certain files out side of Visual Studio (I don’t want it to track or care about those files).

Then, all I have to do to build and deploy my ASP.NET Core 1.1 application is to run:


And it’ll then build, deploy, change the container if needbe, and start the container.

Fix for ASP.NET Core Docker service not being exposed on host

When attempting to Dockerize my ASP.NET Core micro-service, I ran into an interesting issue. We use Docker’s Network feature to create a virtual network for our docker containers; but for some reason I wasn’t able to issue a curl request against the ASP.NET Docker container, it simply returned:

curl: (52) Empty reply from server

Well crap.  Docker was set up correctly; and ASP.NET Core applications listen on port 5000 typically:

Complete Dockerfile:

FROM microsoft/dotnet:1.1.0-runtime
ARG source=./src/bin/Release/netcoreapp1.1/publish
COPY $source .
ENTRYPOINT ["dotnet", "MyProject.dll"]

ASP.NET Core dotnet run output:

Hosting environment: Production
Content root path: /app
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

Hm. It’s listening on localhost (the docker container), and I’ve exposed port 5000, right? Maybe my port settings are wrong when I spin up the container? Let’s check:

docker run -i -p 5000:5000 --name my-project -t my-project:latest

That checks out. The syntax for docker -p is HOST:CONTAINER, and I’ve made them 5000 on both sides just for testing, but I’m still not getting a response.

I found out that by default, ASP.NET Core applications only listen on the loopback interface — that’s why it showed me localhost:5000. That doesn’t allow it to be viewed externally from the host. Sort of a bonehead moment on my part; but there you are. So to fix it, I can tell Kestrel to listen using the UseUrls() method and specify interfaces to listen on:

public static void Main(string[] args)
  var host = new WebHostBuilder()
    .UseUrls("http://*:5000") //Add this line


Now, it will listen to all network interfaces on the local machine at port 5000, which is exactly what I want.

How do I debug ASP.NET Core 1.1 applications in Visual Studio 2015?

I updated .NET Core 1.0.1 to .NET Core 1.1.0, and am no longer able to ‘Start Debugging’ (F5) from Visual Studio 2015.

When I tried to debug, I’d get the following error in the output console in Visual Studio:

The program '[6316] dotnet.exe' has exited with code -2147450751 (0x80008081).
The program '[4612] iisexpress.exe' has exited with code 0 (0x0).

The latest version of .NET Core is 1.1 (1.1.0 if you’re a package manager type), but Visual Studio 2015 only supports F5 Debugging with .NET Core 1.0.1.

You can still debug .NET Core 1.1.0 Applications in Visual Studio 2015, however. Here’s how:

Open the Package Manager Console (or use cmd.exe).

Type dotnet run from either console.
You should see the following prompt:


Go to the debug menu in Visual Studio and click “Attach to Process” (or use the Ctrl+Alt+P shortcut).

attachtoprocessLook for dotnet.exe, and hold down shift while selecting all the dotnet.exe processes (it’s one of those three; and you can actually select all at the same time).

Click the “Attach” button.

You’ll know you’re debugging because set breakpoints will change from clear interiors to a red interior (indicating the breakpoints have been loaded).

Happy Debugging!

Fix for Cannot find runtime target for Framework .NETCoreApp=v1

I’ve been working on an ASP.NET Core application; and even though I constantly say I’ll never upgrade in a Dev Cycle, I did.

I updated from .NET Core 1.0.1 to .NET Core 1.1.0, and during the upgrade path, I updated the packages in Nuget using Visual Studio, and suddenly, everything stopped working, specifically I’d get the following error when trying to build:

Can not find runtime target for framework '.NETCoreAPP, Version=v1.0' compatible with one of the target runtimes:

It turns out, Nuget modifies the project.json file in Visual Studio in one specific crucial way: It changes what was previously:

"Microsoft.NETCore.App": {
      "version": "1.0.1",
      "type" :  "platform" 


"Microsoft.NETCore.App": "1.1.0",

Notice the difference? the former JSON is an object, and Nuget replaces it with a string. To fix the error, simply make that line look like the object it was previously:

"Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type" :  "platform" 

This error should only happen if you try to upgrade in Visual Studio.

How do I change the name of my ASP.NET Core project?

By default, the project output name when building your .NET Core project is the same name as the directory/folder that contains the project.json (which will be back to *.csproj) as of Visual Studio 2017.  So if you’re like me, and you keep your projects like so:

- src
  - project.json
  - ProjectName.xproj
  -  <snip>Lots of *.cs files and folders</snip> 
- tests
- Dockerfile

Then you’re going to run into a problem because the name of your output file will be src.dll, since the containing directory is src. Not what you want.

To fix this, you can change a setting in the project.json (or the ProjectName.csproj file):

For project.json, under the buildOptions object:

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true,
    "outputName":  "MyProjectName"       //add this 

Add the outputName property, and your string value will be the name you want to be emitted for your DLLs and settings.

For ProjectName.csproj in Visual Studio 2017, it’s the same property:


This will allow you to name the project whatever you want, and not be dependent upon the convention of the folder name as project name.