Azure Search – New Storage Optimized service tiers available in preview

Azure Search is an AI-powered cloud search service for modern mobile and web app development. Azure Search is the only cloud search service with built-in artificial intelligence (AI) capabilities that enrich all types of information to easily identify and explore relevant content at scale. It uses the same integrated Microsoft natural language stack as Bing and Office, plus prebuilt AI APIs across vision, language, and speech. With Azure Search, you spend more time innovating on your websites and applications, and less time maintaining a complex search solution.

Today we are announcing the preview of two new service tiers for Storage Optimized workloads in Azure Search. These L-Series tiers offer significantly more storage at a reduced cost per terabyte when compared to the Standard tiers, ideal for solutions with a large amount of index data and lower query volume throughout the day, such as internal applications searching over large file repositories, archival scenarios when you have business data going back many years, or e-discovery applications. 

Searching over all your content

From finding a product on a retail site to looking up an account within a business application, search services power a wide range of solutions with differing needs. While some scenarios like product catalogs need to search over a relatively small amount of information (100MB to 1GB) quickly, for others it’s a priority to search over large amounts of information in order to properly research, perform business processes, and make decisions. With information growing at the rate of 2.5 quintillion bytes of new data per day, this is becoming a much more common–and costly– scenario, especially for businesses.

What’s new with the L-series tier

The new L-Series service tiers support the same programmatic API, command-line interfaces, and portal experience as the Basic and Standard tiers of Azure Search. Internally, Azure Search provisions compute and storage resources for you based on how you’ve scaled your service. Compared to the S-Series, each L-Series search unit has significantly more storage I/O bandwidth and memory, allowing each unit’s corresponding compute resources to address more data. The L-Series is designed to support much large indexes overall (up to 24 TB total on a fully scaled out L2) for applications.

	Standard S1	Standard S2	Standard S3	Storage Optimized L1	Storage Optimized L2
Storage	25 GB/partition (max 300 GB documents per service)	100 GB/partition (max 1.2 TB documents per service)	200 GB/partition (max 2.4 TB documents per service)	1 TB/partition (max 12 TB documents per service)	2 TB/partition (max 24 TB documents per service)
Max indexes per service	50	200	200 or 1000/partition in high density2 mode	10	10
Scale out limits	Up to 36 units per service (max 12 partitions; max 12 replicas)	Up to 36 units per service (max 12 partitions; max 12 replicas)	Up to 36 units per service (max 12 partitions; max 12 replicas) up to 12 replicas in high density2 mode	Up to 36 units per service (max 12 partitions; max 12 replicas)	Up to 36 units per service (max 12 partitions; max 12 replicas)

Customer success and common scenarios

We have been working closely with Capax Global LLC, A Hitachi Group Company to create a service tier that works for one of their customers. Capax Global combines well-established patterns and practices with emerging technologies while leveraging a wide range of industry and commercial software development experience. In our discussions with them, we found that a storage optimized tier would be a good fit for their application since it offers the same search functionality at a significantly lower price than the standard tier. 

“The new Azure Search Storage Optimized SKU provides a cost-effective solution for customers with a tremendous amount of content. With it, we’re now able to enrich the custom solutions we build for our customers with a cloud hosted document-based search that meets the search demands of millions of documents while continuing to lead with Azure. This new SKU has further strengthened the array of services we have to utilize to help our customers solve their business problems through technology.”

– Mitch Prince, VP Cloud Productivity + Enablement at Capax Global LLC, A Hitachi Group Company

The Storage Optimized service tiers are also a great fit for applications that incorporate the new cognitive search capabilities in Azure Search, where you can leverage AI-powered components to analyze and annotate large volumes of content, such as PDFs, office documents, and rows of structured data. These data stores can result in many terabytes of indexable data, which becomes very costly to store in a query latency-optimized service tier like the S3. Cognitive search combined with the L-Series tiers of Azure Search provide a full-text query solution capable of storing terabytes of data and returning results in seconds.

Regional availability

