Ramblings from an Independent Consultant

In May, I attended the Microsoft BUILD 2018 conference in Seattle. It was my first Microsoft BUILD conference, so I didn’t have any expectations. I’ve watched many of the past BUILD session videos on Channel9 – so I knew the presenters and content would be really good. By the end of the second day of the three-day conference, I had come to the realization that there were too many sessions that interested me to be able to attend them all. By the third day I decided take advantage of the expo and speak with as many product groups as I could – something I wouldn’t be able to do after the conference.

Once the conference was over, I left Seattle with a few key takeaways that I’d like to share.

#1 The MVP experience rocked!

I’ve been an Azure MVP now for just over a year, so I hadn’t heard of any special MVP experience at BUILD. Of all the benefits Microsoft gives its MVPs, the most valuable is access to the product groups and, of course, the MVP Summit (which is a week full of content presented by the product groups).

Microsoft Influencer Pre-Day

I spent the Sunday before BUILD in a large conference room with around 50 other MVPs and RDs attending sessions by the product groups. It was great to get a summary of what was to come at BUILD, and it allowed me to better create my session schedule for the conference.

MVP conference badge lanyards

At BUILD the lanyards (those ribbons that go around your neck with the conference badge) were color-coded for certain groups: MVPs had white, RDs (Regional Directors) had azure blue, MSPs (Microsoft Student Partners) had purple, and regular attendees had black. I found having distinct lanyards served two purposes: I could identify other MVPs easier (which for an introvert like myself helped start a few conversations with “What area is your MVP in?”). I also noticed that product groups at the expo picked up on me being an MVP without my having to mention it.

Fast lane and reserved section for keynotes

I heard that the lines for the keynotes would be huge, but that didn’t turn out to be a problem, since a handful of Microsoft programs (such as MVPs, RDs, and MSPs) enjoyed a fast lane into the keynotes and reserved seating upfront.

#2 If you aren’t already moving to .NET Core, it’s time to reevaluate

I’ve spent most of my career working on software in the financial industry. I don’t know about other industries, but in my experience the financial industry is not an early adopter of new software such as new versions of operating systems, frameworks, and the like. If there is an overwhelming reason to upgrade, then it will happen – but with .NET Core and .NET Standard, the industry isn’t moving very fast.

.Net Core 2.1 and 3.0 roadmap

At BUILD they announced the .NET Core 2.1 RC (with Go Live Support) and a .NET Core 3.0 roadmap. If you’re waiting for the infamous Microsoft version 3 to happen before moving to the next version, you’re in luck – it is on the way! But seriously, if you aren’t yet planning your move to .NET Core, you should start to evaluate why not. The huge performance increases alone in .NET 2.1 (and I’m sure 3.0) may make you want to reconsider and keep in mind some of those performance improvements will never make it to the full .NET Framework.

If you are waiting because you have a heavy dependency on desktop applications, then you’ll want to keep an eye on .NET 3.0 since it brings WPF, WinForms and UWP applications to .NET Core running on Windows.

#3 Containers are now everywhere and you need to know how to use them

I’ve been a huge fan of PaaS since Azure launched and over the years have moved from Cloud Services to Web Apps for many of my clients. Though there are still a few holdouts on Cloud Services – mainly due to the App Service sandbox, which prevents the usage of shared components like the registry, cryptography and GDI, etc. Most, if not all, of these problems can be resolved using containers.

New Container Features with App Services

There were several App Services announcements about its container features and how Web App creation has changed. Now, when you create a web app, you decide if you want to use Windows, Linux or Docker – effectively promoting containers to the same level of choice as determining the operating system. Though if you want to use Windows containers, you’ll need to get on the private preview list or wait a couple of months.

Another new feature is the multi-container Linux Web App, which allows you to use a Docker compose yml file or Kubernetes Pod Definition yml file describing multiple containers to be deployed in a single App Service Web App.

Once the Windows containers functionality comes out of preview, App Service will have a full container story.

· New Azure Portal experience – I think this makes it more approachable for people to try out.

· Ability to deploy Kubernetes nodes into existing VNETs – This makes it more practical for larger projects that seem to be the sweet spot for AKS.

· DevOps Project support – The new DevOps Project makes it easy to create a Kubernetes cluster and wires up a CI/CD pipeline for you in a matter of minutes.

#4 DevOps isn’t only for large companies

The past couple of years, I’ve been learning more about DevOps. However, it is sometimes difficult to convince customers that have smaller IT departments of its value because they are under the impression it is too complicated to get started with.

“Friends don’t let friends right-click and publish” was the running joke in the DevOps sessions I attended. Publishing files from a developer machine to a deployment environment is usually thought of as “quick-and-dirty deployment” and generally not a good idea. But many people still do it, and it often leads to unpredictable deployments that may break in the deployed environment. As we all know, what runs on the developer’s machine doesn’t always run in the deployed environment.

The definition of DevOps shown in the sessions was provided by Donovan Brown:

DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.

To me that definition may sound a bit lofty for a one- or two-person IT department. However, definitions aside, the new DevOps Project resource in Azure makes it really simple to wire up a CI/CD pipeline (taking care of the “continuous delivery” part of the definition).

Improvements to the DevOps Project in Azure

The DevOps Project now covers most of the customer scenarios I need. And, the build and release steps can be modified afterward to account for the ones that aren’t covered. Once you complete the four- step wizard in the DevOps Project, you will get a nice dashboard that provides jumping-off links to project home page in VSTS, project backlogs, users & groups, your code repo, build definitions, build logs, release definitions, web app endpoint, status of the web app and an Application Insights chart. This really is a single pane for your CI/CD and VSTS projects inside of the Azure Portal.

The takeaway here is: the DevOps Project wizard can now build you a “proper” CI/CD pipeline in about the same time it takes to “right-click and publish,” so there really is no excuse any more to not use it.

Closing thoughts on Microsoft BUILD 2018

This was my first BUILD conference, and I was impressed with the size and quality of the event. I really enjoyed being there when the announcements were made. Spending the last day speaking with people on the expo floor was awesome and something that can’t be done any other way. I am still trying to catch up and watch all the BUILD sessions on Channel9 that I couldn’t fit into my schedule.