Cloud-native developer. Distributed systems wannabe. DevOps and continuous delivery. 10x troublemaker. DevOps Manager at VHT.
6797 stories
1 follower

BlueMilk 0.8: It’s fast, runs MVC apps, and probably needs a new name

1 Share

I just published the latest BlueMilk v0.8 to Nuget with quite a bit of performance optimization, some additional StructureMap functionality added in, and the ability to handle every kind of service registration that a basic MVC Core application will throw at an IoC container.

BlueMilk is the current codename for a new IoC tool that partially originated in Jasper. You can read about the goals and motivation for the project in Introducing BlueMilk: StructureMap’s Replacement & Jasper’s Special Sauce.

One of my colleagues made the observation yesterday that while being a Star Wars nerd and getting the reference, the name “BlueMilk” is off putting and we probably need to change that (plus it feels awkward to say out loud to me). Other than Marten and BlueMilk, all the projects in the JasperFx organization are named after other little towns or landmarks around my hometown. Once upon a time, I parked some of the code that’s not part of BlueMilk in another repository named “Lamar” that fits that naming scheme, plus my wife is doing a master’s program at Lamar University, I have a former coworker who played baseball there, and it’s also the name of a Texas revolutionary hero. If nobody has a better idea, I’ll probably rename BlueMilk to “Lamar.” My other idea was “Corsair,” but that’s really just too cool a name for yet another IoC tool.

Usage in MVC Core

I blogged last week that BlueMilk is Ready for Early Adopters. I was wrong of course, but thank you to Mark Warpool and others for actually trying to use it and giving me some important feedback. The big problems with 0.7 were that the code generation model that BlueMilk uses internally can’t handle internal types and didn’t allow for using generic types as constructor parameters. Wouldn’t you know it, ASP.Net Core MVC has quite a bit of both of those usages in its service registrations and BlueMilk was falling flat on its face in an MVC Core application (correction, “works on my box,” fails on a couple registrations in AppVeyor even though it’s the same version of the .Net SDK. Still saying it’s good to go at least until someone proves it’s a no go).

After a couple fixes (one big and one small), there’s now a test in BlueMilk that successfully builds every possible service registration from a basic MVC Core application. For those of you following along at home, I had to revert to using the dynamic Expression compiled to a Func<> trick to slide around the nonpublic types just to call non-public constructors.


A caveat here, it’s just not terribly likely that your IoC tool of choice is the performance bottleneck in your system. 

First off, Maksim Volkau has built some seriously cool stuff, and BlueMilk got quite a bit of the performance boost I’m talking about here from using his ImTools library (both Marten and StructureMap use FastExpressionCompiler as well).

One of my coworkers asked how BlueMilk compared to StructureMap in terms of performance, so I threw together some benchmarks where I was able to show BlueMilk being over 5X faster than StructureMap over a range of potential usages. I made the mistake of tweeting about that yesterday, and Eric Smith asked me how BlueMilk compared to the build in DI container inside of ASP.Net Core. After adding a comparison to the built in container to my BenchmarkDotNet metrics, I could see that BlueMilk lagged a bit (~30% slower over all). Several optimizations later, I can now say that BlueMilk is (barely) faster than the built in DI container and closing in on an order of magnitude faster than the latest StructureMap.

Using a barebones MVC Core application with logging added in as well, I built a series of metrics that just loops through the registered types and builds each possible type. It’s a lazy way of building up metrics, but it gave me a mix of registrations by type, by lambda, pre-built objects, and some deeper object graphs. It’s probably a bit bogus because this isn’t the way that an application is going to use the IoC tool at runtime and may weight more heavily on usages that don’t actually happen.

That being said, here’s the overall metrics on just creating every possible registered type in that minimal MVC Core application:

