Into the unknown, sort of

Over half of my life ago, I was looking for a job. I had written a bunch of triggers and stored procedures at my first job, but I was relatively green. I had just (barely) gotten my degree in Computer Science, and was looking to get out of Cleveland, TN. I checked around and found a headhunter that found me a couple of opportunities.  One was in downtown Atlanta, Georgia. The other was in Virginia Beach, Virginia. Considering traffic in Atlanta and my, at the time, complete fear of driving in heavy traffic… amongst other reasons… I opted for Virginia Beach.  If you want to know where, it isn’t hard to find, I’ve never made it a secret…

I am not going to say that every minute of every day I worked in Virginia Beach was awesome. They have traffic there, they have hurricanes, and I have coworkers there that are human beings. But over the years I worked there, I have honestly loved everyone I worked with and many of the things we have accomplished. It is very hard to say such things about any other job I have had, though to be fair that is a pretty low number of locations. After working there for five years, it was time to try a new location. 

A coworker of mine called me up about working for a startup in Nashville, Tennessee which delivered Internet to schools. I got to work with different data, different concepts, but just as I have for 25 years, I was working with SQL Server designing Databases and writing T-SQL code. After around 4 years there, I was laid off (which was mostly sad only because I missed the day when the FBI came in and carted off materials. It wasn’t like it was anything sinister, more improper influencing kind of stuff. In fact the company still exists in a slightly different form doing a subset of what we did 15 years ago. I even just read today that the company merged with another in the past few months). 

As I was looking for a job to replace that one, my old company was in the process of setting up a location in Nashville as a disaster recovery\call center site.  I went back and managed their call center equipment for a few years until they could fill out a complete staff. If you are reading this, you probably can guess this is NOT my first, second, or third love in life or even technology.  

After proper call center/hardware management was hired, I went back to my real love database design and implementation. I started working with a team back in Virginia Beach exclusively and was more or less telecommuting from a different office space. Due to the traffic in Nashville, I gradually introduced my company to the actual concept of telecommuting. It was not accepted with open arms. For several years I did this and was kind of the only one. It was a nightmare at times, because if you have ever joined a meeting where you are the only one remote, it is a pain. But the times, they were changing. Even pre-pandemic, they started hiring people to work from anywhere. So much so that a coworker just moved out of country one day, I don’t even think he told our manager first. 

Over the years, I have only considered changing jobs a few times. I have always had a very short list of places I would consider changing jobs to. Very short. One company on that list had a job I had always wanted, called me and basically said “You have the job” and then interviewed me and said “You have the job” and then I didn’t hear back for a few weeks instead of a few days. They had changed their mind due to a reduction in telecommuting and I wasn’t moving that far away from my aging mother. Kind of funny at this point. 

A few months ago, I learned of a job with one of the other companies on my short list that I had lightly coveted when the previous person took it. This person decide to move on, and t he rest is history (which will probably show up in later blogs!) 24 years and just over 9 months of employment later… I am saying goodbye. It is sad. I am leaving a family behind to deal with 20+ years of code I wrote. Some utilities are from my first stint there over 20 years ago which I still occasionally had to update. 

 But it is time and the new journey is going to be incredible. My next position will be using the other skill I employ more than any other. (And I am not talking about theme park photography). Where am I heading? A place we all know and love. More on that in my next blog.

The post Into the unknown, sort of appeared first on Simple Talk.

from Simple Talk https://ift.tt/dnJgFTB
via

.NET App Services: Containers or not containers, that’s the question

The app services in the title can be function apps, web apps or more. We can deploy the app services on the native app service environment provided by Microsoft or using containers.

What’s the different between using the native environment or using containers?

The differences aren’t many and it’s not easy to identify when it’s better to use the native environment or when its’s better to user containers.

There are two main differences we can identify:

• The cold startup time is better using the native environment than using a container
• We need to manage all the patches to a custom container, in the opposite to the native environment. Microsoft manages the patches to the native environment.

These doesn’t appear to be very critical decision points on most situations. But let’s dig further and add more variables.

Certificates and Containers

We can choose to use a Linux container or use a Windows container. There are some differences according to our choice. A few weeks ago, I stumbled upon one of the difference.

In some applications, we may need to insert a certificate inside the container.  WEBSITE_LOAD_CERTIFICATES is a special configuration we can use for this. This configuration makes the app service insert the certificate inside the container.

In windows containers, the app service installs the certificate inside the windows certificate storage and the certificate is recognized by the applications in the container.

On the other hand, if the container uses linux, the certificate is copied to one folder in a DER format. Most of the times the application will need to read the certificate from the file system and use it by code. This would require code change, usually this is not good.

These links contain explanations about this configuration and code to read the certificate from the file system in a Linux container:

https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code

