Building An Enterprise Multi-Tenant SaaS Product With Hasura By Richard Girges | Workclout

everyone I'm Richard I'm the CTO of a startup called word cloud we've recently adopted his aura it's been a thrilling ride we went into production January of this year with a completely new product after a three-month dev cycle so I thought it'd be fun to walk you through our experiences building our enterprise multi-tenant SAS product with essaouira so first some background on word cloud we're a brand-new product that worked well you know we built this SAS platform for frontline workers and managers in the industrial sector many of us are familiar with agile and lean methodologies these concepts stem from the manufacturing space our software assists industrial companies in the adoption of lean practices with an emphasis on Kaizen workflows so let's take a look at some of the criteria that we faced upon choosing his-- aura for this new product our clients can be medium-sized to large enterprises like manufacturing plants with anywhere between 50 to a thousand users each so that was one thing we have to keep in mind when he decided to build this new product is that it needed to be able to support very large customers the nature of our product is collaborative so being real time is a must that's one of the primary reasons that we chose Sora in the industrial sector compliance and security is extremely important GDP our CCPA data segregation and on a per client basis a lot of clients are cognizant of things like the noisy neighbor problem so we have to get creative with our approach to multi-tenancy we wanted to stay multi-tenancy we wanted to keep that simplicity but we also wanted to be cognizant of the compliance concerns that our customers have finally we needed to ensure that our product a sequel based and highly scalable given the size of our clients so not only are we already a Postgres shop at work cloud before we adopted his Sora but anyone familiar with the old older enterprises like manufacturing knows that you're gonna come across Microsoft sequel servers 9 out of 10 times for every client you integrate with thus having a product that rested on a relational sequel based database was important in our field in addition to that we know how to scale Postgres we know how to replicate it we know how to set up read/write clusters and so on so having something like a syrup sitting on top of a database that were so well-versed in was a huge one for us through this talk we're gonna cover three key phases the R&D and implementation phase what it was like deploying tesora what it was like maintaining history so let's start with R&D and implementation the very first thing that we realized when we were researching historia is that it's not comparable to the likes of firebase this is because hiss or imposed benefits to both the front end and back end stack alike whereas firebase primarily served as a drop-in replacement to most back-end stacks allowing front-end engineers to hit the ground running yes it's true firebase could work alongside your back-end it could be a subset of your back-end but one of its driving value propositions is that you could forego your back-end entirely basura didn't make that value proposition alone if you had a large back-end team or an opinionated back in stock it sort of didn't impose on those scenarios you could bring your own back-end team you can bring your own back-end stack or you could do none of that historic it allow you the basic high-level benefits of firebase in that you could move forward without a back-end stack at all provided you deploy to store it to something like Heroku but let's take a look at what our architecture looked like before has sorta because there are very important aspects of our architecture that we were afraid we'd have to rewrite so this is what our architecture look like you can see here that we're deployed AWS everything is containerized within kubernetes they have a graphical server that sits on top of a crud interface we have various custom business services written in go we have a permissioning service an authentication service a Redis session database you probably noticed the mixture of node and go we're actively transitioning to go laying it's our primary back-end language of choice so that's why you see a split between node and go services so that's another thing that we were a little concerned about we're in the middle of this transition to a different type of back-end technology and how would a surah you know play a role given that transition so this is immediately what happened and when we began adopting his surah we realized three of the services were being replaced by hiss or entirely our graph QL gateway our crud database interfaces and our permissioning services that they all went away and this is what our architecture looked like afterwards so the green is everything that remain and the blue is just a Sora coming in and and replacing those other three services so the end result was a much cleaner architecture but more importantly a Sora didn't impede on any of the technology choices we've made thus far we're still using Redis for a session store we're still housing our custom business services and go if anything it's eased our transition to go because we now only have a single node service that needs to be rewritten and go historic place the other three node services that we were going to rewrite so it actually helped us with some of our tech debt the next question we wanted to answer was just how real time is real time real time was a major requirement for us given the collaborative nature of our product so you know how real time is has Sora let's take a look at what the old traditional way is of doing real time architecture before has Sora with a graph you all stack so the main way we could do real time was by implementing a subscription server using something like a Redis pub/sub system the drawback here is that making external or direct updates to the database won't trigger your real time subscriptions as you saw in our architecture earlier we have various services that post updates to our database outside of the scoville graph QL to anyone familiar with real time architecture you can probably lay out in your head just how you would solve this problem but that just results in an even more complicated architecture than what you see here so so how does this look with essaouira pretty simple if you ask me we just eliminated three services for one and now we have better real time handling that we did with the traditional approach direct updates to the database will now trigger real-time subscriptions here's another way of looking at what I'm trying to describe here I'm in the Postgres console I post an insert command while I'm subscribed to that same table in graph QL I received that insert command immediately so I don't need to simply just only do mutations in graph tool to receive my real-time updates I'm able to do them directly in the database as well that's really important to us because now we've gained an advantage we didn't have before you can look at the services highlighted in yellow here these services direct interface directly to the database and now they're executing real-time updates on the historical on the graph QL level which is something they weren't doing before up next we wanted to choose a graph to our client I don't want to speak too long on graph to all clients because there's so much good information out there already on what graphical clients to use which one's work best but I did want to share our experience a little bit we were originally a relay shop but really proved to be a highly verbose when it came to its enforcement of the real a connection spec which is used for cursor based pagination and some other things ke cache invalidation was also not easy and it's subscription management was unintuitive and difficult for us to ramp up on so we decided we weren't going to use relay it's worth noting that the history team is actually working on supporting the relay connections spec as a first-class you know support which is arguably the biggest blocker to adopting relay but points number two and three would have been a deal breaker for us with nonetheless so our front end setup ended up looking like Apollo client with graphical code gen and those work seamlessly with history subscriptions on react native and react there was very little setup and the setup looked identical across both stacks so in the end result is we're able to define queries subscriptions mutations on the front end and we get type safe auto-generated react hooks for executing those subscriptions or query and whatnot very little setup very little boilerplate very smooth development workflow on the front end overall alright Chapter two let's talk deployment so our high-level strategy for deployment was we wanted to deploy to AWS we wanted to deploy within our kubernetes cluster and we wanted to use Amazon Arora Postgres the kubernetes deployment was extremely straightforward thanks to his sort of stellar documentation and docker images we were also pleased to discover that I saw her with plug-and-play with Aurora that was huge for us because you know it'll solve a lot of our scalability concerns upfront you know for us to be able to lean on Aurora and its auto scalability capabilities means that it's less DevOps the DevOps efforts for us so you know it's great that historia uses such a raw clean version of Postgres that it could work be compatible with Alaura scaling a sewer was pretty simple as well so thanks to the official docker image it was simply a matter of a scaling the deployed historic containers horizontally we had our ingress controller that was connected up with our AWS elastic lb and we ensure that subscriptions and queries operated properly we enabled sticky sessions on the load balancer level so the database migrations are probably the most interesting part of the deployment so every time we needed to deploy database updates we reserved a single replica for applying the migrations we applied the migrations on that one replica you can see that it's not connected to the ingress controller and then after that after the migrations were applied we execute the reload metadata API on each of the remaining replicas allowing all running containers to be synchronized with the newly applied migrations it's worth noting that this workflow is a sort of version 1.1 so there are new and improved strategies for flying migrations in his server version 1.2 and beyond we've yet to try them out but if you were coming into his aura from today onward you're most likely going to find yourself using a slightly different migration strategy finally let's talk about multi-tenancy so this was a huge sticking point for us in terms of deployment given all of the combined stuff that we have to deal with in the enterprise space that we talked about previously so the way we looked at it there are two approaches to multi-tenancy that we were thinking about the first is the traditional approach multi-tenancy on the database level you have an organization table yeah the organization ID which is used to segregate your data and we call this data hotelling the second is multi-tenancy on the Container orchestration level different namespaces are used to segregate data despite everything being hosted on a single kubernetes cluster so we actually implemented both approaches so that's how this is how this work small to medium-sized businesses we went with a data hoteling route so everything was hosted on a shared namespace in a shared database this is very natural in Essaouira as we can ensure all tables returned filtered data based on the organization IP using historias you know permissioning system which proved to be highly versatile larger companies will get a dedicated database and a dedicated has sorta cluster and that will stay inside of a dedicated kubernetes namespace so the really large companies that have extreme compliance measures they still got their segregated data the end result is one multi tenant kubernetes cluster for all customers and we have the shared kubernetes namespace on here in addition to all of the dedicated enterprise namespaces finally maintenance so what was it like maintaining pessoa in production the answer was actually that it was boring and that's a good thing I wish I had something more interesting to say here and I tried really hard to come up with some interesting points but it was pretty uneventful you know so this order was is the database maintenance was on autopilot historia was horizontally scaled in kubernetes we were doing ec2 auto scaling on our kubernetes nodes RDS multi AZ deployment so with automatic failover on the databases and then we used a surahs compute scaling to handle spikes in load so AWS and kubernetes handled the the majority of the sort of DevOps maintenance one interesting thing though is how Hazara affected engineering day-to-day so what what was it like working with his sort of day-to-day after we adopted it the the best way to answer that is to look at what things were like before so I'm actually glad that I got to do this talk because it forced me to look into the quantitative value that we've gained from this aura we knew that we were moving a lot faster because of essaouira but we weren't really looking at the quantitative side of it so we analyzed our git commit history and all of the respective projects and this is what we came up with so here's a breakdown of where our backends team efforts spent most of their time before asura adoption 25% was spent on authorization or permission 50% was spent on data modeling half hour time 50% was spent on building the meet of the backend services development such as crud operations and finally 10% was spent on DevOps so this is what it looked like after Hazara in the four to five months we spent maintaining and iterating on our product we gained 10% of our time back on authorization now that we're using his sort of declarative permissioning system we didn't have to spend time maintaining our own provisioning system data modeling stayed mostly the same the only difference being that we now do all of our data modeling with Essaouira instead of the old flyweight migration tool that we were using service development almost disappeared entirely this is where we gain the most time back we're no longer building and maintaining a backyard gateway nor crud service so the only service development that we did was for custom logic and that happened rarely DevOps also went down a couple percent because we were working with one to horizontally scaled his sorcerer's in place of in place of the three prior services so that left our back-end team with a 57% increase in freedom to work on other things like continuing our migration to going spending more time on research and development spending more time on cool features like we got to build QR scanning into our application for the first time and most importantly we were building a product faster our front-end engineers no longer waited days or weeks for backends to become available finally some closing thoughts on what it was like adopting a saw in retrospect all three of our engineering departments I realized have gained some sort of performance-related benefit the back-end team is certainly the largest winner here but the front-end team now has no more bottlenecks waiting for back in the api's they also have heightened more versatile access to the database that they didn't have before so they're able to query data that the back-end team might not have readily made available in the crud environment but they're still querying that data in a secure way this has allowed us to quickly iterate on features in many cases without any back-end work at all and the ops team has less services to maintain the speed at which we went to production with asura was pretty game-changing we launched on three different platforms iOS Android and web thanks to the combination of react react native and most of all hiss aura we managed to go to market with our new product in three months and the scope of our product was by no means trivial the database alone was over fifty two tables and it was created from scratch and that pretty much sums it up that concludes the talk I hope you've enjoyed it I'll be on the tap afterwards answering questions you can always tweet at me as well and you can access this deck on my github once again I'm Richard and thank you so much for your time

Channel: Hasura

Views: 3,242

Keywords: hasura, saas, graphql, apis, enterprise, authorization, security

Id: F1S_n9GwLVM

Length: 17min 35sec (1055 seconds)

Published: Thu Jun 25 2020