ShareBlog

In coordination with my new company I am moving all my relevant blog posts to http://www.garybusheyllc.com/ and will no longer be posting new blogs here.  Thank you for following me and I hope you will continue to do so at my new site.

Just announced today is the ability for developers to collaborate in real time in either Visual Studio 2017 or Visual Studio code. Much like you can do with MS Teams or Slack but while working with the code.

https://code.visualstudio.com/blogs/2017/11/15/live-share

I have run into this a lot both as a consultant and just talking to people. People think that just by moving their sites, VMs, or entire company into the cloud then everything will magically take care of itself. The funny thing is I have heard this before with other “magical” technologies and it never happens.

Now anyone who knows me knows I am a HUGE proponent of cloud technologies (particularly Azure) and I think the cloud is going to become more and more important as time goes on. That does not mean that I think everything should go to the cloud and that just by throwing VMs and sites into the cloud it will automatically make them work great. Yes, the cloud has some amazing capabilities around scaling, disaster recovery, and other features but they need to be planned out.

I was talking to one person who was telling me how much the cloud sucked and how they pulled their sites back off the cloud because they were not working correctly. After much discussion it turned out that they had chosen a very small application service plan and never setup any sort of scaling so they were stuck with the small application service plan. While it worked great a lot of the time, the site just crawled when a lot of people were using it, as expected.

So should this site have gone to the cloud in the first place? I cannot say with 100% certainty that it should but based on the discussion I had I believe it was a great candidate for the cloud. The problem was the person 1) didn’t educate themselves on how the cloud really works and 2) did not make any sort of plans on how to move the site and what constitutes success.

I even had one person ask me how to connect a input device to their cloud VM. Well, you can’t. First, you have no idea what machine your VM is actually running on and it could actually change from one day to the next. Second, very few people have access to the Azure data centers and even less have access to the actual physical servers. Third, assuming points 1 and 2 did not exist how did you expect the machine to work? How would you get the information that needs to be inputted into the machine which could be thousands of miles away.

Now this is an extreme case and I seriously doubt I would run into it again but it does show that not everything can be moved to the cloud. Machines that require direct connections to external devices is a great example. Others include data that is deemed too sensitive to go into the cloud (I will not get on my soapbox about cloud security versus on-premises security but lets just say I do not like this reason but it is still a concern for a lot of people), costs (if you just purchased new hardware does it make sense to idle it and use the cloud? Probably not), old operating systems (not sure any cloud provider can support a VMS box), and others.

That brings me to my final point for this post. Why do you want to go to the cloud? Is it because it is the buzzword of the day? That is usually not a great idea. Is it because you heard it can save you money? OK, that is a better reason but still needs research to validate Do you have an overworked IT staff and want to take some load off of them? I have heard this once before, and was a bit shocked when I heard it :), but again while this is a valid reason, research needs to be done to make sure this will work. I think you will find that in the short term there may be more work while settings are being tweaked but long term the workload will decrease.

Just remember, the cloud is a great tool to help you achieve your goals but it will not solve every problem.

One of the most asked for features in Azure is finally here!  Protect your Azure storage and SQL by using Virtual Network Service Endpoints.

Currently, when you create either an Azure Storage or Azure SQL instance they are automatically setup with public IPs.  While this is useful most of the time, there are situations where it just is not warranted and in some cases against security rules and regulations.  This has prevented some companies from utilizing these Azure features.

Yesterday it was announced that the public preview of VNet Service Endpoints for Azure Storage and Azure SQL is available!  Using this you can effectively hide your storage and SQL from prying eyes making them that much more secure.

Read the full announcement, including how to use the endpoints, here

If you have not heard of Azure Snapshot debugger, part of Application Insights, it is well worth your time to become acquainted with it.  It allows you to view a debug session of a production instance in the browser as well as download the information into Visual Studio for more debugging.

This week’s Azure Friday is about it and they walk you through an example of how to debug an issue in production code.  In addition there is an excellent MSDN article about it as well.  Even though the article is geared towards .Net Core, Snapshot debugger also works with .Net.

This is going to be a very useful tool to add to your debugging arsenal.

Microsoft just released a preview of the Azure AD Managed Service Identity (MSI) feature.  What this will allow you to do is to completely stop having to store credentials either in code (which is a MAJOR no-no) , in your config file (slightly better), or anywhere else.  Azure will generate a “bootstrap identity” which can then be used to access other Azure features to get information.  If you need to store a password for a 3rd party system, you could place it in the Azure Key Vault and use MSI to get access to the Key Vault without having to save the Key Vault access codes anywhere.

