Category: Microsoft
Category Archives: Microsoft
Azure Functions at Build 2024 – addressing customer feedback with deep engineering
Azure Functions is Azure’s primary serverless service used in production by hundreds of thousands of customers who run trillions of executions on it monthly. It was first released in early 2016 and since then we have learnt a lot from our customers on what works and where they would like to see more.
Taking all this feedback into consideration, the Azure Functions team has worked hard to improve the experience across the stack from the initial getting started experience all the way to running at very high scale while at the same time adding features to help customers build AI apps. Please see this link for a list of all the capabilities we have released in this year’s Build conference. Taking everything into account, this is one of the most significant set of releases in Functions history.
In this blog post, I will share customer feedback and behind the scenes technical work that the Functions and other partner teams did to meet the expectations of our customers. In future, we will go deeper into each of those topics, this is a brief overview.
Flex Consumption: Burst scale your apps with networking support
We are releasing a new SKU of Functions, Flex Consumption. This SKU addresses a lot of the feedback that we have received over the years on the Functions Consumption plans – including faster scale, more instance sizes, VNET support, higher instance limits and much more. We have looked at each part of the stack and made improvements at all levels. There are many new capabilities including:
Scales much faster than before with user controlled per-instance concurrency
Scale to many more instances than before (upto 1000)
Serverless “scale to zero” SKU that also supports VNET integrated event sources
Supports always allocated workers
Supports multiple memory sizes
Purpose built backend “Legion”
To enable Flex Consumption, we have created a brand-new purpose-built backend internally called Legion.
To host customer code, Legion relies on nested virtualization on Azure VMSS. This gives us the Hyper-V isolation that is a pre-requisite for hostile multi-tenant workloads. Legion was built right from the outset to support scaling to thousands of instances with VNET injection. Efficient use of subnet IP addresses by use of kernel level routing was also a unique achievement in Legion.
For all languages, functions have a strict goal for cold start. To achieve this cold start metric for all languages and versions, and to support functions image update for all these variants, we had to create a construct called Pool Groups that allows functions to specify all the parameters of the pool, as well as networking and upgrade policies.
All this work led us to a solid, scalable and fast infrastructure on which to build Flex Consumption on.
“Trigger Monitor” – scale to 0 and scale out with network restrictions
Flex Consumption also introduces networking features to limit access to the Function app and to be able to trigger on event sources which are network restricted. Since these event sources are network restricted the multi-tenant scaling component scale controller that monitors the rate of events to determine to scale out or scale in cannot access them. In the Elastic Premium plan in which we scale down to 1 instance – we solved this by that instance having access to the network restricted event source and then communicating scale decisions to the scale controller. However, in the Flex Consumption plan we wanted to scale down to 0 instances.
To solve this, we implemented a small scaling component we call “Trigger Monitor” that is injected into the customers VNET. This component is now able to access the network restricted event source. The scale controller now communicates with this component to get scaling decisions.
Scaling Http based apps based on concurrency
When scaling Http based workloads on Function apps our previous implementation used an internal heuristic to decide when to scale out. This heuristic was based on Front End servers,: pinging the workers that are currently running customers workload and deciding to scale based on the latency of the responses. This implementation used SQL Azure to track workers and assignments for these workers.
In Flex Consumption we have rewritten this logic where now scaling is based on user configured concurrency. User configured concurrency gives customers flexibility in deciding based on the language and workload what concurrency they want to set per instance. So, for example, for Python customers they don’t have to think about multithreading and can set concurrency =1 (which is also the default for Python apps). This approach makes the scaling behavior predictable, and it gives customers the ability to control the cost vs performance tradeoff – if they are willing to tolerate the potential for higher latency, they might unlock cost savings by running each worker at higher levels of concurrency.
In our implementation, we use “request slots” that are managed by the Data Role. We split instances into “request slots” and assign them to different Front End servers. For example: If the per-instance concurrency is set to 16, then once the Data Role chooses an instance to allocate a Function app to, there are 16 request slots that it can hand out to Front Ends. It might give all 16 to a single Front End, or share them across multiple. This removes the need for any coordination between Front Ends – they can use the request slots they receive as much as they like, with the restriction of only one concurrent request per request slot. Also, this implementation uses Cosmos DB to track assignments and workers.
Along with the Legion as the compute provider, significantly large compute allocation per app and rapid scale in and capacity reclamation allows us to give customers much better experience than before.
Scaling Non-Http based apps based on concurrency
Similar to Http apps, we have also enabled Non-Http based apps to scale based on concurrency. We refer to this as Target Based Scaling. . From an implementation perspective we have moved to have various extensions implement scaling logic within the extension and the scale controller hosts these extensions. This unifies the scaling logic in one place and unifies all scaling based on concurrency.
Moving configuration to the Control Plane
One more change that we are making directionally based on feedback from our customers is to move from using AppSettings for various configuration properties to moving them to the Control Plane. For Public Preview we are doing this for the areas of Deployment, Scaling, Language. This is an example configuration which shows the new Control Plane properties. By GA we will move other properties as well.
Azure Load Testing integration
Customers have always asked us how to configure their Function apps for optimum throughput. Till now we have just given them guidance to run performance tests on their own. Now they have another option, we are introducing native Integration with Azure Load Testing. A new performance optimizer is now available that enables you to decide the right configuration for your App by helping you to create and run tests by specifying different memory and Http concurrency configurations.
Functions on Azure Container Apps: Cloud-native microservices deployments
At Build we are also announcing GA of Functions running on Azure Container Apps. This new SKU allows customers to run their apps using the Azure Functions programming model and event driven triggers alongside other microservices or web applications co-located on the same environment. It allows a customer to leverage common networking resources and observability for all their applications. Furthermore, this allows Functions customers wanting to leverage frameworks (like Dapr) and compute options like GPU’s which are only available on Container Apps environments.
We had to keep this SKU consistent with other Function SKUs/plans, even though it ran and scaled on a different platform (Container Apps).
In particular,
We created a new database for this SKU that can handle different schema needs (because of the differences in the underlying infra compared to regular Functions) and improved the query performance. We also redesigned some parts of the control plane for Functions on ACA.
We used ARM extensions routing to securely route the traffic to host and enable Function Host APIs via ARM for Apps running inside an internal VNET
We built a sync trigger service inside Azure Container Apps environment that detects Function App, reads trigger information from customer’s functions code and automatically creates corresponding KEDA scaler rules for the Function App. This enables automatic scaling of Function Apps on Azure Container Apps (ACA), without customers having to know about the KEDA scaling platform involved.
We developed a custom KEDA external scaler to support scale-to-zero scenario for Timer trigger functions.
VSCode.Web support: Develop your functions in the browser
The Azure Functions team values developer productivity and our VSCode integration and Core Tools are top-notch and one of the main advantages in experience over other similar products in this category. However, we are always striving to enhance this experience.
It is often challenging for developers to configure their local dev machine with the right pre-requisites before they can begin. This setup also needs to be updated with the new versions of local tools and language versions. On the other hand, GitHub codespaces and similar developer environments have demonstrated that we can have effective development environments hosted in the cloud.
We are launching a new getting started experience using VSCode for the Web for Azure Functions. This experience allows developers to write, debug, test and deploy their function code directly from their browser using VS Code for the Web, which is connected to a container-based-compute. This is the same exact experience that a developer would have locally. This container comes ready with all the required dependencies and supports the rich features offered by VS Code, including extensions. This experience can also be used for function apps that already have code deployed to them as well.
To build this functionality we built an extension that launches VS Code for the Web, a lightweight VS Code that runs in a user’s browser. This VS Code client will communicate with Azure Functions backend infrastructure t to establish a connection to a VS Code server using a Dev Tunnel. With the VS Code client and server connected via a DevTunnel, the user will be able to edit their function as desired.
Open AI extension to build AI apps effortlessly
Azure Functions aims to simplify the development of different types of apps, such as web apps, data pipelines and other related work loads. AI apps is a clear new domain. Azure Functions has a rich extensibility model helping developers abstract away many of the mundane tasks that are required for integration along with making the capability be available for all the languages that Functions support.
We are releasing an extension on top of OpenAI which enables the following scenarios in just a few lines of code:
Retrieval Augmented Generation (Bring your own data)
Text completion and Chat Completion
Assistants’ capability
Key here is that developers can build AI apps in any language of their choice that is supported by Functions and are hosted in a service that can be used within minutes.
Have a look at the following code snippet in C# where in a few lines of code:
This HTTP trigger function takes a query prompt as input, pulls in semantically similar document chunks into a prompt, and then sends the combined prompt to OpenAI. The results are then made available to the function, which simply returns that chat response to the caller.
public class SemanticSearchRequest
{
[JsonPropertyName(“Prompt”)]
public string? Prompt { get; set; }
}
[Function(“PromptFile”)]
public static IActionResult PromptFile(
[HttpTrigger(AuthorizationLevel.Function, “post”)] SemanticSearchRequest unused,
[SemanticSearchInput(“AISearchEndpoint”, “openai-index”, Query = “{Prompt}”, ChatModel = “%CHAT_MODEL_DEPLOYMENT_NAME%”, EmbeddingsModel = “%EMBEDDING_MODEL_DEPLOYMENT_NAME%”)] SemanticSearchContext result)
{
return new ContentResult { Content = result.Response, ContentType = “text/plain” };
}
The challenges of building an extension are making sure that it hides enough of “glue code” and at the same time give enough flexibility to the developer for their business use case.
Furthermore, these were some additional challenges we faced:
To save state across invocations in the chat completion scenarios we experimented with various implementations including Durable Functions and finally we move to using Table storage for preserving state during conversations.
We had to figure out which embeddings store we should pursue support – we currently support Azure AI Search, Cosmos DB and Azure Data Explorer
Like any technology that is moving fast we had to figure out the right strategy to use the underlying Open AI models and SDKS.
Streaming support in Node and Python
Another long asked for support that was added at Build is streaming support in Node (GA) and Python (preview)
With this feature, customers can stream HTTP requests to and responses from their Function Apps, using function exposed request and response APIs. Previously with HTTP requests, the amount of data that could be transmitted was limited to the SKU instance memory size. With HTTP streaming, large amounts of data can be processed with chunking. Especially relevant today is that this feature enables new scenarios when creating AI apps including processing large data streaming OpenAI responses and delivering dynamic content.
The journey to enable streaming support is interesting. It started with us first aiming for parity between in-proc and isolated models for .NET. To achieve this we implemented a new Http pipeline where-in the Http request would be proxied from the Functions Host onto the isolated worker. We were able to piggyback on the same technology to build streaming support in other out-of-proc languages.
OpenTelemetry support
In Build we are releasing support for OpenTelemetry in Functions. This allows customers to export telemetry data from both the Functions Host and from the language workers using OpenTelemetry semantics. These are some of the interesting design directions we took for this work:
The customer’s code ignores the Functions host and re-creates the context in each language worker for a smooth experience.
Telemetry is the same for ApplicationInsights and other vendors; customers get the same telemetry data no matter what they use. LiveLogs works with AI, but the overall experience doesn’t change.
To make things easier for our customers, each language worker has a package/module that removes extra code.
Thank you and going forward
Thank you to all the customers and developers who have used Azure Functions through the years. We would love for you to try out these new features and capabilities and provide feedback and suggestions.
Going forward we will be working on:
Getting Flex Consumption to GA to enable more scale for our most demanding customers and keep making improvements in the meanwhile.
Continue to keep enhancing the Open AI extension with more scenarios and models to make Azure Functions the easiest and fastest way to create an AI service.
Continue to enhance our getting started experience and take VSCode.Web integration to more languages and to GA.
Adding support for Streaming to other languages including Java.
Microsoft Tech Community – Latest Blogs –Read More
Group creation needed to start a campaign
Hello all – We recently were granted a trial of Amplify. I went to create a campaign and received an error message. The error message I received said that I do not have access to create groups. I did a little research and found this:
Ensure Microsoft 365 group creation has been enabled for you. You can connect with your admin to check if you have the necessary permissions. Learn more about Microsoft 365 group creation permissions.
Question for this group: How did your organizations get around allowing group creation for those with campaign access? Any guidance is greatly appreciated.
Hello all – We recently were granted a trial of Amplify. I went to create a campaign and received an error message. The error message I received said that I do not have access to create groups. I did a little research and found this: Ensure Microsoft 365 group creation has been enabled for you. You can connect with your admin to check if you have the necessary permissions. Learn more about Microsoft 365 group creation permissions.Question for this group: How did your organizations get around allowing group creation for those with campaign access? Any guidance is greatly appreciated. Read More
Azure File Share – NTFS Permission Extremely Slow
Recently moved file server data to Azure File Share. No issue with mapping, opening files. The issue is when managing the permission. When updating/adding NTFS permission per folder, it is EXTREMELY slow. Any advise or workaround that you could share please.
Thank you.
Recently moved file server data to Azure File Share. No issue with mapping, opening files. The issue is when managing the permission. When updating/adding NTFS permission per folder, it is EXTREMELY slow. Any advise or workaround that you could share please. Thank you. Read More
How can I join Microsoft
I would be honored to join the Microsoft team and contribute to the Copilot team’s mission of providing innovative solutions to enterprises. I recognize the immense potential of this technology to benefit businesses, and I am eager to be a part of the team that is driving its development. I kindly request your guidance on the process of joining the team. Thank you for considering my interest.
I would be honored to join the Microsoft team and contribute to the Copilot team’s mission of providing innovative solutions to enterprises. I recognize the immense potential of this technology to benefit businesses, and I am eager to be a part of the team that is driving its development. I kindly request your guidance on the process of joining the team. Thank you for considering my interest. Read More
GDAP and not allowing global admin to auto renew
Hi all,
The relationships we created two years ago are quickly approaching their expiration date, and I’m interested in how other people are handling the creation of new relationships.
With the introduction of relationships that auto renew, have you found this to be a viable path? We are a Managed Service Provider and our customers expect us to turn ALL the knobs for them in the Microsoft portals.
I want to have the flexibility of techs only enabling the roles they need, but there are a LOT of roles. Creating a relationship with 34 roles is a bit extreme. Plus, it looks like we need 43 built-in roles to have the same level as access as Global Admin, and some of those roles are not available via GDAP today.
The role that stands out the most is “Organizational Branding Administrator.” Am I missing something, or is the only way to change sign-in branding to use the Global Administrator role (which prevents auto-renewal) or use a local tenant admin account?
What would partners think if Microsoft allowed the Global Admin role to auto-renew until Microsoft adds all the built in roles to GDAP roles needed to replace Global Admin? Maybe put some sort of extra warning on the role acceptance side advising the client this is not recommended and let the client make that informed choice themselves?
What do you think customers opinion of this move would be?
From my conversations with different people, I am under the impression that customers didn’t want Microsoft to allow partners the option of letting the Global Admin role auto-renew. Since I have never met a customer that shared this view, I can’t comment on the accuracy of that statement, but that what I’ve heard.
Hi all,The relationships we created two years ago are quickly approaching their expiration date, and I’m interested in how other people are handling the creation of new relationships. With the introduction of relationships that auto renew, have you found this to be a viable path? We are a Managed Service Provider and our customers expect us to turn ALL the knobs for them in the Microsoft portals. I want to have the flexibility of techs only enabling the roles they need, but there are a LOT of roles. Creating a relationship with 34 roles is a bit extreme. Plus, it looks like we need 43 built-in roles to have the same level as access as Global Admin, and some of those roles are not available via GDAP today. The role that stands out the most is “Organizational Branding Administrator.” Am I missing something, or is the only way to change sign-in branding to use the Global Administrator role (which prevents auto-renewal) or use a local tenant admin account? What would partners think if Microsoft allowed the Global Admin role to auto-renew until Microsoft adds all the built in roles to GDAP roles needed to replace Global Admin? Maybe put some sort of extra warning on the role acceptance side advising the client this is not recommended and let the client make that informed choice themselves? What do you think customers opinion of this move would be? From my conversations with different people, I am under the impression that customers didn’t want Microsoft to allow partners the option of letting the Global Admin role auto-renew. Since I have never met a customer that shared this view, I can’t comment on the accuracy of that statement, but that what I’ve heard. Read More
Azure Functions at Build 2024 – Solving customer problems with deep engineering
Azure Functions is Azure’s primary serverless service used in production by hundreds of thousands of customers who run trillions of executions on it monthly. It was first released in early 2016 and since then we have learnt a lot from our customers on what works and where they would like to see more.
Taking all this feedback into consideration, the Azure Functions team has worked hard to improve the experience across the stack from the initial getting started experience all the way to running at very high scale. Please see this link for a list of all the capabilities we have released in this year’s Build conference. Taking everything into account, this is one of the most significant set of releases in Functions history.
In this blog post, I will share a brief glimpse behind the scenes of some of the technical work that the Functions and other partner teams did to meet the expectations of our customers. We will write more technical blogs to explain these areas in depth this is a brief overview.
Flex Consumption: Burst scale your apps with networking support
We are releasing a new SKU of Functions, Flex Consumption. This SKU addresses all the feedback that we have received over the years on the Functions Consumption plans. We have looked at each part of the stack and made improvements at all levels. There are many new capabilities including:
Scales much faster than before with user controlled per-instance concurrency
Scale to many more instances than before (upto 100)
Serverless “scale to zero” SKU that also supports VNET integrated event sources
Supports always allocated workers
Supports multiple memory sizes
Purpose built backend “Legion”
To enable Flex Consumption, we have created a brand-new purpose-built backend internally called Legion.
To host customer code, Legion relies on nested virtualization on Azure VMSS. This gives us the Hyper-V isolation that is a pre-requisite for hostile multi-tenant workloads. Legion was built right from the outset to support scaling to thousands of instances with VNET injection. Efficient use of subnet IP addresses by use of kernel level routing was also a unique achievement in Legion.
For all languages, functions have a strict goal for cold start. To achieve this cold start metric for all languages and versions, and to support functions image update for all these variants, we had to create a construct called Pool Groups that allows functions to specify all the parameters of the pool, as well as networking and upgrade policies.
All this work led us to a solid, scalable and fast infrastructure on which to build Flex Consumption on.
“Trigger Monitor” – scale to 0 and scale out with network restrictions
Flex Consumption also introduces networking features to limit access to the Function app and to be able to trigger on event sources which are network restricted. Since these event sources are network restricted the multi-tenant scaling component scale controller that monitors the rate of events to determine to scale out or scale in cannot access them. In the Elastic Premium plan in which we scale down to 1 instance – we solved this by that instance having access to the network restricted event source and then communicating scale decisions to the scale controller. However, in the Flex Consumption plan we wanted to scale down to 0 instances.
To solve this, we implemented a small scaling component we call “Trigger Monitor” that is injected into the customers VNET. This component is now able to access the network restricted event source. The scale controller now communicates with this component to get scaling decisions.
Scaling Http based apps based on concurrency
When scaling Http based workloads on Function apps our previous implementation used an internal heuristic to decide when to scale out. This heuristic was based on Front End servers,: pinging the workers that are currently running customers workload and deciding to scale based on the latency of the responses. This implementation used SQL Azure to track workers and assignments for these workers.
In Flex Consumption we have rewritten this logic where now scaling is based on user configured concurrency. User configured concurrency gives customers flexibility in deciding based on the language and workload what concurrency they want to set per instance. So, for example, for Python customers they don’t have to think about multithreading and can set concurrency =1 (which is also the default for Python apps). This approach makes the scaling behavior predictable, and it gives customers the ability to control the cost vs performance tradeoff – if they are willing to tolerate the potential for higher latency, they might unlock cost savings by running each worker at higher levels of concurrency.
In our implementation, we use “request slots” that are managed by the Data Role. We split instances into “request slots” and assign them to different Front End servers. For example: If the per-instance concurrency is set to 16, then once the Data Role chooses an instance to allocate a Function app to, there are 16 request slots that it can hand out to Front Ends. It might give all 16 to a single Front End, or share them across multiple. This removes the need for any coordination between Front Ends – they can use the request slots they receive as much as they like, with the restriction of only one concurrent request per request slot. Also, this implementation uses Cosmos DB to track assignments and workers.
Along with the Legion as the compute provider, significantly large compute allocation per app and rapid scale in and capacity reclamation allows us to give customers much better experience than before.
Scaling Non-Http based apps based on concurrency
Similar to Http apps, we have also enabled Non-Http based apps to scale based on concurrency. We refer to this as Target Based Scaling. . From an implementation perspective we have moved to have various extensions implement scaling logic within the extension and the scale controller hosts these extensions. This unifies the scaling logic in one place and unifies all scaling based on concurrency.
Moving configuration to the Control Plane
One more change that we are making directionally based on feedback from our customers is to move from using AppSettings for various configuration properties to moving them to the Control Plane. For Public Preview we are doing this for the areas of Deployment, Scaling, Language. This is an example configuration which shows the new Control Plane properties. By GA we will move other properties as well.
Functions on Azure Container Apps: Cloud-native microservices deployments
At Build we are also announcing GA of Functions running on Azure Container Apps. This new SKU allows customers to run their apps using the Azure Functions programming model and event driven triggers alongside other microservices or web applications co-located on the same environment. It allows a customer to leverage common networking resources and observability for all their applications. Furthermore, this allows Functions customers wanting to leverage frameworks (like Dapr) and compute options like GPU’s which are only available on Container Apps environments.
We had to keep this SKU consistent with other Function SKUs/plans, even though it ran and scaled on a different platform (Container Apps).
In particular,
We created a new database for this SKU that can handle different schema needs (because of the differences in the underlying infra compared to regular Functions) and improved the query performance. We also redesigned some parts of the control plane for Functions on ACA.
We used ARM extensions routing to securely route the traffic to host and enable Function Host APIs via ARM for Apps running inside an internal VNET
We built a sync trigger service inside Azure Container Apps environment that detects Function App, reads trigger information from customer’s functions code and automatically creates corresponding KEDA scaler rules for the Function App. This enables automatic scaling of Function Apps on Azure Container Apps (ACA), without customers having to know about the KEDA scaling platform involved.
We developed a custom KEDA external scaler to support scale-to-zero scenario for Timer trigger functions.
VSCode.Web support: Develop your functions in the browser
The Azure Functions team values developer productivity and our VSCode integration and Core Tools are top-notch and one of the main advantages in experience over other similar products in this category. However, we are always striving to enhance this experience.
It is often challenging for developers to configure their local dev machine with the right pre-requisites before they can begin. This setup also needs to be updated with the new versions of local tools and language versions. On the other hand, GitHub codespaces and similar developer environments have demonstrated that we can have effective development environments hosted in the cloud.
We are launching a new getting started experience using VSCode for the Web for Azure Functions. This experience allows developers to write, debug, test and deploy their function code directly from their browser using VS Code for the Web, which is connected to a container-based-compute. This is the same exact experience that a developer would have locally. This container comes ready with all the required dependencies and supports the rich features offered by VS Code, including extensions. This experience can also be used for function apps that already have code deployed to them as well.
To build this functionality we built an extension that launches VS Code for the Web, a lightweight VS Code that runs in a user’s browser. This VS Code client will communicate with Azure Functions backend infrastructure t to establish a connection to a VS Code server using a Dev Tunnel. With the VS Code client and server connected via a DevTunnel, the user will be able to edit their function as desired.
Open AI extension to build AI apps effortlessly
Azure Functions aims to simplify the development of different types of apps, such as web apps, data pipelines and other related work loads. AI apps is a clear new domain. Azure Functions has a rich extensibility model helping developers abstract away many of the mundane tasks that are required for integration along with making the capability be available for all the languages that Functions support.
We are releasing an extension on top of OpenAI which enables the following scenarios in just a few lines of code:
Retrieval Augmented Generation (Bring your own data)
Text completion and Chat Completion
Assistants’ capability
Key here is that developers can build AI apps in any language of their choice that is supported by Functions and are hosted in a service that can be used within minutes.
Have a look at the following code snippet in C# where in a few lines of code:
This HTTP trigger function takes a query prompt as input, pulls in semantically similar document chunks into a prompt, and then sends the combined prompt to OpenAI. The results are then made available to the function, which simply returns that chat response to the caller.
public class SemanticSearchRequest
{
[JsonPropertyName(“Prompt”)]
public string? Prompt { get; set; }
}
[Function(“PromptFile”)]
public static IActionResult PromptFile(
[HttpTrigger(AuthorizationLevel.Function, “post”)] SemanticSearchRequest unused,
[SemanticSearchInput(“AISearchEndpoint”, “openai-index”, Query = “{Prompt}”, ChatModel = “%CHAT_MODEL_DEPLOYMENT_NAME%”, EmbeddingsModel = “%EMBEDDING_MODEL_DEPLOYMENT_NAME%”)] SemanticSearchContext result)
{
return new ContentResult { Content = result.Response, ContentType = “text/plain” };
}
The challenges of building an extension are making sure that it hides enough of “glue code” and at the same time give enough flexibility to the developer for their business use case.
Furthermore, these were some additional challenges we faced:
To save state across invocations in the chat completion scenarios we experimented with various implementations including Durable Functions and finally we move to using Table storage for preserving state during conversations.
We had to figure out which embeddings store we should pursue support – we currently support Azure AI Search, Cosmos DB and Azure Data Explorer
Like any technology that is moving fast we had to figure out the right strategy to use the underlying Open AI models and SDKS.
Streaming support in Node and Python
Another long asked for support that was added at Build is streaming support in Node (GA) and Python (preview)
With this feature, customers can stream HTTP requests to and responses from their Function Apps, using function exposed request and response APIs. Previously with HTTP requests, the amount of data that could be transmitted was limited to the SKU instance memory size. With HTTP streaming, large amounts of data can be processed with chunking. Especially relevant today is that this feature enables new scenarios when creating AI apps including processing large data streaming OpenAI responses and delivering dynamic content.
The journey to enable streaming support is interesting. It started with us first aiming for parity between in-proc and isolated models for .NET. To achieve this we implemented a new Http pipeline where-in the Http request would be proxied from the Functions Host onto the isolated worker. We were able to piggyback on the same technology to build streaming support in other out-of-proc languages.
OpenTelemetry support
In Build we are releasing support for OpenTelemetry in Functions. This allows customers to export telemetry data from both the Functions Host and from the language workers using OpenTelemetry semantics. These are some of the interesting design directions we took for this work:
The customer’s code ignores the Functions host and re-creates the context in each language worker for a smooth experience.
Telemetry is the same for ApplicationInsights and other vendors; customers get the same telemetry data no matter what they use. LiveLogs works with AI, but the overall experience doesn’t change.
To make things easier for our customers, each language worker has a package/module that removes extra code.
Thank you and going forward
Thank you to all the customers and developers who have used Azure Functions through the years. We would love for you to try out these new features and capabilities and provide feedback and suggestions.
Going forward we will be working on:
Getting Flex Consumption to GA and keep making improvements in the meanwhile.
Continue to keep enhancing the Open AI extension with more scenarios and models to make Azure Functions the easiest and fastest way to create an AI service.
Continue to enhance our getting started experience and take VSCode.Web integration to more languages and to GA.
Adding support for Streaming to other languages including Java.
Microsoft Tech Community – Latest Blogs –Read More
Azure Functions at Build 2024 – Technical underpinnings and challenges
Azure Functions is Azure’s primary serverless service used in production by hundreds of thousands of customers who run trillions of executions on it monthly. It was first released in early 2016 and since then we have learnt a lot from our customers on what works and where they would like to see more.
Taking all this feedback into consideration, the Azure Functions team has worked hard to improve the experience across the stack from the initial getting started experience all the way to running at very high scale. Please see this link for a list of all the capabilities we have released in this year’s Build conference. Taking everything into account, this is one of the most significant set of releases in Functions history.
In this blog post, I will share a brief glimpse behind the scenes of some of the technical work that the Functions and other partner teams did to meet the expectations of our customers. We will write more technical blogs to explain these areas in depth this is a brief overview.
Flex Consumption: Burst scale your apps with networking support
We are releasing a new SKU of Functions, Flex Consumption. This SKU addresses all the feedback that we have received over the years on the Functions Consumption plans. We have looked at each part of the stack and made improvements at all levels. There are many new capabilities including:
Scales much faster than before with user controlled per-instance concurrency
Serverless “scale to zero” SKU that also supports VNET integrated event sources
Supports always allocated workers
Supports multiple memory sizes
Purpose built backend “Legion”
To enable Flex Consumption, we have created a brand-new purpose-built backend internally called Legion.
To host customer code, Legion relies on nested virtualization on Azure VMSS. This gives us the Hyper-V isolation that is a pre-requisite for hostile multi-tenant workloads. Legion was built right from the outset to support scaling to thousands of instances with VNET injection. Efficient use of subnet IP addresses by use of kernel level routing was also a unique achievement in Legion.
For all languages, functions have a strict goal for cold start. To achieve this cold start metric for all languages and versions, and to support functions image update for all these variants, we had to create a construct called Pool Groups that allows functions to specify all the parameters of the pool, as well as networking and upgrade policies.
All this work led us to a solid, scalable and fast infrastructure on which to build Flex Consumption on.
“Trigger Monitor” – scale to 0 and scale out with network restrictions
Flex Consumption also introduces networking features to limit access to the Function app and to be able to trigger on event sources which are network restricted. Since these event sources are network restricted the multi-tenant scaling component scale controller that monitors the rate of events to determine to scale out or scale in cannot access them. In the Elastic Premium plan in which we scale down to 1 instance – we solved this by that instance (which also has access to the network restricted event source) also communicating scale decisions to the scale controller. However, in the Flex Consumption plan we wanted to scale down to 0 instances.
To solve this, we implemented a small scaling component we call “Trigger Monitor” that is injected into the customers VNET. This component is now able to access the network restricted event source. The scale controller now communicates with this component to get scaling decisions.
Scaling Http based apps based on concurrency
When scaling Http based workloads on Function apps our previous implementation used an internal heuristic to decide when to scale out. This heuristic was based on Front End servers,: pinging the workers that are currently running customers workload and deciding to scale based on the latency of the responses. This implementation used SQL Azure to track workers and assignments for these workers.
In Flex Consumption we have rewritten this logic where now scaling is based on user configured concurrency. User configured concurrency gives customers flexibility in deciding based on the language and workload what concurrency they want to set per instance. So, for example, for Python customers they don’t have to think about multithreading and can set concurrency =1 (which is also the default for Python apps). This approach makes the scaling behavior predictable, and it gives customers the ability to control the cost vs performance tradeoff – if they are willing to tolerate the potential for higher latency, they might unlock cost savings by running each worker at higher levels of concurrency.
In our implementation, we use “request slots” that are managed by the Data Role. We split instances into “request slots” and assign them to different Front End servers. For example: If the per-instance concurrency is set to 16, then once the Data Role chooses an instance to allocate a Function app to, there are 16 request slots that it can hand out to Front Ends. It might give all 16 to a single Front End, or share them across multiple. This removes the need for any coordination between Front Ends – they can use the request slots they receive as much as they like, with the restriction of only one concurrent request per request slot. Also, this implementation uses Cosmos DB to track assignments and workers.
Along with the Legion as the compute provider, significantly large compute allocation per app and rapid scale in and capacity reclamation allows us to give customers much better experience than before.
Scaling Non-Http based apps based on concurrency
Similar to Http apps, we have also enabled Non-Http based apps to scale based on concurrency. We refer to this as Target Based Scaling. . From an implementation perspective we have moved to have various extensions implement scaling logic within the extension and the scale controller hosts these extensions. This unifies the scaling logic in one place and unifies all scaling based on concurrency.
Moving configuration to the Control Plane
One more change that we are making directionally is to move from using AppSettings for various configuration properties to moving them to the Control Plane. For Public Preview we are doing this for the areas of Deployment, Scaling, Language. This is an example configuration which shows the new Control Plane properties. By GA we will move other properties as well.
Functions on Azure Container Apps: Cloud-native microservices deployments
At Build we are also announcing GA of Functions running on Azure Container Apps. This new SKU allows customers to run their apps using the Azure Functions programming model and event driven triggers alongside other microservices or web applications co-located on the same environment. It allows a customer to leverage common networking resources and observability for all their applications. Furthermore, this allows Functions customers wanting to leverage frameworks (like Dapr) and compute options like GPU’s which are only available on Container Apps environments.
We had to keep this SKU consistent with other Function SKUs/plans, even though it ran and scaled on a different platform (Container Apps).
In particular,
We created a new database for this SKU that can handle different schema needs (because of the differences in the underlying infra compared to regular Functions) and improved the query performance. We also redesigned some parts of the control plane for Functions on ACA.
We used ARM extensions routing to securely route the traffic to host and enable Function Host APIs via ARM for Apps running inside an internal VNET
We built a sync trigger service inside Azure Container Apps environment that detects Function App, reads trigger information from customer’s functions code and automatically creates corresponding KEDA scaler rules for the Function App. This enables automatic scaling of Function Apps on Azure Container Apps (ACA), without customers having to know about the KEDA scaling platform involved.
We developed a custom KEDA external scaler to support scale-to-zero scenario for Timer trigger functions.
VSCode.Web support: Develop your functions in the browser
The Azure Functions team values developer productivity and our VSCode integration and Core Tools are top-notch and one of the main advantages in experience over other similar products in this category. However, we are always striving to enhance this experience.
It is often challenging for developers to configure their local dev machine with the right pre-requisites before they can begin. This setup also needs to be updated with the new versions of local tools and language versions. On the other hand, GitHub codespaces and similar developer environments have demonstrated that we can have effective development environments hosted in the cloud.
We are launching a new getting started experience using VSCode for the Web for Azure Functions. This experience allows developers to write, debug, test and deploy their function code directly from their browser using VS Code for the Web, which is connected to a container-based-compute. This is the same exact experience that a developer would have locally. This container comes ready with all the required dependencies and supports the rich features offered by VS Code, including extensions. This experience can also be used for function apps that already have code deployed to them as well.
To build this functionality we built an extension that launches VS Code for the Web, a lightweight VS Code that runs in a user’s browser. This VS Code client will communicate with Azure Functions backend infrastructure t to establish a connection to a VS Code server using a Dev Tunnel. With the VS Code client and server connected via a DevTunnel, the user will be able to edit their function as desired.
Open AI extension to build AI apps effortlessly
Azure Functions aims to simplify the development of different types of apps, such as web apps, data pipelines and other related work loads. AI apps is a clear new domain. Azure Functions has a rich extensibility model helping developers abstract away many of the mundane tasks that are required for integration along with making the capability be available for all the languages that Functions support.
We are releasing an extension on top of OpenAI which enables the following scenarios in just a few lines of code:
Retrieval Augmented Generation (Bring your own data)
Text completion and Chat Completion
Assistants’ capability
Key here is that developers can build AI apps in any language of their choice that is supported by Functions and are hosted in a service that can be used within minutes.
Have a look at the following code snippet in C# where in a few lines of code:
This HTTP trigger function takes a query prompt as input, pulls in semantically similar document chunks into a prompt, and then sends the combined prompt to OpenAI. The results are then made available to the function, which simply returns that chat response to the caller.
public class SemanticSearchRequest
{
[JsonPropertyName(“Prompt”)]
public string? Prompt { get; set; }
}
[Function(“PromptFile”)]
public static IActionResult PromptFile(
[HttpTrigger(AuthorizationLevel.Function, “post”)] SemanticSearchRequest unused,
[SemanticSearchInput(“AISearchEndpoint”, “openai-index”, Query = “{Prompt}”, ChatModel = “%CHAT_MODEL_DEPLOYMENT_NAME%”, EmbeddingsModel = “%EMBEDDING_MODEL_DEPLOYMENT_NAME%”)] SemanticSearchContext result)
{
return new ContentResult { Content = result.Response, ContentType = “text/plain” };
}
The challenges of building an extension are making sure that it hides enough of “glue code” and at the same time give enough flexibility to the developer for their business use case.
Furthermore, these were some additional challenges we faced:
To save state across invocations in the chat completion scenarios we experimented with various implementations including Durable Functions and finally we move to using Table storage for preserving state during conversations.
We had to figure out which embeddings store we should pursue support – we currently support Azure AI Search, Cosmos DB and Azure Data Explorer
Like any technology that is moving fast we had to figure out the right strategy to use the underlying Open AI models and SDKS.
Streaming support in Node and Python
Another long asked for support that was added at Build is streaming support in Node (GA) and Python (preview)
With this feature, customers can stream HTTP requests to and responses from their Function Apps, using function exposed request and response APIs. Previously with HTTP requests, the amount of data that could be transmitted was limited to the SKU instance memory size. With HTTP streaming, large amounts of data can be processed with chunking. Especially relevant today is that this feature enables new scenarios when creating AI apps including processing large data streaming OpenAI responses and delivering dynamic content.
The journey to enable streaming support is interesting. It started with us first aiming for parity between in-proc and isolated models for .NET. To achieve this we implemented a new Http pipeline where-in the Http request would be proxied from the Functions Host onto the isolated worker. We were able to piggyback on the same technology to build streaming support in other out-of-proc languages.
OpenTelemetry support
In Build we are releasing support for OpenTelemetry in Functions. This allows customers to export telemetry data from both the Functions Host and from the language workers using OpenTelemetry semantics. These are some of the interesting design directions we took for this work:
The customer’s code ignores the Functions host and re-creates the context in each language worker for a smooth experience.
Telemetry is the same for ApplicationInsights and other vendors; customers get the same telemetry data no matter what they use. LiveLogs works with AI, but the overall experience doesn’t change.
To make things easier for our customers, each language worker has a package/module that removes extra code.
Thank you and going forward
Thank you to all the customers and developers who have used Azure Functions through the years. We would love for you to try out these new features and capabilities and provide feedback and suggestions.
Going forward we will be working on:
Getting Flex Consumption to GA and keep making improvements in the meanwhile.
Continue to keep enhancing the Open AI extension with more scenarios and models to make Azure Functions the easiest and fastest way to create an AI service.
Continue to enhance our getting started experience and take VSCode.Web integration to more languages and to GA.
Adding support for Streaming to other languages including Java.
Microsoft Tech Community – Latest Blogs –Read More
Edge Browser window (all tabs included) recovery ?
A while ago, about two months ago roughly. I had accidently closed one of a few Microsoft Edge Browser Windows. I know that Edge has a recovery option but in my case the browser window was accidently closed; on top of that, disk space is low on the computer; for now.
Therefore it would be outrageous but not surprising if browser windows with all the tabs for that browser window was not kept somewhere on the computer. I know even with limited space that this file if it exists would still exist so I can retrieve the file ?
A while ago, about two months ago roughly. I had accidently closed one of a few Microsoft Edge Browser Windows. I know that Edge has a recovery option but in my case the browser window was accidently closed; on top of that, disk space is low on the computer; for now. Therefore it would be outrageous but not surprising if browser windows with all the tabs for that browser window was not kept somewhere on the computer. I know even with limited space that this file if it exists would still exist so I can retrieve the file ? Read More
how can i make linux terminal with asp.net
hello guys ,
so im working on project for graduation , i want to make at least a simple web application that contains a linux terminal emulator only , that takes commands from the user and execute them in the server and display the ouput back in the web page for the user , and im only begining to learn asp.net , so can someone plz explain to me how can i achieve that or at least give me a roadmap and the tools i need to get to the result i want cuz im realy feeling LOST right now :
hello guys ,so im working on project for graduation , i want to make at least a simple web application that contains a linux terminal emulator only , that takes commands from the user and execute them in the server and display the ouput back in the web page for the user , and im only begining to learn asp.net , so can someone plz explain to me how can i achieve that or at least give me a roadmap and the tools i need to get to the result i want cuz im realy feeling LOST right now : Read More
Support tip: Organizational messages is moving to Microsoft 365 admin center
The Intune experience for managing organizational messages will be removed no earlier than August 2024. You can now view and manage your messages created in Intune in the new experience within the Microsoft 365 admin center. The new experience includes new, top requested features such as the ability to author custom messages and message delivery on Microsoft 365 apps. To learn more about the new experience, review: Introducing organizational messages (preview) in the Microsoft 365 admin center.
Key points: What this means for messages created in Intune
If you’re using organizational messages in Intune, there are several key things to be aware of with the experience moving to Microsoft 365:
There’s no impact to your users unless you choose to cancel or delete messages.
Existing messages that you have created in Intune will be available in the new experience in Microsoft 365 admin center for you to continue viewing and managing.
Get Started messages cannot be created in Microsoft 365 admin center. Existing Get Started messages will continue to work until they are cancelled or deleted (which can be done in either Intune or the Microsoft 365 admin center).
All Intune role-based access control (RBAC) roles with organizational messages permissions will no longer work and you will have to create new roles (or custom roles) in Microsoft Entra.
Scope tags are only available in Intune and will not be applicable after this change.
Update RBAC assignments for organizational messages
Intune RBAC roles won’t work once the experience has been removed from Intune. You’ll want to update your Intune roles to the Microsoft Entra roles before August 2024 to ensure your admins are able to continue managing organizational messages.
To create organizational messages in Microsoft 365 admin center, create a new custom role or use one of the built-in roles in Microsoft Entra:
Organizational Messages Approver
Organizational Messages Writer
Microsoft Entra Global Administrator (not recommended as security best practice)
For instructions on creating custom roles or assigning roles in Entra, review the following documentation:
Create and assign a custom role in Microsoft Entra ID
Assign Microsoft Entra roles to users
Common questions
Will I be able to access organizational messages from Intune?
You can continue to access and manage organizational messages in Intune until the experience is removed no earlier than August 2024. After that, the organizational messages user interface within the Intune admin center (Tenant administration > Organizational messages) will be removed.
What will happen to messages I have created in Intune organizational messages?
Your entire messages history and all active messages from Intune’s organizational messages will be available to view, cancel, or delete in the Microsoft 365 admin center. All active messages from Intune will continue to be delivered until the expiration date you have specified.
What will change for my organization and users?
The following functionality will be impacted:
Scope tags will not be supported in or migrated to Microsoft 365 admin center. Any scope tags created in Intune will no longer be honored.
Any automated scripts for managing organizational messages in Intune will not work.
Any Intune RBAC roles will not be honored. You must enable the Entra RBAC roles highlighted above or create a custom role to create and manage organizational messages.
The authoring of new Get Started messages will not be available in Microsoft 365 admin center. These messages don’t expire and won’t be canceled until you take action to cancel or delete. Admins may cancel or delete any existing Get Started messages at any time.
How will an admin distinguish messages authored from Intune in the Microsoft 365 admin center?
Under the Message Detail pane, the Source field will indicate messages authored from Intune or other entry points.
What happens to audit logs of organizational messages in Intune?
Intune audit logs can be viewed in the Intune admin center for the last 30 days or up to 1 year when using Graph API.
How will this impact the existing setting which allows you to block Microsoft messaging?
There’ll be no changes to the existing management of Microsoft messaging policy within Intune before August 2024. If you currently block messages that come from Microsoft, you can continue to do so while also allowing organizational messages to come through. Later, after August 2024, this functionality will migrate to organizational messages in the Microsoft 365 admin center.
Sign in to the Microsoft Intune admin center.
Go to Tenant administration > Organizational messages.
In the Overview tab, go to step 2 under “Before you create a message”.
Decide whether to block messages directly from Microsoft, while allowing admin messages to display by:
Switching the toggle to Allow to allow both Microsoft messages and organizational messages.
Switching the toggle to Block to block Microsoft messages and allow organizational messages.
Stay tuned to this post for updates on the exact timing of this change! If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam.
Microsoft Tech Community – Latest Blogs –Read More
Can’t Delete Marketplace Listings
Partner Center does not allow you to delete a marketplace listing (only drafts), but does allow you to hide. Why? This has a huge impact on downstream integrations with Tackle.io, Workspan, etc.
Partner Center does not allow you to delete a marketplace listing (only drafts), but does allow you to hide. Why? This has a huge impact on downstream integrations with Tackle.io, Workspan, etc. Read More
VLOOKUP Name error
I am using =Vlookup for a database to display my acct names and passwords.
It seems to be working although I get a #NAME? error. I am wanting the password to be displayed
The DB is located on a 2nd tab.
This my formula: =VLOOKUP($D$5,Database,3,Database!D2*********FALSE) (asterisks=password)
Help highlights $D$5
I am very new to Excel.
Thanks in advance!
I am using =Vlookup for a database to display my acct names and passwords.It seems to be working although I get a #NAME? error. I am wanting the password to be displayedThe DB is located on a 2nd tab. This my formula: =VLOOKUP($D$5,Database,3,Database!D2*********FALSE) (asterisks=password)Help highlights $D$5 I am very new to Excel.Thanks in advance! Read More
Simplify deletion of FHIR resources with the bulk delete operation in Azure Health Data Services
We are excited to share that the bulk delete capability for the FHIR® service in Azure Health Data Services is generally available. The FHIR service in Azure Health Data Services facilitates the exchange and persistence of health data by using the Fast Healthcare Interoperability Resources (FHIR) open data standard.
High throughput deletion for efficient data management
The bulk delete capability enables organizations to delete FHIR resources at high throughput. Bulk delete is particularly beneficial for organizations looking to adhere to data retention policies and integrate this capability into their data management workflows.
What can bulk delete do?
Previously, the FHIR service allowed deletion at an individual resource level or in batches of 100 resources that meet specified search criteria, requiring customers to build a workflow to delete large sets of resources at a specific time.
Responding to customer feedback, the bulk delete capability supports high-throughput operations, which you can invoke at various levels:
System-level deletion: Allows for the deletion of resources from the FHIR server across all resource types. System-level deletion is useful for removing historical data or cleaning outdated records.
Individual resource types: Allows deletion of resources corresponding to specific resource types, which enables selective removal of data.
Query parameters for filtering: Supports query parameters that filter and identify resources for deletion, which allows deletion of resources based on specific criteria such as patient resources with a birthdate after a certain value.
The bulk delete capability in the FHIR service is a result of input from our customers. We’re excited to make this capability available to our customers on Azure API for FHIR as well.
For a comprehensive understanding of bulk delete capability, visit Bulk Delete in the FHIR service.
Do more with your data with the Microsoft Cloud for Healthcare
In the era of AI, Microsoft Cloud for Healthcare enables healthcare organizations to accelerate their data and AI journey by augmenting the Microsoft Cloud with industry-relevant data solutions, templates, and capabilities. With Microsoft Cloud for Healthcare, healthcare organizations can create connected patient experiences, empower their workforce, and unlock the value from clinical and operational data using data standards that are important to healthcare. And we’re doing all of this on a foundation of trust. Every organization needs to safeguard their business, their customers, and their data. Microsoft Cloud runs on trust, and we’re helping every organization build safety and responsibility into their AI journey from the very beginning.
We’re excited to help your organization gain value from your data and use AI innovation to deliver meaningful outcomes across the entire healthcare journey.
Learn more about Azure Health Data Services.
Explore Microsoft Cloud for Healthcare.
Stay up to date with Azure Health Data Services Release Notes.
FHIR® is the registered trademark of HL7 and is used with the permission of HL7.
Microsoft Tech Community – Latest Blogs –Read More
SharePoint Online – View In File Explorer No Longer Working
Is anyone else having issues with the View In File Explorer function in SharePoint Online via Microsoft Edge. It was working for us until yesterday morning. All parameters and policies are in place, not sure why it stopped working. Any assistance is much appreciated.
Windows 11
MS Edge version 125.0.2535.51 (64-bit)
ConfigureViewInFileExplorer policies status: OK
Is anyone else having issues with the View In File Explorer function in SharePoint Online via Microsoft Edge. It was working for us until yesterday morning. All parameters and policies are in place, not sure why it stopped working. Any assistance is much appreciated.Windows 11MS Edge version 125.0.2535.51 (64-bit)ConfigureViewInFileExplorer policies status: OK Read More
Sum of values in a column based on corresponding values in another
How to add values in Column K if their corresponding L values match?
How to add values in Column K if their corresponding L values match? Read More
Conditional formatting – make a cell white based on another cell’s specific text “EXW”
Hello,
I could use some help regarding my sheet and would appreciate very much if someone could help me.
I have the need that every time in for example H3 it says EXW or FCA then I would like F3 to have no color/white.
Can any please help with this?
Thank you very much in advance.
Hello,I could use some help regarding my sheet and would appreciate very much if someone could help me.I have the need that every time in for example H3 it says EXW or FCA then I would like F3 to have no color/white.Can any please help with this?Thank you very much in advance. Read More
New Blog | Microsoft Security Development Lifecycle (SDL)
Security and privacy should never be an afterthought when developing software. A formal process must become standard practice to ensure they are considered at all points of the product’s lifecycle. The rise of software supply chain attacks—including the XZ Utils, SolarWinds attack and Log4j vulnerabilities—highlights the critical need to build security into the software development process, from the ground up.
Over the last 20 years, there have been many improvements to the security development lifecycle (SDL) reflecting changes in internal tools and processes. We are excited to announce that this week, we have updated the security practices on the SDL website, and we will continue to update this site with new information on a regular basis.
Microsoft Security Development Lifecycle (SDL) Timeline
Figure 1: Graphic of the SDL Timeline
In the early 2000s, personal computers (PCs) were becoming increasingly common in the home and the internet was gaining more widespread use. This led to a rise in malicious software looking to take advantage of users connecting their home PCs to the internet. It quickly became evident that protecting users from malicious software required a fundamentally different approach to security.
In January 2002, Microsoft launched its Trustworthy Computing initiative to help ensure Microsoft products and services were built to be inherently highly secure, available, reliable, and with business integrity.
Read the full post here: Microsoft Security Development Lifecycle (SDL)
By Joylynn Kirui
Security and privacy should never be an afterthought when developing software. A formal process must become standard practice to ensure they are considered at all points of the product’s lifecycle. The rise of software supply chain attacks—including the XZ Utils, SolarWinds attack and Log4j vulnerabilities—highlights the critical need to build security into the software development process, from the ground up.
Over the last 20 years, there have been many improvements to the security development lifecycle (SDL) reflecting changes in internal tools and processes. We are excited to announce that this week, we have updated the security practices on the SDL website, and we will continue to update this site with new information on a regular basis.
Microsoft Security Development Lifecycle (SDL) Timeline
Figure 1: Graphic of the SDL Timeline
In the early 2000s, personal computers (PCs) were becoming increasingly common in the home and the internet was gaining more widespread use. This led to a rise in malicious software looking to take advantage of users connecting their home PCs to the internet. It quickly became evident that protecting users from malicious software required a fundamentally different approach to security.
In January 2002, Microsoft launched its Trustworthy Computing initiative to help ensure Microsoft products and services were built to be inherently highly secure, available, reliable, and with business integrity.
Read the full post here: Microsoft Security Development Lifecycle (SDL) Read More
New Blog | Secure and Govern Your Custom-Built AI Apps with Microsoft Purview
By Liz Willets
The rise of generative AI unlocks new opportunities for developers to create groundbreaking applications. Studies show that 75% of organizations are more likely to adopt AI apps when they come with assurance mechanisms for secure and compliant use. This underscores the importance of building apps that can handle and govern sensitive data appropriately. But despite this growing demand for secure and compliant AI applications, developers often lack security expertise and tools to build these controls into custom-built applications. What developers need are easy to use APIs that enable them to build data security and compliance controls into their applications by design.
As consumers of AI applications, enterprises are concerned about data oversharing, data leakage, and non-compliant use of AI apps. Ensuring that your application meets enterprise needs for safeguarding against data risks is critical for enterprise adoption. Once deployed, security teams want visibility into which GenAI applications are being used, how often, by whom, and what kind of sensitive data is being shared with those applications.
On top of that, end users want clear visibility into the confidentiality of data referenced by AI applications. Ensuring that end users can clearly see the sensitivity label of any files referenced by your GenAI app is imperative. This visual cue informs the user that the application is interacting with a sensitive document, which is critical to maintain data integrity and compliance with their organization’s data handling obligations.
Today, we are excited to announce new innovations from Microsoft Purview to help developers build enterprise-grade security and compliance controls into their custom-built AI apps:
Microsoft Purview integration in Copilot Studio (public preview) and Azure AI Studio (coming soon) offers data security and compliance features to developers using Copilot Studio and Azure AI Studio. This integration provides visibility into when an application accesses sensitive data by recognizing and honoring sensitivity labels of the data being accessed. It also protects sensitive data generated by the app through label inheritance, and honors label permissions, limiting data access to authorized users only. Additionally, it facilitates governance of app development by providing audit logging for developer activities.
Build enterprise-grade data security and compliance controls with Purview SDK (coming soon) offering a set of easy to integrate APIs for pro-code developers. These APIs enable enterprise-grade data security, compliance and governance controls with just a few lines of code.
Microsoft Purview integration in Copilot Studio (public preview) and Azure AI Studio (coming soon)
For developers looking to get started today, we are thrilled to announce the integration of Microsoft Purview capabilities in Copilot Studio (public preview) and Azure AI Studio (coming soon). With this integration, Microsoft Purview capabilities come built-in so that when you build your custom apps in Copilot Studio or Azure AI Studio, your enterprise customers and end users get best-in-class security and governance features, including:
Discover data risks in AI interactions: Enhance end user confidence by providing visibility into the sensitivity label of the data referenced from SharePoint in responses from your custom-built Copilots and GenAI apps.
Protect sensitive data with encryption: Ensure that app generated responses inherit the sensitivity label of the files referenced and are encrypted accordingly. Additionally, ensure that your AI applications respect user permissions and sensitivity labels, limiting the access to sensitive data to authorized users only. This builds trust with your customers, as they know their data is handled according to their security policies.
Capture AI activities: Log developer activities during the creation of custom-built applications to understand which data sources were enabled, whether GenAI answers were enabled on those sources, and more. This ensure comprehensive oversight and transparency for enterprises purchasing your application to maintain control over data and applications interacting with it.
Figure 1: Copilot Studio can inherit labels from the referenced files, honor permission controls associated with the label, and enhance users’ awareness on the sensitivity of the content.
Read the full post here: Secure and Govern Your Custom-Built AI Apps with Microsoft Purview
By Liz Willets
The rise of generative AI unlocks new opportunities for developers to create groundbreaking applications. Studies show that 75% of organizations are more likely to adopt AI apps when they come with assurance mechanisms for secure and compliant use. This underscores the importance of building apps that can handle and govern sensitive data appropriately. But despite this growing demand for secure and compliant AI applications, developers often lack security expertise and tools to build these controls into custom-built applications. What developers need are easy to use APIs that enable them to build data security and compliance controls into their applications by design.
As consumers of AI applications, enterprises are concerned about data oversharing, data leakage, and non-compliant use of AI apps. Ensuring that your application meets enterprise needs for safeguarding against data risks is critical for enterprise adoption. Once deployed, security teams want visibility into which GenAI applications are being used, how often, by whom, and what kind of sensitive data is being shared with those applications.
On top of that, end users want clear visibility into the confidentiality of data referenced by AI applications. Ensuring that end users can clearly see the sensitivity label of any files referenced by your GenAI app is imperative. This visual cue informs the user that the application is interacting with a sensitive document, which is critical to maintain data integrity and compliance with their organization’s data handling obligations.
Today, we are excited to announce new innovations from Microsoft Purview to help developers build enterprise-grade security and compliance controls into their custom-built AI apps:
Microsoft Purview integration in Copilot Studio (public preview) and Azure AI Studio (coming soon) offers data security and compliance features to developers using Copilot Studio and Azure AI Studio. This integration provides visibility into when an application accesses sensitive data by recognizing and honoring sensitivity labels of the data being accessed. It also protects sensitive data generated by the app through label inheritance, and honors label permissions, limiting data access to authorized users only. Additionally, it facilitates governance of app development by providing audit logging for developer activities.
Build enterprise-grade data security and compliance controls with Purview SDK (coming soon) offering a set of easy to integrate APIs for pro-code developers. These APIs enable enterprise-grade data security, compliance and governance controls with just a few lines of code.
Microsoft Purview integration in Copilot Studio (public preview) and Azure AI Studio (coming soon)
For developers looking to get started today, we are thrilled to announce the integration of Microsoft Purview capabilities in Copilot Studio (public preview) and Azure AI Studio (coming soon). With this integration, Microsoft Purview capabilities come built-in so that when you build your custom apps in Copilot Studio or Azure AI Studio, your enterprise customers and end users get best-in-class security and governance features, including:
Discover data risks in AI interactions: Enhance end user confidence by providing visibility into the sensitivity label of the data referenced from SharePoint in responses from your custom-built Copilots and GenAI apps.
Protect sensitive data with encryption: Ensure that app generated responses inherit the sensitivity label of the files referenced and are encrypted accordingly. Additionally, ensure that your AI applications respect user permissions and sensitivity labels, limiting the access to sensitive data to authorized users only. This builds trust with your customers, as they know their data is handled according to their security policies.
Capture AI activities: Log developer activities during the creation of custom-built applications to understand which data sources were enabled, whether GenAI answers were enabled on those sources, and more. This ensure comprehensive oversight and transparency for enterprises purchasing your application to maintain control over data and applications interacting with it.
Figure 1: Copilot Studio can inherit labels from the referenced files, honor permission controls associated with the label, and enhance users’ awareness on the sensitivity of the content.
Read the full post here: Secure and Govern Your Custom-Built AI Apps with Microsoft Purview
New Blog | Azure Firewall integration in Copilot for Security: protect networks with Gen AI
Azure Firewall is a cloud-native and intelligent network firewall security service that provides best of breed threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. In this blog we will be focusing on the newly announced Azure Firewall integration in Copilot for Security.
How Copilot for Security works with the Azure Firewall plugin
The Azure Firewall integration in Copilot for Security helps analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Copilot for Security standalone experience.
The Azure Firewall plugin enabled in the Copilot for Security standalone experience
Read the full post here: Azure Firewall integration in Copilot for Security: protect networks at machine speed with Gen AI
By Abhinav Sriram
Azure Firewall is a cloud-native and intelligent network firewall security service that provides best of breed threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. In this blog we will be focusing on the newly announced Azure Firewall integration in Copilot for Security.
How Copilot for Security works with the Azure Firewall plugin
The Azure Firewall integration in Copilot for Security helps analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Copilot for Security standalone experience.
The Azure Firewall plugin enabled in the Copilot for Security standalone experience
Read the full post here: Azure Firewall integration in Copilot for Security: protect networks at machine speed with Gen AI
New Blog | Leverage Generative AI to expedite attack surface investigations in Defender EASM
By Soham Patel
A prerequisite to securing an organization on the internet is first knowing what digital assets in the organization are internet-facing. With the constantly changing internet, the migration to multi-cloud environments, the evolution of organizations with mergers and acquisitions, and the emergence of shadow IT, it is often difficult to maintain an updated external view of an organization’s attack surface, leading to security gaps emerging for attackers to exploit.
Microsoft Defender External Attack Surface Management (EASM) solves this challenge by discovering externally facing assets and identifying their risk. Their vulnerabilities can be identified, which helps with prioritizing them, so you know where to start with remediation efforts.
While Defender EASM equips organizations with an updated external attack surface view and the risks associated with it, these vast, multifaceted attack surfaces require many resources to analyze each asset and its associated metadata. This often increases the time to remediation and the likelihood of an attacker exploiting a security gap. However, generative AI can expedite this analysis process, enabling security professionals to defend organizations at machine speed.
At Microsoft Ignite in November 2023, we announced Defender EASM’s prompting capabilities in Copilot for Security. Today, we are thrilled to share that the same capabilities – and more – are available in public preview the Copilot chat pane in the Azure portal and can be used alongside Copilot for Security customers’ Defender EASM resources. This allows organizations to stay secure, with ease.
Dig into your external attack surface
The Copilot chat pane in Azure gives customers AI-driven insights on risky assets within their external attack surface. Instead of manually drilling down to investigate asset details, simply ask Copilot about recently expired SSL certificates and domains, and you’ll get automated answers for each in seconds. To understand which assets may have Common Vulnerabilities and Exposures (CVE), you can quickly find out by asking Copilot “which assets have critical severity CVEs?” or “Does this ‘CVE ID’ impact me?” Knowing where CVEs lie, and how they are classified, will help you in focusing resources and remediation efforts on those that matter most.
Our Copilot capabilities also enable customers to quickly identify assets impacted by specific risks and vulnerabilities, such as assets that have Common Vulnerability Scoring System (CVSS) scores, that are still using SHA-1 certificates, or are expiring soon – empowering them to determine what assets must be remediated first.
For example, we can investigate which assets are impacted by medium priority CVSS Scores and what vulnerabilities must be remediated to secure the targeted assets. In this scenario in the image below, we can see that because of the jQuery version, https://portal.fabrikam.com/ is at risk.
Read the full post here: Leverage Generative AI to expedite attack surface investigations in Defender EASM
By Soham Patel
A prerequisite to securing an organization on the internet is first knowing what digital assets in the organization are internet-facing. With the constantly changing internet, the migration to multi-cloud environments, the evolution of organizations with mergers and acquisitions, and the emergence of shadow IT, it is often difficult to maintain an updated external view of an organization’s attack surface, leading to security gaps emerging for attackers to exploit.
Microsoft Defender External Attack Surface Management (EASM) solves this challenge by discovering externally facing assets and identifying their risk. Their vulnerabilities can be identified, which helps with prioritizing them, so you know where to start with remediation efforts.
While Defender EASM equips organizations with an updated external attack surface view and the risks associated with it, these vast, multifaceted attack surfaces require many resources to analyze each asset and its associated metadata. This often increases the time to remediation and the likelihood of an attacker exploiting a security gap. However, generative AI can expedite this analysis process, enabling security professionals to defend organizations at machine speed.
At Microsoft Ignite in November 2023, we announced Defender EASM’s prompting capabilities in Copilot for Security. Today, we are thrilled to share that the same capabilities – and more – are available in public preview the Copilot chat pane in the Azure portal and can be used alongside Copilot for Security customers’ Defender EASM resources. This allows organizations to stay secure, with ease.
Dig into your external attack surface
The Copilot chat pane in Azure gives customers AI-driven insights on risky assets within their external attack surface. Instead of manually drilling down to investigate asset details, simply ask Copilot about recently expired SSL certificates and domains, and you’ll get automated answers for each in seconds. To understand which assets may have Common Vulnerabilities and Exposures (CVE), you can quickly find out by asking Copilot “which assets have critical severity CVEs?” or “Does this ‘CVE ID’ impact me?” Knowing where CVEs lie, and how they are classified, will help you in focusing resources and remediation efforts on those that matter most.
Our Copilot capabilities also enable customers to quickly identify assets impacted by specific risks and vulnerabilities, such as assets that have Common Vulnerability Scoring System (CVSS) scores, that are still using SHA-1 certificates, or are expiring soon – empowering them to determine what assets must be remediated first.
For example, we can investigate which assets are impacted by medium priority CVSS Scores and what vulnerabilities must be remediated to secure the targeted assets. In this scenario in the image below, we can see that because of the jQuery version, https://portal.fabrikam.com/ is at risk.
Read the full post here: Leverage Generative AI to expedite attack surface investigations in Defender EASM