Located in Berlin, Germany, movinary offers a cloud-hosted, online platform that enables customers to create videos from their photos and embellish them with text. Using these videos, customers can tell unique, personal stories about special events like weddings, holidays, and birthdays. Each video can be downloaded immediately, so customers can place orders immediately after the video is created.
Founder and CEO Maximilian Modl says, “While classical video tools are very complex, movinary is based on state-of-the-art usability guidelines. The creation process is completely intuitive.”
Initially, movinary faced business challenges similar to those of many online services. They wanted to set up a scalable business model with the potential to serve a worldwide audience. This model required easy server setup for their e-commerce site (a complex scaling Magento system) and high CPU power for the video rendering process.
Before adopting AWS, the movinary team researched comparisons of on-premises options and cloud hosting. “We wanted to make our service as fast and efficient as possible to compete with similar services,” Modl says. “It was clear that we would need the cloud.”
Why Amazon Web Services
The movinary team chose to work with Amazon Web Services (AWS) from the outset. They needed:
Fluency in common web technologies
Abundant CPU power
The flexibility to expand globally
Security, privacy, and ease of setup were also important considerations. Modl says, “With AWS, we can deliver a service that lets customers store all their personal videos and pictures safely. AWS also met our needs for an easy server setup. Connecting with Amazon Relational Database Service (Amazon RDS), configuring the Amazon Elastic Load Balancing, and the scaling mechanism all fit perfectly with our internal IT mantra: start small, scale fast.”
The handling of the personalized video rendering was a bit more complicated. Rendering requires a great deal of CPU power and must be as fast as possible.
For movinary, AWS held an important advantage over other cloud solutions: the use of common web technologies like PHP, MySQL, Adobe AIR, and Apache web servers. Those technologies are essential to their platform. It also delivered the power that the CPU needed.
“In terms of a scaling service, the Amazon Elastic Load Balancer is easy to use with predefined metrics, such as CPU usage,” Modl says. “If the load balancer fails, the scaling can still be done by non-professionals. That allows us to plan marketing campaigns with high traffic expectations without impacting the web development team.
“Amazon Elastic Compute Cloud (Amazon EC2) Reserved Instances for handling normal traffic and traffic peaks really well,” Modl continues. On average, movinary sees about 3,000 visits a day. During peak times (such as during marketing launches), up to 20,000 users have been creating videos simultaneously on movinary.
The use of Windows instances with the CPU power they needed worked well with their personalized video rendering engine. “Our developers have full control of the servers via Secure Shell (SSH),” Modl says. “The existing infrastructure and services are easy to use, so a setup with predefined images takes only a short time.”
The movinary team uses Git to deploy their code to the web server. The team created a base image of a Linux server to run as an Apache web server. In the boot process of an instance, every change made from the Git repository is pulled automatically. If everything is synchronized, the server accepts HTTP requests, which enable the server to be available for the Elastic Load Balancer. If the server is running, the repository is polled automatically every five minutes to receive changes in the code.
The movinary service uses many AWS products, as shown in the following architectural diagram.
The movinary team is using three Amazon EC2 instances: one for the team’s cloud renderer, one for their web server, and one for a database. The cloud renderer starts one instance for each render request and shuts down an instance if no further render requests are in the queue. The movinary web server scales automatically, measured by means of the latency and the database scales with read replicas, which works well for web shops where far more read requests than write requests are executed. Currently, movinary is storing 67 GB of images, PDFs and videos in the Amazon Simple Storage Service (Amazon S3) for the user videos, images and video templates.
More information about how the movinary team used the AWS services follows.
Amazon CloudWatch is used for scaling web instances and sending notifications via email if the service is not accessible.
Amazon RDS is used for online shop information.
The movinary cloud renderer engine (a service which creates an individual video from photos and templates, rendered in the cloud) runs on Windows machines and the renderer itself is written in Flash.
Magento is used both for the movinary web site and as the e-commerce system (the shopping application)—which requires PHP and MySQL to run in the company’s infrastructure (Amazon EC2 and Amazon RDS).
GWT is used to create a seamless experience on the video creation process.
Varnish Cache is used to cache the site and deliver a responsive web service to customers.
An Apache Tomcat server is used to accept and monitor requests to our cloud renderer.
Adobe AIR and Avidemux are used to render customers’ videos on the back end.
Using AWS enabled the movinary team to move into production quickly. “We started on local machines and were surprised by how effortlessly we could bring our service to the AWS Cloud technology,” Modl says. “In particular, the predefined Amazon Machine Images (AMIs) and the Elastic Load Balancer helped us to get from local to production within a month.”
The team also improved performance with Amazon EC2. “Our video personalization back end requires a lot of performance,” Modl says, “and we were pleased to find that the m1-medium instances perfectly matched our CPU performance and RAM needs. Being able to increase the amount of disk space for our instance with two clicks saves a lot of time.”
Regarding Amazon RDS, Modl says, “AWS manages backups and updates. It also scales the infrastructure semi-automatically. Our system generates much more read requests than write requests, which is supported by the scaling offered by Amazon RDS.”
Hosting their service on the cloud proved to be more cost-effective because it allowed movinary to dynamically change allocated instances. The structure enables a highly customizable solution on a scalable infrastructure.
The movinary team is currently evaluating Amazon RDS and Amazon ElastiCache, and may use Amazon Simple Queue Service (Amazon SQS) for handling their rendering queue.
For other developers considering using AWS, movinary recommends starting with auto scaling based on CPU usage. “After collecting additional metrics, one can improve the scaling by selecting other measurement and scaling techniques,” says Modl. The team needed a little rework for setting up Amazon EC2 instances. There are many preconfigured images available.
The team also discovered that, for setting up Amazon EC2 instances, there are many preconfigured images available, which, for them, only needed a little rework.
According to Modl, the decision to use AWS was right from the start. "There are no comparisons to what AWS is able to offer."