28 September, 2021

c# Copy an Azure Storage blob into Subfolder or Subdirectories

 Copying All Blob of given Container into the same container and under subfolder?

Here are few key points about the copying blob in Azure Storage Account:

  • When you copy a blob within the same storage account, it's a synchronous operation.
  •  When you copy across accounts it's an asynchronous operation.
  • The source blob for a copy operation may be a block blob, an append blob, a page blob, or a snapshot. If the destination blob already exists, it must be of the same blob type as the source blob. An existing destination blob will be overwritten.
  • The destination blob can't be modified while a copy operation is in progress. A destination blob can only have one outstanding copy operation. In other words, a blob can't be the destination for multiple pending copy operations.


To copy a blob, call one of the following methods:

  • StartCopyFromUri
  • StartCopyFromUriAsync

We are using  .Net Core 3.1

Step  1Install-Package Azure.Storage.Blobs -Version 12.10.0

Step 2:  use the following code to move your container (named images)file into the same container  under a subfolder name called 

for example, if your current file store in images/my-pic.png this code will move to images/my-folder/my-pic.png


private static async Task CopyBlobToSubFolderAsync(BlobContainerClient container)
{
    
        // Get the name of the first blob in the container to use as the source.
        string blobName = container.GetBlobs().FirstOrDefault().Name;

        // Create a BlobClient representing the source blob to copy.
        BlobClient sourceBlob = container.GetBlobClient(blobName);

        // Ensure that the source blob exists.
        if (await sourceBlob.ExistsAsync())
        {
            // Lease the source blob for the copy operation 
            // to prevent another client from modifying it.
            BlobLeaseClient lease = sourceBlob.GetBlobLeaseClient();

            // Specifying -1 for the lease interval creates an infinite lease.
            await lease.AcquireAsync(TimeSpan.FromSeconds(-1));

            // Get the source blob's properties and display the lease state.
            BlobProperties sourceProperties = await sourceBlob.GetPropertiesAsync();

            // Get a BlobClient representing the destination blob with a unique name.
            BlobClient destBlob = 
                container.GetBlobClient("my-folder/" + sourceBlob.Name);

            // Start the copy operation.
            await destBlob.StartCopyFromUriAsync(sourceBlob.Uri);

            // Get the destination blob's properties and display the copy status.
            BlobProperties destProperties = await destBlob.GetPropertiesAsync();

         
            // Update the source blob's properties.
            sourceProperties = await sourceBlob.GetPropertiesAsync();

            if (sourceProperties.LeaseState == LeaseState.Leased)
            {
                // Break the lease on the source blob.
                await lease.BreakAsync();

                // Update the source blob's properties to check the lease state.
                sourceProperties = await sourceBlob.GetPropertiesAsync();
            }
        }   
}



15 September, 2021

Challenges of Microservices and When To Avoid Them

 When not to use microservices?


  • Your defined domain is unclear or uncertain
  • Improved efficiency isn’t guaranteed
  • Application size is small or uncomplex


Challenges of Microservices


Microservices could be more expensive than monolithic applications.

A poor design may lead to:
  • Increased latency
  • Reduced speed of calls across different services
  • A cascading failure may overwhelm your server
  • Poorly breaking down a module into microservices 
  • Handling Distributed Transactions in the Microservice

Running overproduction





Disclaimer: following above screenshots from pluralsight.com

06 September, 2021

What Are Deployment Strategies?

 What Are Application Deployment Strategies?

An application deployment strategy is a way to upgrade an application with the new version of code. The aim is to make the changes without downtime in a way that the user barely notices the improvements.

In this post, we are going to talk about the following strategies:

  1. Recreate: Version A is terminated and then version B is rolled out.
  2. Ramped (rolling-update/incremental): Version B is slowly rolled out and replacing version A.
  3. Blue/Green: Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.
  4. Canary: Version B is released to a subset of users, then proceeds to a full rollout.
  5. A/B testing: Version B is released to a subset of users under specific conditions.
  6. Shadow: Version B receives real-world traffic alongside version A and doesn’t impact the response.

Ramped/Rolling update/Incremental

The ramped deployment strategy consists of slowly rolling out a version of an application by replacing instances one after the other until all the instances are rolled out. It usually follows the following process: with a pool of version A behind a load balancer, one instance of version B is deployed. When the service is ready to accept traffic, the instance is added to the pool. Then, one instance of version A is removed from the pool and shut down.

Pros:
  • Easy to set up.
  • Version is slowly released across instances.
  • Convenient for stateful applications that can handle rebalancing of the data.

Cons:
  • Rollout/rollback can take time.
  • Supporting multiple APIs is hard.
  • No control over traffic.

Blue/Green

Version B is released alongside version A, then the traffic is switched to version B.     A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

Pros:
  • Instant rollout/rollback.
  • Avoid versioning issue, the entire application state is changed in one go.
Cons:
  • Expensive as it requires double the resources.
  • Proper test of the entire platform should be done before releasing to production.
  • Handling stateful applications can be hard.


Canary

A canary deployment consists of gradually shifting production traffic from version A to version B. Usually, the traffic is split based on weight. For example, 90 percent of the requests go to version A, 10 percent go to version B.

This technique is mostly used when the tests are lacking or not reliable or if there is little confidence about the stability of the new release on the platform.

Pros:
  • Version released for a subset of users.
  • Convenient for error rate and performance monitoring.
  • Fast rollback.
Con:
  • Slow rollout

A/B testing 

A/B testing deployments consist of routing a subset of users to a new functionality under specific conditions. It is usually a technique for making business decisions based on statistics, rather than a deployment strategy. However, it is related and can be implemented by adding extra functionality to a canary deployment so we will briefly discuss it here. This technique is widely used to test the conversion of a given feature and only roll out the version that converts the most.
 Here is a list of conditions that can be used to distribute traffic amongst the versions:
  • By browser cookie 
  • Query parameters 
  • Geolocalisation 
  • Technology support: browser version, screen size, operating system, etc. 
  • Language

Microservices vs Monolithic Architecture

 Microservices vs Monolithic Architecture Here’s a clear side-by-side comparison between Microservices and Monolithic architectures — fro...