Azure Service Fabric: a Platform for Mission Critical Apps – Part 1

Microsoft’s unveiling of HoloLens at Build 2015 caused a lot of excitement. But for me the biggest excitement was something Microsoft released that we can download now. It’s this:


This is Preview 1 of Azure Service Fabric. If you aren’t sure what that is, look on the left. Onebox is my laptop, and it is running a local cluster comprised of four applications and five nodes. The applications are named ClusterManagerService, FailoverManagerService, ImageStoreService and NamingService. Sound familiar?

Those four applications are what we commonly refer to as “Azure.” That’s the Azure Microsoft runs in the cloud to host Azure SQL Database, Power BI, Cortana, DocumentDb, Event Hubs, and “many other core Azure services”. That Azure is now running on my laptop.

Which means I can build Azure apps and run them locally on real Azure, not an emulator. I’ll be able to deploy them to Azure on Microsoft’s public cloud, and they’ll run the same there as they do locally. And I’ll be able to deploy them to on-premise data centers or ISV data centers when they run Microsoft Azure Stack on Windows Server 2016.

I haven’t gotten a chance to try a HoloLens yet. But this is plenty of excitement for me. Let’s consider how Azure Service Fabric apps are different from other apps.

Azure Service Fabric applications run in clusters. A cluster is a group of virtual or physical machines, each hosting a collection of isolated processes called nodes. On my laptop a Windows Service called FabricHost.exe is managing the cluster. Each of the five nodes is implemented by a trio of Windows processes running Fabric.exe, FabricGateway.exe and FileStoreService.exe.


An Azure Service Fabric application consists of one or more microservices. Each microservice will be deployed in one or more containers on one or more nodes. Microservices run in isolation from each other, and can be either stateless or stateful.

Here is what my Service Fabric Explorer looks like after I have deployed four Service Fabric applications (one from each project template in Visual Studio). Each application contains one microservice, but most of them are deployed on multiple nodes.


What can we gain by dividing applications into microservices and running them on clusters of nodes?

First we gain High Availability. When a microservice crashes, the Service Fabric intervenes immediately to redirect traffic to a backup copy of the microservice on a different node. Thanks to the Naming Service, microservices hide their physical locations, so redirection to a new instance happens transparently. Service Fabric then instantiates a new microservice instance to replace the old one. If the failed microservice is stateful, then the backup instance will include its own copy of the state, and the replacement instance will get a copy of the current state as well. By the same means, Service Fabric can quickly recover from the loss of an entire node or the loss of an entire machine in the cluster.

We gain High Scalability. We can have as many instances of our microservices running on as many nodes as we need. We can constantly right-size our deployment to optimize performance while minimizing costs.

The support for stateful microservices brings important advantages, and I think this is one of the big things that sets Service Fabric applications apart from other kinds of Azure applications. By putting state side-by-side with code – by not separating between “service tiers” and “data tiers” – we can dramatically Reduce Latency. Think of Microsoft’s Cortana, an Azure service that finds restaurants and looks up movie times in split seconds. And by packing data and computing together, we can reduce our apps’ hardware footprint and thus further Reduce Costs. And the Programming Experience for developers can become much simpler.

The last big gain I’ll mention now (I’ll talk about many more in coming posts) is support for Rolling Live Upgrades. To deploy a new version of a microservice, you don’t need to stop what’s already in production. Service Fabric will create instances of the new version and silently substitute them for old instances as they become idle, taking care that work underway is never handled by inconsistent versions. This is the same way Microsoft rolls out updates to Azure SQL Database and its other cloud services.

I think these make Azure Service Fabric an excellent platform for building all sorts of apps, but especially mission critical apps, such as

  • Apps that need to run all the time, never going down for planned or unplanned reasons
  • Apps that handle heavy workloads
  • Apps requiring split-second throughput
  • Apps with heavy resource demands that need to be frugal with costs

