Developer, tech enthusiast, and gamer.

VP of Technology, Authenticom

BUILD-fest 2017

BUILD-fest 2017

I had a great time getting my yearly injection of the future as Microsoft see's it. The Azure, The Windows, The AI, and The .NET all got The Love. Azure even received the coveted day 1 keynote slot that typically belonged to Windows and Microsoft partners building apps, so from my perspective, we got right to the good stuff. So put your "augmented mixed reality" headsets on , scale your serverless compute, and lets intelligently (and responsibly) Dock(er) with the the BUILD container.

.NET Standard 2.0

Any OSS library maintainer or framework developer will tell you that this is both very welcome and long overdue. Gone will be the days of targeting this framework or that device. Is that Mono 4.x compatible? If I target .Net Core 1.x, will my nuget dependences still work? How do I make a PCL again? You get the idea and have likely experienced this yourself. The .NET team at Microsoft has been working in the open for a while now on .NET Standard, which means to solve all of these problems. Moving forward, you'll target your apps and libraries to a version of .NET Standard, which will guarantee you a level of API coverage that will run on X number of .NET frameworks installed in the wild. What's new with 2.0 is the promise of full API coverage for the full .NET Framework, Xamarin's Mono framework, and existing PCL's. That's huge! Let me say that another way, that's the full .NET framework running on Linux! And in a Container of course, we're not animals.

More Info


There is a lot to the serverless story at Microsoft. And while I plan to experiment with Logic apps and Flow for at scale business processes, I'm mostly interested in functions as a service. I've been a huge fan of Azure Functions since the beginning and I've played with and written about them before on this blog. However, with the latest updates announced at BUILD this year, I'm all in. Now, not only do we have first class tooling for both C# (via vs 2017) and Node (via VS Code), but we've also gained the full runtime to run functions wherever (Windows) and whenever we want. So let me break down a few of the areas which I think will have the biggest impact on deploying your micro service code to Functions in production.

C# functions are now pre-compiled

Using the new Preview tooling, the functions you build, debug, and deploy locally (or vi CI) are compiled to a class library. I dug into this a little bit when chatting with the functions team at Build, and the decision to move away from .csx was pretty obvious...using .cs classes provides a better local development and debugging experience. That doesn't mean .csx apps are no longer supported though, you can still drop in your run.csx and the runtime will still work like it has that is good news for those of us who want to continue leveraging the simplicity of running C# code sans compiler. The other big change that comes with the tooling, is leveraging WebJob attributes to define the function triggers, inputs, and outputs in your code. The attributes are then used to generate the same .json files Functions users have been used to. So again, decisions based on optimizing the development experience and they are very welcome.

The Runtime

This may not sound like a big deal, but I assure you that anyone working in a hybrid cloud environment or a less than progressive enterprise, will welcome it with open arms. This isn't just for low latency IoT scenarios, it's for anyone wanting to leverage their on premises compute using the exact same code you write for the Azure service...without the need to deploy the full Azure stack. This is local compute, running off of cloud (or Stack) triggers, on as many workers as you want. That is incredibly powerful stuff. The concept is simple, you have a management node which serves up the portal and orchestrates the work, and then you have X number of worker nodes distributed to run your functions. So scale to your hybrid cloud to save money or run your on premises only code in the same runtime for maximum portability. In the wise words of Lloyd, "That sounds good, I'll have that".

More info:

Cosmos DB

Cosmos puts a real-time, globally distributed, low latency, SLA (4 9's) backed infrastructure underneath all of the storage API's we already use. It continues support for DocumentDB and MongoDB for document storage, and brings in Table storage (yes that one) as a fully indexed key value store, and Graph which supports the Gremlin (Apache) language for querying and storing entities. The other major concepts being introduced with Cosmos are it's new consistency levels and it's new per minute RU scaling. In consistency, there are five new levels ranging from Strong, as the most consistent and costly, to Eventual as the least consistent and cost effective. Consistency can be defaulted on the account level and can also be scoped per request in your chosen API. In scale, you can now programmatically scale your request units in near real-time based on predictable spikes in your usage. This will be huge in terms of cost savings for most SMB's or startups that are on tight budgets and only need that scale....well, when they need it.

More info:

Containers, you may have heard of them

Just in case the sarcasm was lost on you, you can't visit a website in the development or devops space that does not use, mention, or refer to containers. I get it, PaaS is so last more convincing needed (excluding Functions of course :). Containers, are in fact, a fantastic way to wrap your app and all of its dependencies into a secure sandbox and deploy to any host or service which supports your container. Without diving in too deep into what containers are and why you should use them...what's new in Azure land that you might consider? Some of the big ones for me are the new App service support for containers and the new Docker and Docker Compose support in Service Fabric.

App service Linux container support

Microsoft has released, in preview, App Services with Linux container support. What's exciting to me, is that it supports public and private Docker hub registries out of the box. For some, including myself, deploying my containers to Azure will be as simple as hooking up my orgs Docker Hub registry to the new App Service. For now, only Linux containers are supported, but they are working to provide Windows based containers later this year.

Full support for Docker in Service Fabric

Not be be confused with Docker Swarm, which is the native form of container orchestration provided by Docker, this is Docker running on Service Fabric's own orchestration. And with the just announced Compose support, you can bring in your existing docker-compose.yml and push it directly to a SF cluster. It's not fully baked yet, but I plan to start playing with this right away as I'm working through containerizing some older windows based applications.

More info:

Augmented Virtual Mixed Reality

Why are VR and AR always fighting, cant we all just get along? The solution? Mixed reality is born! Nothing dramatically new here if you've been following Hololens. What I'm most excited about here is that we'll finally start seeing some affordable headsets this fall supporting Windows. You can pre-order a developer headset from Acer or HP for around $300 bucks today at the Microsoft store. I've opted for the HP, and I'm looking forward to playing more with the mixed reality dev kit later this summer.

AI, ML, DL, and Cognitive services for everyone!

Depending on where you live on the developer spectrum, there is something in this for you. Scientist's have R Studio (OSS) support in SQL Server & Azure Services, Developers have Azure ML Studio & Cognitive services, and in Big data you've got Deep learning and the new Azure GPU clusters along with new R and Python runtime support in SQL Server 2017. What I'm most interested in on the application development side are leveraging more of the Cognitive services, especially some of the new API's launched at BUILD this year. I have used the Language Understanding Intelligent Services (LUIS), which is totally named to have a cool acronym, while developing with Bot Framework, and plan to use some of the new Language API's in upcoming applications. Really excited about the new Speech and Knowledge API's as well, so many interesting ways to use that technology...and who wouldn't' want to us the Custom Speech Service in something!

More info:

So much more

All Sessions:

Scott Hanselman's Rollup for .NET Developers:

Working with the Azure Storage REST API in automated testing

Working with the Azure Storage REST API in automated testing