@Carmel Hinks : at @13:31, If we are still fine with eventual consistency for read then what was the need for single source of truth. I believe while writing data, you can set quorum and decide how many nodes should receive data before confirming write successful. Later all nodes will get sync data and have upto date information. In that way even write will also get performance improvement because write operation will also happen based on nearest datacenter. Please correct me if I have wrong understanding.
"single source of truth" imagine that. It's a good thing modern sensibilities regarding truth haven't infiltrated the computing world. yet. Good speech. I enjoyed it very much. I'm a total noob so it's refreshing learning about this without all the inside tech jargon. It's also quite refreshing hearing how it all came about and why. Thank you.
Awesome talk. Thank you for uploading this. We're just about to re-platform our legacy product and this video has answered many questions and verified a lot of my thinking :)
Simply fantastic. Can you tell us more about your single tenant architecture ? How many customers were you able to serve with that arch? how did you upgrade these thousands of customers? how frequently did you upgrade? were you able to keep all of them on the same version? etc.
With reference at 12:49. At 14:21, Why do we need to have a tool to sync data from single point of truth, write again and flush it back? Shouldn't Kinesis stream hold unread streams in its queue? and when Western EU is back online, start accepting messages inorder and save it?
Thank you for such an amazing video ! One request , Can someone explain more about the client side caching ? Does it mean that client(say chrome browser accessing Jira) queries TCS and stores the DB info, and sends it in each request ? Or client refers to a microservices receiving the request from an app or web browser ?
In multi-tenant architecture how do we provide a certain feature to only a selected customer ? Acc. to me we can achieve this in single tenant by only upgrading a customer specific node..
Hello Carmel, this video is probably one of those rare hidden gems where deep architectural insights are explained in the simplest manner possible.. kudos to you for sharing this... I do have a request - will it be possible for you to share the presentation slide deck
Excellent presentation! I must admit, though, the material reminded me of the excitement of Novell's Netware Directory Services back in 1995. Multi-tenancy is nothing new, but I am happy to hear how it has matured and remained relevant especially in cloud computing.
4 ปีที่แล้ว
If you use a JAMStack and deploy your app on a serverless platform like Zeit, you can abstract away from the Dev Ops and not have to worry about managing compute nodes, load balancers or caching. It also has built in redundancy and availability. The front end is served on a CDN so latency is very low too.
Thanks for sharing. very interesting. I am curious if anyway possible to only have cache at TCS side, no dynamo db. I.e (Catalog =dynamo+ec2) --> stream --> (Tcs=ec2 writing on cache)
Wait, wait, wait. I'm making an assumption here, but they talked about "stateless" nodes. Then they put caching (which is storage of state), on each of the EC2 nodes requesting information from the database? Why not have a separate caching server, where any node can invalidate/ update the cache centrally? That should have gotten rid of the need for the SNS service and leaves the nodes stateless. And, btw.....we use Jira and it is slow. So..... whatever.
How do I create architecture for azure appservice+functions with two same but separate databases that are in diffferent regions and should not be replicated. code base can be one or multiple, whats best option. Will it Azure front door in front of codebase with db in two different region or Will it be same code base with only db in two separate regions
Great presentation Carmel. I think you mentioned it, but wanted to verify that you are using TCS to obtain one which server a users data resides on. I know Altassian as I have used them before and know there are thousands and thousands of users. Were you setting up a different database per client or different schema per client within the database? I ask because at one time when I was using Altassian, I didn't use it as much only because I didn't have the time to learn it, great product though, and I know there are probably hundreds of users like me and dedicating a database per client seems a bit expensive to me. Perhaps I have it wrong, but curious to know how you managed this or did I miss this in the presentation. Like you said updating thousands of database if there is a change is time-consuming. Thanks...
Thanks for sharing! And i want to say that using Jira a couple of years ago inspired me to start thinking about changing my app to MT SaaS app. But there is one part that i'am still struggling with. How are you implementing the url subdomain architecture? i mean infrastructure wise? I mean when i deploy my app to a webserver it responds to domain.com but how can i make it respond to subdomain.domain.com so that i could grab the subdomain in the app and query the relative DB.
Hi Mostafa, thanks for your question! So the answer to this kind of depends on your use case. In our case, we use subdomains to identify our customers. For example, say we had carmel.atlassian.net and mostafa.atlassian.net. In this case, `carmel` and `mostafa` would be two completely different customers. Given that, we can actually use the entire hostname (subdomain included) to query the TCS for the data we need. It's also worth pointing out that in my talk, I've actually simplified the whole process. In reality, we actually assign unique identifiers to all of the customers. So, we'll use the hostname during the first request to the TCS, which will get us access to the unique identifier. All subsequent requests use the unique identifier instead of the hostname. I'm not sure if that answers your question, but good luck all the same!
@@carmelhinks7341 Hi Carmel, Thanks for your reply! Yeah that was really helpful. But what I wanted to know is how are you creating the subdomains? Or are you using a wildcard subdomain?
Literally the BEST video about multi-tenancy
This is like an entire AWS architecture series in 18 minutes. Loved every minute of it. Thanks for sharing
As someone who maintained Atlassian products in-house (2014-2016) this talk really brings me back to the good old days.
How is this video having only 200 likes? Very important architectural information given out for free.
This is one of the best explanations ever on MT-DB
@Carmel Hinks : at @13:31, If we are still fine with eventual consistency for read then what was the need for single source of truth. I believe while writing data, you can set quorum and decide how many nodes should receive data before confirming write successful. Later all nodes will get sync data and have upto date information. In that way even write will also get performance improvement because write operation will also happen based on nearest datacenter. Please correct me if I have wrong understanding.
Amazing story telling. It's crisp and clear.
If i could like this talk 10 times, I would do that. Thanks for the talk.
Incredibly clear and great deck.
AWESOME! Brilliantly Explained 🎯Cheers Carmel 👍🏻
Super awesome content. Thanks Carmel!
Whoaa!! This was more clarifying than AWS itself could hv been.
One of the best talks ever. So crisp, clear and packed.
"single source of truth"
imagine that. It's a good thing modern sensibilities regarding truth haven't infiltrated the computing world. yet.
Good speech. I enjoyed it very much. I'm a total noob so it's refreshing learning about this without all the inside tech jargon. It's also quite refreshing hearing how it all came about and why. Thank you.
Bloody Beautiful!
Bloody awesome comment, thanks mate ;)
Awesome talk and thanks for uploading
Simple short yet so informative!
Thank you! I'm so glad you thought so!
Awesome talk. Thank you for uploading this.
We're just about to re-platform our legacy product and this video has answered many questions and verified a lot of my thinking :)
instablaster.
Simply fantastic. Can you tell us more about your single tenant architecture ? How many customers were you able to serve with that arch? how did you upgrade these thousands of customers? how frequently did you upgrade? were you able to keep all of them on the same version? etc.
With reference at 12:49.
At 14:21, Why do we need to have a tool to sync data from single point of truth, write again and flush it back? Shouldn't Kinesis stream hold unread streams in its queue? and when Western EU is back online, start accepting messages inorder and save it?
Thank you for such an amazing video !
One request , Can someone explain more about the client side caching ? Does it mean that client(say chrome browser accessing Jira) queries TCS and stores the DB info, and sends it in each request ? Or client refers to a microservices receiving the request from an app or web browser ?
This was probably one of my favorite talks at GHC!
Oh wow, thank you so much!
Fantastic video. Now I want to know how they structured there single-tenant architecture!!
very interesting, short and sweet!
I'm so glad you thought so, thank you Barbara!
Note to self : Watch it before any interview
In multi-tenant architecture how do we provide a certain feature to only a selected customer ? Acc. to me we can achieve this in single tenant by only upgrading a customer specific node..
Fantastic Talk!!Kinesis is real love for multitenant applications!
Amazing talk!!
Interesting approach to multi-tenancy.
Thanks for sharing. Found this useful for something I'm designing/architecting right now.
Hello Carmel, this video is probably one of those rare hidden gems where deep architectural insights are explained in the simplest manner possible.. kudos to you for sharing this... I do have a request - will it be possible for you to share the presentation slide deck
Excellent presentation! I must admit, though, the material reminded me of the excitement of Novell's Netware Directory Services back in 1995. Multi-tenancy is nothing new, but I am happy to hear how it has matured and remained relevant especially in cloud computing.
If you use a JAMStack and deploy your app on a serverless platform like Zeit, you can abstract away from the Dev Ops and not have to worry about managing compute nodes, load balancers or caching. It also has built in redundancy and availability. The front end is served on a CDN so latency is very low too.
Excellent presentation
Thanks so much :)!
excellent talk, thanks
Beautiful.
Thanks for sharing. A good learning experience.
Simple And clear thanks
if you cache per ec2 nodes how do you ensure ordering ..was it write through.?
Thanks for sharing. very interesting. I am curious if anyway possible to only have cache at TCS side, no dynamo db. I.e (Catalog =dynamo+ec2) --> stream --> (Tcs=ec2 writing on cache)
great talk !
Thanks so much Debu!
impressive deisnging and ingeneering
You are awesome. Great Talk
Great talk!!!!
useful but in the middle you skipped couple of things... like where did catalogue service come all of a sudden with no background?
Hey, Carmel. Thanks for sharing!
No problem at all, thanks for watching!
Wait, wait, wait. I'm making an assumption here, but they talked about "stateless" nodes. Then they put caching (which is storage of state), on each of the EC2 nodes requesting information from the database? Why not have a separate caching server, where any node can invalidate/ update the cache centrally? That should have gotten rid of the need for the SNS service and leaves the nodes stateless. And, btw.....we use Jira and it is slow. So..... whatever.
Great talk! Thank you.
How do I create architecture for azure appservice+functions with two same but separate databases that are in diffferent regions and should not be replicated. code base can be one or multiple, whats best option. Will it Azure front door in front of codebase with db in two different region or Will it be same code base with only db in two separate regions
Great presentation Carmel. I think you mentioned it, but wanted to verify that you are using TCS to obtain one which server a users data resides on. I know Altassian as I have used them before and know there are thousands and thousands of users. Were you setting up a different database per client or different schema per client within the database? I ask because at one time when I was using Altassian, I didn't use it as much only because I didn't have the time to learn it, great product though, and I know there are probably hundreds of users like me and dedicating a database per client seems a bit expensive to me. Perhaps I have it wrong, but curious to know how you managed this or did I miss this in the presentation. Like you said updating thousands of database if there is a change is time-consuming. Thanks...
Would like to know as well i don't think it was mentioned in the presentation.
Thank you
Nice explanation!
Great talk Carmel :)
basically K8 architecture pattern
Fast and Fantastic
Thanks for sharing! And i want to say that using Jira a couple of years ago inspired me to start thinking about changing my app to MT SaaS app. But there is one part that i'am still struggling with. How are you implementing the url subdomain architecture? i mean infrastructure wise? I mean when i deploy my app to a webserver it responds to domain.com but how can i make it respond to subdomain.domain.com so that i could grab the subdomain in the app and query the relative DB.
Hi Mostafa, thanks for your question!
So the answer to this kind of depends on your use case. In our case, we use subdomains to identify our customers. For example, say we had carmel.atlassian.net and mostafa.atlassian.net. In this case, `carmel` and `mostafa` would be two completely different customers. Given that, we can actually use the entire hostname (subdomain included) to query the TCS for the data we need.
It's also worth pointing out that in my talk, I've actually simplified the whole process. In reality, we actually assign unique identifiers to all of the customers. So, we'll use the hostname during the first request to the TCS, which will get us access to the unique identifier. All subsequent requests use the unique identifier instead of the hostname.
I'm not sure if that answers your question, but good luck all the same!
@@carmelhinks7341 Hi Carmel, Thanks for your reply! Yeah that was really helpful. But what I wanted to know is how are you creating the subdomains? Or are you using a wildcard subdomain?
@@gadothegado I had the same question about creating those subdomains. And how should you handle the customization of the UI per tenant
Amazing !!
Nice. I’m building my own server
Wow
i am also software engineer.
more like an aws talk haha
But why do your products still slow? You claim you achieved excellent performance (Req/sec) but it feels far from fast and responsive.
Aws sponsored
Whoaa!! This was more clarifying than AWS itself could hv been.