https://stackoverflow.com/questions/55599001/azure-function-key-vault-reference-for-certificates

Security Scans

This happened to me some weeks ago. A security code scan tool started to complain about one dll: Microsoft.AspNetCore.Http.dll version 2.1.0.

You can find more about this issue on the following links:
https://github.com/dotnet/announcements/issues/165
https://nvd.nist.gov/vuln/detail/CVE-2020-1045#match-6013238

This assembly is a reference included in the package Microsoft.NET.Sdk.Functions . More than that, it’s part of the .NET Core Framework. How to solve a security problema like this?

It’s usual to find security problems with frameworks such as .NET Core. The framework is always evolving. You can check the framework versions and the security patches published on the following links:
https://dotnet.microsoft.com/en-us/download/dotnet/3.1
https://dotnet.microsoft.com/en-us/download/dotnet/6.0

The solution to the security problem is to update the .NET Core framework on the execution machine.

There are some details capable to make anyone confused. When the .NET project is compiled, the assemblies are inserted in the BIN folder. The version of the Microsoft.AspNetCore.Http.dll is the bad version, 2.1.0, even if the .NET Core framework on the machine is updated. How could this be possible?

We can even think further: if the assembly is in the BIN folder, this means a devOps pipeline would pack and deploy this assembly. How the update on the .NET Core framework would solve this?

The explanation is simple: Framework assemblies in the BIN folder are ignored, and the app uses the .NET Core assemblies.

Checking .NET Version in an App Service

App Services have the Advanced Tools. On the left menu, you under Developer Tools, you can click Advanced Tools and click the link Go on the page which will appear in the middle.

This will open an advanced development environment. On this environment, click  Debug Console on the top menu and choose a CMD console or Powershell console. Both can be used.

Once on the console, you can use one or both of the following statements:

dotnet –version

dotnet –list-runtimes

The first one will tell you the .NET version. You can use the .NET download pages (links above) to confirm your environment is up-to-date with the latest .NET version.

The 2nd one will tell you the exactly version of the main core libraries. The security report usualy will contain exactly the library versions you should have to be safe and you will be able to confirm you have them.

 

 

Security Scans Impact on App Service Containers

If you deploy your app service on the native environment, the app service will make updates to the .NET Core regularly. Microsoft deploys new fixes to the app service environment in 1 or 2 weeks after they are available.

However, if you deploy your app service as a container, it’s your responsibility to make updates to the container. You will be the responsible to create an automated flow in your devOps environment to identify new security features to the environment, update the container image and deploy it again regularly, avoiding down time.

Conclusion

Innitialy the requirement to manage the updates to the app service containers may appear a small difference, but when we check the security updates and the need to create an automated process to apply these security updates to the containers images we end up finding a very good reason to avoid deploying containers to app services and stick to the native environment.

If something changes later, it’s easy to deploy the application to a container when needed.

 

The post .NET App Services: Containers or not containers, that’s the question appeared first on Simple Talk.

from Simple Talk https://ift.tt/jERYbow
via

Technology is hard

I book my travel almost exclusively through a single airline and its affiliates. There are a lot of reasons for this, but the big one is status. And no, not so I get upgrades (although they are very nice), but so when things go wrong, I have a hotline to getting them fixed. However, I don’t want to talk about that today, I want to talk technology. See, my airline’s web site won’t run properly on my work laptop.

And works everywhere else.

Oh, I’ve tried it all. Changed the location on my VPN. Turned off my VPN. Browser A. Browser B. Browser C (even though I vowed I’d never install that junk ever again). Heck, off-brand Browser D. Uninstall the VPN. Reset the internet connection. Tether from the phone. Install updates. Get on the phone with tech support. Clear the browser cache (like going to a different browser doesn’t obviate the need for this one, but, hey) and the history.

Yet, if I walk three feet to my personal laptop, it works fine. My wife doesn’t have a problem. I can log in from my phone. My children’s laptops also connect. Nope. It’s just the one laptop.

After all that, you know the one thing I have learned?

Technology is hard.

I mean think about it. We have these web pages that work, almost, for everyone, almost, all the time, almost. Yeah, I know, joking. However, they really do work, and for huge swaths of the populace, despite all the wild variation on technologies employed. Yet, when things go south, very tiny as in my case, or huge when systems are hacked or experience internally generated outages, they go very badly wrong. Recovery is hard. Troubleshooting, extremely difficult, even if you have the skill (and too many do not), takes forever. All of it hurting our organizations and causing pain for ourselves.

We are in a position where we’re working miracles, but it’s all with some pretty brittle tech because, frankly, this stuff isn’t easy.

Now, I need to grab my other laptop so I can book a trip.

Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.

The post Technology is hard appeared first on Simple Talk.

from Simple Talk https://ift.tt/fTzNqXb
via