In this series I will explore Azure Service Fabric in some detail. Watch for more posts exploring the architecture, the tooling, and the application lifecycle on this new but proven platform.

In the meantime you can start your own exploration by downloading the Service Fabric Preview 1 here.

Build Day 3 – In With the New: Microsoft Edge, More HoloLens, Azure Logic Apps, and Direct2D

[This post is by Jeff Mlakar, a member of the Business Intelligence Team at Bennett Adelson.  Follow us @BIatBA and @JeffMlakar]

This was my third and final day at the Microsoft Build Conference. My first was almost all HoloLens. My second was all data. I tried to find a theme in the sessions I saw today. Best I could come up with was that they were all dealing with something new. Of course that could also be said for any collection of sessions at this conference, but anyway… Session 1:

The Microsoft Edge Rendering Engine That Makes the Web Just Work

Presented by David Catuhe and David Rousset.

I gotta say, on Wednesday it was pretty exciting to be in the room for a name announcement. And yes, we have our new browser name: Microsoft Edge, with a logo that looks not far off from IE. Which has to make me wonder: IE has a strong presence within the enterprise, right? A lot of companies have old versions of IE as part of their approved software. It’s probably not going to be going away from the enterprise any time soon. A lot of employees have their old IE versions for business applications and then install a newer/other browser for going out to the web. So what will happen if these employees start to choose Edge as their other browser? Will they now have two different browsers of near-identical logos in their work computer taskbar? Gotta wonder. Anyway, on to the session.

The Davids talked about the history of IE, with its trident engine and many document modes. They talked about how Edge’s new engine, a fork of trident called EdgeHTML, has one document mode and currently benchmarks better than Chrome or Firefox. A lot of the session was on WebGL performance and gaming in the browser, with built-in game pad support and all. This led to an impressive spooky-scene game demo in Edge where the biggest cheer was for a gravestone reading “RIP IE 6”.

One interesting thing was the discussion of IE on Windows Phones currently having issues with mobile displays as some sites check for Android or iOS as a criterion for displaying mobile. Edge corrects this by almost faking as Android or iOS:

Jeff Mlaker 1

The Davids stressed the use of CSS filters. And feature detection, which hopefully developers are doing already. Edge seems to be catching up a couple years to the other browsers in the use of @supports to do feature detection in CSS.

All in all, Edge looks very promising. I’m looking forward to learning more specifics about its features, seeing how it will work for business applications, and trying out its dev tools.

Case Studies of HoloLens App Development

This was a panel discussion where we got to text questions to people who have worked on HoloLens projects already. It was moderated by Rukari Austin, a Microsoft Community Manager for HoloLens. The panel included Dr. Jeff Norris of NASA, Aviad Almagor of Trimble Navigation, Professor Mark Griswold of Case Western Reserve University in Cleveland, and Microsoft Studios Manager Megan Saunders. You’ve probably already seen the videos of the projects these panelists have been working on, so I won’t elaborate on their work. If you haven’t seen the videos, I’d highly recommend you see them. I’ll mostly go through and outline some of the points that resonated with me as I listened to the panelists. These are somewhat paraphrased and could be out of order, but I’ll stick to the spirit of what the speaker was saying. This is not complete, so I’ll urge you to watch the video.

Jeff Mlaker 2

(from left: Rukari Austin, Jeff Norris, Aviad Almagor, Mark Griswold, and Megan Saunders)

Jeff described how HoloLens is helping the two main initiatives of NASA: to explore and to share the experiences of that exploration. He noted that when first developing for such a new technology, all his instincts were wrong. Megan elaborated on the issues of defining a new kind of UI and UX. Aviad said that in this new world, a proper user experience is critical. Mark postulated that as we develop for the technology, we’re probably going to start out making it look like a traditional computer, but we’re not going to end there.

