Microservices shared front end aka How does servicestack find services?

ServiceStack
1

I am refactoring an application to be a little more microservices oriented, so my goal is to have a common app host project that handles auth & session and front ends services, and then each microservice solution will contain that shared app project and then include projects for Services, DTO’s and Persistence associated with that “subject area” of the architecture. We’ll then deploy instances of each of these solutions as appropriate for load and fault tolerance.

Is this a reasonable approach and are there any restrictions or design consideration on how a shared apphost project might discover services across different solutions?

Target runtime is dotnet core on ECS if it matters.

Thanks in advance.

-K

2

If your Services are split across multiple .dlls, you can just add the Assemblies in ServiceStack’s AppHost constructor, if you’re splitting your System into multiple Microservices than we recommend using the Service Gateway which allows you to make intra Service API calls with the same API irrespective of whether it’s calling an internal Service or external Service. Built on top of the Service Gateway are some Service Discovery solutions that take care of automatically discovering available services and will automatically route them to the appropriate Service.

Also my recommendation for enabling Auth across multiple microservices is to use JWT.

Finally a word of caution, whilst we believe designing for Microservices provides benefits, I’d only consider doing so if they provide some tangible value. e.g. StackOverflow doesn’t use Microservices for performance/latency, Basecamp doesn’t see any value in Microservices for small/medium-sized projects and many other prominent industry leaders also suggest going monolith first or that you can get more benefits with less trade-offs by modularizing your system.

ServiceStack’s lets you “design for Microservices” by being able to split Services across multiple .dlls and decouple inter-service dependencies behind its Service Gateway so you can delay physically decoupling your architecture into multiple deployment units since it’s naturally and easy to do once you identify there’s value in it.

3

Demis, thanks as always very informative and helpful :smile:

In particular those service discovery options look good, much better than the likes of eureka IMHO.

Not sure basecamp’s assertion “900 methods==large/complex”. :wink:

1 Like
4

If you must split services and make them discoverable, you may find Consul a good option. There is an implemention for ServiceStack with Consul here:

I modified some bits and pieces to be able to have right naming and support for different JSON configs. I put thos in this pull request to their code:

Hope this helps.