BenchmarkDotNet=v0.10.12, OS=macOS 10.12.6 (16G1212) [Darwin 16.7.0]
Intel Core i7-6920HQ CPU 2.90GHz (Skylake), 1 CPU, 8 logical cores and 4 physical cores
.NET Core SDK=2.1.4
  [Host]     : .NET Core 2.0.5 (Framework, 64bit RyuJIT
  DefaultJob : .NET Core 2.0.5 (Framework, 64bit RyuJIT

   Method | ProviderName |      Mean |     Error |    StdDev |
--------- |------------- |----------:|----------:|----------:|
 AllTypes |   AspNetCore |  73.98 us |  1.444 us |  1.976 us |
 AllTypes |     BlueMilk |  70.92 us |  1.408 us |  2.392 us |
 AllTypes | StructureMap | 646.28 us | 12.856 us | 27.398 us |

Getting much more specific, here are some finer grained metrics with an explanation of the different measurements below:

BenchmarkDotNet=v0.10.12, OS=macOS 10.12.6 (16G1212) [Darwin 16.7.0]
Intel Core i7-6920HQ CPU 2.90GHz (Skylake), 1 CPU, 8 logical cores and 4 physical cores
.NET Core SDK=2.1.4
  [Host]     : .NET Core 2.0.5 (Framework, 64bit RyuJIT
  DefaultJob : .NET Core 2.0.5 (Framework, 64bit RyuJIT

      Method | ProviderName |         Mean |        Error |        StdDev |       Median |
------------ |------------- |-------------:|-------------:|--------------:|-------------:|
 CreateScope |   AspNetCore |     429.0 ns |     8.288 ns |      7.347 ns |     428.2 ns |
     Lambdas |   AspNetCore |   1,784.4 ns |    25.886 ns |     22.948 ns |   1,777.8 ns |
   Internals |   AspNetCore |     914.2 ns |    17.575 ns |     15.580 ns |     912.6 ns |
     Objects |   AspNetCore |     810.2 ns |     7.723 ns |      6.449 ns |     808.7 ns |
  Singletons |   AspNetCore |  18,428.6 ns |   203.784 ns |    159.101 ns |  18,441.3 ns |
       Scope |   AspNetCore |     556.7 ns |     7.823 ns |      7.317 ns |     555.9 ns |
  Transients |   AspNetCore |  41,882.1 ns |   391.872 ns |    327.231 ns |  41,787.8 ns |
 CreateScope |     BlueMilk |     110.8 ns |     2.205 ns |      2.944 ns |     111.4 ns |
     Lambdas |     BlueMilk |   2,138.1 ns |    27.465 ns |     25.691 ns |   2,140.5 ns |
   Internals |     BlueMilk |     332.2 ns |     3.926 ns |      3.278 ns |     331.4 ns |
     Objects |     BlueMilk |     586.9 ns |    17.605 ns |     51.633 ns |     575.4 ns |
  Singletons |     BlueMilk |   9,852.8 ns |   196.721 ns |    548.380 ns |   9,780.1 ns |
       Scope |     BlueMilk |     330.8 ns |     5.781 ns |      4.828 ns |     332.1 ns |
  Transients |     BlueMilk |  54,439.2 ns | 1,083.872 ns |  2,967.082 ns |  53,801.7 ns |
 CreateScope | StructureMap |  16,781.0 ns |   334.284 ns |    948.307 ns |  16,584.2 ns |
     Lambdas | StructureMap |  12,329.5 ns |   244.697 ns |    686.155 ns |  12,121.9 ns |
   Internals | StructureMap |  10,585.0 ns |   209.617 ns |    393.712 ns |  10,519.9 ns |
     Objects | StructureMap |  17,739.9 ns |   430.679 ns |    560.005 ns |  17,606.7 ns |
  Singletons | StructureMap | 162,029.0 ns | 3,191.513 ns |  6,148.961 ns | 161,590.8 ns |
       Scope | StructureMap |   5,830.1 ns |   158.896 ns |    463.507 ns |   5,700.8 ns |
  Transients | StructureMap | 451,798.1 ns | 8,988.047 ns | 21,707.143 ns | 448,860.3 ns |

The metrics named in the first column are:

  1. “CreateScope” — measures how long it takes to create a completely new container scope as MVC Core and other frameworks do on each HTTP request.
  2. “Lambdas” — resolving services that were registered with some kind of Func<IServiceProvider, object> factory
  3. “Internals” — resolving non-public types
  4. “Objects” — resolving services that were registered with a pre-built object
  5. “Singletons” — all singleton registrations of all kinds
  6. “Scope” — bad name, but all registrations with the “Scoped” lifetime
  7. “Transients” — all registrations with the “Transient” lifetime


There’s still some performance fat in BlueMilk’s code, but I’m saying that I’ve hit the point of diminishing returns for now and I’m staying put on performance.

New Functionality

BlueMilk v0.8 adds in some old StructureMap behavior for:


I’m probably done working on BlueMilk for now other than the inevitable bug reports. When I do come back to it (or someone else picks it up), the next version (v0.9) will hopefully have support for decorators and interception similar to StructureMap’s existing model. I’d hope to have a 1.0 version out sometime this summer or fall after it’s been in production somewhere for awhile.

Read the whole story
2 hours ago
Akron, OH
Share this story

New VSTS Messaging Extension for Microsoft Teams

1 Share
Today we are releasing our new Messaging Extension to add to the integrations between Microsoft Teams and Visual Studio Team Services (VSTS). The messaging extension allows you to search, find, and discuss specific work items in your channel or private chats. It is great way to have a group conversation about your work, without leaving... Read More
Read the whole story
2 hours ago
Akron, OH
Share this story

The False Dichotomy of Monoliths and Microservices

1 Share

When learning about microservices, you're nearly always introduced to the concept of a monolith. If you're not doing microservices, you're building a monolith. If you're not building a monolith, you must go with microservices. If you're building a monolith, perhaps you're doing it well and it's a majestic monolith.

From my early encounters with microservices, this dichotomy bothered me. The discussion of a monolith was nearly always focused on its purported problems. Difficult to develop. Difficult to deploy. Difficult to scale.

Which I always found odd, I've built applications that weren't microservices that had none of these properties, so what was different?

Redefining Microservices and Monoliths

The problem is that this is presented as a dichotomy. But it is a false dichotomy. It isn't an either/or choice. And we can get away from this false dichotomy by refining our definition of microservice (which, as even Wikipedia shows, doesn't have consensus about what the term means).

From my microservices FAQ:

A microservice is a service with a design focus towards the smallest autonomous boundary.

And a monolith:

A monolith is software whose design, information model, and interface combine multiple competing and interfering domains into one single application and data model. There is no longer consensus from users and designers of the software on terms, modeling, information design, or interface. The coupling between competing models makes future changes to the system difficult or impossible.

We can still build services that don't strive for the smallest autonomous boundary. And we can build monoliths out of distributed components. And our microservices can also be individual monoliths, if they can't meet the defined operational, business, and delivery objectives.

It's also why I see the question of "do I start with microservices or monoliths" to only have one answer: Mu. No one strives for a monolith, but they may not have a good enough understanding of the business to understand where the service boundaries should be. You're asking the wrong question, you need to unask the question and start over.

Read the whole story
2 hours ago
Akron, OH
Share this story

Now Available – AWS Serverless Application Repository

1 Share

Last year I suggested that you Get Ready for the AWS Serverless Application Repository and gave you a sneak peek. The Repository is designed to make it as easy as possible for you to discover, configure, and deploy serverless applications and components on AWS. It is also an ideal venue for AWS partners, enterprise customers, and independent developers to share their serverless creations.

Now Available
After a well-received public preview, the AWS Serverless Application Repository is now generally available and you can start using it today!

As a consumer, you will be able to tap in to a thriving ecosystem of serverless applications and components that will be a perfect complement to your machine learning, image processing, IoT, and general-purpose work. You can configure and consume them as-is, or you can take them apart, add features, and submit pull requests to the author.

As a publisher, you can publish your contribution in the Serverless Application Repository with ease. You simply enter a name and a description, choose some labels to increase discoverability, select an appropriate open source license from a menu, and supply a README to help users get started. Then you enter a link to your existing source code repo, choose a SAM template, and designate a semantic version.

Let’s take a look at both operations…

Consuming a Serverless Application
The Serverless Application Repository is accessible from the Lambda Console. I can page through the existing applications or I can initiate a search:

A search for “todo” returns some interesting results:

I simply click on an application to learn more:

I can configure the application and deploy it right away if I am already familiar with the application:

I can expand each of the sections to learn more. The Permissions section tells me which IAM policies will be used:

And the Template section displays the SAM template that will be used to deploy the application:

I can inspect the template to learn more about the AWS resources that will be created when the template is deployed. I can also use the templates as a learning resource in preparation for creating and publishing my own application.

The License section displays the application’s license:

To deploy todo, I name the application and click Deploy:

Deployment starts immediately and is done within a minute (application deployment time will vary, depending on the number and type of resources to be created):

I can see all of my deployed applications in the Lambda Console:

There’s currently no way for a SAM template to indicate that an API Gateway function returns binary media types, so I set this up by hand and then re-deploy the API:

Following the directions in the Readme, I open the API Gateway Console and find the URL for the app in the API Gateway Dashboard:

I visit the URL and enter some items into my list:

Publishing a Serverless Application
Publishing applications is a breeze! I visit the Serverless App Repository page and click on Publish application to get started:

Then I assign a name to my application, enter my own name, and so forth:

I can choose from a long list of open-source friendly SPDX licenses:

I can create an initial version of my application at this point, or I can do it later. Either way, I simply provide a version number, a URL to a public repository containing my code, and a SAM template:

Available Now
The AWS Serverless Application Repository is available now and you can start using it today, paying only for the AWS resources consumed by the serverless applications that you deploy.

You can deploy applications in the US East (Ohio), US East (N. Virginia), US West (N. California), US West (Oregon), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Canada (Central), EU (Frankfurt), EU (Ireland), EU (London), and South America (São Paulo) Regions. You can publish from the US East (N. Virginia) or US East (Ohio) Regions for global availability.



Read the whole story
2 hours ago
Akron, OH
Share this story

Label improvements: emoji, descriptions, and more

1 Share

Organizing issues and pull requests with labels can help you manage the chaos and be more productive. To support your labeling efforts and make labels even more useful, we've made a few enhancements.

Using emoji in labels


When words are just not enough, include emoji in your labels to express yourself and the needs of your project through tiny images. ✨


Add descriptions to your labels to provide even more context and help your contributors apply the right ones to their issues or pull requests. Descriptions will appear when you hover your mouse over labels around GitHub.


Now that labels include descriptions, we've added search to the "Labels" page of each repository to help you find the one you're looking for. Filtering labels in the sidebar of your issue or pull request also filters by description.


When editing a label, you'll now see a preview of how it will appear once you save it. Use this preview to choose the perfect color or see how your emoji look.

API and Enterprise support for these features is coming soon!

Learn more about using and editing labels on GitHub.

Read the whole story
2 hours ago
Akron, OH
Share this story

Azure Event Grid: Glue for the Internet


Serverless publisher/subscriber for all of us

February 20th, 2018 I attended the Azure in the ATL meetup group to share a presentation about Event Grid. The feature reached general availability in January and I expect it is more powerful than many developers are aware. I like to think of Event Grid as “serverless publisher/subscriber” because with a few clicks you can have a fully functional event-driven pubsub backbone up and running without worrying about the infrastructure.

Event Grid meetup

The features Event Grid provides include:

  • Event routing
  • Near real-time event delivery
  • Automated publications and subscriptions from Azure resources
  • Platform and language agnostic services (yes, you can publish from your Go app running on Linux and subscribe with AWS Lambda if you like)

As of this writing, the pricing of Event Grid is U.S. $0.60 per million operations with the first 100,000 each month free. That comes with some very impressive service level agreements.

Event Grid performance

I shared a comparison between Event Grid and other services like Event Hubs and Service Bus. For a more in-depth explanation I recommend the excellent blog post by Clemens Vasters titled Events, Data Points, and Messages: Choosing the right Azure messaging service for your data. I walked through the components of Event Grid and then jumped into two demos.

The audience had a great time participating in our 360 degree picture.

For the first demo I created a custom Event Grid topic, then live-coded a cross-platform .NET Core 2.0 console app. The goal was to demonstrate how easy it is to publish to Event Grid even without using any special SDKs — the demo relied solely on the built-in HTTP client that ships with .NET Core. After creating the publisher, I hooked up a Logic App to receive the messages that sent me an email almost immediately. Although that part was written live, all of the functionality is part of the second demo that I have available on GitHub.

The second demo was more involved.

Image app architecture

The flow looks like this:

  • A console app publishes a message with the URL to an image
  • An Azure function is invoked that reads the image, stores the bytes into Blob Storage and then loads some metadata into Table Storage
  • A Logic App also subscribes to the same event, and leverages the Computer Vision API to obtain a caption for the image, then updates Table Storage with the description
Logic App for captioning

Although I’ve seen a few misses (for example, in one pass the API decided a toy figure of superman was a woman wearing a costume), for the most part the results are impressive and match the pictures provided. Here are some of the images I’ve loaded over time. All of these were triggered by Event Grid and captioned with the Computer Vision API.

Event Grid image app

You can view the full deck here:

All of the source code is available here.

Until next time,

Azure Event Grid: Glue for the Internet was originally published in Developer for Life on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read the whole story
7 hours ago
Akron, OH
8 hours ago
West Grove, PA
Share this story
Next Page of Stories