Mark’s background is in building MRIs. In addition to his physics, radiology, and engineering background, he had programming experience and had worked with Unity. He talked about how unsure he was of how long it would take to get set up and working with a new technology like HoloLens. Installing SDKs, configuring, troubleshooting, doing the “hard math” of 3D graphics transformations, etc. He decided to time how long it would take him to go from first sitting down, to making a hologram, to viewing it in HoloLens. It was less than 5 minutes. Which is amazing. Jeff described an experience of intuitively wanting to move his mouse off the screen to interact with the hologram. He suggested that to a member of the team, who implemented it in an hour or two, and he now has mouse interaction with the holograms. So ease of development in the Windows Holographic platform is a big talking point.

All speakers talked of the importance of collaborating via holograms. Jeff said we take for granted how important physical co-presence is. Mark described it as the only way he can educate students, and he can see applications for museums and other such institutions coming out of the technology. Mark also reminded us of the importance of the spatial sound feature of the HoloLens for further immersing you in the augmented reality.

Aviad discussed the inherent human difficulty in translating 2D images into imagined 3D. For a device to do that is huge for “real architects”, as he said (not “system architects” or such). I wonder: if Microsoft is working with someone from Trimble on HoloLens, and Trimble bought SketchUp from Google, will we see SketchUp integrating with HoloLens at some point? I’m just wondering.

No one could answer the big question of when we’ll be able to get our hands on a HoloLens with which to develop. Or when we might see an emulator or such. It’s interesting to me that as this new technology comes out, our gaze is not on how it works but on how we can develop and expand on it.

