Released: Preview of Azure Arc enabled SQL Server

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

We are making available the private preview of Azure Arc enabled SQL Server. The preview includes the following features:

• Use the Azure Portal to register and track the inventory of your SQL Server instances across on-premises, edge sites, and multi-cloud in a single view.
• Use Azure Security Center to produce a comprehensive report of vulnerabilities in SQL Servers and get advanced, real time security alerts for threats to SQL Servers and the OS.
• Investigate threats in SQL Servers using Azure Sentinel.

You can register any Windows or Linux based SQL Server to track your inventory. Azure Security Center’s advanced data security works on Windows-based SQL Server version 2012 or higher, running on virtual machines and physical servers and hosted on any infrastructure outside of Azure.

Here’s a video of the Arc enabled SQL Server experience with Azure Security Center.

If you are interested in participating in this preview, please fill out the sign-up form and select the option Server Management (SQL Server).

5 Ways Selecting Injected Instance from Multiple Instances of Same Interface on Azure Functions

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

While building an Azure Functions application, setting an IoC container for dependency injection has many benefits by comparing to just using the static classes and methods. Azure Functions leverages the built-in IoC container featured by ASP.NET Core that is easy to use, without having to rely on any third-party libraries. Throughout this post, I’m going to discuss five different ways to pick up a dependency injected from multiple instances sharing with the same interface.

Implementing Interface and Classes

Let’s assume that we’re writing one IFeedReader interface and three different classes, BlogFeedReader, PodcastFeedReader and YouTubeFeedReader implementing the interface. There’s nothing fancy.

public interface IFeedReader
{
    string Name { get; }
    string GetSingleFeedTitle();
}

public class BlogFeedReader : IFeedReader
{
    public BlogFeedReader()
    {
        this.Name = "Blog";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is blog item 1";
    }
}

public class PodcastFeedReader : IFeedReader
{
    public PodcastFeedReader()
    {
        this.Name = "Podcast";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is audio item 1";
    }
}

public class YouTubeFeedReader : IFeedReader
{
    public YouTubeFeedReader()
    {
        this.Name = "YouTube";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is video item 1";
    }
}

IoC Container Registration #1 – Collection

Let’s register all the classes declared above into the Configure() method in Startup.cs.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReader, BlogFeedReader>();
    builder.Services.AddTransient<IFeedReader, PodcastFeedReader>();
    builder.Services.AddTransient<IFeedReader, YouTubeFeedReader>();
}

By doing so, all three classes have been registered as IFeedReader instances. However, from the consumer perspective, it doesn’t know which instance is appropriate to use. In this case, using a collection as IEnumerable<IFeedReader> is useful. In other words, inject a dependency of IEnumerable<IFeedReader> to the FeedReaderHttpTrigger class and filter one instance from the collection.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._reader = readers.SingleOrDefault(p => p.Name == "Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

It’s one way to use the collection as a dependency. The other way to use the collection is to use a loop. It’s useful when we implement either a Visitor Pattern or Iterator Pattern.

public class FeedReaderHttpTrigger
{
    private readonly IEnumerable<IFeedReader> _readers;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._readers = readers;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = default(string);
        foreach (reader in this._readers)
        {
            if (reader.Name != "Blog")
            {
                continue;
            }

            title = reader.GetSingleFeedTitle();
        }

        return new OkObjectResult(title);
    }
}

IoC Container Registration #2 – Resolver

It’s similar to the first approach. This time, let’s use a resolver instance to get the dependency we want. First of all, declare both IFeedReaderResolver and FeedReaderResolver. Keep an eye on the instance of IServiceProvider as a dependency. It’s used for the built-in IoC container of ASP.NET Core, which can access to all registered dependencies.

In addition to that, this time, we don’t need the Name property any longer as we use conventions to get the required instance.

public interface IFeedReaderResolver
{
    IFeedReader Resolve(string name);
}

public class FeedReaderResolver : IFeedReaderResolver
{
    private readonly IServiceProvider _provider;

    public FeedReaderResolver(IServiceProvider provider)
    {
        this._provider = provider;
    }

    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = this._provider.GetService(type);

        return instance as IFeedReader;
    }
}

After that, update Configure() on Startup.cs again. Unlike the previous approach, we registered xxxFeedReader instances, not IFeedReader. It’s fine, though. The resolver sorts this out for FeedReaderHttpTrigger.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

