Microsoft Whiteboard anyone? Some additions…

Introduction

About half a year ago I made a post on some practical tips & tricks with “Microsoft Whiteboard“. In today’s post I’ll highlight some additional things that were not mentioned in that post.

 

More Microsoft Whiteboard anyone? 😉

In the last post we invited Satya to our whiteboard…

Which you can do by writing the name with your pen ;

Though I forgot to mention that you can also flip it to a keyboard… By pressing the keyboard sign.

And then you can type Satya’s name. 😉

 

Images!

Do know you can also import images into your whiteboard. Search for the image icon. If you do not see it in the bar, click on the “+” (plus) sign, where you can see it in the dropout menu.

 

Once you clicked on it, you can either do a bing search (similar flow to inviting someone), take a picture with your camera or search for a photo on your device.

So I went for my local device, and selected a screencap I made of a presentation ;

Now it appears in your whiteboard and you can tweak it a bit…

And there we have it… Inside of our whiteboard.

And now we can start drawing on it!

You might wonder in what use cases I use this? On a regular basis we do whiteboard design sessions. Here we ask organizations to provide some context from which we can start. Typically I take this information (in the form of a screencap, with consent given) and insert it into the whiteboard drawing. Where we can then start designing from… Which makes it a lot more tangible for the participants.

 

Bonus TIP ; Surface Book Drawing!

Did you know you can undock your screen and put it on backwards? Afterwards you can fold the book with the screen facing “outside” (or “up”). Below is a picture of my daughter showcasing how this can be done!

That being said… This is a very handy approach when doing these kind of whiteboard sessions. As otherwise your screen will “wiggle” way too much and give you an unsteady hand.

 

Closing Thoughts

I am an avid user of Microsoft Whiteboard! It is an awesome (and free!) tool that helps you virtually collaborate on whiteboarding. If you haven’t tried it out yet, try it out! 😉

Azure Networking ; Service endpoints, Private links and VNET Injection

Introduction

Today’s post is inspired by the combination of a twitter thread from earlier today… and having had the same conversation with a customer earlier today too! Truth be told, there are a variety of networking options when integration Azure Services with your VNET (Virtual Network). So let us go over them!

 

The different options

When you want to integrate PaaS services, you have several options on how to integrate them into your VNET ;

• Service Endpoints
• Private Link
• Deploy inside of a VNET (“VNET Injection”)

 

Now lets us take a look at the differences by using the following schematic ;

 

You will see that both the “SQL Managed Instance” and “Azure Kubernetes” service reside inside of the virtual network. This is what used to be called “VNET injection”, and where you deploy the service directly into the VNET. Typically you give each of those services their own subnet, without any other things inside of it to avoid interoperability issues. Though from then on you can leverage private traffic within your VNET and have hybrid integration scenarios (aka “Connect to On Premises”).

When looking towards the “Azure Storage”, you can see two colors ;

• Purple indicates a “Private Link” & “Private Endpoint”. The private link is the line from the service to the dot. Where the dot is actually the private endpoint, which will have a private ip belonging to the range of the subnet (within the VNET) it belongs too. This means that the service will be able to connects you privately and securely to a service powered by Azure Private Link. The nuance difference between “VNET injection” and “Private Link” is that the first is used for resources dedicated to you (AKS Workers, SQL Managed Instance, …) and the latter is used for services that share resources underneath (AKS Master Nodes, Azure SQL DB, Azure Storage, …). This will also allow you to connect to services in a hybrid integration scenario.
• The orange link depicts the concept of a service endpoint. It extends your virtual network private address space to a shared service. The endpoints also extend the identity of your VNet to the Azure services over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network. If you want to understand more of the mechanics underneath, check the following post from when I took my first glance at them. Important to know is that the service will still have its public IP, and that you will leverage that to connect to it. It is used to connect from inside of the VNET to a public endpoint, while you can configure the firewall of the public service to filter on your private range. It cannot be used to connect to a service in a hybrid integration scenario.

 

Not all options work for all services!

Though be aware that not all services have all options available… Check the documentation of the services at hand and the above options. I know this makes it a bit complex at times. Though the capabilities are constantly evolving! And sometimes network integration is also only unlocked in premium editions of a service. For example, in the past you could only get a fully private scenario for App Service by leveraging the Isolated edition (or “App Service Environment”). This made it possible to inject the service into your VNET. Though it had a starting cost of about 1k USD… With the arrival of Private Link/Endpoint, this is not a requirement anymore. Where the API Management does still require either the Premium (Production) or Developer (Non-Production) variants of the service to unlock VNET integration.

 

Closing Thoughts

Things might be confusing at times. Though I hope this brief post helps you position the different options you have in terms of network integration.

• Service Endpoints ; Connect in a hardened way from a VNET to a shared service
• Private Link ; Give a shared service a private endpoint in your VNET
• Deploy inside of a VNET (“VNET Injection”) ; Deploy a service privately for you into your VNET