Uncategorized – Page 5

As of June 25, the version of Bower shipped with Visual Studio was deprecated, resulting in Bower operations failing when run in Visual Studio. If you use Bower, you will see an error something like:

EINVRES Request to https://bower.herokuapp.com/packages/bootstrap failed with 502

This will be fixed in Visual Studio 15.8. In the meantime, you can work around the issue by using a new version of Bower or by adding some configuration to each Bower project.

The Issue

Some time, ago Bower switched their primary registry feed but continued to support both. On June 25th, they turned off the older feed, which the copy in Visual Studio tries to use by default.

The Fix

There are two options to fix this issue:

Update the configuration for each Bower project to explicitly use the new registry: https://reigstry.bower.io
Manually install a newer version of Bower and configure Visual Studio to use it.

Workaround 1: Define the new registry entry in the project’s Bower config file (.bowerrc)

Add a .bowerrc file to the project (or modify the existing .bowerrc) with the following content:

{ "registry": "https://registry.bower.io"
}

With the registry property defined in a .bowerrc file in the project root, Bower operations should run successfully on the older versions of Bower that shipped with Visual Studio 2015 and Visual Studio 2017.

Workaround 2: Configure Visual Studio to point to use a newer version of Bower

An alternative solution is to configure Visual Studio use to a newer version of Bower that you have installed as a global tool on your machine. (For instructions on how to install Bower, refer to the guidance on the Bower website.) If you have installed Bower via npm, then the path to the bower tools will be contained in the system $(PATH) variable. It might look something like this: C:\Users\[username]\AppData\Roaming\npm. If you make this path available to Visual Studio via the External Web Tools options page, then Visual Studio will be able to find and use the newer version.

To configure Visual Studio to use the globally installed Bower tools:

Inside Visual Studio, open Tools->Options.
Navigate to the External Web Tools options page (under Projects and Solutions->Web Package Management).
Select the “$(PATH)” item in the Locations of external tools list box.
Repeatedly press the up-arrow button in the top right corner of the Options dialog until the $(PATH) item is at the top of the list.
Press OK to confirm the change.

Ordered this way, when Visual Studio is searching for Bower tools, it will search your system path first and should find and use the version you installed, rather than the older version that ships with Visual Studio in the $(VSINSTALLDIR)\Web\External directory.

Note: This change affects path resolution for all external tools. So, if you have Grunt, Gulp, npm or any other external tools on the system path, those tools will be used in preference to any other versions that shipped with VS. If you only want to change the path for Bower, leave the system path where it is and add a new entry at the top of the list that points to the instance of Bower installed locally. It might look something like this: C:\Users\[username]\AppData\Roaming\npm\node_modules\bower\bin

We trust this will solve any issues related to the recent outage of the older bower registry. If you have any questions or comments, please leave them below.

Happy coding!

Justin Clareburt, Senior Program Manager, Visual Studio

Justin Clareburt is the Web Tools PM on the Visual Studio team. He has over 20 years of Software Engineering experience and brings to the team his expert knowledge of IDEs and a passion for creating the ultimate development experience.

Follow Justin on Twitter @justcla78

Scott Guthrie recently shared one of my favorite anecdotes on his Azure Red Shirt Tour. A Microsoft customer regularly invokes 1 billion (yes, that’s with a “B”) Azure Functions per day. The customer reached out to support after the first month thinking there was a bug in the billing system, only to find out that the $72 was in fact correct. How is that possible? Azure Functions is a serverless compute platform that allows you to focus on code that only executes when triggered by events, and you only pay for CPU time and memory used during execution (versus a traditional web server where you are paying a fee even if your app is idle). This is called micro-billing, and is one key reason serverless computing is so powerful.

Curious about Azure Functions? Follow the link https://aka.ms/go-funcs to get up and running with your first function in minutes.

Scott Guthrie on the Azure Red Shirt Tour

In fact, micro-billing is so important, it’s one of three rules I use to verify if a service is serverless. There is not an official set of rules and there is no standard for serverless. The closest thing to a standard is the whitepaper published by the Cloud Native Computing Foundation titled CNCF WG-Serverless Whitepaper v1.0 (PDF). The paper describes serverless computing as “building and running applications that do not require server management.” The paper continues to state they are “executed, scaled, and billed in response to the exact demand needed at the moment.”

It’s easy to label almost everything serverless, but there is a difference between managed and serverless. A managed service takes care of responsibilities for you, such as standing up a website or hosting a Docker container. Serverless is a managed service but requires a bit more. Here is Jeremy’s Serverless Rules.

The service should be capable of running entirely in the cloud. Running locally is fine and often preferred for developing, testing, and debugging, but ultimately it should end up in the cloud.
You don’t have to configure a virtual machine or cluster. Docker is great, but containers require a Docker host to run. That host typically means setting up a VM and, for resiliency and scale, using an orchestrator like Kubernetes to scale the solution. There are also services like Azure Web Apps that provide a fully managed experience for running web apps and containers, but I don’t consider them serverless because they break the next rule.
You only pay for active invocations and never for idle time. This rule is important, and the essence of micro-billing. ACI is a great way to run a container, but I pay for it even when it’s not being used. A function, on the other hand, only bills when it’s called.

These rules are why I stopped calling managed databases “serverless.” So, what, then, does qualify as serverless?

The Azure serverless platform includes Azure Functions, Logic Apps, and Event Grid. In this post, we’ll take a closer look at Azure Functions.

Azure Functions

Azure Functions allows you to write code that is executed based on an event, or trigger. Triggers may include an HTTP request, a timer, a message in a queue, or any other number of important events. The code is passed details of the trigger but can also access bindings that make it easier to connect to resources like databases and storage. The serverless Azure Functions model is based on two parameters: invocations and gigabyte seconds.

Invocations are the number of times the function is invoked based on its trigger. Gigabyte seconds is a function of memory usage. Image a graph that shows time on the x-axis and memory consumption on the y-axis. Plot the memory usage of your function over time. Gigabyte seconds represent the area under the curve.

Let’s assume you have a microservice that is called every minute and takes one second to scan and aggregate data. It uses a steady 128 megabytes of memory during the run. Using the Azure Pricing Calculator, you’ll find that the cost is free. That’s because the first 400,000 Gigabyte seconds and 1 million invocations are free every month. Running every second (there are 2,628,000 seconds in a month) with double memory (256 megabytes), the entire monthly cost is estimated at $4.51.

Pricing calculator for Azure Functions

Recently I tweeted about my own experience with serverless cost (or lack thereof). I wrote a link-shortening tool. It uses a function to take long URLs and turn them into a shorter code I can easily share. I also have a function that takes the short code and performs the redirect, then stores the data in a queue. Another microservice processes items in the queue and stores metadata that I can analyze for later. I have tens of thousands of invocations per month and my total cost is less than a dollar.

A tweet about cost of running serverless code in Azure

Do I have your attention?

In future posts I will explore the cost model for Logic Apps and Event Grid. In the meantime…

Learn about and get started with your first Azure Function by following this link: https://aka.ms/go-funcs

Tag: Uncategorized

Workaround for Bower Version Deprecation

The Issue

The Fix