For the initial public preview, the Storage Optimized service tiers will be available in the following regions:

◈ West US 2

◈ South Central US

◈ North Central US

◈ West Europe

◈ UK South

◈ Australia East

Continue reading

Analyze AI enriched content with Azure Search’s knowledge store

Through integration with Cognitive Services APIs, Azure Search has long had the ability to extract text and structure from images and unstructured content. Until recently, this capability was used exclusively in full text search scenarios, exemplified in demos like the JFK files which analyzes diverse content in JPEGs and makes it available for online search. The journey from visual unstructured content, to searchable structured content is enabled by a feature called cognitive search. This capability in Azure Search is now extended with the addition of a knowledge store that saves enrichments for further exploration and analysis beyond search itself.

The knowledge store feature of Azure Search, available in preview, refers to a persistence layer in cognitive search that describes a physical expression of documents created through AI enrichments. Enriched documents are projected into tables or hierarchical JSON, which you can explore using any client app that is able to access Azure Storage. In Azure Search itself, you define the physical expression or shape of the projections in the knowledge store settings within your skillset.

Customers are using a knowledge store (preview) in diverse ways, such as to validate the structure and accuracy of enrichments, generate training data for AI models, and ad-hoc analysis of their data.

For example, the Metropolitan Museum of Art opened access to all images of public domain works in its collection. Enriching the artworks with cognitive search and the knowledge store allowed us to explore the latent relationships within the artworks on different dimensions like time and geography. Questions like how have images of family groups changed over time, or when were domestic animals included in paintings, are now answerable when you are able to identify, extract, and save the information in a knowledge store (preview).

With the knowledge store, anyone with an Azure subscription can apply AI to find patterns, insights, or create dashboards over previously inaccessible content.

What is the knowledge store (preview)?

Cognitive search is the enrichment of documents with AI skills before they are added to your search index. The knowledge store allows you to project the already enriched documents as objects (blobs) in JSON format or tabular data in table storage.

As part of your projection, you can shape the enriched document to meet your needs. This ensures that the projected data aligns with your intended use.

When using tabular projections, a knowledge store (preview) can project your documents to multiple tables while preserving the relationships between the data projected across tables. The knowledge store has several other features like allowing you to save multiple unrelated projections of your data.

Data visualization and analytics

Search enables you to find relevant documents, but when you’re looking to explore your data for corpus wide aggregations or want to visualize changes over time you need your data represented in a form other than a search index.

Leveraging Power BI’s integration with Azure tables, gets your dashboard started with only a few clicks. To identify insights from the enriched documents over dimensions like time or space, simply project your enriched documents into tables, validate that Power BI recognizes the relationships and you should now have your data in a format that is ready to consume within the visuals.

When you create a visual, any filters work, even when your data spans related tables. As an example, the art dashboard was created on the open access data from the MET in the knowledge store and the Art Explorer site uses the search index generated from the same set of enrichments.

The art explorer site allows you to find art works and related works while the Power BI report gives you a visual representation of the corpus and allows you to slice your data along different dimensions. You now can answer questions like “How does body armor evolve over time?”

In this example, a knowledge store (preview) enabled us to analyze the data ad-hoc. In another example, we may for instance enrich invoices or business forms, project the structured data to a knowledge store (preview), and then create a business-critical report.

Improving AI models

A knowledge store (preview) can also help improve the cognitive search experience itself as a data source for training AI models deployed as a custom skill within the enrichment pipeline. Customers deploying an AI model as a custom skill can project a slice of the enriched data shaped to be the source of their machine learning (ML) pipelines. A knowledge store (preview) now serves as a validator of the custom skill as well as a source of new data that can be manually labeled to retrain the model. While the enrichment pipeline operates on each document individually, corpus level skills like clustering require a set of documents to act on. A knowledge store (preview) can operate on the entire corpus to further enrich documents with skills like clustering and save the results back in a knowledge store (preview) or update the documents in the index.

Continue reading

Accelerate your SAP on Azure HANA project with SUSE Microsoft Solution Templates

