2

I have an existing Web API 2 project that I'm looking to move over to Azure Service Fabric. I'm planning on creating a single stateless service within Fabric as detailed here (mainly as I don't understand actors/services at the moment!) and move the API across.

My API uses Entity Framework for it's backend and the built in Individual Accounts using OWIN.

Is there anything I need to consider when moving the service over (I mainly thought the the DB and authentication might be an issue) or is it just a case of putting a Service Fabric layer on top?

Thanks

EDIT

I've had a bit more of a thought about this and have some more questions (based on @Mihail's comment)!

So I'm going to have many stateless services (so I'm splitting my Web API project up) which will be exposed via a Web API project (based on this)

So two questions really:

  1. I need to authenticate users based on Individual Accounts. I think I should do this on the Web API frontend so only authenticated users get through to the Fabric services but that means that the API has access to the DB and it's not just a pass through anymore. Is this OK? Should the API call a microservice to authenticate and then call the service it requires or is this overkill?

    1. Entity Framework. If I have many services (and API frontend) accessing the same DB do I have to worry about concurrent connections/locking or will Entity Framework handle this for me?
ADringer
  • 2,614
  • 36
  • 63
  • DB and authentication should be no issue. The thing to consider is why you need SF if you only have Web API, but I assume that's just the beginning. – Mikhail Shilkov Mar 16 '16 at 15:43
  • @Mikhail I've updated my question as I've had a further investigation regarding Fabric and also your comment on only one API. Is this still not an issue? – ADringer Mar 17 '16 at 08:50
  • To your questions: 1. Both are OK. It might be a bit cleaner to separate authentication to a separate service. 2. Again, nothing specific to SF here. If you use the standard connection pooling of .NET, you won't get concurrency issues. – Mikhail Shilkov Mar 17 '16 at 09:18

1 Answers1

-1

As Mihail said, the questions around Entity Framework and authentication shouldn't be a problem, or at least not a Service Fabric specific problem.

One thing to consider though is whether Service Fabric is appropriate here if the only thing you'll have is a simple API, or whether an Azure API app would be a better fit for you.

If you went with Service Fabric, you'd have to have at least 5 VMs so you'll need to consider whether your app requires 5 VMs or whether that would be an overkill. Also remember that you'll need to manage those VMs - you don't get the magic that a PaaS solution would give you. You'd also have to deal with certain things that you'd get out of the box from an API app like auto-scale, authentication, rate limiting, integration with SaaS applications, etc. Might be worth having a look at this SO question for a comparison between Service Fabric and the App Service.

Community
  • 1
  • 1
charisk
  • 3,190
  • 2
  • 24
  • 18
  • 5
    I believe this answer is a bit misleading. If you are hosting a Service Fabric cluster in Azure, it IS a PaaS solution and you DON'T have to manage VMs manually. You will be able to scale the cluster from the portal, and auto-scaling is definitely on the roadmap. – Mikhail Shilkov Mar 19 '16 at 21:21