Service Fabric is a distributed systems platform used to build hyper-scale, agile and fault-tolerant microservices on the cloud. It provides set of services for orchestrating the functioning of the applications deployed on the cluster. It abstracts complexities around provisioning, deploying, fault handling, scaling and optimizing the applications that are deployed to the cluster.

It is responsible for fault handling and recovery of services, should something fail. Service Fabric plays the same role as some of the other microservice orchestration platforms such as Docker Swarm, Kubernetes, Mesosphere, Core OS etc.,

Service Fabric supports quite a few programming models to make it easy to develop variety of microservices. Each service can be either stateful or stateless. Stateless services are typically used for creating Web APIs or any other service that doesn’t need to maintain their state on the nodes. These services will treat each request as an independent one and will assume all the information required to process the request is contained with-in it. State is maintained in external data-stores like SQL Server, CosmoDB or Redis cache etc.,

Stateful services on the other hand maintain their state on the same cluster. Service Fabric provides data-structures that can replicate state through all the nodes in a cluster. It provides APIs for storing, retrieving and updating data structures. Any time an update is made to a data structure, it’s automatically replicated to all the nodes in the cluster and made available to other instances of the service running on other nodes in the cluster. Since the data and the services are co-located, it can significantly reduce the latency in processing the data.

With Azure

Microservices have become a popular architectural style for building cloud applications that are resilient, highly scalable, and able to evolve quickly. In this post, we explore how to build and run a microservices architecture on Azure, using Kubernetes as a container orchestrator. Future articles will include Service Fabric.
The following common open source technologies are used:

1- Azure Container Service (Kubernetes) to run front-end and back-end services.
2- Azure Functions to run event driven services.
3- Linkerd to manage inter-service communication.
4- Prometheus to monitor system/application metrics.
5- Fluentd and Elasticsearch to monitor application logs.
6- Cosmos DB, Azure Data Lake Store, and Azure Redis Cache to store different types of data.

Azure Service Fabric is a Platform as a Service (PaaS) offering from Microsoft. Azure SQL Database, Azure DocumentDB, Azure IoT, Cortana, Power BI, Microsoft Intune, Event Hubs and Skype for Business are some of the products from Microsoft that leverage Service Fabric. Service Fabric provides the infrastructure to run massive scale, reliable, stateless or stateful services. It provides end-to-end application lifecycle management and provides container and process orchestration services and health monitoring.

For richer debugging with runtime details and events, you can set up diagnostics logging with Azure Log Analytics. Log Analytics is a service in Azure that monitors your cloud and on-premises environments to help you maintain their availability and performance.

1-In the Azure portal, find and select your logic app.

2- On the logic app blade menu, under Monitoring, choose Diagnostics > Diagnostic Settings.

3- Under Diagnostics settings, choose On.

4- Now select the Log Analytics workspace and event category for logging as shown:

• Select Send to Log Analytics.
• Under Log Analytics, choose Configure.
• Under OMS Workspaces, select the Log Analytics workspace to use for logging.
• Under Log, select the WorkflowRuntime category.
• Choose the metric interval.
• When you’re done, choose Save.

After you create and run a logic app, you can check its runs history, trigger history, status, and performance. For real-time event monitoring and richer debugging, set up diagnostics logging for your logic app. That way, you can find and view events, like trigger events, run events, and action events. To get notifications about failures or other possible problems, set up alerts. For example, you can create an alert that detects “when more than five runs fail in an hour.” You can also set up monitoring, tracking, and logging programmatically by using Azure Diagnostics event settings and properties.

1- To find your logic app in the Azure portal, on the main Azure menu, choose All services. In the search box, type “logic apps”, and choose Logic apps.

2- Select your logic app, then choose Overview.

• Runs history shows all the runs for your logic app.
• Trigger History shows all the trigger activity for your logic app

3- To view the steps from a specific run, under Runs history, select that run.

4- To get more details about the run, choose Run Details. This information summarizes the steps, status, inputs, and outputs for the run.

5- To get details about a specific step, choose that step. You can now review details like inputs, outputs, and any errors that happened for that step.

6- To get details about a specific trigger event, go back to the Overview pane. Under Trigger history, select the trigger event. You can now review details like inputs and outputs.

Azure Logic Apps helps you orchestrate and integrate different services by providing 100+ ready-to-use connectors, ranging from on-premises SQL Server or SAP to Microsoft Cognitive Services. The Logic Apps service is “serverless”, so you don’t have to worry about scale or instances. All you have to do is define the workflow with a trigger and the actions that the workflow performs. The underlying platform handles scale, availability, and performance. Logic Apps is especially useful for use cases and scenarios where you need to coordinate multiple actions across multiple systems.

Azure Logic App Common Scenarios

Every logic app starts with a trigger, and only one trigger, which starts your logic app workflow and passes in any data as part of that trigger. Some connectors provide triggers, which come in these types:

Polling Triggers: Regularly checks a service endpoint for new data. When new data exists, the trigger creates and runs a new workflow instance with the data as input.

Push Triggers: Listens for data at a service endpoint and waits until a specific event happens. When the event happens, the trigger fires immediately, creating and running a new workflow instance that uses any available data as input.

Practical scenarios for polling:

Schedule – Recurrence trigger lets you set the start date and time plus the recurrence for firing your logic app. For example, you can select the days of the week and times of day for triggering your logic app.

The “When an email is received” trigger lets your logic app check for new email from any mail provider that’s supported by Logic Apps, for example, Office 365 Outlook, Gmail, Outlook.com, and so on.

The HTTP trigger lets your logic app check a specified service endpoint by communicating over HTTP.

Practical scenarios for Pushing:

The Request / Response – Request trigger lets your logic app receive HTTP requests and respond in real time to events in some way.

The HTTP Webhook trigger subscribes to a service endpoint by registering a callback URL with that service. That way, the service can just notify the trigger when the specified event happens, so that the trigger doesn’t need to poll the service.

After receiving a notification about new data or an event, the trigger fires, creates a new logic app workflow instance, and runs the actions in the workflow. You can access any data from the trigger throughout the workflow.