Following the launch of M-SERIES/SAP HANA certified Virtual Machines (VMs) on Azure, we are happy to announce a new marketplace offering in partnership with SUSE. The offering leverages Azure Resource Manager Templates to automate the rapid provisioning of an SAP HANA infrastructure in Azure with SUSE technology.

The templates deploy VMs which are optimized for SAP HANA using the latest pay-as-you-go version of the SUSE Linux Enterprise Server for SAP Applications operating system. The templates are based on a simplified SAP sizing in four t-shirt sizes Demo, Small, Medium and Large.

Each template first lays the network foundation by implementing an Azure Virtual Network, enabling subnet customization and Network Security Groups. All templates use Premium (SSD) Managed Disks and can be deployed in 2-tier, 3-tier and 3-tier high availability (HA) architectures. The Demo and Small templates are targeted at non-productive SAP HANA workloads. The Medium and Large templates can be used for productive SAP HANA workloads and are based on best practice for storage configuration and utilizing Write Accelerator technology for sub-millisecond writes of the SAP HANA transaction log.

An overview of each template is shown below with an extended overview of the 3-tier HA template showing VM sizes for each t-shirt and database storage for the “Large” t-shirt. Please refer to the linked technical document on the SUSE website for the complete technical overview.

2 – tier

3 – tier

3 – tier HA

The 3-tier HA template will deploy the VMs for the SAP HANA database (DB), xSCS, HA-NFS, and Application servers in Availability Sets with Azure Internal Load Balancers deployed for the DB, xSCS and HA-NFS clusters.

With the proper post-processing activities this will allow you to reach an infrastructure SLA of 99.95 percent.

3 – tier HA: VM SKU

T-Shirt	VM SKU	VM Nr	Instance
Demo	E4s_v3	2	DB
	D2_v3	2	xSCS
	D2_v3	2	HA-NFS
	D2_v3	2	APP
small	E64_v3	1	DB
	D2_v3	2	xSCS
	D2_v3	2	HA-NFS
	E64_v3	5	APP
Medium	M64s	1	DB
	D2_v3	2	xSCS
	D2_v3	2	HA-NFS
	E64_v3	5	APP
Large	M128s	2	DB
	D2_v3	2	xSCS
	D2_v3	2	HA-NFS
	E64_v3	10	APP

3 – tier HA: DB disk layout for Large t-shirt template

In future releases the SUSE Microsoft Solution Templates will be extended to include automated configuration of the SUSE Pacemaker cluster integrated with Azure Load Balancer, Availability Zone deployments and M-SERIES/SAP HANA scale-out.

Continue reading

Full-integrated experience simplifying Language Understanding in conversational AI systems

Creating an advanced conversational system is now a simple task with the powerful tools integrated into Microsoft’s Language Understanding Service (LUIS) and Bot Framework. LUIS brings together cutting-edge speech, machine translation, and text analytics on the most enterprise-ready platform for creation of conversational systems. In addition to these features, LUIS is currently GDPR, HIPPA, and ISO compliant enabling it to deliver exceptional service across global markets.

Talk or text?

Bots and conversational AI systems are quickly becoming a ubiquitous technology enabling natural interactions with users. Speech remains one of the most widely used input forms that come natural when thinking of conversational systems. This requires the integration of speech recognition within the Language Understanding in conversational systems. Individually, speech recognition and language understanding are amongst the most difficult problems in cognitive computing. Introducing the context of Language Understanding improves the quality of speech recognition. Through intent-based speech priming, the context of an utterances is interpreted using the language model to cross-fertilize the performance of both speech recognition and language understanding. Intent based speech recognition priming uses the utterances and entity tags in your LUIS models to improve accuracy and relevance while converting audio to text. Incorrectly recognized spoken phrases or entities could be rectified by adding the associated utterance to the LUIS model or correctly labeling the entity.

