AWS Case Study: KineticGlue
Hi Srinivas, briefly tell us about your business.
In 2008, KineticGlue was founded by Vivek Paul and Meeta Malhotra. We’re based in the Silicon Valley of India, Bangalore.
KineticGlue’s next-generation collaboration platform combines the power of social networks with document management, project management, and knowledge management features in a smart and easy-to-use web-based application.
We offer an instant, secure, social network that is exclusive to your company or team. It combines people management, document management and project management and quite simply ― helps you work faster and smarter. You get a single secure site on the cloud that meets all your collaboration needs, has customizable access controls and offers integration with existing applications.
How have you incorporated AWS as part of your architecture?
We use AWS to host and provide KineticGlue services to its clients. We use EC-2 instances for our Web servers, DB servers, search servers, and mail servers as well as for other services that are required as a part of our solution. EBS and S3 are used for storage of data and files.
Please describe what you were using for your infrastructure prior to using AWS technology.
KineticGlue was on GoGrid prior to the move to Amazon AWS. Now, all services required for providing our solution to our customers are on AWS.
Why did you decide to use AWS?
The scalability and reliability factors were a huge point in our consideration. We evaluated almost all of the cloud providers and chose AWS as it was easy to setup and scale. More importantly, it offers a start-up the luxury of stretching the money longer by deploying smaller instances to start with.
The programmatic interface for auto-scaling was another factor.
Have you learned any valuable lessons during the AWS development process that you’d like to pass on?
There have been some challenges. For example, I cannot access a deployed EBS store from another instance of EC-2. This implies that I would have to have a thorough architectural plan before instantiating servers and storage.
Choose Elastic IPs as the general pool has IPs that could be blacklisted. Especially if you are using a mailer to send mails to your customers.
It also is a test bed for validation of pilots. Just instantiate a server, test your pilot and bring it down. No fussy hardware requirements and can be done round the clock from anywhere!
Buy decisions (servers) are super-fast. No indents, invoices, wait times, shipping, configuration, hardening and the whole shebang of things that is the ‘Virtue’ of a ‘Real’ server.
Do you have any future plans to incorporate other AWS solutions?
Our plan is to move to RDS in the near future
Do you have anything else to share about AWS?
It really is hosting for dummies. No brainer really. You just create an account, choose a plan, instantiate servers and you are all set. The fact that you can create AMIs and store them really creates a compelling proposition to use AWS. It just cuts the time required for deployment of new servers significantly.
More importantly, it just does its job. Very well, without failure!
To learn more, visit http://www.kineticglue.com/site/ 
.
Added February 7, 2012
Security Whitepaper
Learn about our physical and operational security processes for network infrastructure.
View Whitepaper (pdf)
AWS Customer News
©2013, Amazon Web Services, Inc. or its affiliates. All rights reserved.
