CODEWITHSUNDEEP
servicestack
JohnC
JohnC

Reputation: 23

Using ServiceStack with Micro-Service Architecture - Shared Security Issues etc...

I am looking at using ServiceStack and implementing services based on Martin Fowlers Micro-Service architecture, these will be deployed as Worker Roles in Azure.

i.e. say I have 10 services, each will be a separate ServiceStack instance running in it's own Worker Role instance.

All the examples online show a single instance of ServiceStack which host multiple services, this works really well, however this does not fit the architecture I have been asked to look into.

What is the best / preferred method of using multiple micro-services (ServiceStack instances / Worker Roles) and authenticating a user / passing some form of TokenID to the other ServiceStack instances (Only one will handle logon).

Will a STS handle this or something like Thinktecture? Also, is ServiceStack meant to be configured in this manner? Is there a simpler option?

Effectively I want all my standalone services which run in their own process to work with a single authentication service and share a security mechanism.

I would appreciate any feedback from folks who have used ServiceStack in a true Micro-Service architecture.

Thanks John

Upvotes: 0

Views: 1657

Answers (1)

mythz
mythz

Reputation: 143369

I'd recommend not getting too hung up about Micro Services, it's essentially a technical fad that very few Service developers take too seriously to mean anything more than normal Service Oriented Architecture.

Effectively just partitioning your architecture into smaller isolated lightweight runtime services.

Benefits and Tradeoffs of partitioning Services

You should be mindful of the trade-off when partitioning your system architecture into smaller services:

On the 1 hand it's great to be able to reduce the complexity of your overall system by dividing it into smaller isolated components that are decoupled and can be consumed independently from the rest of your system.

On the other hand it introduces more moving parts which adds additional management and deployment overhead with each runtime component, and if your isolation is too fine-grained you'll force un-necessary out-of-process requests (i.e. slowing down your system) when your services have inter-dependencies on other parts of your system.

Avoid prescribed architectures

As always it's recommended to use your judgement as to what granularity is optimal for your use-case and not try to force a prescribed architecture.

ServiceStack's modular architecture

In general ServiceStack is itself a fairly lightweight services framework that scales well to support small and large service architectures. Most of ServiceStack's functionality is encapsulated in Plugins that lets you easily compose together just the functionality that you need. It also supports Modularizing your services implementation across multiple projects which lets you achieve isolation without the overhead of introducing additional runtime components.

Self-Hosting and Messaging options

Should you need to you can easily refactor your existing Service implementations into separate Self-Hosting Services to provide isolated lightweight HTTP services as well as support for Messaging so your services can be hosted on non-HTTP endpoints when preferred.

As ServiceStack has a lightweight footprint it's also possible to encapsulate your entire ServiceStack solution into a single self-hosting executable suitable for hosting inside Console, Windows WinForms/WPF or OSX Cocoa Apps.

Upvotes: 6

Related Questions