AWS Adria 2017 Conference
Our team of two engineers, a senior backend developer and a system administrator, attended the first ever AWS conference in Croatia, which was held on Oct 27 & 28. On the first day the talks took place in Opatija, and on the second in Rijeka. However, the team only participated in the first day since they had to rush to a very important Dream Implementation event: Casual Friday.
The conference had some interesting talks, such as AWS success stories about businesses profiting from migrating to AWS to business process automation, including how to offload heavy load from one’s own infrastructure to AWS services, how to save money and cool things like zero-downtime failovers.
The most popular topic and buzzword was — “serverless”.
What is “Serverless Architecture” you may ask? Serverless architectures “refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”), the best known vendor host of which currently is AWS Lambda”. By using these ideas, and by moving much of the behavior to the front end, such architectures remove the need for the traditional ‘always on’ server system sitting behind an application. Depending on the circumstances, such systems can significantly reduce operational cost and complexity at the cost of vendor dependencies.
This got us thinking…what can we change in our own architecture? Are we already on the right track? Well, one of our primary projects, Saybubble, already uses a great deal of Amazon Web Services and it is an ideal project to learn new things.
We have already achieved the “part-serverless” status by using AWS Lambda service for executing the task of encoding video files to streaming format for easier use and playback of videos in our mobile apps.
Currently we are working on replacing image and video processing instances with lambda functions. The upload to the server will also be replaced with direct upload from the mobile application to AWS S3 bucket.
Direct upload from a mobile device to a bucket will remove unnecessary traffic from the server. With bucket triggers we can invoke a lambda function that will process the uploaded media file, and after processing, the SNS service will alert our API server that the media is ready for the user (video is transcoded for streaming, images resized, thumbnails created, etc.).
Offloading the server in this way would have several major benefits: we will no longer have need for video or image upload and processing instances. Furthermore, such AWS services are highly scalable and also allow for a pay-as-you-go payment option, which means you only pay for the services you use.
Key components of our AWS infrastructure:
- Amazon Lambda — serverless code execution on demand. Supported languages: Node.js, Java, C# and Python.
- Simple Notification Service — for sending notifications (media uploaded, video transcoded, etc.)
- Amazon Cognito — collects a user’s profile attributes into directories called user pools that a mobile app or web app uses to configure limited access to AWS resources.
- Security Token service — generates temporary, limited-privilege credentials
So why haven’t we done it before? Until now temporary security credentials didn’t exist. With temporary security credentials we can allow all application users direct upload to the bucket without storing AWS credentials in the mobile application. For security reasons, mobile application users are able to upload media only to a specific location in the bucket.
The main reason for using AWS infrastructure was offloading our EC2 instances. With AWS Lambda we hope to achieve high scalability and availability without managing the infrastructure at a low cost.