Building SaaS on AWS - Deep dive: Architecting serverless SaaS

[Music] [Applause] hi everyone and welcome to the second episode of building sass on aws my name is gilner and i am a developer advocate at aws and if you are building or planning to build a sas product this is the show for you so on the previous episode i was joined by randy dramond and we had a deep dive on on architecting multi-tenant sas on amazon eks so to even things out a bit this episode will dive deep on architecting a serverless sas solution and to do that i am joined today by ujjval and alibab from the aws sas factory team welcome to the show both of you thank you yeah all right so let's do the the traditional introductions let's start with ujjwal tell people a bit about yourself hi everyone i'm joel i am a partner solution architect with aws subscription team i am the part of the team where myself and above developed this reference solution which we are excited to present today uh hello everyone this is anubhav and you know i'm working here at aws since last couple of years now and as soon as you will mention i'm also part of the team called as sas factory and just maybe a quick introduction about our team so we are part of aws partner network and we help our partners who are building sas solutions on aws um you know we work with them very closely both on technical and business front um so and in fact you know working with these customers we heard a lot of feedback uh around you know how to build serverless how to how to use serverless technologies to build sas solutions and that's where uh this whole concept of serverless as reference solution came into existence so nice to meet you thank you so much all right so if you didn't catch the previous episode this show is supposed to be as interactive as possible so if you are watching and you have any questions along the way feel free to just post your message in the chat and we'll try to get well my expert guests to to answer your questions so if you're joining us right now please post something in the chat so make sure that everything works as intended all right so let's start things out then uh i think we need to first ask the question why do we want to build a serverless sas solution so yeah um so let me you know briefly introduce about the key features of serverless and then we'll dive into your question so the with the serverless basically enables you to build agile applications so that you can innovate and respond to the changes faster and with serverless you don't need to worry about the management tasks such as you know capacity provisioning and patching and with the several services come along you know they come with automatic scaling and building high availability and also they based upon the billing model is a pay for value building model um so the key features i'm trying to point out here is you get a better agility and less operational footprint so better operational efficiency and better cost optimization with these features uh it lets you concentrate more on innovating your own product rather than maintaining or spending time on the operational bits of it these key features are very much useful or needed when you're building a sas solution because in sas you need to adapt to the marketing changes faster having a gel application that makes it helps and also in the sas solution or ss product the activity of the tenants are always be changing and the way they are consuming the resources also is changing and it will be a challenge for the sas architects to build an architecture which closely follows this current activity and the build and then the activity should and the architecture is such a way that it it provisions the resources effectively and efficiently with serverless taking over the scaling and also management of the infrastructure definitely helps in this area and also it uh it also reduces the burden of management so hence enough and also with all these features um you get more time spent on innovating your own product rather than maintaining it so with all these um you know serverless is definitely compelling to build solutions yeah i would just you know maybe add maybe couple of sentences like the sas providers need to go to the market as soon as possible with their first mvp released right they need to focus on their ip rather than managing servers and everything so so with serverless they can more focus on the ip on on their on the propriety software as such rather than you know spending time managing scaling up and down and so serverless take away that um that headache from them i would say yeah so so serverless is definitely a good choice for for building something like a sas product and for sure given that and the scaling for instance is something that well you want your sales products to scale to scale with with the number of tenants you have on board so let's just mention that we're going to dive quite deep into the architecture but to start things out let's let's talk a bit about the service as reference architecture what are some of the best practices that you've implemented into this architecture right so so there are you know if you look at there are various uh sas best practices uh when you're uh trying to provision uh different tenants or managing the tenants such as like for example you can provision attendant in such tenants in such a way that they can use the shared resources it's called full model or you can provision the resources for the tenants in such a way that only you can provision a resource for only just for that particular opinion it's called silo model whether you're provisioning the resources in the pool model or the silo model there are various best practices around how you implement onboarding how you implement authorization and authentication and how do you implement current isolation and data partitioning and also there are you know there's some good practices around how you need to laid out your services like for example you can have a bunch of shared services which are used across the tenants such as tenant management service user management service primarily used when you're trying to onboard internet and you you will have a bunch of services specific to your application it's called application services so what we did in the reference architecture is is try to bring all these concepts into a working unit so that the consumer of this service can you know play with it understand it and take it further based on their needs we use most of the you know aws services to build uh serverless services uh to build this weapons architecture um to name a few uh we used cognito uh amazon cognito and amazon api gateway uh ews lambda and the amazon dynamodb and aws uh code pipeline on amazon coldwatch yeah and just to maybe you know add usual like we use sam and cdk for the deployment bits of it so um one thing which sometimes people kind of ignore is the operational excellence that that's required in a sas platform right you need to be able to apply releases of zero down time i would say like you have thousands of tenants like you know the whole concept of on-premise solution upgrade over the weekend doesn't really apply in a size solution i would say so you need to be very much agile so um we also have covered some some ci cd best practices and how to apply a single build across those multiple environments as a dual perception in this as this application so yeah also like to point yeah so i also would like to find out you know the notion of microservices or the way we implemented the microservices in serverless as so basically the the microservice boundary in the serverless is a api gateway backed up with a couple lambda functions like for example if you take an order service if we created a lambda function for create order update order or delete order and these functions um altogether work on a similar set of a data set so we can logically group them together there is this basically there is a huge advantage in decomposing your service into smaller bits because uh if if something fails the impact of that uh failure is very less and this is a huge advantage in environment where where your tenants are sharing your resources so i think let's start by by looking at the repo the repository for this servless reference architecture and let's take it step by step there to dive deep into each part of the the reference architecture so bring your screen up sure let me maximize it here so yeah so this is the github repo of serverless reference architecture um so before you start playing with this reference architecture please do run through this prerequisites otherwise you'll run into some weird issues uh the way you would kick start this reference architecture is by following these instructions here so as a part of this instructions what you are basically doing is you are running a deployment script which is in here this deployment before we look at this deployment script let me show you a few other things here um so there is a bootstrap template.yaml is nothing but a sam template and this sam template basically provisions the baseline infrastructure which is required for this reference architecture as a part of this design infrastructure it provisions a bunch of shared services which i mentioned earlier such as tenant management service user management service and provisioning service and also provisions an api gateway to expose these services and there are three uis which are which we used in this uh reference architecture and so this reference uh this particular template provisions three s3 buckets and uh cold front three to open distributions to host uh the three uis and finally it provisions a cognitive user tool for pool tenants and a cognitive user pool for operational users such as sas admins there is also another template called tenant template again this is a sam template uh which provisions the infrastructure required for a particular action um so as a part of this uh template we are provisioning a couple services called order service and product service which which are application services which loosely mimics an e-commerce application it also provisions an api gateway and dynamo db tables which are required for this particular service and there is also a ci cd pipeline which we built using cdk which takes care of provisioning the tenant template of yaml which we just saw basically provisions uh the tenant infrastructure now uh now let's look at the deployment script um so there's a part of this uh deployment script is basically what it does is it provisions bunch of resources in your aws account it starts off with the creating a code commit repo and pushes your code into it and then it builds and deploys the ci cd pipeline which we just saw and then it builds and deploys a bootstrap template which provisions the baseline infrastructure you need to pass in an email id when you're provisioning the your baseline infrastructure this email id will be configured as a sas admin it's basically added to the user tool and the user pool will save you the temporary credentials to login and then the script uh provisions or kicks off the cicd pipeline which basically runs the tenant template at this point it is basically provisioning the resources required for the full return and the rest of the script what it is doing is is basically building the code related to three uis and pushing that code into the s3 buttons and to summarize all of these things um this is the this is a high level uh architecture diagram that we are provisioning so basically we are provisioning three uis one is as you can see here in the far right one is the sas admin where sas admin can manage the tenants and the far left there is another ui called lineup as landing or sign up page where a client can come in and sign up themselves and uh and we are also provisioning a samples as application and there is an api gateway we are provisioning and then there are a bunch of shared services uh as i mentioned earlier we are provisioning those things as a part of the baseline infrastructure and also we are provisioning couple of the application services order and product services so looking at looking at the high level architecture and comparing it to to the the first episode when we did one on amazon eks it is very similar in the way the high level architecture looks but this one is instead based on on the serverless architecture i do want to mention though one one um subtle difference and the strategy that would operate here so and as usual mentioned initially we have followed a tier based um architecture so so basically what that means is the deployment first of all deployment dot sh that's that said one single file if you run you just get the whole infrastructure deployed for you in your aws account so that's pretty straightforward right all you have to do is specify an email address then you're good to go now with this high-level architecture that you are seeing now that is something we are calling calling it as baseline architecture and and what that means is this will install or deploy everything required for our pooled tenants but then there and we'll walk through in more detail later we have a concept of hybrid uh model here so what that means is we are having certain like platinum tier tenants so when they provision themselves or when they register themselves we are actually provisioning a whole separate application services for them so we will jump into that aspects in a little bit more detail and and that's one of the differences i just wanted to highlight and want to make sure that you know customers and understand that you know in some cases sas providers might have to support different variations of deployment depending upon their customer profile right and that's the idea we want to emphasize and highlight here um and you know that and i think that's something we want to go in more detail as far as we as we go along in this session today that's great uh so i think maybe we should start from the beginning then let's say that we have this baseline infrastructure up and running now the first step would then be to onboard a tenant right so yeah so once you successfully uh provision this reference architecture uh just want to point out like a few things in the cloud formation service so what what what you will see there is you will see a bunch of stacks of provision so there will be a stack name stacked with the name of serverless sas this is basically the baseline infrastructure the bootstrap template which we just saw and also it provisions a bunch of nested stacks and also you will see a stack with the name serverless pipeline uh which which is basically the ci cd pipeline uh and you will see a stack with the stack with the name as a stack tool this is provisioning the pool resources for now just ignore this particular stack i'll get back to it just assume that you know you're not seeing that so for uh so far as part of the baseline infrastructure there are three uis uh we have provision and we'll look at the first of the first ui so this is the sas admin u1 and um with this uis asset link can manage the tenants basically provision the trends and look into the list of the names and now let's try to look at uh you know obviously i need to log in so when when you're when you run the deployment script as i mentioned earlier um you need to send in an email id uh that email id will be configured as sas admin and i'll use those credentials now to login okay i'm logged in and then now so as of now uh this is the tenant's uh list of the tenants here um and uh i've pre-provisioned one tenant already so we'll get to that hold on to that and the way we would provision a tenant or the on-board account is basically filling up this form let's try to fill this form here [Music] so we have a bunch of service plans um this is what anubhav was previously hinting to so basically the service plans are the different years we have this basic standard premium and uh platform so if you provision a tenant with the basic standard or premium uh so what they are basically provisioned as the pool tenants where the tenants will be sharing the resources and if you provision a tenant with the platform here a separate set of infrastructure will be created for this particular tenant um it's called the silo model and also uh there is a varying level of performance between these service plans what i mean by that is that for example if the epa gave the level each of these service plan has a different uh set of usage plans and hence has a different throttling limits and all that good stuff so let's try to provision a basic tier comment here so now uh as for the pool tenants all the resources are already provisioned what it does is now basically changing the or updating the configuration to accommodate this particular client so let's let's look at the aws console and see what the things it has done you know to start off with and on the user pool you can see that you know if there is a pool tenant and if you click on that pool tent there will be a new user added or you know basically the tenant admin and also it creates a group for this particular tenant and adds that event admin to that group and also the other thing what it does is it captures the student information in a dynamodb table and we can look at that so in the tenant details table um if i refresh here you should we should see yeah so this is the one that the first tenant is the one which is got onboarded just ignore the second report we'll get to it so so that's uh that's the way you would you know that there is another ui uh where you know it's called a landing page or uh signup page uh where a a tenant or a client would come in and can sign up uh the way you would do again is a similar form um same form and you know we'll try to onboard a second tenant um the will use as a platform here as a service plan and again as i mentioned with the platform here a silo resources will be created for this particular tenant and after you click this particular event for the uh silo or the platform tier 10 and what happens is that it triggers a ci cd pipeline um and usually this is the provisioning of resources for a particular ah can enter for a platinum trend takes a couple minutes so what i did is that i pre-provisioned the particular particular tenant so if you look at the cicd pipeline um it is already a ram before and what it does what it does is it's basically provisions the tenant template this is what the template or the the the the confirmation stack you were looking into it before so this is this is the stack for just for that platform tier tenant which has provisioned a bunch of resources and we can look at those resources here to start off with uh we can look at the user pool there is a separate new user pool created just for this particular platform three of them and if you look at the users again it has created the tenant admin and also it created the user groups and if you look at the apa gateway it has created a new api gateway just for this particular platform to tenant and if you look at the dynamodb tables and on here you will see that you know there is a separate order table and a product table specifically for this particular tenant that is the order pool and the product pool is for the pool temps now now what we'll try to look at the code and try to understand what are all the things happen when we try to onboard it so let's just uh just step back there the first example you gave was through the the sas provider admin interface to onboard a tenant and and you choose the pool model but but you could have chosen any model there as well of course and the other example was through a well a self-service portal for instance the web page for that sas provider whatever it is they are selling yeah so normally you know think about it this way like you are a tenant you are you're coming to register yourself in your sas application you need a way to just a open page without any authentication because you're not registered yet right so you need a way to go and just register yourself so that's the registration page the concept registration page but then normally sas administrators or sas providers need a way to manage their tenants and then what that means is they should be able to onboard new tenants if needed on behalf of a tenant or update the tenant or maybe just deactivate a tenant as well right so so that sas administrator console is basically importing that concept of a sas administrator doing certain things and we we are allowing um both ways for attendance registration and onboarding to happen yep all right go ahead drop yeah sure um so let's let me open my ide here so so here in here you can see that you know the the bunch of shared resources which i'm trying to point out here um so these are the shared resources which are you i was mentioning earlier which will be used while onboarding a tenant so to start off me make with easier um right to start off with uh this is a python code um so when you when you onboard a tenant or click on that create button this is the registration tenant is the method which gets called and you can look at is the first thing what we are checking here is what type of a tier you are trying to onboard and if it is a platform clear tenant you need to provision obviously the silo resources so we are creating an attribute we named is a dedicated tendency as a true you will see in down we will how we are using uh this attribute to provision the resources and again i have mentioned that you know we are using different usage plans uh for different years so we are trying to get the correct api key for that particular tenant here uh that's all that's what we are doing in these conditions and then uh what happens is like you know we are making a call uh to a method called which creates a tenant admin user at this point what we are doing is we are making a call to another service called user management service i will look into that in a bit which takes care of creating the admin user and once it is successfully done and then we are again making a call to another method called create in it at this point it makes a call to another service called management service which captures the direct information in the telling details table and then uh you can look at here is that you know we're checking if the dedicated tenancy is true that means you're checking if the if you're on boarding a platinum to your tenant then invoke a method to provision so at this point we are calling another service called tenant provisioning service uh which kicks off the ci cd pipeline which will look at it in so if you look at one of these methods here um what we are doing is basically uh we are making a http call to the api gateway urls of these services the way we are restricting the interactions between the service to service calls is by im roles and using the resource policies of the apa now let's try to look at these individual services and try to see what we are doing in those methods so as i mentioned earlier this method for this method we are calling another service called user management service if i open that user management service you can see that you know in this user management service the first thing again we are doing is if it is a dedicated tenancy that means if you are provisioning a platform to your tenant um we need to provision a separate chat of user pool or a new user pool for them that's what we are doing here we are creating that user poll and creating the cool client and all that stuff and if it is not in pre platinum tier 10 and we are just using the pooled tenant user pool id and those configuration and the rest of the code here is basically creating that user group and then creating the inventory user and for the tenant management uh we and the next step which which we did is that you know we're calling it create tenant and for that uh this particular tenant management service is called and if you look at the tenant management method all it's doing here is basically capturing the tenant information i can see this all the current information in attending details table so that can be used later and finally the we if it is a dedicated uh tenancy or if it is a platform tier tenant we invoke a provisioning method so that at that point there is this the trend provisioning service is called and the method it invokes is a provisioning tenant and what it does is a couple things so basically what it first it captures the stack name with the tenant id in a tenant starting uh standing stack mapping table and then invoke the ci cd pipeline here so this a cd pipeline looks at this uh stack mapping table and get the list of tenants it needs to provision and start provisioning those services uh provisioning those uh stacks basically provisioning the cloud formation stacks that's that's a brief overview of like what are all the things happens in the back end when we are trying to onboard it yeah so and also if there is any change in the code um the cicd pipeline will automatically update all the stacks based upon this configuration table now so it's fully automated um and obviously you know it makes sure that it will get the code from the code command build it do whatever unit testing you need to do and there might be other things that might want to do integration testing some security testing and then you deploy across all those tenant environments basically cool so if you just joined us this is the building sas on aws show we are a bi-weekly show where we're diving deep on how to build sas on aws and this week we are looking at the serverless sas reference architecture so doing a deep dive on that if you have any questions just pop them in the chat and we'll do our best to answer those as well one thing that we keep talking about when it comes to sas and multi-tenant sas is isolation so can you show me a bit about how you're implementing authorization for a tenant isolation use with the apis sure uh let me pull up a slide here um we'll explain the concept through the slide and then we can go into the code and look at things in more detail so that it will make sense so let me pull this right here um so so here um so whenever a user comes in he'll be redirected depending upon the tenancy they they've redirected to the cognitive user pool that's where uh it gets authenticated and then the cognitive user pool will generate the job token and with that request with the jar token um the request would reach out to the api gateway at the api gateway level um we are using uh the api available we are using lambda authorizer um i need that the lambda authorizes does bunch of things to start off with it looks at the user role and then allows or disallows some of the rules and also as i mentioned earlier at the api get available you are using a usage plan so it brings in the correct api key based upon the tenant you are basically the service plan you are using and enforces the restrictions which are laid out in the usage plans and then the next thing what it does is based upon the tenant and the role that the user has what it does is uh basically it creates an im policy with the list of permissions and also it adds a condition which has a tenant context in it um and then it takes this i am policy and interacts with the sts to generate the scope credentials this concept will be will be more clear when you look at the code in a bit here but what it does is it basically generates a scoped credentials and passes the stroke credentials to the downstream lambda functions so when when the tenants are running in the pool environment as i mentioned earlier the they're sharing the resources and they'll be sharing these lambda functions in those cases these scoped credentials will have access to they will have a narrow narrow scope only just for that particular internet so that these lambda functions can use the scope retentions to interact with their dynamodb table in this case so this is how we are implementing the tenant isolation in the in the pooled environment case whereas if you take the example of this side load environment where what where we would do is that we would provision a separate set of a lambda function and it will have a separate execution role and there are also a separate dynamodb tables for that particular tenant and this lambda execution role will have the access to those specific tables that's how we are doing the tenant isolation in the first silo diagram so back up a little bit here um so the concept which i explained where we are generating the scope credentials in the lambda authorizer is called dynamic policy generation and if you want to know more about that there is a blog post which is created by our colleague called bill thorpe um please refer to the blog post we will we'll paste that uh link in the chat so so and and the way like you know we have implemented this dynamic policy generation at the lan in the lambda authorizer at the apa data level the other way you can implement this is you can push this dynamic generation policy concept into a micro service and you can build that in a micro service so in that case depending upon your environment you can depending upon your architecture you might need to caching the the scope credentials because every time the request comes in you might need to regenerate it so in order to avoid that you might need to introduce caching um so but the advantage of implementing that uh this dynamic policy generation in the api gateway level is you can use the caching provided by the api gateway so inherently apk provides the caching feature where the time to view for the cache you can configure from 300 seconds to 30 3600 seconds so the advantage of building uh this dynamic policy generation in the lambda using the lambda authorizer at the apk variable you give that caching out of the box so and again and depending upon your architecture or depending upon your needs you can either build it here or you can build it into your downstream microservices and yeah no i just want to maybe you know add like the this whole authentication authorization process i would say is at the core of this uh sas architecture um i mean if you understand this then you will probably be able to uh basically understand what's going on behind the scenes and and this also feeds as usual mentioned into the tenant isolation bits as well um maybe just think of one thing i want to point out is that number two blue dot on this architecture when you get back the job token from cognito just want to mention that inside the jaw token we have the tenant id and the user role as part of custom claims and that's what enable us and allow us to use and identify what tenant or what what tenant this user actually belongs to and that is how we are able to now apply these authorization policies uh apply the api keys because now we know the tenant ide and now we know that which api keep belongs to this tenant ide we know which user role this uh user all this user belongs to and also then as as as usual mentioned we are able to leverage the tenant id from the custom claim obviously after we validate the chart token and and then able to dynamically apply uh that to a policy template and obviously we will look at the code as well and then that's that that enables us to generate a short dip credential scope for that tenant and everything start from the fact that we have that tenant id and and the user role inside the chart token so question from toby in the chat so so api key in equal to api gateway api key now we're talking about the api gateway api key functionality actually in this case so we are using the usage plans and api keys um which comes as part of the api gateway so so one thing which might be worth noting here is that we are setting the api key inside the authorizer and not necessarily passing it from the ui because in api gateway you can do it in both ways the the client can pass the api key from the from the client itself but in our case since we are dealing with the ui and not necessarily exposing this as apis we choose to look at the tenant id get from the tenant details what api key it belongs it it has and then apply inside the authorizer and and then the authorizer policy once it knows which api key is associated with this particular user is able to apply that usage plan and and the way usage pen works is in two ways right it first of all how many concurrent requests you can have at that time in a second basically and also it allows you to set some sort of quotas like you know you can only have maybe 10 000 requests per day as an example and this is actually one of the best practices uh in a sas solution you should be able to limit your tiers your tenants you you should you should not let one tenant ruin the experience of other tenants right so because if you don't apply any throttling limits in your in your application in architecture it may very well also happen that one tenant can just keep bombarding your application and cause some sort of noisy neighbor issues for the other tenants so follow-up question from toby then do you have to pass the access token and an api key so as i mentioned uh the access token has the tenant id in it and we are using a tenant details table to fetch the api key and apply in the authorizer itself i think it will be more clear when you know let's just pull up the code so so this is the authorizer which we are talking about so what uh so basically um it looks the first thing what it is looking is depending upon the role if it is a sas admin uh this asset means as i said it's created in a different user tool so um it's getting this useful configuration and if it is not if it is the rest of the for the rest of the things what it is doing is fetching the details from the details table where we are capturing the tenants so if you look at those details here what we are getting is the user pool id uh apa client id and then the api key the api key the one which another was referring so we got the api key from the impedance table and the the next what it does is basically it has the user pool and that current id load so obviously it tries to validate the job token and once the jar token is validated uh what it does is uh basically checking the role to ensure that they have proper access to access this particular urls and does that check and then then the rest of the code here is what it is doing the dynamic policy generation so let's look at so if you look at the line here what it is doing is it passing the role and based upon the role it is generating the in policy let's look at what policy it generates so let me go to this particular method manager um get policy for user and if it is uh any of the you know any of these users but what it does if you look at the for the tenant let's look at the tenant of numbers so here it's generating a policy um this this policy has uh is giving permissions to bunch of uh tables these permissions for these memorial tables and the thing the interesting thing is they're doing is placing a condition here basically injecting the tenant context and the tenant context is nothing but the tenant id and what happens what you're doing here is that basically you're giving access only to the data which are with the leading key of tenant id so when after the after the authorizer gives the scope credentials and then the lambda in the pool terminal tries to access uh the dynamodb table for its data only the data of related to that particular tenant will be visible to that particular lambda function that's how you are narrowing the scope and if i can go back here i'll show you the rest of the steps what's happening there so you get this i am policy and apply that i am called a c to a role and then you interact with sts to generate the scoped credentials and what we are doing is that we are creating a context which has these scope credentials and the api key and all that stuff and then setting the context to the response so that you know it will be sent to the downstream lambda functions and finally the api key we set this api key here so as anubhav was saying uh what the the approach which we took is where um ap we have configured api gateway to look at the authorizer and validate the api keys the way it does is basically you need to configure api gateway to look at the authorizer and you have to set this api key to this usage identifier key and the api gateway takes care of the rest of the match as another was saying the other approach is you can set the apa to look at the header for this api key in that case at the client level you need to you know basically pass in the api key and usually the you know sometimes you know api key would be in the uh as a custom claims in the jar token you have to crack open the jar token and send the api key but in this case you don't need to do that because we are using uh the no i was just you know this this this context object in itself is very interesting right um and this is how we are basically passing the access keys um and the secret key basically the short-lived credentials to the downstream uh lambda functions and also telling the lambda function which tenant it belongs to and i think um you know obviously we will look at the the code for that lambda function as well how it's applying tenant isolation eventually uh but but uh i mean as i mentioned it is really important to understand that this authorizer is playing multiple roles here and and the reason why we are choosing to generate this sts credentials instead the authorizer as usual pointed out is to take advantage of the caching behavior of the authorizer which comes by default inside api gateway but you can very well just choose to create this shortcut in your lambda function as well if you want to right so this is building sas on aws we're doing a walkthrough of the serverless sas reference architecture and i think can we perhaps have a look at how it's implemented in dynamodb with pool and silo tenants sure yeah so if we go to the aws console and uh let's pull up db so so as i mentioned earlier a little bit here uh so for the pool tenants uh what we are doing is uh you you are creating a pooled table that is a foreign service there is a table called the for product pool and the order table uh would be order pool and for the each individual tenants whereas the platinum share tenant will have a separate set of tables created for these uh individual services that is the order dash and then we know that the unique id and the product and the way we are storing this uh data in the uh in the dynamodb table is basically we use the tenant id and with this suffix and you can once we you know once we try to provision some products you will see the data here but the the important bits here is that you know you the partition key here here is is basically the tenant id with a suffix to it the suffix is a random number and the reason why we are doing that way is to avoid hard partitions um which might lead to the noise in neighbor conditions and in order to know more about this concept like now why we need to do it and how we need to do it uh i would strongly recommend to look at the blog written by amber and todd uh we'll paste that link in the chat uh so yeah another feel free to you know uh chiming here yeah and and we it's hard to see because we don't have any data in this uh table right now unfortunately maybe maybe you know um if you just post the link of the blog post in gunnar in the in the chat we have screenshot which have the actual data and the idea and the idea is that the shard id basically means you have tenant id and a business key and not just only tenant id into it because then you can run into hot partition issues because then you can then you can then you will have maybe thousands or millions of rows only only for that one tenant and there will be a short key for sure to have that primary key complete primary key in place but uh we basically are sharding by tenant and business key and and if you might have noticed that condition that we provided initially it was not string equals it was string like so so so that means anything which contains or starts with the tenant id and it could there could be another business key after that uh so there's a whole blog post which is you know something which i i recommend that um you know people go through and read through it for sure and maybe usually if you don't mind can we also pull up the data data access layer um and and and just quickly look at that what happens after you get those short lift credentials uh unless you plan to do that later i'm sure you can show it uh right here now um so let me pull up uh so if you look at the we will take an example of an order service and the application survey so yeah they want to want me to write we'll go with the product service yeah product service data access layer yeah so yes database if you just go to the get dynamodb method at the very end you'll get another table actually yeah yeah so i think um maybe just one thing i want to you know show here is if you might remember in the authorizer we were passing the secret key in the access key and and if you notice here the line number 157 to line number 161 so if you see that when we are creating the dynamodb client we are passing that access key and secret key we got from the authorizer and this is how your tenant isolation is happening by the way um so so you were generating a short-lived credentials but you you pass that sds credential to your lambda function and and your lambda function when it click it creates a dynamodb client is now applied by virtue of those shortage credentials only have access to those rows which belong to the tenant and then if you look at that else block um which basically is like if it is not a pool tent and if it's just a silo tenant we are not applying that we are not using those sjs credentials and the reason being as which were pointed out when you deploy those individual lambda functions for the tenant you are just applying uh you're just mentioning the execution role of that lambda function itself that which table it has access to because we have separate tables for those uh silo tenants so you don't really have to use shortcut credentials there you can just in the execution role of the lambda function itself say that okay this lambda function only have access to this particular table so i just wanted to point that out as well so maybe to show uh some more details maybe we should log in to the actual sas application to see what happens when when we use it and what happens in in the dynamodb tables for instance sure so let me pull up the sample sensor so yeah this is a sample sas application um so i just want to point out one challenge we design sample class application is uh whenever a user reaches uh whenever user access samples as application you need to know the tenant the user belongs to so that you can load the configuration related to that particular thing the configuration in here what you are seeing what you are talking here is basically uh you need to know which user pool the user belongs to or the tenant or user pool of that particular and also so that you can authenticate that user against that user tool and after that you need to know which api gateway url you need to send the request so there are a couple ways of doing this uh the the one approach you can take is using sub domains uh that is for example if your domain name is example.com uh you can for the ethernet you can have a difference of domain like tenant1.example.com and if the request comes from that particular sub domain you can uh forward the you know you can do the magic errors of the magic we saw in the previous episode with the amazon eks reference organization ui is exactly the same with the only difference with the only difference that we asked for the tenant name while logging in and in the eks they are using subdomain based approach maybe maybe just you know one quick caveat there or maybe just you know highlighting that fact that there are a couple of ways you can identify um or maybe pull up the configuration for that and you can either use subdomain based approach or you can just ask for an email address or something and and that's how you identify which tenant is trying to log into the system and then you can do the appropriate flow after that basically yeah so as anybody was saying we have implemented the second approach where we are asking the tenant away sometimes information now let's try to provide that information here since we have onboarded and when we are if you remember when we onboarded this particular first tenant uh uh we have given an email address and that will be configured as a tenant admin and uh let me pull up uh let me pull that credentials in here and give me a few seconds here yeah while woodwall is doing that post your questions in the chat if there's if we're not able to answer them live we also have bill in the chat who's answering questions i can see as well so go ahead but the synthetic for the first time we are logging in it is asking me to reset the password here so yeah now that i am authenticated um now you know let's try to provision some product sorry dump some dummy products so it has created the product and i can similarly i can create some order order and now by the way you can also see some data on the tables yeah so that's what yeah i might have missed that was was this the pooled or the siloed the first tenant is the pool because it's a basic tier tenant so now we can look at the table the pooled table uh and look at those that information so since it is a pooled one so since we have added a product uh it has created the product information here and then this is what we are referring to the suffix it has a not sure you guys have seen that but you can see that you click on the this is a better view i don't know yeah so we're just generating a very long tenant for now i mean it doesn't have to be that way but it just guarantees some uniqueness though and it has a suffix in the end that's the concept we were trying another was it explained in detail before so so so that and also the similar similar thing you will see in the orders table um where you you have created since we have created in the ui that will be in here so yeah that that's how you uh on you know a sample size applications you know try to show you that you know how you will do that let's do one thing here you know we'll try to log out of this particular question and try to login into the second tenant and see how it looks right now basically what you'll see is again there is um there won't be any there will be no any products and anything products or orders are created there because uh it's a different tenant and uh basically one of the point i'm trying to make here is that you will have each tenant will have its own unique experience of specification right let's have a look at that then yep and again yeah and while it's just trying to log in obviously we have separate api gateway for that tenant right so um so that's another and that's one of the reason why we are inputting the tenant name so that we can know which api gateway to call to or which which user pool to authenticate against because there's a standard user pool as well and i just want to point that all while while usual is trying to reset the password here and and one thing i also want to point out the whole concept of this tenant admin and why we provision a tenant admin as part of the tenant provisioning process because this tenant admin is now responsible for adding new users for that tenant or even managing the tenant in general so yeah um so it's a question around uh let's say around the service quotas and the 10 000 user groups is reached for pool tenants what's the workaround to onboard new pool tenants yeah so then that's where the you know we have this hybrid model um you can you can choose to have one one user pool per year if you want to you know we just had uh one user pool uh for all the basic standard and premium tier but but you can always have um you know separate user pools and and our the way the solution has been architected it it's very convenient for use you to have multiple user pools per tier and then also have one user pool possible platinum rotary tenant that would have strategy there yeah and having separate user pools means that you're able to to have well configure them each the security settings things like that for each yes exactly yeah i mean you can also have different password policies or different reset policies and etc yeah right yes wrong yeah so as a as they're saying yeah you don't have any product you don't see the products or orders uh which are uh which we created uh for the other other tenant so basically you'll have each time you have its own unique experience of the sat solutions that's what i was trying to show it here right so if you were to create something now it would then be stored in that specific tenants and dynamics okay oh yeah we can oh yeah let's let's just do that to make sure that for sure yeah that's it sure so we are approaching top of the hour so we need to start wrapping up a couple of questions this reference architecture it has a sample sas application but how much work would it be to to use the reference architecture with your own sas application how how separated is that application from the rest of the architecture yeah i mean uh the whole architecture in itself is micro service based right so so what i have seen personally you know working with multiple customers and the way they are taking advantage of this reference architecture they do one of two ways right the first way uh our customers what they're trying to do is they look at this architecture they're they they take some best practices they take those concepts that we have applied and apply them in their own way in their own architecture or the second thing what they do is they especially take out that shared services piece and the authorizer piece right because that's the i would say meat of it uh the shared services how the registration process work how the tenant management works how the user management works and the whole authorization piece where you are you know authorizing and generating it as short-lived credentials and applying dynamic policies and that that the core in the data access layer that we saw which enforces the internet isolation um so so that is what you really need from this architecture obviously there are other things like ci cd and we haven't really talked about the concept of observability which by the way we are taking taking advantage of lambda layers to generate metrics and logging as well and that allows us to centralize create separate libraries for basically uh metric management and and logging because we are making sure that the tenant context is applied when you're logging your your logs into cloudwatch or when you're generating metrics uh as well i think we can have a separate episode just on observability and yeah exactly exactly for sure right so yeah is that the the tenants table we see right there now yeah the product table and the order table uh we just provisioned so it has been made into the increasingly successfully tested right that's cool so i think uh it's time to wrap things up just a couple of minutes to go um i'll leave it up to you to to just give some last minute tips what do you think the viewers should do based on what we've just seen yeah i mean i would say feel free to jump in and try to uh onboard you know try to run this thing and load it to your account and play with it so that you can you know get your get your hands basically dirty and understand the things and take it further based on them based on your needs and yeah you you know it is a github repo and you know you can post your questions and any issues you see or anything you know feel free to suggest any ideas with you or the things which you plan to you know look for in this reference architecture yeah and please give us some feedback i mean we will be maybe prioritizing more and adding more features to this reference architecture based upon the feedback um there is uh obviously in github you can just open an issue and and just ask for a feature if you think that's that's something beneficial for you we'll be uh definitely trying to prioritize that as soon as we can and just get your hand dirty as usual mentioned the whole documentation itself i would say it's very informative even if you uh just want to understand the concept of sas if you just go through the documentation itself it will be very informative and enlightening for you i would say very cool so i think this hour just uh several hours more going through this reference architecture but i'm very happy to have have you both on and to walk us through the reference architecture i hope the the viewers enjoyed it as well and that they got uh at least a glimpse of what the reference architecture can do so don't miss the show in two weeks we are on every other wednesday so the next episode let me just get that up uh so the next next episode is on trying to find the date september 8th and where we will be talking about aws private link for sas and how to deliver sas through aws private very interesting topic yeah it is so once again thanks on about thanks val thanks everyone for watching and i hope to see you again in two weeks [Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] you

Channel: Gunnar Grosch

Views: 1,024

Keywords:

Id: CVMXYcqJI40

Length: 60min 4sec (3604 seconds)

Published: Wed Aug 25 2021