Think Different: Micro Services Best Practices

We are using monolithic of single code-based application for long. From when client-server solutions have been evolved. And it continues on internet solutions era as well.

But the monolithic architecture of a big application has many difficulties as well. Most importantly for deployment and scalability. As it is tightly coupled with all the modules.

Therefore the new way of application architecture evolved microservice architecture. Where the whole problem is divided into several small parts. Each part solves a small set of problem or implementations. And then comes this architecture’s complexities as well. Like how one microservice will talk to another microservice and so.

Who are interested and .Net developer and architect can download open source microservices containers with whole application here https://github.com/dotnet-architecture/eShopOnContainers

I am trying to describing microservices architecture best practices with a small example. Which will help the beginner as well as for architect and senior developers who are familiar with monolithic development so far.

Eg. Requirements
There are three entities involve in the functional flow of the application The platform owner The Resellers (who will be subscribing into the platform)The End users who will be registering with the reseller (according to their choice) to use those utilities. Many utility applications will be available (added by the platform owner) on a platform for the resellers to subscribe in SAAS model. That means the platform will be providing those utility applications to the resellers who will be registering there and choose among those utility apps that they want to sell to their users (End users). The resellers can add or remove any number of utilities from the platform according to their wish, and they will be charged (by the platform owner) accordingly. The number of utility application available in the platform is also dynamic, the platform owner can add more and more application into the platform. Once the reseller completes his subscriptions by choosing the required utility applications, the platform owner will provide customised web and mobile application for each reseller which will be used by the users(End users)under that reseller. Those web and mobile applications will be consuming the utility application functionality in SAAS model (REST API) from the platform. Once the reseller gets his web and mobile application from the platform owner, he will start marketing to acquire users (End users) for his applications. Those end users will eventually be using those utility applications by making payments. Their payments will directly come to the platform owners account and the platform owner will disburse the applicable amount to the corresponding reseller. There will also be an online chat system where all the end users under any reseller can chat within themselves. There will also be a Chat bot for customer care support for the end users. Please note that the platform will also consume APIs from different third-party service providers like Payment gateways, Social media etc.

So we will design a suitable architecture keeping AWS as the Cloud platform to make sure that if the number of users grows considerably then also the End users don’t face any issue with using those utility applications. The architecture should be able to handle any number of concurrent requests from the End users across the resellers.

Primary Solution Idea

There are multiple aspects that need to be taken care of, and a variety of options for deploying SaaS solutions on AWS. But I shall try to describe here which will be most cost-effective yet provide performance, security and future scalability.
The decision to pick a particular AWS deployment model depends on multiple criteria, including:
Level of segregation across tenants and deployments
Application scalability aspects across tenant-specific stacks
Level of tenant-specific application customizations
Cost of deployment
Operations and management efforts
End-tenant metering and billing aspects
Security and Networking (Tenant Isolation Modeling)

The first step in any multi-tenant system design is to define a strategy to keep the tenants secure and isolated from one another. This may include security considerations such as defining segregation at the network/storage layer, encrypting data at rest or in transit, managing keys and certificates safely, and even managing application-level security constructs.

Identity Management, User Authentication, and Authorization It’s important to decide on the strategy for authenticating and authorizing users to manage both the AWS services and the SaaS application itself eg. Different level IAM.
Depending on your requirements, AWS Elastic Beanstalk and AWS OpsWorks can also help with quick deployments and automation.
Based on our requirement we will choose one model
Tenant Isolation at the Amazon VPC Layer In this model, all the tenant solution deployments are in the same AWS account, but the level of separation is at the VPC layer. For every tenant deployment, there’s a separate VPC, which provides logical separation between tenants.
It too has some pros and cons.
Most importantly Everything is in a single account, so this model is easier to manage than a multi-account setup. There’s appropriate isolation between different tenants because each one lives in a different VPC.

Amazon VPC-related limits will have to be closely monitored, both from an overall account perspective and from each tenant’s VPC perspective.
But my preferred model is following now. I want to use Tenant Isolation at the Application Layer This model represents a major shift from the earlier discussed models; now the application or solution deployment is shared across different tenants.

For this solutions, if we take a typical 3-tier application with shared web and application layers, there can be some subtle variations at the database layer (which, for example, could be either Amazon RDS or a database on an Amazon EC2 instance):
Separate databases: Each tenant will have a different database for maximum isolation. To enable the application layers to pick up the right database upon each tenant’s request, you will need to maintain metadata in a separate store (such as Amazon DynamoDB) where mapping of a tenant to its database is managed.
To implement this model successfully, consider the following important aspects: Oftentimes, different tenants have their own specific needs for certain features or customizations:
Try to group tenants according to their requirements; tenants with similar needs should be put on the same deployment. Try to build the most asked for features in the core platform or application itself, and avoid customizations at the tenant level for long-term maintainability.
Use role-based and fine-grained access controls to enable access to limit a tenant’s access across the entire stack.
Onboarding

Identity management

Tenant management

Tenant registration & authentication
Application services
A multitenant process
Single tenant master DynamoDB for partition key and related data
Multitenant authentication pool table in DynamoDB

Add security token to verify partitioning in DynamoDB
Isolating Tenant data

tenant access
inject tenant identifier

verify tenant access
Configure policies
restrict tenant access
edit existing policies
key condition
Map tole to policies

Cognito role management
tenant admin/user mapping
scoped credentials
deploy

register a tenant
authenticate new user
Mapping tenant toles to policies
Temporary credentials
Example microservice [not directly related to this but I have created before] So how it will be for each microservices