1

What is the reasoning behind Applications concept in Service Fabric? What is the recommended relation between Applications and Services? In which scenarios do Applications prove useful?

Denis Biondic
  • 7,943
  • 5
  • 48
  • 79
  • Possible duplicate of [What is the difference between Azure API Apps and Azure Service Fabric?](http://stackoverflow.com/questions/41600014/what-is-the-difference-between-azure-api-apps-and-azure-service-fabric) – feranto Feb 20 '17 at 02:08
  • 1
    Azure API Apps are something different – Denis Biondic Feb 23 '17 at 09:52

4 Answers4

1

Here is a nice summary how logical services differ from physical services: https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/logical-versus-physical-architecture

Now, in relation to Service Fabric, Service Fabric applications represent logical services while Service Fabric services represent physical services. To simplify it, a Service Fabric application is a deployment unit, so you would put there multiple services that rely on the same persistent storage or have other inter-dependencies so that you really need to deploy them together. If you have totally independent services, you would put them into different Service Fabric applications.

DixonD
  • 6,557
  • 5
  • 31
  • 52
1

An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function and can start and run independently of other services. A service is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.

It is described here in detail

bomaboom
  • 190
  • 1
  • 14
0

How I currently see it, applications are a nice concept to group multiple services together and manage them as single unit. In context of service fabric, this is useful if you have multiple nano-services which do not warrant them being completely standalone; instead you can package them together into microservices (SF application).

Disclaimers: - nano-service would be a REALLY small piece of code running as a stateless SF service for example (e.g. read from queue, couple of lines of code to process, write to another queue). - in case of "normal" microservices, one could consider packaging them as 1 SF application = 1 SF service

Denis Biondic
  • 7,943
  • 5
  • 48
  • 79
  • 1
    If you develop a LOB application I would probably create an application per domain and have multiple microservices in it. So how to break up things into applications and services depends also on the type of solution you are creating. – Peter Bons Feb 23 '17 at 10:28
  • "So how to break up things into applications and services depends also on the type of solution you are creating." - agree – Denis Biondic Feb 23 '17 at 13:44
0

An application is a required top level container for services. You deploy applications, not services. So you cannot really speak about differences between the two since you cannot have services without an application.

From https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-application-model:

An application is a collection of constituent services that perform a certain function or functions. A service performs a complete and standalone function (it can start and run independently of other services) and is composed of code, configuration, and data. For each service, code consists of the executable binaries, configuration consists of service settings that can be loaded at run time, and data consists of arbitrary static data to be consumed by the service. Each component in this hierarchical application model can be versioned and upgraded independently.

Take a look at the link provided and you will see the hierarchical relationship.

Peter Bons
  • 26,826
  • 4
  • 50
  • 74
  • "you cannot have services without an application." - does not really clarify why you need the applications, or why they were introduced in service fabric. "You deploy applications, not services." - technically yes, but in essence since services are versioned independently, why do you need an application? P.S. I posted my opition on the subject in my answer for this question. – Denis Biondic Feb 23 '17 at 09:56
  • Well, you've asked three questions. The first one is hard to answer, but in my opinion my answer addresses the second and third question: since applications are mandatory the relationship is defined by that requirements and since have to deploy services using an application that 'proves' why they are useful. Your answer does not address the need for applications as well other than to group services together as I have stated as well. – Peter Bons Feb 23 '17 at 10:10