Just another way Microsoft is making Azure more and more secure.

For more information check out the Microsoft Azure blog posting.

Edit:  You need to opt-in to this and Microsoft is only letting a few tenants in at a time. Go to this site for more information.

In a continuation of the announcement of the Azure Event Grid, Azure Blob storage now has storage events in preview.  Azure Blob storage will trigger events when a blob is added or deleted (no word on any other events like blob modification) and right now it is only available for the US West Central location with more locations coming soon.

Read the full announcement here

In an interview I had recently (been doing that a lot lately trying to find a good job) I had one person ask me “What do you feel is the biggest difference between developing for on-premises and the cloud?”   That one caught me a bit off guard as I have never really considered it before.  Is it the fact that you have so many readily available services to use?  The fact that you can scale out your code quickly and easily? The fact that you can make it instantly available to everyone in the world? The tools involved?  I was thinking of all those items when it the answer came to me in a flash.  It isn’t any of those things (at least in my opinion).  It is how you handle errors.

When you are on-premises you do everything you can to make sure that your program will not stop for any reason.  This starts with the hardware.  Your server will most likely have multiple power supplies, each of those plugged into a different circuit, RAID enabled hard disks, and more to keep the machine up and running.  Then it is up to you, as a developer, to make sure the program does not crash when encountering an error by checking inputs and uses of Try/Catch blocks (in C#).

It is different in the cloud.  First, you have no idea what the hardware configuration is for the server.  Does it have multiple power supplies?  Maybe and then again maybe not.  There is a saying I keep hearing when talking about cloud hardware:  “Cloud servers are treated more like cattle than pets.”  Meaning if one server has an issue it is just replaced.  It can be sent somewhere else to be fixed but as far as the cloud provider is concerned it is easier to replace it than fix it right there and then (I should note I do not care for this saying.  Growing up in Dairy country I know how important the cows are). In any case, if a machine has an issue there is no consideration as to what the server is doing, it will be shut down and replaced.  If your code is running then it dies (it is always a good idea to make sure you have at least 2 copies of your software running for just such a reason).

There are plenty of other issues that can happen in the cloud that may not happen on-premises.  You may not be able to access your SQL server due to network issues.  Granted, this can happen on-premises but at least you have a phone number that you can call and someone to yell at 🙂   You may also be running on a shared server and the other applications start taking up too much CPU or network bandwidth.  In any event, cloud applications need to be able to die and restart gracefully which is something that most on-premises applications are not written to do.  Of course, you still want to check your inputs and catch errors but you need to decide if an error is severe enough to just start over or continue.

Edit: As I was writing this I noticed that Jeffrey Richter release a video series called Architecting Distributed Cloud Applications which discusses a lot of the same topics

Microsoft announced today the public preview of Azure Archive Blob storage. This gives you a way to cheaply store documents that you need to keep, perhaps for legal reasons, but you are fairly certain you will not need to look at often, if at all. The actual pricing has not yet been released but seeing how Cool Blob storage costs $0.01/GB/month, it is sure to less than that.

I know that one place I worked has a large room full of documentation that probably no one will ever read (unless there is an audit in which case the auditor usually just checks to make sure the document is actually there).  Imagine scanning all those documents and then putting them into Archive Blob storage.  This will free up the room for other tasks not to mention saving money on printing and binders.  Setup Azure Search to index the Archived Blobs and then you can easily search for keywords if an audit ever occurs.  With a 99% availability SLA, accessing the data should never be an issue.

As part of the announcement, Microsoft also stated that you can change the level of the Blob (Hot, Cold, or Archive) without having to move the Blob to a different account.  In addition this can be done using .NET, Python, or Node.js with Java  and portal support coming soon.   By allowing .Net access you can easily write a function or logic app that checks the last modified date or some tag on the document and change its level according automatically.

Check out Microsoft’s Azure blog post for more information as well as how to sign up for this public preview.

It goes without saying that if you are using Azure you are aware of the Azure portal and can access it via https://portal.azure.com. However, did you know that you can see what is coming soon to the Azure portal by going to https://preview.portal.azure.com ?  This gives you a chance to check out the newest features before they arrive.  Everything else in the portal is the same and you can have both the preview and regular portals open at the same time.

Scott Hanselman has a video showcasing some of the newest features you can expect soon (as of writing this of course).  Check out the video here