You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/service-fabric/scripts/service-fabric-powershell-change-rdp-port-range.md
+5-10Lines changed: 5 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,28 +2,23 @@
2
2
title: Azure PowerShell Script Sample - Change the RDP port range | Microsoft Docs
3
3
description: Azure PowerShell Script Sample - Changes the RDP port range of a deployed cluster.
4
4
services: service-fabric
5
-
documentationcenter:
6
-
author: athinanthny
7
-
manager: chackdan
8
-
editor:
9
5
tags: azure-service-management
10
-
11
-
ms.assetid:
6
+
author: athinanthny
7
+
ms.author: atsenthi
12
8
ms.service: service-fabric
13
9
ms.workload: multiple
14
10
ms.topic: sample
15
11
ms.date: 03/19/2018
16
-
ms.author: atsenthi
17
-
ms.custom: mvc
12
+
ms.custom: sfrev
18
13
---
19
14
20
15
# Update the RDP port range values
21
16
22
-
This sample script changes the RDP port range values on the cluster node VMs after the cluster has been deployed. Azure PowerShell is used so that the underlying VMs do not cycle. The script gets the `Microsoft.Network/loadBalancers` resource in cluster's resource group and updates the `inboundNatPools.frontendPortRangeStart` and `inboundNatPools.frontendPortRangeEnd` values. Customize the parameters as needed.
17
+
This sample script changes the RDP port range values on the cluster node VMs after the cluster has been deployed. Azure PowerShell is used so that the underlying VMs do not cycle. The script gets the `Microsoft.Network/loadBalancers` resource in the cluster's resource group and updates the `inboundNatPools.frontendPortRangeStart` and `inboundNatPools.frontendPortRangeEnd` values. Customize the parameters as needed.
Copy file name to clipboardExpand all lines: articles/service-fabric/service-fabric-api-management-overview.md
+10-11Lines changed: 10 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,7 @@
1
1
---
2
2
title: Azure Service Fabric with API Management overview
3
3
description: This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications.
4
-
5
4
author: vturecek
6
-
7
5
ms.topic: conceptual
8
6
ms.date: 06/22/2017
9
7
ms.author: vturecek
@@ -13,7 +11,7 @@ ms.author: vturecek
13
11
14
12
Cloud applications typically need a front-end gateway to provide a single point of ingress for users, devices, or other applications. In Service Fabric, a gateway can be any stateless service such as an [ASP.NET Core application](service-fabric-reliable-services-communication-aspnetcore.md), or another service designed for traffic ingress, such as [Event Hubs](https://docs.microsoft.com/azure/event-hubs/), [IoT Hub](https://docs.microsoft.com/azure/iot-hub/), or [Azure API Management](https://docs.microsoft.com/azure/api-management/).
15
13
16
-
This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services.
14
+
This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services.
17
15
18
16
## Availability
19
17
@@ -44,7 +42,8 @@ Azure API Management can be used with any combination of stateless services, sta
44
42
45
43
In the simplest case, traffic is forwarded to a stateless service instance. To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a specific stateless service instance in the Service Fabric back-end. Requests sent to that service are sent to a random instance of the service.
46
44
47
-
#### Example
45
+
**Example**
46
+
48
47
In the following scenario, a Service Fabric application contains a stateless service named `fabric:/app/fooservice`, that exposes an internal HTTP API. The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.
49
48
50
49
![Service Fabric with Azure API Management topology overview][sf-apim-static-stateless]
@@ -53,7 +52,7 @@ In the following scenario, a Service Fabric application contains a stateless ser
53
52
54
53
Similar to the stateless service scenario, traffic can be forwarded to a stateful service instance. In this case, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps a request to a specific partition of a specific *stateful* service instance. The partition to map each request to is computed via a lambda method using some input from the incoming HTTP request, such as a value in the URL path. The policy may be configured to send requests to the primary replica only, or to a random replica for read operations.
55
54
56
-
#### Example
55
+
**Example**
57
56
58
57
In the following scenario, a Service Fabric application contains a partitioned stateful service named `fabric:/app/userservice` that exposes an internal HTTP API. The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.
59
58
@@ -63,14 +62,14 @@ The service is partitioned using the Int64 partition scheme with two partitions
63
62
64
63
## Send traffic to multiple stateless services
65
64
66
-
In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance.
65
+
In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance.
67
66
68
67
To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateless service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. Requests to a service are sent to a random instance of the service.
69
68
70
-
#### Example
69
+
**Example**
71
70
72
71
In this example, a new stateless service instance is created for each user of an application with a dynamically generated name using the following formula:
73
-
72
+
74
73
-`fabric:/app/users/<username>`
75
74
76
75
Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Instead, the name of the service to which to send a request is generated in the back-end policy definition from the `name` value provided in the URL request path. For example:
@@ -86,10 +85,10 @@ Similar to the stateless service example, an API Management operation can map re
86
85
87
86
To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateful service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. In addition to mapping a request to specific service instance, the request can also be mapped to a specific partition within the service instance, and optionally to either the primary replica or a random secondary replica within the partition.
88
87
89
-
#### Example
88
+
**Example**
90
89
91
90
In this example, a new stateful service instance is created for each user of the application with a dynamically generated name using the following formula:
92
-
91
+
93
92
-`fabric:/app/users/<username>`
94
93
95
94
Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Instead, the name of the service to which to send a request is generated in the back-end policy definition from the `name` value provided the URL request path. For example:
@@ -113,4 +112,4 @@ Follow the [tutorial](service-fabric-tutorial-deploy-api-management.md) to set u
Copy file name to clipboardExpand all lines: articles/service-fabric/service-fabric-application-scenarios.md
+17-16Lines changed: 17 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,15 @@
1
1
---
2
2
title: Application scenarios and design
3
3
description: Overview of categories of cloud applications in Service Fabric. Discusses application design that uses stateful and stateless services.
4
-
5
4
ms.topic: conceptual
6
-
ms.date: 4/24/2019
5
+
ms.date: 01/08/2020
6
+
ms.custom: sfrev
7
7
---
8
8
# Service Fabric application scenarios
9
-
Azure Service Fabric offers a reliable and flexible platform where you can write and run many types of business applications and services. These applications and microservices can be stateless or stateful, and they're resource-balanced across virtual machines to maximize efficiency.
10
9
11
-
The unique architecture of Service Fabric enables you to perform near real-time data analysis, in-memory computation, parallel transactions, and event processing in your applications. You can easily scale your applications up or down (really in or out), depending on your changing resource requirements.
10
+
Azure Service Fabric offers a reliable and flexible platform where you can write and run many types of business applications and services. These applications and microservices can be stateless or stateful, and they're resource-balanced across virtual machines to maximize efficiency.
11
+
12
+
The unique architecture of Service Fabric enables you to perform near real-time data analysis, in-memory computation, parallel transactions, and event processing in your applications. You can easily scale your applications in or out depending on your changing resource requirements.
12
13
13
14
For design guidance on building applications, read [Microservices architecture on Azure Service Fabric](https://docs.microsoft.com/azure/architecture/reference-architectures/microservices/service-fabric) and [Best practices for application design using Service Fabric](service-fabric-best-practices-applications.md).
14
15
@@ -30,8 +31,8 @@ Consider using the Service Fabric platform for the following types of applicatio
30
31
31
32
***Computation on data**: Service Fabric enables you to build stateful applications that do intensive data computation. Service Fabric allows the colocation of processing (computation) and data in applications.
32
33
33
-
Normally, when your application requires access to data, network latency associated with an external data cache or storage tier limits the computation time. Stateful Service Fabric services eliminate that latency, enabling more optimized reads and writes.
34
-
34
+
Normally, when your application requires access to data, network latency associated with an external data cache or storage tier limits the computation time. Stateful Service Fabric services eliminate that latency, enabling more optimized reads and writes.
35
+
35
36
For example, consider an application that performs near real-time recommendation selections for customers, with a round-trip time requirement of less than 100 milliseconds. The latency and performance characteristics of Service Fabric services provide a responsive experience to the user, compared with the standard implementation model of having to fetch the necessary data from remote storage. The system is more responsive because the computation of recommendation selection is colocated with the data and rules.
36
37
37
38
Customers who have built computation services include [Solidsoft Reply](https://customers.microsoft.com/story/solidsoft-reply-platform-powers-e-verification-of-pharmaceuticals) and [Infosupport](https://customers.microsoft.com/story/service-fabric-customer-profile-info-support-and-fudura).
@@ -41,16 +42,18 @@ Consider using the Service Fabric platform for the following types of applicatio
41
42
***Scalable services**: Individual services can be partitioned, allowing for state to be scaled out across the cluster. Individual services can also be created and removed on the fly. You can scale out services from a few instances on a few nodes to thousands of instances on many nodes, and then scale them in again as needed. You can use Service Fabric to build these services and manage their complete life cycles.
42
43
43
44
## Application design case studies
44
-
Case studies that show how Service Fabric is used to design applications are published on the [Customer stories](https://customers.microsoft.com/search?sq=%22Azure%20Service%20Fabric%22&ff=&p=0&so=story_publish_date%20desc/) and [Microservices in Azure](https://azure.microsoft.com/solutions/microservice-applications/) sites.
45
+
46
+
Case studies that show how Service Fabric is used to design applications are published on the [Customer stories](https://customers.microsoft.com/search?sq=%22Azure%20Service%20Fabric%22&ff=&p=2&so=story_publish_date%20desc) and [Microservices in Azure](https://azure.microsoft.com/solutions/microservice-applications/) sites.
45
47
46
48
## Designing applications composed of stateless and stateful microservices
47
-
Building applications with Azure Cloud Services worker roles is an example of a stateless service. In contrast, stateful microservices maintain their authoritative state beyond the request and its response. This functionality provides high availability and consistency of the state through simple APIs that provide transactional guarantees backed by replication.
49
+
50
+
Building applications with Azure Cloud Services worker roles is an example of a stateless service. In contrast, stateful microservices maintain their authoritative state beyond the request and its response. This functionality provides high availability and consistency of the state through simple APIs that provide transactional guarantees backed by replication.
48
51
49
52
Stateful services in Service Fabric bring high availability to all types of applications, not just databases and other data stores. This is a natural progression. Applications have already moved from using purely relational databases for high availability to NoSQL databases. Now the applications themselves can have their "hot" state and data managed within them for additional performance gains without sacrificing reliability, consistency, or availability.
50
53
51
54
When you're building applications that consist of microservices, you typically have a combination of stateless web apps (like ASP.NET and Node.js) calling onto stateless and stateful business middle-tier services. The apps and services are all deployed in the same Service Fabric cluster through the Service Fabric deployment commands. Each of these services is independent with regard to scale, reliability, and resource usage. This independence improves agility and flexibility in development and life-cycle management.
52
55
53
-
Stateful microservices simplify application designs because they remove the need for the additional queues and caches that have traditionally been required to address the availability and latency requirements of purely stateless applications. Because stateful services have high availability and low latency, there are fewer details to manage in your application.
56
+
Stateful microservices simplify application designs because they remove the need for the additional queues and caches that have traditionally been required to address the availability and latency requirements of purely stateless applications. Because stateful services have high availability and low latency, there are fewer details to manage in your application.
54
57
55
58
The following diagrams illustrate the differences between designing an application that's stateless and one that's stateful. By taking advantage of the [Reliable Services](service-fabric-reliable-services-introduction.md) and [Reliable Actors](service-fabric-reliable-actors-introduction.md) programming models, stateful services reduce application complexity while achieving high throughput and low latency.
56
59
@@ -62,19 +65,17 @@ Here's an example application that uses stateful services:
62
65
63
66
## Next steps
64
67
65
-
* Learn more about [patterns and scenarios](service-fabric-patterns-and-scenarios.md).
66
-
67
68
* Get started building stateless and stateful services with the Service Fabric
68
69
[Reliable Services](service-fabric-reliable-services-quick-start.md) and [Reliable Actors](service-fabric-reliable-actors-get-started.md) programming models.
69
70
* Visit the Azure Architecture Center for guidance on [building microservices on Azure](https://docs.microsoft.com/azure/architecture/microservices/).
70
71
* Go to [Azure Service Fabric application and cluster best practices](service-fabric-best-practices-overview.md) for application design guidance.
71
72
72
-
*Also see the following topics:
73
-
*[Tell me about microservices](service-fabric-overview-microservices.md)
0 commit comments