June 2019 - Applied Information Sciences

@Blueelvis_roxxx

Following up my last post on Azure Web App for Containers, in part two we’ll go through the various types of storage options available with Azure Web App for Containers, along with the scenarios where they fit best.

As of writing this post, there are 3 storage options:

Stateless
Storage on App Service Plan
Storage using a Storage Account File Share

Stateless

As you all know, containers without any volume mounts are completely stateless — i.e., the container will not persist data once it is shut down. When you create an instance of Azure Web App for Containers, this is the default option. Reboots on Azure App Service platform can happen from time to time for maintenance. The only files which are persisted across reboots in this mode are the logs which are located under the /home/LogFiles folder.

This scenario is best applicable for APIs where you don’t have to store any data on the server itself. A typical use case would be a 3-tier architecture application where each layer resides as a separate resource in Azure.

Storage on App Service Plan

Using this option allows you to store data on the App Service Plan. In order to enable this, you would have to create an App Setting (WEBSITES_ENABLE_APP_SERVICE_STORAGE=true). In this mode, what happens is that the /home directory is persisted across reboots. Azure does this by mounting storage behind the scenes at this path and then persisting it. As this storage is maintained by Azure, it ensures that it is performant. From what I have seen, in case there is an issue (Performance or Availability) with the storage, Azure will try to switch to the secondary copy and while this is being done, this storage becomes read-only.

When site level backups are enabled on such an instance, the contents of the /home directory are also backed up. The downside to this is that this storage is only visible to your Web app and is not accessible to the outside world.

This option is best for scenarios where storage is required on the server with a minimal overhead of maintenance like when hosting Drupal & WordPress.

Storage using a Storage Account File Share

As of writing this, this option is still in Preview but allows you to connect external services to the Storage Account. This can be set up by going to the “Path Mappings” section of the Azure App Configuration –

This type of mapping supports both Blob containers and Azure Storage File Shares. Although the functionality provided by both is pretty much the same, the technologies behind the scenes which support these are different. For Blob Containers, Blobfuse is used to handle the translation and mapping of file paths to remote blob paths whereas mounting Azure Storage File Shares uses SMB Protocol and uses the CIFS mounts on Linux.

I would suggest you use the Azure Storage File Shares and not the Blob Containers for these storage mounts as Blobfuse is not POSIX (Portable Operating System Interface) compliant. For best performance and stability, use the Azure Storage File Share mount.

While using this option, do keep in mind that the site backups do not back up the mounts. You would have to manage the backups of the mounts on your own.

This option is best suited for scenarios where you need more control over the storage and the ability to connect other devices to the same storage as the Web App for Container.

Stay tuned for the next part!

Chris Hettinger

@ChrisHettinger1

To benefit the most from this post, you should understand the following concepts:

Dynamics CRM Workflows
DocuSign Integration with Dynamics CRM
DocuSign merge fields and merge-back

The Problem

I recently experimented with integrating DocuSign with Dynamics 365 — specifically, the merging of data into a DocuSign form and then writing the data back into Dynamics. After reading the DocuSign for Dynamics 365 CRM – 6.1 documentation I found that DocuSign Drop Downs and Radio Button controls are not supported for Dynamics merging and write backs. I started work on a solution that would use a Checkbox field in DocuSign and a Two Options field in Dynamics. I had all my text fields working correctly and assumed it would be straightforward as there were both Boolean fields.

I was disappointed to find out that the solution would not merge. After researching online and trying a few suggestions, I finally decided to add a temporary text field to my DocuSign form and see what Dynamics was putting into it, and found that the value was “Yes.” Then I looked at the form data in DocuSign…and it had the value “X.” I tried replacing the values for “Yes” and “No” in the Dynamics Two Options field with “X” and “O”, but that didn’t work either.

The Solution

I finally decided to change the “Yes” and “No” values to “true” and “false.”

This time, when the data was merged, the checkbox was checked!

And once the client receives the email, fills out the form, and the .pdf files are sent…this is when the ‘X’ we saw in the form data is used:

Finally, I verified it worked end-to-end by unchecking the box in Dynamics and saving the record:

After firing off the workflow to merge data in DocuSign form, the box is unchecked now:

Send the email off to be filled, check the box and add a new allergy:

Now, wait for the Dynamics envelope status workflow to complete. Check the record and the record will update successfully in Dynamics.

Conclusion

Albeit small, I’m surprised I didn’t find it documented. So if you’ve come across this issue working with DocuSign Checkbox fields and Dynamics 365, I hope this post saves you some time!

Vishwas Lele

@vlele

I recently read Patrick Lencioni’s latest book, Getting Naked: A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty. I found the book useful, well written, and insightful.

Here is a quick summary of the key ideas:

Always Consult instead of Sell

Rather than harping on past accolades and what you can do if the organization hires you, transform every sales situation into an opportunity to demonstrate value. Start adding value from the very first meeting… without waiting to be hired. Don’t worry about a potential client taking advantage of your generosity. (One potential client in 10 may – but you don’t want that one potential client as a customer anyway!)

**Tell kind truth**

