Headquartered in Silicon Valley, Gupshup is the world’s most advanced bot and messaging platform. It enables developers to quickly and easily build, test, deploy and manage chatbots across all messaging channels.
Gupshup has been a pioneer in messaging and bots, long before they became trendy. Gupshup’s messaging platform is used by over 30,000 businesses, leading companies such as Flipkart, OLA, Facebook, Twitter, ICICI, HDFC and Zee TV.
Gupshup’s platform handles over 4 billion messages per month and over 150 billion cumulative. Gupshup also developed a smart-messaging app, Teamchat, which introduced patent-pending “smart” messages in 2014, only now being offered by other messaging apps. Gupshup’s bot platform provides tools for the entire bot lifecycle enabling developers to quickly and easily build, test, deploy, monitor and track bots.
Gupshup’s working on the IDE which will be useful for the user who came to Gupshup’s platform for creating the bot. The idea behind giving this IDE to user is to check the bot on the UI itself if things are working as expected or not. With the Help of this IDE user can debug the code and work on the solution to get the bot working.
1. The real challenge while designing this project is how we can secure the user data?
2. How can we separate the IDE for each user?
3. How long we will store the data once the user is registered and starts using IDE?
4. How to manage the high availability of IDE?
5. How to manage the scale?
6. How each user can identify his/her own IDE?
7. Which platform to use?
8. How to authenticate the user?
And the list goes on… This time Techpartner came into the picture to figure out the way and to design, implement and manage the solution.
Techpartner team worked with tech lead and project management team to understand the project needs. Together we chalked down the plan and finalise the architecture. Our more focus was to utilize the more open source tools and achieve the required output.
Since every user is going work on its own IDE. Techpartner proposed to go with microservice level approach using one docker container for every new IDE. For authorisation, we didn’t want to maintain another authentication tool so we integrated it with Git & Facebook to support SSO. For container orchestration, we use Mesosphere to support the scale and faster rollout.
For data storage, we use AWS EFS service so that data on the EFS available across all the running node which is the basic need of application when scaling in/out.
Containers were created runtime every time users try to use IDE. They are kept running still user session is alive. Data is continuously synced to the local repository in case there are any code changes in user-defined bot using IDE.
Auto Scaling feature is configured for scale as well as for high availability so that at if any EC2 instance holding container goes down auto-scaling feature will launch the instance again and put it behind the Load balancer and then mesosphere will take it from there for container orchestration. This is fully automated and self-healing architecture designed for the Gupshup bot.
SECURITY BEST PRACTICES
Since it was flat subnet architecture as each container which is created and destroyed at runtime need to be available over the internet to the user so that they can work on the respective IDE. To keep the data on each IDE secure from other IDE running for another user data security is a must. We achieve this by using several.
● Even though it is flat subnet we kept the ALB in public subnet and all other containers and mesosphere under private subnet so that access to application is only via Load balancer.
● Except for docker image nothing is stored on the EC2 instance.
● Data constantly push to user repository to maintain consistency.
● EFS is configured to store all temporary data which can be used across all the EC2 instances running containers.
● Cloud Formation template is used to set up the entire infrastructure.
● For all new application deployment, we are following Blue-Green deployment practice. (This helps us to migrate the running IDE containers seamlessly)
● Except port 443 for web, nothing is publically open.
● Scalable Architecture: With the scalable architecture Gupshup was able to serve the user with improved response time which in turns helped to acquire more users.
● Performance: As the application became modular the whole CI/CD process became easy and efficient.
● Automation: Automation reduced the manual deployment time by 90% giving free hand to the developer to concentrate on innovation.
For the success of the project, Techpartner used below AWS services.
● Amazon EC2 was used for computing with a combination of on-demand and reserved instance. The instance was configured to spin up automatically during load.
● Amazon S3 was used to store mainly for the images which need to be accessible across the instance.
● AWS NAT Gateway Service was used to provide the Internet to systems in private subnet during patch management.
● AWS CloudWatch was used to monitor to the instance performance.
● AWS CloudTrail was used to keep track of the activity across the AWS Environment.
● AWS CloudFormation was used to templatize the infrastructure footprint.
● AWS Inspector was used to check application and OS security and apply fixes as recommended and ensure consistency.
● AWS Config was used to track changes for AWS resources and also to alert with resources that are not compliant as per defined rules.
● AWS Identity and Access Management (IAM) was used to provide AWS resources access as per the company’s policy. Also wherever possible, IAM roles were used to provide access to AWS resources as per IAM’s best practices.