Azure

Recap: Microsoft Build 2020

Posted on by Mark Johnson

“3 time zones, hundreds of thousands of attendees, hundreds of sessions and 48 hours”.

That just about sums up the MSBuild conference this year and what an achievement. Many conferences were cancelled due to Covid-19 but Microsoft rose to the challenge of a 100% virtual conference and they absolutely delivered.

The conference felt very connected, the community was involved, the speakers showing demos from their homes and a sense of we are all in this together. There were some great innovations in the imagine cup, all of them deserved to win but only one could.

Satya Nadella inspiring us with his vision and highlighting how technology and developers were helping in the current crisis. Well worth watching.

Scott Hanselman and guests gave a very different type of keynote, it was fun, interactive, open and still showed off some cool tech. If you haven’t seen it, watch it here.

Beyond the keynotes there was so many announcements of general availability, new tools, new services and even new previews, It was impossible to keep up with everything going on or attend all the sessions. So here are some of the things that stood out from the sessions I got to attend.

Windows Terminal 1.0 Released

I’ve been using the new terminal for a while now and it’s become my go to command line tool, really glad its got to 1.0. Find out more and give it a go.

Winget

Other operating systems like Linux have had native package managers for what seems like forever but Windows has only got close with tools like chocolatey, To be honest I didn’t think we would get a native package manager for Windows, but now we have with the introduction of Winget. Whilst this is a preview release it looks good and well worth checking out.

Codespaces

Codespaces look amazing, the ability to run a dev environment with all the dependencies without downloading everything to your local machine is very cool.

Just to add some confusion there is Visual Studio Codespaces and GitHub Codespaces.

GitHub Codespaces

GitHub Codespaces provides the ability to setup a development environment including all the dependencies and start editing the code without leaving the browser. This means that devices that would normally not be able to build/run the code now can, for example the iPad.

Editing the code in GitHub Codespaces is done by using a web based version of Visual Studio Code. If you are running VS code on a support operating system (Windows, Linux or Mac) then you can sync your settings to the web version and share your extensions, colour schemes, etc.

Visual Studio Codespaces

Visual Studio Codespaces is designed to be used from a browser (just as with GitHub Codespaces) but also from within Visual Studio Code or Visual Studio 2019.

Dapr

I had heard about Dapr but not in any detail, so attending the session to get more was well worth it. The description on the website says “Dapr is a portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.”

I think this diagram from the Dapr website helps visualize it:

Without Dapr we might have a Service A that uses an SDK to communicate with Redis to push data and Service B that also uses the SDK to read data.

Now suppose we wanted to change Redis for Cosmos Db, we would have to change both services. Using Dapr, each service would use the Dapr API and so a change to the Dapr sidecar is all that would be needed.

During the Q&A from the session there was interesting points:

  • You can run Dapr using the CLI
  • Dapr can be ran locally
  • You can host Dapr in Kubernetes, Service Fabric and Azure Functions (coming soon)
  • Dapr works along side of service mesh’s

Blazor WebAssembly 3.2 Released

I’ve not had a chance to look into this but it looks very promising, writing C# code instead of JavaScript for the UI is a really nice option. Take a look at the Release Blog.

Static Web Apps

Welcome to a new member of the Web App family Static Web Apps, globally available static frontend and dynamic backend powered by serverless api’s.

Despite this being very new there is already an example of deploying a Blazor WebAssembly app in Static Web Apps https://dev.to/azure/deploy-blazor-webassembly-apps-to-azure-static-web-apps-6bp.

Summary

There were so many sessions to attend and I’ll definitely be catching up with the other sessions when the recordings are available, check out myBuild, the Channel9 page and/or YouTube channel.

I’m sure there will be more updates in the coming weeks and months on some of these. Happy coding 🙂

Azure, DevOps

Co-locate IaC with My Application

Posted on by Mark Johnson

Over the last few years there has been a definite increase in the use of IaC (Infrastructure as Code) within cloud development and companies seem to choose a single team to create/maintain their infrastructure, or each application team to create/maintain their infrastructure, or a combination of the two.

No matter which direction is chosen there are some considerations in maintaining infrastructure as code.

  • Source control the IaC
  • Keep plain text secrets out of source control
  • Applying least privilege to who can change the production infrastructure
  • Reviewing the changes to the infrastructure
  • Easy to deploy infrastructure changes
  • Reliable infrastructure deployments

All of these things are easily achieved with any source control, a good review process and a well defined deployment pipeline, but this article is about “Should I co-locate my Infrastructure as Code with my application?“

I have certainly co-located IaC myself when working in an applications team deploying to Azure, keeping ARM (Azure Resource Management) templates in a folder along side my application in source control, so when the code is built the infrastructure can also be created/updated during the deployment process.

There are many benefits to this as the team can:

  • Maintain a single repository to hold code and IaC
  • See what infrastructure they are responsible for
  • Decide/change what technology is used for their application e.g. changing the data store type or introducing a message bus, etc.
  • Apply monitoring/alerting to their application easily
  • Deploy to an environment knowing the required infrastructure will be created/updated

Sounds like I’ve answered the question, and that I agree that I should co-locate my IaC with my application, hmmm, well not quite, this only considers a single application and team and does not consider multiple teams or shared infrastructure.

So what if there are multiple teams, each independent and not requiring any shared infrastructure, in this scenario co-locating the IaC would give the same benefits as a single team/application.

Now what if there are multiple teams and shared infrastructure? Co-locating all the IaC in this scenario doesn’t make any sense as the shared infrastructure doesn’t belong to any application. The multiple teams could share this infrastructure and maintain it between them or another team could be responsible, depending on the team makeup.

Summary

I believe that co-locating the application specific IaC with the application code to be a good thing and gives the application team full control over their application. However any non-application specific IaC should be located away from the application, this maybe Virtual Networks, Cloudflare configuration, Application Gateways, etc.

However you maintain your infrastructure at the moment, consider this may change as applications grow or you introduce multiple applications. I suggest reviewing and revising how you manage infrastructure on a regular basis, continue to improve processes and practices and find the best way to build and maintain your cloud infrastructure.

Additional Information

If you are unfamiliar with IaC then I suggested looking at the following links:
Azure ARM templates
Azure CLI
Ansible
Terraform
Pulumi

2