In this release, we have simplified the process of integrating speech priming into LUIS. You no longer must use multiple keys or interact through other middleware. This more streamlined integration also reduces the latency that your users would experience when using speech as an input to your conversational system. All you need to do is to enable speech priming in the publish setting of your LUIS application. Speech priming will be invoked on the same subscription key used in LUIS and transferred to the speech APIs seamlessly.

Text Analytics: Understand your text?

LUIS continues to bring together different technologies to help understand your user. It already includes the power of Bing Spell Check and now we are adding functionality from the Text Analytics Cognitive Service. Integrating text analytics into your LUIS model enabling sentiment detection on utterances is a simple configuration. Through this integration your bot can tell you if your customer is happy or sad. Text analytics also enables the detection of key phrases within utterances without requiring labeling or training. These advanced natural language processing tools enable better, more personalized interaction with your customers.

The JSON object returns the sentiment of the utterance as a value from 0 – 1, with values closer to 1 are more positive while closer to 0 are more negative. Additionally, adding key phrases pre-built entity enables identifying key phrases in the returned object.

Create a Global Bot, without being "lost in translation"

Are you worried about the effort it would take you to design a Bot that speaks multiple languages? With the integration of Machine Translation middleware into the Bot Framework, you don't need to worry any more. Using the Bot created in one language across 60+ languages in a few lines of code makes it much simple to build and improve models. With personalization and customization included in the middleware, enabling a global Bot is a simple task. Combining translation middleware with LUIS and QnA maker is simple and includes passing the utterance after translation. The middleware also specifies if the response should be translated back to the user language or returned in the bot native language.

The translation middleware also includes the ability to identify patterns that shouldn’t be translated to the target language (such as names of locations or entities that are meaningful in their own terms). An example if the user says “My name is …” in a non-native language for the bot you want to avoid translating this name using a pattern in every language. The code snippet reflects this in pattern for French.

The middleware also includes a localization converter for currencies and dates to distinct cultures by adding LocaleConverterMiddleware. The Machine Translation middleware is currently released as preview with Bot Framework SDK V4.  

Generalizing the Model using Regex and Pattern features

In this release LUIS is introducing two features that enable an improved language understanding of entities and intents. Regex entities allows the identification of an entity in the utterance based on a regular expression. For example, a flight number regular expression includes two or three characters and then 4 digits. The Delta Airlines flight regular expression could be expressed as DL[0-9]{4}. Defining this regular expression entity will allow LUIS to extract matching entities from an utterance.

Patterns, on the other hand, allow developers to define intents they could represent effectively without the need to provide extensive utterances. This is especially effective for forms that could capture a wide variety of common ways of expressing an utterance. Consider for example a shopping application, the pattern “add the {Shopping.Item} to my {Shopping.Cart}” is a common way of expressing the intent Shopping.AddToCart. 

Patterns are especially useful when there are similarities between utterances that reflect different intents. Take for example the utterances in a human resource domain “Who does Mike Jones report to?” and “Who reports to Mike Jones?”. The two statements contain the same tokens yet reflect different intents. This could be captured by either introducing many utterances, or by simply expressing these common utterances by their respective patterns “Who does {Employee} report to?” and “Who reports to “Employee}?”. Introducing these patterns, alongside the utterances allow LUIS to identify the most suitable intent to fit to an utterance. Moreover, patterns could also capture the distinct roles of entities. As an example, the pattern “Book a ticket from {Location:origin} to {Location:Destination}” in a flight booking application. This pattern captures the distinct roles of the locations included in the utterance.

Additionally, patterns could encompass entities with variable length represented as Patterns.any entities. The entities are detected first, prior to the matching of the pattern. In turn the pattern “Where is the {FormName} and who needs to sign it after I read it?” will match form names that could extent multiple tokens.

Involve your personal data scientist to help improve your model

The tools provided in Cognitive Services enable developers without a machine learning (ML) background to develop conversational systems. Once the bot is built, developers are faced with multiple options to further improve their models. Some of these options are rooted in ML, and in turn developers with limited ML experience might not fully explore these options. 