Be ready to confront a client with a problematic message, even if the client might not like hearing it. Don’t sugar coat or be obsequious. Rather, replay the message in a manner that recognizes the dignity and humanity of the client. Be prepared to deal with “the elephant in the room” that everyone else (including your competitors) is afraid to address.

Don’t be afraid to ask questions or suggest ideas, even if they seem obvious

There is a good chance that a seemingly obvious question/suggestion is actually of benefit to many in the audience.

Of course, there is also that chance of posing a “dumb” question. But no one is expecting perfection from their consultants, but they do expect transparency and honesty. There is no better way to demonstrate both than by acknowledging mistakes.

**Make everything about the client**

Be prepared to humble yourself by sacrificially taking the burden off of a client in a difficult situation. Be ready to take on whatever the client needs you to do within the context of the services you offer.

The focus of all of your attention needs to be on understanding, supporting, and honoring the business of the client. Do not try to shift attention to yourself, your skills, or your knowledge. Honor the client’s work by taking an active interest in their business and appreciating the importance of their work.

Admit your weaknesses and limitations

Be true to your strengths and be open to admitting your weaknesses. Not doing so will wear you out and prevent you from doing your best in your areas of strength.

Like many of you, we at AIS attempt to subsume many of the above ideas from Lencioni’s book. For example, rather than “sell” a project, we often co-invest (along with the customer) in a micro-POC* or a one-day architecture and design session that helps lay out the vision for the solution, identify main risks, and crystallize the requirements for a project. With the insights derived from a micro-POC, clients can make an informed decision on whether to move forward or not. Here are a couple of examples of micro-POCs: Jupyter Notebooks as a Custom Calculation Engine, and Just-in-Time Permission Control with Azure RBAC

* Micro-POC (micro Proof of concept) – a time-boxed (typically ~40 hours) “working” realization of an idea/concept with the aim to better understand the potential, risks, and effort involved. This is *not* an early version of a production application. Also, see this Wikipedia definition of Proof of concept

Vishwas Lele

@vlele

As we think about services that Azure can offer, we often think about apps (e.g., App Services, AKS, and Service Fabric) and data (e.g., Azure Storage, Data Bricks, and Azure Data Lake). It turns out that you can also leverage Azure networking, also known as as a Network-as-a-Service (NaaS). Network is a basic building block for all app and data services in Azure. But, by NaaS, I am explicitly talking about leveraging Azure networking in a *standalone* manner. Allow me to explain what I mean: In the picture below, you will see a representation of the Azure global footprint. It is so vast that it includes 100K+ miles of fiber and subsea cables, and 130 edge locations connecting over 50 regions worldwide. Think of NaaS as a way to tap into Azure’s global infrastructure to improve network performance and resilience of your applications, regardless of whether the apps are hosted in Azure or not.

Let’s discuss two specific Azure networking Services that offer NaaS capabilities. Note, there are other services like Azure Firewall – think firewall as a service – that can fall in the NaaS category. However, I am limiting my discussion to two services – Azure Front Door Service and Azure Virtual WAN Service. In my opinion, these services closely align with a focus on leveraging Azure network infrastructure and services in a standalone manner.

Azure Front Door Service

Azure Front Door service allows you to define global routing for your applications that optimize performance and resilience. Front Door is a layer 7 (HTTP/HTTPS) service. Please refer to the diagram

below for a high-level view of how Front Door works – you can advertise your application’s URL using the anycast protocol. This way, traffic directed towards your application will get picked up by the “closest” Azure Front Door service and routed to your application hosted in Azure on-premises – for applications hosted outside of Azure, the traffic will traverse the Azure network to the point of exit closest to the location of the app.

The primary benefit of using the Azure Front Door service is to improve the network performance by routing over the Azure backbone (instead of the long-haul public internet). It turns out there are several secondary benefits to highlight: You can increase the reliability of your application by having Front Door provide instant failover to a backup location. The Azure Front Door service uses smart health probes to check for the health of your application. Additionally, Front Door offers SSL termination and certificate management, application security via Web Application Firewall, and URL based routing.

Azure Virtual WAN

Azure Virtual WAN offers branch connectivity to, and through, Azure. In essence, think of Azure regions as hubs, that along with the Azure network backbone can help you establish branch-to-VNet and branch-to-branch connectivity.

You are probably wondering how Virtual WAN relates to existing cloud connectivity options like point-to-site, site-to-site, and express route. Azure WAN brings together the above connectivity options into a single operational interface.

The following diagram illustrates a client’s virtual network overlay over the Azure backbone. The Azure WAN virtual hub is located in the Western Europe region. The virtual hub is a managed virtual network, and in turn, enables connectivity to VNets in Western Europe (VNetA and VNetB) and an on-premises branch office (testsite1) connected via site-to-site VPN tunnel over IPSec. An important thing to note is that the site-to-site connection is hooked to the virtual hub and *not* directly to the VNet (as is the case with a virtual network gateway).

Finally, you can work with one of many Azure WAN partners to automate the site-to-site connection including setting up the branch device (VPN/SD-WAN – software defined wide area network) that automates the connectivity setup with Azure.

BlogMonthly Archives: June 2019