Update the FeedReaderHttpTrigger class like below.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IFeedReaderResolver resolver)
    {
        this._reader = resolver.Resolve("Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #3 – Resolver + Factory Method Pattern

Let’s slightly modify the resolver that uses the factory method pattern. After this modification, it removes the dependency on the IServiceProvider instance. Instead, it creates the required instance by using the Activator.CreateInstance() method.

public class FeedReaderResolver : IFeedReaderResolver
{
    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = Activator.CreateInstance(type);

        return instance as IFeedReader;
    }
}

If we implement the resolver class in this way, we don’t need to register all xxxFeedReader classes to the IoC container, but IFeedReaderResolver would be sufficient. By the way, make sure that all xxxFeedReader instances cannot be used as a singleton if we take this approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

IoC Container Registration #4 – Explicit Delegates

We can replace the resolver with an explicit delegates. Let’s have a look at the code below. Within Startup.cs, declare a delegate just outside the Startup class.

public delegate IFeedReader FeedReaderDelegate(string name);

Then, update Configure() like below. As we only declared the delegate, its actual implementation goes here. The implementation logic is not that different from the previous approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<FeedReaderDelegate>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

Update the FeedReaderHttpTrigger class. As FeedReaderDelegate returns the IFeedReader instance, another method call should be performed through the method chaining.

public class FeedReaderHttpTrigger
{
    private readonly FeedReaderDelegate _delegate;

    public FeedReaderHttpTrigger(FeedReaderDelegate @delegate)
    {
        this._delegate = @delegate;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._delegate("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #5 – Implicit Delegates with Lambda Function

Instead of using the explicit delegate, the Lambda function can also be used as the implicit delegate. Let’s modify the Configure() method like below. As there is no declaration of the delegate, define the Lambda function.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<Func<string, IFeedReader>>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

As the injected object is the Lambda function, FeedReaderHttpTrigger should accept the Lambda function as a dependency. While it’s closely similar to the previous example, it uses the Lambda function this time for dependency injection.

public class FeedReaderHttpTrigger
{
    private readonly Func<string, IFeedReader> _func;

    public FeedReaderHttpTrigger(Func<string, IFeedReader> func)
    {
        this._func = func;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._func("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

—

So far, we have discussed five different ways to resolve injected dependencies using the same interface, while building an Azure Functions application. Those five approaches are very similar to each other. Then, which one to choose? Well, there’s no one approach better than the other four, but I guess it would depend purely on the developer’s preference.

Dependency Injection on Azure Functions: 5 Ways Selecting Instance from Instances of Same Interface

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

While building an Azure Functions application, setting an IoC container for dependency injection has many benefits by comparing to just using the static classes and methods. Azure Functions leverages the built-in IoC container featured by ASP.NET Core that is easy to use, without having to rely on any third-party libraries. Throughout this post, I’m going to discuss five different ways to pick up a dependency injected from multiple instances sharing with the same interface.

Implementing Interface and Classes

Let’s assume that we’re writing one IFeedReader interface and three different classes, BlogFeedReader, PodcastFeedReader and YouTubeFeedReader implementing the interface. There’s nothing fancy.

public interface IFeedReader
{
    string Name { get; }
    string GetSingleFeedTitle();
}

public class BlogFeedReader : IFeedReader
{
    public BlogFeedReader()
    {
        this.Name = "Blog";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is blog item 1";
    }
}

public class PodcastFeedReader : IFeedReader
{
    public PodcastFeedReader()
    {
        this.Name = "Podcast";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is audio item 1";
    }
}

public class YouTubeFeedReader : IFeedReader
{
    public YouTubeFeedReader()
    {
        this.Name = "YouTube";
    }

    public string Name { get; }

    public string GetSingleFeedTitle()
    {
        return "This is video item 1";
    }
}

IoC Container Registration #1 – Collection

Let’s register all the classes declared above into the Configure() method in Startup.cs.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReader, BlogFeedReader>();
    builder.Services.AddTransient<IFeedReader, PodcastFeedReader>();
    builder.Services.AddTransient<IFeedReader, YouTubeFeedReader>();
}

By doing so, all three classes have been registered as IFeedReader instances. However, from the consumer perspective, it doesn’t know which instance is appropriate to use. In this case, using a collection as IEnumerable<IFeedReader> is useful. In other words, inject a dependency of IEnumerable<IFeedReader> to the FeedReaderHttpTrigger class and filter one instance from the collection.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._reader = readers.SingleOrDefault(p => p.Name == "Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

It’s one way to use the collection as a dependency. The other way to use the collection is to use a loop. It’s useful when we implement either a Visitor Pattern or Iterator Pattern.

public class FeedReaderHttpTrigger
{
    private readonly IEnumerable<IFeedReader> _readers;

    public FeedReaderHttpTrigger(IEnumerable<IFeedReader> readers)
    {
        this._readers = readers;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = default(string);
        foreach (reader in this._readers)
        {
            if (reader.Name != "Blog")
            {
                continue;
            }

            title = reader.GetSingleFeedTitle();
        }

        return new OkObjectResult(title);
    }
}

IoC Container Registration #2 – Resolver

It’s similar to the first approach. This time, let’s use a resolver instance to get the dependency we want. First of all, declare both IFeedReaderResolver and FeedReaderResolver. Keep an eye on the instance of IServiceProvider as a dependency. It’s used for the built-in IoC container of ASP.NET Core, which can access to all registered dependencies.

In addition to that, this time, we don’t need the Name property any longer as we use conventions to get the required instance.

public interface IFeedReaderResolver
{
    IFeedReader Resolve(string name);
}

public class FeedReaderResolver : IFeedReaderResolver
{
    private readonly IServiceProvider _provider;

    public FeedReaderResolver(IServiceProvider provider)
    {
        this._provider = provider;
    }

    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = this._provider.GetService(type);

        return instance as IFeedReader;
    }
}

After that, update Configure() on Startup.cs again. Unlike the previous approach, we registered xxxFeedReader instances, not IFeedReader. It’s fine, though. The resolver sorts this out for FeedReaderHttpTrigger.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

Update the FeedReaderHttpTrigger class like below.

public class FeedReaderHttpTrigger
{
    private readonly IFeedReader _reader;

    public FeedReaderHttpTrigger(IFeedReaderResolver resolver)
    {
        this._reader = resolver.Resolve("Blog");
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._reader.GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #3 – Resolver + Factory Method Pattern

Let’s slightly modify the resolver that uses the factory method pattern. After this modification, it removes the dependency on the IServiceProvider instance. Instead, it creates the required instance by using the Activator.CreateInstance() method.

public class FeedReaderResolver : IFeedReaderResolver
{
    public IFeedReader Resolve(string name)
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"{name}FeedReader");
        var instance = Activator.CreateInstance(type);

        return instance as IFeedReader;
    }
}

If we implement the resolver class in this way, we don’t need to register all xxxFeedReader classes to the IoC container, but IFeedReaderResolver would be sufficient. By the way, make sure that all xxxFeedReader instances cannot be used as a singleton if we take this approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<IFeedReaderResolver, FeedReaderResolver>();
}

IoC Container Registration #4 – Explicit Delegates

We can replace the resolver with an explicit delegates. Let’s have a look at the code below. Within Startup.cs, declare a delegate just outside the Startup class.

public delegate IFeedReader FeedReaderDelegate(string name);

Then, update Configure() like below. As we only declared the delegate, its actual implementation goes here. The implementation logic is not that different from the previous approach.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<FeedReaderDelegate>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

Update the FeedReaderHttpTrigger class. As FeedReaderDelegate returns the IFeedReader instance, another method call should be performed through the method chaining.

public class FeedReaderHttpTrigger
{
    private readonly FeedReaderDelegate _delegate;

    public FeedReaderHttpTrigger(FeedReaderDelegate @delegate)
    {
        this._delegate = @delegate;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._delegate("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

IoC Container Registration #5 – Implicit Delegates with Lambda Function

Instead of using the explicit delegate, the Lambda function can also be used as the implicit delegate. Let’s modify the Configure() method like below. As there is no declaration of the delegate, define the Lambda function.

public override void Configure(IFunctionsHostBuilder builder)
{
    builder.Services.AddTransient<BlogFeedReader>();
    builder.Services.AddTransient<PodcastFeedReader>();
    builder.Services.AddTransient<YouTubeFeedReader>();

    builder.Services.AddTransient<Func<string, IFeedReader>>(provider => name =>
    {
        var type = Assembly.GetAssembly(typeof(FeedReaderResolver))
                           .GetType($"FeedReaders.{name}FeedReader");
        var instance = provider.GetService(type);

        return instance as IFeedReader;
    });
}

As the injected object is the Lambda function, FeedReaderHttpTrigger should accept the Lambda function as a dependency. While it’s closely similar to the previous example, it uses the Lambda function this time for dependency injection.

public class FeedReaderHttpTrigger
{
    private readonly Func<string, IFeedReader> _func;

    public FeedReaderHttpTrigger(Func<string, IFeedReader> func)
    {
        this._func = func;
    }

    [FunctionName(nameof(FeedReaderHttpTrigger.GetFeedItemAsync))]
    public async Task<IActionResult> GetFeedItemAsync(
        [HttpTrigger(AuthorizationLevel.Function, "post", Route = "feeds/item")] HttpRequest req,
        ILogger log)
    {
        var title = this._func("Blog").GetSingleFeedTitle();

        return new OkObjectResult(title);
    }
}

—

So far, we have discussed five different ways to resolve injected dependencies using the same interface, while building an Azure Functions application. Those five approaches are very similar to each other. Then, which one to choose? Well, there’s no one approach better than the other four, but I guess it would depend purely on the developer’s preference.

This post has been cross-posted to DevKimchi.

New Azure Sentinel notebook experience and the retirement of the Azure Notebooks service

by Scott Muniz | Jul 1, 2020 | Azure, Microsoft, Technology, Uncategorized

This article is contributed. See the original author and article here.

A new Azure Sentinel notebook experience will soon be released which provides several management, security, customization, and productivity benefits.  Examples of these benefits includes, but is not limited to, a new intuitive UI with Intellisense, compute provisioning via ARM template support, Azure Virtual Network (VNET) support as well as a full range of compute configuration options. 

While the existing Azure Notebooks website and service will be retired by September 29th (see link for the announcement), the existing Azure Sentinel notebook experience will not be impacted or interrupted as a result of the planned retirement.

Continue to check back for additional announcements as we transition to the new Azure Sentinel notebook experience. For questions or concerns, let us know!