In this release of LUIS and Bot Framework, we have taken our goal of democratizing ML further. We are incorporating tools to provide personalized data science guidance to developers on the existing applications. This includes identifying the areas where the current model falls short and providing suggestion to help improve the trained model. It also allows for automatically generating different architectures of multiple conversational models, which include LUIS and QnA maker, through the dispatcher tool. This might be creating a hierarchical architecture with a dispatching model or consolidating multiple models into one LUIS model. Collectively, these tools use LUIS to realize the different architectures and dissect the models to help provide the most suitable guidance to developers. The dispatch tool is currently released in preview on Bot Framework SDK V4.

These are some of the highlights of the features that have been introduced to LUIS and Bot Framework. Through integrating the different tools, and compliance with GDPR, HIPPA, and ISO, LUIS and Bot Framework are distinguishing themselves as the most enterprise-ready platform. These new additions make understanding customers and reaching new markets and users a few lines of code away. It also makes bot interactions more natural to your users.

Continue reading

Organizing subscriptions and resource groups within the Enterprise

One of the common questions members of the Core Services Engineering and Operations teams frequently get when speaking to customers at the Executive Briefing Center here in Redmond is how do our engineering teams secure our Azure footprint for our Line of Business applications while still giving developers the freedom to go fast, have visibility into our environment and use the capabilities of Visual Studio Team Services for CI/CD, Release, and much more.

At the core of this answer is how we use the combination of subscriptions, resource groups, and Role Based Access Control to ensure compliance with a set of guidelines.

Let's start at the top level: Azure Subscriptions. CSEO, as you can imagine has a lot of Line of Business applications, currently over a thousand.

The business unit pattern

In particular, many of our teams have adopted a common mapping of the above pattern to enterprise/federal/state/local. This common vocabulary provides practical constructs that everyone understands and can relate to, ensuring we're on the same page.

What does this translation look like in reality with examples for subscription organization? It looks like this from the top down:

◈ Enterprise - This stays the same as Enterprise in the Azure scaffold for us. Enterprise level items are common concerns across the entire company – it might be ensuring we don't count internal Azure consumption as public revenue, or how secure we are across all Azure subscriptions in our tenants, or other high-level strategic objectives that we care about regardless of level. Another way to think of this might be how Microsoft reports our global quarterly earnings – it's across the entire company.

◈ Federal - Our major departments are named Federal. For example, CSEO is one of the federal groups. At this level, we may have additional policies and procedures, automation that runs against our footprint, or other things specific to that department. Typically, this is where large budgets have roll-up views, etc.

◈ State - A group of services or a service offerings that are related. For example, the Tax Service Offering within the Finance IT organization. Here you may have additional policies and procedures, for example, HIPAA, PCI, SOX controls, and procedures. A state has a group of services that are related.

◈ Local – This is where a subscription lives and is associated with a service. Each subscription contains multiple applications that are related to delivering the set of functionalities that make up the service. Each application is typically contained in an explicit resource group. The resource group becomes the container for that application, which is part of the service (the subscription). There may sometimes be a shared or common application in the service. At the application/resource group level is where the team of application developers live and they’re accountable for their footprint in Azure from security to optimal Azure spend in everything they do. A great development team operating at this level solves most of the concerns and roll-up reporting questions that are typically asked from higher levels. If each development team looks at the Azure Security Center blade, pinned dashboards built from Azure Log analytics, and the Azure Advisor blades on a daily basis, you wouldn’t have division-wide efforts created to reduce spend or bring up patch compliance, etc.

This hierarchical construct allows the differing level of controls and policies while allowing the developers to go fast. Below is a typical subscription configuration:

An example CSEO Subscription for the Tax Service

Within the resource groups above, the typical components you would see in each of the production resource groups (applications) would be the Azure components used to build that specific service such as:

◈ Azure HDInsight cluster

◈ Storage Accounts

◈ SQL Database

◈ Log Analytics

◈ Application Insights

◈ Etc., etc.

Each resource group has the components specific to that application. On occasion, the subscription might have a Common or Shared Services resource group. These are items that are used across the applications in the service, for example:

◈ Common Log Analytics workspace

◈ Common Blob Storage accounts where files are dumped for processing by the other services

◈ An ExpressRoute VNet

In our CSEO Tax Service there are multiple applications, each in their own resource groups such as the data warehouse, ask tax (the help web portal and some bots), a calculation engine, an archiving application, a reporting application and more.

Within the subscription and resource groups, we use least privilege access principles to ensure that only the people that need to do the work have access to resources. Therefore, only the engineering owners of the service are the owners of the subscription. No contributors exist on the subscription. Some specific identities are added to the reader role, these are typically accounts used by automated tooling.

Each resource group has only the identities necessary added with the minimum required permissions. We try to avoid creating custom roles, which over the passage of time and with scale create management headaches.

Within the resource groups, the owner and reader roles are inherited from the subscription. The VSTS Build Account identity is added in as a contributor to the resource group for automated deployments. This means that only the service owner and the build identities can touch the production service on a continuous basis.

In the pre-production resource group, the engineering team is added to the reader role. This still means that only the service owner and build accounts can touch pre-production on a continuous basis, but the engineering team can see what's going on in the resource group. If a developer needs to do some work for testing, they can’t go putting that in the pre-prod or prod environment.

There are some variations on this but they’re not common. For instance, some teams might want someone from the security as the sub owner, and some teams even remove people from the equation and use a form of service account as the sub owner. Some teams might give engineers contributor on pre-prod if they’re not fully mature on the automation required. It all depends on the needs of the team.

So now that we have these together, what does it mean for typical roles in the organization?

Developers have access to the pre-production resource group to see what's going on in the dev/pre-production/uat/whatever-you-want-to-call-non-production-in-your-company but must get used to using telemetry mechanisms in the platform for debugging, just like they would have to do in production. While the teams are maturing to this level, you may see developers with contributor level access at the pre-production resource groups. The result of this discipline is typically much richer Application Insights portals and Azure Log Analytics dashboards. As teams mature they switch to deploying from a CI/CD system like Visual Studio Team Services that uses Microsoft Release Management and get really good at creating build and release definitions. Developers also script out and automate operational concerns like key rotation.

Security & Operations have access via identities with Just-in-Time VM Access through Azure Security Center for IaaS and Privileged Identity Management through Azure AD. Some operations teams might use automated tools to interrogate our Azure subscription footprint looking for configurations to reduce risk, for example looking for a resource group containing a public internet endpoint (PiP) and an ExpressRoute circuit that might pose a security risk. These teams use those audit account identities added at the subscription level.

Another thing that this model implicitly drives is the shift of accountability from any Central IT team to the development team. This does not mean shift of concerns as security and operations teams still care about compliance and risk. But if the local development team makes part of their daily standup looking at billing, security center, and the Azure Advisor tools, then cost optimization, security compliance and concerns that are inevitably asked from the enterprise, federal and state layers will already be optimized.

Continue reading

How Microsoft computer scientists and researchers are working to “solve” cancer

Scientists at Microsoft’s research labs are trying to use computer science to solve one of the most complex and deadly challenges humans face: Cancer.

And, for the most part, they are doing so with algorithms and computers instead of test tubes and beakers.

One team of researchers is using machine learning and natural language processing to help oncologists figure out the most effective, individualized cancer treatments for their patients.

Another is pairing machine learning with computer vision to give radiologists a more detailed understanding of how their patients’ tumors are progressing.

Yet another group of researchers has created powerful algorithms that help scientists understand how cancers develop and what treatments will work best to fight them.

And another team is working on moonshot efforts that could one day allow scientists to program cells to fight diseases, including cancer.

While the individual projects vary widely, they share the core philosophy that success depends on both biologists and computer scientists bringing their expertise to the problem.

“The collaboration between biologists and computer scientists is actually key to making this work,” said Jeannette M. Wing, Microsoft’s corporate vice president in charge of the company’s basic research labs.

To learn about these efforts to solve cancer with the help of algorithms and computers, read the full story.

Continue reading