I started learning Service Fabric applications, and little confused about stateful Reliable Services.
In stateful Reliable Services state means the data to be stored in the tables in our normal database applications or something else?
Is it possible to use EF with stateful Reliable Services ?
How we can store/retrieve the data to/from database (like Products, Categories, Employess etc...) using EF in Reliable Services?
Any tutorial/help will be much appreciable.
Thanks in advance
There are 2 flavors of reliable services, stateless and stateful. The main difference being that stateful services give access to reliable collections to store your data.
TL;DR
If you are planning to use Entity Framework (EF) and you have no plan for storing data using reliable collections, stick to stateless services.
Q1
In stateful Reliable Services state means the data to be stored in the tables in our normal database applications or something else?
It means you are planning to store the data in Reliable Collections.
Q2
Is it possible to use EF with stateful Reliable Services ?
Yes, even when you use a stateful service you can write logic to store data in EF, and optionally store data in reliable collections (See the use case presented by Oleg in the comments for example) but if you only want to use EF then go for a stateless service. A stateful service only makes sense if you use reliable collections.
Q3
How we can store/retrieve the data to/from database (like Products, Categories, Employess etc...) using EF in Reliable Services?
Create a stateless service, add the EF NuGet packages and write the code as you would normally do.
Additional information
From this quickstart
A stateless service is a type of service that is currently the norm in cloud applications. It is considered stateless because the service itself does not contain data that needs to be stored reliably or made highly available. If an instance of a stateless service shuts down, all of its internal state is lost. In this type of service, state must be persisted to an external store, such as Azure Tables or a SQL database, for it to be made highly available and reliable.
and
Service Fabric introduces a new kind of service that is stateful. A stateful service can maintain state reliably within the service itself, co-located with the code that's using it. State is made highly available by Service Fabric without the need to persist state to an external store.
Reliable Collection can be best described as a No-Sql data store. It is up to you if you want to use this, or have a mix between stateful and stateless services.
For a more in-depth overview of Reliable Collections, read this doc
Related
I have a Service Fabric application and it contains two services stateless and stateful. Service Fabric Application Stateless Service: It contains API endpoints to communicate with stateful service. Stateful Service: The data is being stored in Reliable collections i.e in-memory storage.
I have around 15 service fabric microservices that will be communicating with each other based on the requirement. I'm ending up with a lot of proxy calls in order to communicate between the services which is one of the major reasons for performance hindrance.
In order to mitigate this issue, I have a thought to remove stateful service( in-memory storage with Reliable Dictionaries) and use external storage like Azure Cosmos DB as a data storage.
In the new approach, my application will have one stateless service and it will communicate with the external data store ( ex: Cosmo DB). Service Fabric Application Stateless Service: It contains API endpoints to communicate with the storage provider ( Ex: CosmosDB).
Can anyone let us know whether Service fabric in-memory or external storage gives more performance?
Apart from the performance issues with the in-memory storage, it is becoming very challenging to implement the complex queries or do any elastic search or creating reports as we have dependencies between the services.
Is there any other better approach that can really resolve these kinds of issues?
The whole point of using stateful services is to bring the data to where the compute (your service) is. The benefit of this is performance, as there is no network latency for getting the data.
Now, what you are doing is effectively throwing this benefit away by using a stateful service as a central datastore for other services to get data from.
There are at least two option I can think of. The first is to use an external datastore like Cosmos DB and have all services connect to that datastore or, second opion, to convert your stateless services to stateful services and copy/distribute only the portions of the data a given service need to that service. To make it easier to report based on the data you could create read models.
Currently, we have a databse and moving all databse tables as microservices. Inorder to implement stored procedures/ views, we are fetching few services data in a single service and implemting the logic. Do we have an alternative approach for the Sp's/ Views?
You should not try to map a database and its views/stored procedure to some logic and microservices. Instead, try a new view on it. Let each service put their own data into one or more reliable collections. If there is need for a data store with data combined from each service have those services update a so called read model (you'll probably and up having more than one readmodel).
Look up terms like CQRS and read models, they will help with a micro services architecure.
Or have all services connect to, for example, a sql server giving the benefits of stored procedures and views. But do mind that once you use a centralized database, whether it is a sql database or cosmos db database, your micro services are no longer independent services as they all share a single database schema.
I am going through Reliable Services and Reliable Actors. I have gone through online documentation but few concepts are not clear to me.
With what I understood:
(1) Reliable Service is a programming model and comprises of Stateless and Stateful services. Reliable Service provides highly available set of classes called as: Reliable Collections.
(2) Reliable Actors is a programming model which comprises of Stateful services which utilize single thread for execution. Reliable Actors cannot be Stateless.
I want to know when to use:
(a) Stateless Service
(b) Stateful Service, and
(c) Reliable Actors
What type of services are best suited as single-threaded application?
It will depend on your application and how it is strructured I imagine that you are talking about Service Fabric Here since you just put a tag and not on the question itself.
For the reliable services you have 2 option they are statefull services iagine this as a webpage that wants to keep the state of the client (if you are used to .net imagine this as a persistent session state of having the affinity cookie enabled on your application) basically what you are doing ti tis persisting the information that comes trough this services in order to do that you should be using reliable collections.
Stateless services are basic api calls that will get the response from a service or do some work and return the response back. the classical case it is imagine that you have a services that will do the sum of 2 numbers it doesn't need to implement state it will do the work and retuirn the reponse back but this can be used for services that store the state outside of the service itself.
Reliable Actors are build on top of the reliable services that are statefull they are an implementation of the actor model but built on top of the statefull reliable services. THey just add some utilities on top of the statefull services.
you can read more details on the service fabric implementation of those model on : https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-overview
Can you guys explain
Service Fabric can be packaged with MULTIPLE SERVICES to be shipped but then
how do you reuse some of these services into other Application?
Is there a way Reliable Dictionary or Reliable Queue may be shared among
services deployed on Same Cluster?
I tried reading on google but no clear understanding. Your help will be really appreciated.
... how do you reuse some of these services into other Application?
What do you mean with reuse? Sharing the code? You could have a service in Application A talk to a service in Application B instead of having the same service in Application A.
Is there a way Reliable Dictionary or Reliable Queue may be shared among services deployed on Same Cluster?
No there is not. A Reliable Dictionary or Reliable Queue provides data locality to a service removing the need for additional network calls. As soon as you need this same data for multiple services you should consider using other storage solutions like CosmosDB, Blob storage or another database.
If you are looking for some kind of distributed cache you can take a look at Azure Redis.
It is, however, entirely possible to expose the data of a Reliable Dictionary or Reliable Queue using a service. Then that service acts like a data provider / repository. You can expose methods like Add() or Delete() in such a service that results in an update of the Reliable Dictionary or Reliable Queue.
I am very new to Service Fabric.
Is Service Fabric recommends to use only Reliable Collections to store ALL the data for an application?
What if I use SQL DB to persist all my business data and use Reliable Collection to lazily persist to SQL DB for integration purposes. Following DDD, if i persist my aggregate to SQL DB and leave a entry in reliable collection to communicate with other Bounded Context. Will this approach has any issues?
The Service Fabric does NOT recommend to store all the data in Reliable Collections. Its your choice. The Service Fabric provides you freedom on how to do things, on many levels.
You can use an external DB(like SQL DB or DocumentDB or anything) and use the stateful service as a cache. Or use the stateful service as a primary storage and don't use an external DB at all.
Even though the Reliable Collection is a bit limited in usage(its a key/value store with no effective query interface other than looping all the data) it has the advantage of being internally stored(performance) and it has good fail safe mechanisms(defining secondary instances, as many as you want). The partitioning capabilities should not be forgotten either.
Personally I tend to minimize the external dependencies. An external DB is a dependency. But if your requirements for your application specify extensive query capabilities, go for it.
According to Microsoft
Treat Reliable Actors as a transactional system. Service Fabric
Reliable Actors is not a two phase commit-based system offering ACID.
If we do not implement the optional persistence, and the machine the
actor is running on dies, its current state will go with it. The actor
will be coming up on another node very fast, but unless we have
implemented the backing persistence, the state will be gone. However,
between leveraging retries, duplicate filtering, and/or idempotent
design, you can achieve a high level of reliability and consistency.
https://acom-feature-videos-twitter-card.azurewebsites.net/en-us/documentation/articles/service-fabric-reliable-actors-anti-patterns/
Service Fabric was just announced at the build conference. I was reading the scarce documentation about it and I have a question.
I'm evaluating Service Fabric for hosting CRUD like microservices that are at the moment built in ASP.NET WebApi.
Is Service Fabric geared towards hosting small pieces of functionality that receive data, process it and return the result, rather than hosting CRUD WebApi types of application?
Service Fabric enables the creation of both stateless and stateful microservices.
As the name suggests, any state maintained by an an instance of a stateless service will be lost if the node goes down. A new, fresh instance will simply be spun up elsewhere in the cluster.
Stateful services offer the ability to persist state without relying on an external store. Any data stored in a Reliable Collection will be automatically replicated across multiple nodes in the cluster, ensuring that the state is resilient to failures.
A common pattern is to use a stateless service as the client-facing gateway to the application and then have that service direct traffic to the app's partitioned stateful services. This hides the work of resolving partitions from clients, allowing them to to target one logical endpoint with all requests.
Take a look at the WordCount sample for an example of how this works. The WordCount.WebService stateless service acts as the front end to the application. It simply resolves the partition based on the incoming request and then sends it on. The WordCount.Service stateful service (partitioned based on the first letter of the word) immediately puts those incoming requests in a ReliableQueue and then processes them in the background, storing the results in a ReliableDictionary.
For more details, see the Reliable Services Overview.
Note: for now, the best way to expose WebAPI endpoints to clients is to self-host an OWIN server in the stateless service. ASP.NET 5 projects will soon be supported as well.
This video answers my own question: http://channel9.msdn.com/Events/Build/2015/2-704. In summary, we should use Stateless Services to host ASP.NET based sites or API's which persist data to external data stores.
If you don't have state (or have it externally), Stateless Service is the way to start.
Answer to the original question is "both". Basically, anything that have main() function (with couple of more extended contract methods to talk to Service Fabric) can be a service in Service Fabric world.