Reviews

BUILD-fest 2017

Chris Kirby

19 May 2017 — 6 min read

I had a great time getting my yearly injection of the future as Microsoft sees it. The Azure, The Windows, The AI, and The .NET all got The Love. Azure even received the coveted day one 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 BUILD container.

.NET Standard 2.0

Any OSS library maintainer or framework developer will tell you this is 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 dependencies 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 solving all of these problems. Moving forward, you'll target your apps and libraries to a version of .NET Standard, guaranteeing 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: the full .NET framework running on Linux! And in a Container of course, we're not animals.

More Info

Serverless

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 primarily interested in functions as a service. I've been a massive fan of Azure Functions since the beginning, and I've played with and written about them on this blog. However, I'm all in with the latest updates announced at BUILD this year. 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 I think will significantly impact deploying your microservice 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 into a class library. I dug into this a bit when chatting with the functions team at Build. The decision to move away from .csx it 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 as it has before...so that is good news for those who want to continue leveraging the simplicity of running C# code sans compiler. The other significant change 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 are 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 same code you write for the Azure service without needing 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 compelling stuff. The concept is simple, you have a management node that 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:

The Node toolsnpm i -g azure-functions-core-tools
The VS Preview (side-by-side install needed for the tools
The VS tools (uses the same node runtime)
The Windows Runtime
Session: Day in the life, a quick overview of the new tooling and features

** UPDATE

v2 of the Azure functions runtime now supports .NET Core 2.0. See Develop Azure functions on any platform.

Cosmos DB

Cosmos puts a real-time, globally distributed, low latency, SLA (4 9's) backed infrastructure underneath all of the storage APIs we already use. It continues support for DocumentDB and MongoDB for document storage. It 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 significant concepts being introduced with Cosmos are its new consistency levels and its new per-minute RU scaling. Inconsistency, 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 scoped per request in your chosen API. In scale, you can 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 SMBs or startups on tight budgets and only need that scale 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 week...no more convincing is needed (excluding Functions, of course :). Containers are a fantastic way to wrap your app and all its dependencies into a secure sandbox and deploy it to any host or service that supports your container. Without diving 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 organization's 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 to be confused with Docker Swarm, the native form of container orchestration provided by Docker, this is Docker running on Service Fabric's orchestration. And with the just announced Compose support, you can bring in your existing docker-compose.yml and push it directly to an 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 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 affordable headsets supporting Windows this fall. At the Microsoft store, you can pre-order a developer headset from Acer or HP for around $300 bucks. 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 is leveraging more of the Cognitive Services, especially some of the new APIs 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 I plan to use some of the new Language APIs in upcoming applications. Really excited about the new Speech and Knowledge APIs as well; so many exciting ways to use that technology...and who wouldn't want to use the Custom Speech Service in something!

More info: