Encouragement

[johnkattenhorn]

Hey,

I thought I'd reach out to say I like the direction the project is going, it has a lot of the same goto patterns we use but I also say a couple of nice improvements from what we've done.

Looking forward to seeing how this project progresses!

Thanks

John

[tjementum]

Hi @johnkattenhorn,

Thanks for the feedback. This is the first community engagement, exciting! 🎉

With more than 25 years of experience in this domain, I'm optimistic about creating something valuable.

Feel free to share any thoughts or suggestions you might have.

/Thomas

[johnkattenhorn]

I'll be interested in seeing how you implement distributed tracing, we've done this only partially through a behaviour and I've never totally happy with the implementation we came up with but with OpenTelemetry focus from the AppInsight team we've never got to tackle it.

Do you yet have a though on how you will do Tenant data separation ? Most of our clients are from the Enterprise and their second people want physical separation.

We went all in with our app spinning up tenant resources but most ask for that to be disabled and replaced with manual steps....

Looking forward to seeing more.

Best Regards

John

[johnkattenhorn]

We also use Orleans quite a bit, if you take a look at our Applicita github account, you can see an implementation there.

We've got a version of clean architecture of sorts which works with grains which we should talk about more.

[tjementum]

I'll be interested in seeing how you implement distributed tracing, we've done this only partially through a behaviour and I've never totally happy with the implementation we came up with but with OpenTelemetry focus from the AppInsight team we've never got to tackle it.

If you meant through distributed events, then a correlation id (e.g. use CorrelationId), will ensure that you can follow a request from the API, to sub API calls, to the event processors, all the way through the system. I've been using Application Insights since 2016, and I think it's awesome (but also expensive). The problem with distributed tracing is mostly when you start sampling data.

Do you yet have a though on how you will do Tenant data separation ? Most of our clients are from the Enterprise and their second people want physical separation.

I'm going for shared database for all tenants (or rather one in each cluster/region: EU, US, AU, etc.).

In my day job, I'm CTO in a company with only truly enterprise customers, in highly-regulated industries (healthcare, financial, pharmaceutical, etc.). We have more than 3 million users and more than a big handful of customers with more than 100.000 users. And we run shared database(s) for all tenants (plural as we have many services). Customers have also asked us about this, but when we explain about what that will mean for database migrations, disaster recovery, dead letter management, monitoring, etc., all customers have been able to understand that strong logical separation of data is acceptable.

The important part is that you do this separation in central location that can't be easily bypassed (what I call the Shared Kernel). The Shared Kernel will ensure that there is no way that a developer can accidentally write code to access data that belongs to a different tenant (every request is scoped to a specific tenant). Having one database per tenant is possible, but it does not really help if it's shared compute (the connection string is available on the computer).

While I would go a long way to avoid this, it will be possible in PlatformPlatform, by spinning up a dedicated cluster for a Tenant. That way it's truly isolated (and more expensive).

But as you know, software architecture is about trade-offs. I'm not trying to solve all problems for everyone. I'd rather solve a problem in a great way for some. My background is that I've built such systems several times, so I've built my own experience.

We went all in with our app spinning up tenant resources but most ask for that to be disabled and replaced with manual steps....

We have been able to educate our customers. All studies show that having everything automated and doing multiple deployments (of both infrastructure and application code), will not only speed up the velocity, it will also mean higher security, higher uptime, minimize mean time to recovery. It sounds counterintuitive, but if you deploy 10 times per day, you must work in very small steps and you must have absolutely everything automated, including unit tests, end-to-end tests, security scanning, load testing, etc. See https://dora.dev (the biggest and longest-running study in our industry).

I'm committed to using trunk-based development, and by trunk, I mean what's running in production. There might be deployment rings where not all production clusters receive updates immediately. However, in the event of an incident, you must be able to push whatever is on the main branch to all clusters.

We also use Orleans quite a bit, if you take a look at our Applicita github account, you can see an implementation there.

I will take a look, thanks.

I'm not very fond of Microsoft Enterprise Architecture (they tend to want to solve everything for everyone). I have no experience with Orleans, but from what I've seen it falls in that category (but I might be completely wrong 😄). I'm also not a fan of microservices, so I'm preaching a flavor called self-contained systems, where you avoid many of the problems with distributed systems. Take a look at the updated README, that is currently sitting in an open pull-request.