fotograf.de

CASE STUDY

INDUSTRY

CMS & eCommerce

CUSTOMER SINCE

April 2019

LOCATION

Berlin, Germany

USE CASE

Improve the performance
by detecting bottlenecks,
root cause analysis of the issues
in distributed architecture


fotograf.de-logo

 

three_steps_de_small

FOTOGRAF.DE INTRODUCTION

fotograf.de (GotPhoto) is software for digitalization of school and high-volume photography. It makes the lives of photographers easier and more efficient with its online solution for volume photographers. In 2013 fotograf.de started running an online sales system targeting wedding, event, studio and school photographers in a small office in Kreuzberg, Berlin. Eventually, they extended their market focus to enterprise and SMB customers in school & preschool photography. As their team expanded to over 50 employees, fotograf.de became the market leader in Europe and opened an office in the United States.


THE CHOICE FOR AWS SERVERLESS

fotograf.de’s efficient system enables its customers who are mainly photographers to operate with ease because the platform is fully built on AWS. It relies on AWS cloud services for several reasons. Scalability is the biggest reason but not the only one. Ease of use to host a SaaS application, having the flexibility to select any database or web application platform, paying for only what you use pricing model and security are the other reasons why fotograf.de chose AWS.

Ivan Toth, a Senior Software Developer at fotograf.de, expresses the reason why they chose AWS cloud services in his own words. “We do not have enough manpower to deal with DevOps. It’s so much easier with AWS cloud services. We did have some dedicated servers before but now it’s much easier.”

fotograf.de uses Amazon EC2, Amazon S3 buckets, Amazon RDS for databases, AWS Elastic Beanstalk for deployment, Amazon API Gateway, Amazon SNS, Amazon SQS, Amazon DynamoDB, and AWS Lambda services. After facing scalability issues they decided to go serverless on AWS. At the moment serverless is only a part of the system; the rest of the main system is still a PHP system running on Amazon EC2.

In fotograf.de they process images on the upload of an image, and they process images for the orders of the customers’ selected products. They also have a QR recognition on the upload of an image. Before going serverless, they had Amazon EC2 instances which took the brunt of the load. When the load jumped very high, the Amazon EC2 Load Balancer would create another instance to meet it; however this took some time of course. Consequently, during the peak times it was not easy to scale up or down because as soon as Amazon EC2 Load Balancer scaled up the traffic would go down or vice versa. This is where AWS Lambda helped fotograf.de to scale smoothly.

fotograf.de


WHY THUNDRA?

Switching to AWS Lambda was the right choice for fotograf.de, but they faced some problems discovering the root cause of errors and bottlenecks. They also had difficulties responding to the problems of a specific customer because it’s hard to filter invocations of this customer. Thundra helped fotograf.de gain the visibility required through their serverless architecture. Ivan Toth says, “It brought us much more insight into errors happening and tracking them down which we were missing for some years now. The tagging feature is awesome as it brings us the ability to track issues based specifically per customer.”

On the staging account, the AWS Lambda functions only get invoked a couple of times a day. That is not problematic because everything can be found among a trace of logs in Amazon CloudWatch manually. But when it comes to the production account, the AWS Lambda functions are invoked frequently. At that point, it is no longer straightforward to filter the logs manually.  fotograf.de needed an automated way to explore the logs. Thundra came to the rescue by providing an automated way of gathering and classifying the logs by function name, project, log level, and more.

Additionally, it was very important for fotograf.de to find out what exactly happened when the image upload failed for one photographer of a photo. They wanted to be able to search with a photo ID or photographer ID to see exactly what happened and resolve the error. Also, they did not have a clear picture of errors and edge cases. Although they were aware that the errors on the edge cases were happening, they were not sure of the frequency compared to the normal invocations.

Ivan continues: “We heard about Thundra in AWS Berlin Summit 2019. My colleague met your team there. We had a need for something like this for a while and I was thinking to implement our own solution even though I was aware of the fact that it would take so much time and effort. After we implemented Thundra we observed a significant increase in our system’s overall health and decrease in the average duration of the AWS Lambda functions. At the same time, the average cost of the AWS Lambda functions decreased.” See the example below of the improvement achieved through the Thundra Console. Errors were decreased by 82%, and the cost was reduced by 55% with the help provided by Thundra.

image1

Thundra’s unique tag support is one of the features that fotograf.de values the most. They tag the AWS Lambda functions’ invocations with the photo ID and the photographer ID. This enables them to specifically search for the invocation they want to examine and focus on. Now, with Thundra, discovering errors on the edge cases and timeouts is much easier. Based on the information Thundra provides, fotograf.de was able to implement improvements to fix several bugs already and will continue Thundra as the default tool of software development, testing, and monitoring.