After the session, we got a chance for one-on-one questions with the panelists. I’m surprised at how the choice of platform is always Unity for their applications. So basically, if you want to get ready for HoloLens development, learn Unity. (

Logic Apps

Presented by Ilya Grebnov and Stephen Siciliano.

Logic Apps are a part of the relatively new Azure App Service. They enable a developer to create business process workflows in a designer. Business processes are thus automated as a SaaS service. In this session, Ilya and Stephen gave us an introduction to the concept and showed us how to lay out our workflows in a designer, and how to code them.

They talked about all key app services currently available. I learned a new acronym: IPaaS, where the I is for Integration. Ilya and Stephen also taught me about Azure Pack, basically a “mini Azure” that can run on prem. In this way, Logic Apps could run on premises.

Over the course of the demo, they defined Logic Apps in the designer and through code. It’s nice that the Logic Apps can be completely defined in JSON. This means that whatever you can do with Logic Apps, you can configure via the RESTful API of the Logic App.

There are a handful of components in Logic Apps. First Triggers, which might be a bit of a misnomer. Because let’s say you use a Twitter trigger, it is still polling on a schedule, say every minute. We define a Recurrence trigger. Next is Actions, which is a set of steps. Possible types are Http, ApiApp, or even a Workflow itself. In the demo, we wire up a Twitter connector and a DropBox connector.

At this point, I can’t help but be struck by the number of sessions I’ve seen that are using Twitter in their demos. Does this mean it’s a treasure-trove of valuable data? Or is it just really good for pedagogical purposes? Either way, I’m glad that in at least one session, I was able to get a tweet saying “Lee-rooooy Jenkins!!” onto the presenter’s screen.

It’s nice that in Logic Apps everything is metadata driven, defined in Swagger. This is nice because then everything can wire up apparently pretty seamlessly. At least it did in the demo. More complex logic can be accomplished through conditions and JSON transformations. As for what you have to do to prepare your own API to be used by a Logic App, as long as you have a RESTful, JSON-returning API using OAuth or another common Auth provider, you should be able to use it in a Logic App.

As far as a new possible location for your Logic App, just this week, Azure App Service Environments were released, which encapsulate a fully isolated and dedicated environment to run all your apps, be they Web, Mobile, API, or Logic.

It was a great session on a cool technology with good demos. Though I do have to wonder about Logic Apps’ similarity to Azure Data Factories. There are certainly similarities, as each are visual workflows of data in the cloud. But Data Factories seem to be more about the Analytic Data Pipeline and have better connections to SQL and other data stores. Logic Apps seem to be all about APIs and smaller volume business process data flows. It could just be all about size of data. I’ll have to play with each more to give a better comparison.

What’s New in Direct2D and DirectWrite for Windows 10

Presented by Anthony Hodsdon.

This was my final session at Build and it was nice coverage of some fundamental graphics enhancements that can really make a difference in your Windows apps. Imagine you have document text in your app and you provide pinch-zoom-in to enlarge your text. Odds are the text is pixelated as you’re zooming and then snaps to a much cleaner view when you let go. (I just confirmed it on a Word document on my Windows 8.1 slate). This is because in Windows 8.1, by default, text was constantly being re-rasterized, putting a lot of work on the CPU that gets uploaded to the GPU. So, the app developer probably did what was common practice, which was to render the document to a bitmap during the scaling, hence the pixilation on zoom-in. The solution: Hardware accelerated vector-based text rendering in Windows 10. Anthony gave an impressive demonstration of zooming in very close to a document in a Windows 10 app and seeing the text remain clear with nice, round Béziers.

I think it’s little formatting things of this sort that really make for an enjoyable app experience for users. This is what the Direct2D and DirectWrite enhancements were bringing in this session. Direct2D and DirectWrite are hardware accelerated graphics APIs for 2D graphics and text display, respectively. Enhancements that come for them in Windows 10 are going to help displays not just on PCs, but phones as well.

For example, most phones don’t want to give up the ½ GB of space needed for all desktop fonts. If they don’t have the font your app is using, it could cause serious formatting issues. The solution: asynchronous font downloading and rendering built in not only to DirectX, but directly to XAML as well. You can configure your app to display a default font as you download the appropriate font, as in the following code:

class MyFontDownloadListener : IDWriteFontDownloadListener
STDMETHOD_(void, DownloadCompleted)( /* … */)
spDwriteFactory->GetFontDownloadQueue(/* … */, &spQueue);
spQueue->AddListener(/* … */);

Non-text graphics enhancements include things like built-in shader linking for optimization, and a simple, efficient API for loading and rendering images which reduces what was chucks of code down to a manageable amount.

Inking capabilities exist as a new 2D primitive that is hardware accelerated and provides low latency, high fidelity, and no polymerization. Anthony gave a great demo with his own handwriting showing how one can manipulate ink thickness and ink rotation. Makes me bummed for missing the DirectInk talk yesterday; I’ll have to go back and watch it.

In summary, as Anthony put it, these enhancements will mean your apps on DirectX will be faster, more maintainable with less code, more consistent across devices, and more beautiful.

Final thought:

So that’s it. Heck of a 3 days. Build is the kind of conference that makes you realize how much more you’ve got to learn. I’d say that’s a good thing.

My Data Day at Build – Azure Elastic Databases, Azure Search, IoT, Azure Stream Analytics, and more

[This post is by Jeff Mlakar, a member of the Business Intelligence Team at Bennett Adelson.  Follow us @BIatBA and @JeffMlakar]

Today was Day 2 for me at Microsoft Build. And it was all about DATA. From the new Azure SQL Database Elastic Databases, to Azure Search, to Big Data, to Azure Stream Analytics, and Azure Machine Learning. All data. And, more amazingly, all data in the cloud. I remember when Azure’s data offerings were limited to their blob and table storage and the beginnings of SQL Server Data Services. To see how much the data offerings in Azure have exploded is surprising and exciting. Even today’s keynote was heavy on Azure Machine Learning. Analyzing mapped human genomes in R and exposing that algorithm as an api in the cloud so anyone with a (now surprisingly accessible) mapped human genome can create a heat map of their health risks shows how what is happening in data analytics can really make personal differences in our lives. And, I gotta say, when thinking about IoT and ML, I didn’t see cow pedometer artificial insemination coming. “AI meets AI”…

My first session:

Modern Data in Azure

Presented by Lance Olson, et al. In many ways, it was perfect that this session kicked off my day of data. This demo was presented as a tour of Azure data offerings, primarily from a developer point of view. As in, it wasn’t just an explanation of different data storage types in Azure, as I was expecting. They built a web app and brought in each form of data technology as it was needed for the application. A nice approach. The app was called the WingTip Ticketing application, and would be expanded on in the next session to be a SaaS offering. The first data offering being added to the ticketing application was:

Azure SQL Database Elastic Database Pool

The ticket ordering was to be handled by a relational database, Azure SQL Database. The argument for using the brand new Elastic Database Pool (announced today and in preview) was that it would make sense to logically and physically partition the database by artist, as some artists might naturally have far more load than others, depending on demand. They demonstrated ticket sales loads against a standard database and against a newly sharded Elastic Database Pool, sharded by artist. The load was measured in DTUs, or Database Throughput Units. I’ll explain this more in a bit as it was heavily covered in the next session. I was impressed by how performance could be increased, but I was more impressed with how easy it all was to configure. This includes setting up the sharding strategy, and integrating the Elastic Database Client Library into the web application code. Elastic Databases were covered thoroughly in the next session, so I’ll come back to them then.

Azure Document DB

They used Azure’s NoSQL document database service, Azure Document DB to handle ratings and reviews, with the thought that this data would be largely unstructured. For those who don’t work with document databases, you can basically think of a document as a record in a table whose schema is fluid. This way when new data is added, no schema changes are needed, just updates to the Model, View, and Controller in the web. Documents could be created with the code:

Documents doc = Client.CreateDocument(Collection.SelfLine, entity);

Even SQL-like queries could be created using


Azure Search

Azure Search was utilized to provide users with an intuitive search box in the ticketing application. Azure Search is a fully managed Search-as-a-Service in the cloud. It reminds me of working with ElasticSearch in the way you set up indexes, analyzers, and suggestions, though since we are in the Azure cloud it is FAR easier to provision and set up. Once an index and indexer was set up and data populated, wiring up the search was easy using the namespace:


And using the SearchIndexClient for operations like:


They showed the use of better scoring in Search, as well as suggestions. They didn’t demo any highlighting of hits capability, but I asked them afterwards and they said this was available.

Apache Storm for HD Insight

Some Big Data work was then done for the interesting example of upping the search results score based on number of recent tweets. They used Apache Storm on HDInsight with a spout to twitter based on a hashtag of a fictional music star. They bolted this to our Azure Search index and then had us in the audience tweet to the hashtag. When the hard-coded number of 10 tweets for the hashtag was met, that artist’s score would increase in the Search results. A compelling example.

All-in-all a great tour of many newer Azure data offerings. It was like 4 sessions in one.

My next session:

Building Highly Scalable and Available SaaS Applications with Azure SQL Database

Presented by Bill Gibson and Torsten Grabs. This session was more of a deep-dive into the new elastic capabilities of Azure SQL Databases, like I mentioned before. For me, I kept trying to get my head around how this was different from Federations. I’m starting to get the idea now, though, that this is not just a logical separation, but a strong data sharding strategy that can handle predicted and unpredicted loads while saving you from having to write all the routing code that you had to with Federations.

We’re back in the WingTip Ticketing application (a tongue-twister name all presenters were having trouble with). This time we’re making the application to be a SaaS offering, with different customers using the service for their own ticketing pages. We’re shown how to set up our elastic databases in PowerShell scripts. We create a database, a database per customer, we register these databases with the ShardMap, and then we add our customers to traffic manager rules. What we end up with is a collection of customer databases and a common customer catalog database. Not that different from a Federation, but without the usual bottlenecks.

Establishing the connection is achieves as follows:

SqlConnection conn = SaasSharding.GetCustomerShardmap.OpenConnectionForKey(

passing in the customer’s key.

We’re shown how we can scale our databases’ min and max DTUs via the portal (see pic below), PowerShell, Rest APIs, or T-SQL.


I mentioned DTUs (Database Throughput Units) before, so let me elaborate on at least my current understanding of what it means. Of 4 dimensions of performance: Reads, Writes, ComputeCPU, and Memory, a DTU is the max value of these 4, after they have (somehow) been adjusted. I’ll have to read their whitepaper sometime to see exactly how this is done.

In the end, it all looks good. Easy to manage and with the possibility of handling unpredictable usage.

Building Data Analytics Pipelines using Azure Data Factory, HDInsight, Azure ML, and More

Presented by Mike Flasko. Boy, if ever there was a session that made me feel like I didn’t know anything about data flows, this was it. Azure Data Factories, named so because they resemble a Henry Ford assembly line for data, are a shift for me in my SSIS-centric ideas of data flows. They are a new preview service for modeling and executing the data analytics pipeline. In a visual designer in the Azure portal, we create data sets (be they tables or files), activities (like Hadoop jobs, custom code, ML models, etc), and pipelines (a series of Activities) to complete a data analytics load process.

The Data Set source is defined in a json document. Activities to partition data are done via a Hive script on an HDInsight cluster. We combine and aggregate data in an activity defined by a JSON object. A final activity is used to call an Azure ML scoring activity. We don’t need to know its inner workings. Only the schema of the input and output and how to call the algorithm.

The end result is a process that takes cell phone log data, combines it with our existing customer data, aggregates it, and spits out a data set that says what the probability is of each customer cancelling their service. This end result is then easily (also using the Factory) sent to PowerBI for a lovely dashboard.

This is all still really new to me and I really need to study up on this. I have left over questions like how would you handle workflows for bad data and what is the best way to promote a factory from staging to prod (Mike answered the latter for me after the session: leaving the factory as is and swapping linked services definitions to make the factory run against production). One way or another, the data game is changing, and this session was an excellent introduction to the brave new world.

Gaining Real-Time IoT Insights using Azure Stream Analytics, Azure ML, and Power BI

Presented by Bryan Hollar et al. Azure Steam Analytics was just released to GA 2 weeks ago and this is the first I’ve gotten to see it in action. After seeing case studies from Fujitsu and the Kinect team, ASA implementation was mapped out for us. The shift is from thinking about reporting on data at rest, to data in motion. For example, we could analyze how many twitter users switched sentiment on a topic within a minute in the last ten minutes. SAQL (Stream Analytics Query Language), makes this easy by being a flavor of SQL mixed with temporal extensions. You’re analyzing within a time window, and these windows could be tumbling, hopping, or sliding depending on how you’ve set up your queries. For example:

SELECT Topic, COUNT(*) AS TotalTweets
FROM TwitterStream TIMESTAMP BY CreatedAt
GROUP BY Topic, HoppingWindow(second,10,5)

With Azure Stream Analytics, your data flow pipeline is set to pull from existing event hubs, analyze, and persist (or display) its results. The processed data doesn’t even need to be persisted to be reported on. ASA basically exists in the same place in the data flow pipeline as ML. But where ML would take the “cold path” of analyzing large sets of data at rest, ASA is analyzing the data as it streams. Though now, for a brief preview, ML is integrated into ASA. I’m told you’ll be able to sign up for this preview at the ASA team blog:

As far as integrating the Internet of Things, it’s basically a matter of configuring your event hub in your data pipeline. So, there’s not much difference pulling from twitter or the Internet of Things. You can then configure your output to be PowerBI (also in preview) for a real-time dashboard. The most impressive IoT and ASA example was by Fujitsu who showed an impressive app that geo-mapped energy consumption data and could zero in on spikes right down to an area of a building in real time. Though, now that I think about it, they may be tied with pedometer analysis to tell when your cows were in heat. And now I finally know why they call it a “Heat Map”.

Building Big Data Applications Using Azure HDInsight Service

Presented by Asad Khan. The final session of my day was a tour-de-force of Big Data in Azure. It was four one-hour sessions compressed to one and it was a doozy. Started with 30 seconds of the basics of big data: caring about volume, velocity, variety, and variability of data. They mentioned how Apache Hadoop is an Open Source platform for large amounts of unstructured data, but how the managed infrastructure of Azure makes HDInsight an enticing implementation. They covered HBase for NoSQL, and taught us how to use Storm for streams of data, by showing us how to build spouts for twitter and bolts for Signal R to display data on the web in real time. It was an ambitious session, but pulled off very well.

Final thought:

I’m just now realizing that of everything I’ve mentioned, Big Data with HDInsight is the old man at the ripe old age of a year and a half. Speaks volumes to how much Microsoft is invested in growing its cloud data offerings. Can’t wait to see what’s next!

A Lap Around the Azure API Management Service

At a recent conference, our team presented a talk called “A Lap Around Azure API Service Management.” It was a great opportunity to meet others in the area who are active developing on the Microsoft platform.  We appreciated meeting people with varying levels of familiarity in the Web APIs, and it was a perfect opportunity to exchange ideas and experiences.

For people who are new to this space, the presentation covered the Web API ecosystem as well as their value in building modern applications.


From a Web API user’s perspective, there is a wide range of functionality that they expose, including security, caching, logging, tracing, storage, etc.  If you’re building an app, changes are there is already an existing API that will fit your needs.


In addition to pre-built APIs, there is a large, vibrant developer community who are creating and consuming these APIs.  Your company may be able to connect with new customers and new revenue channels by creating your own APIs and working with this community to connect your services in these developers’ applications.

At a high level, the Windows Azure API Management Service (AMS) has four feature sets:

· API Management via the Admin portal

· Admin Portal – manage your APIs

· Proxy – hosting public version of your APIs

· Developer portal – helps developers discover your APIs and promotes adoption

· Analytics – provides insight into usage and the health of your APIs


Publisher/Admin Portal:

Also called the API Management Console, this is where API publishers configure and manage their public APIs.

In AMS, a product contains one or more APIs as well as a usage quota and the terms of use. Once a product is published, developers can subscribe to the product and begin to use the product’s APIs.

The screenshot below shows some of the various types of products that can be created with the management console.  Here, each product represents a tier of service. API publishers can use the AMS product configuration feature to provide different levels of service using call rates, subscriptions requiring approvals, etc.



The AMS Proxy is the middleware that glues the published APIs to an actual implementation. It uses the information provided when importing an API to invoke this “backend” API in response to someone calls the AMS-published API. The proxy is very useful because not only does it isolate the backend API but it also allow the pre and post processing of messages through policies.


Developer Portal:

The developer portal is where developers can learn about the publisher’s APIs, view and call operations, and subscribe to products. Prospective customers can visit the developer portal, view APIs and operations, and sign up. The URL for the developer portal is located on the dashboard in the Azure portal for the API Management service instance.  API publishers can customize the look and feel of their developer portal by adding custom content, customizing styles, etc.  Features like the developer portal, alongside the product and subscriber management, can help developers accelerate the adoption of their APIs.



The Analytics features provide insight into your API platform. Usage data like successful/blocked/failed calls are reported on a per-user, per product and per API level. There are several charts and tables that allow you to quickly understand how your APIs are operating.  The Analytics features can help providers track API usage and identify performance issues, should these arise.

In addition to these features, the portal also provides a mechanism for policy management.  Using this feature, administrators can easily create policies that can control several facets of the API, such as quotas, payload transformation, etc.  Below is an example of a policy that limits the rate of calls to the API to a maximum of three calls every 60 seconds:


If you would like to learn more about the Azure Management Service and Web API development, please feel free to contact us at Bennett Adelson.  Also, the links below can help provide more information: