While we develop many amazing and creative projects at our company, we are working with clients from around the world, providing an outsourcing service as one of many. There are a lot of benefits that our employees get from that kind of cooperation, but besides that, we as a company can gather the knowledge brought back from those contracts and keep up to date with technologies and solutions used around the world.
Following new trends is important when it comes to the programming world, but checking how they perform on a live example is a really valuable experience. Gathering that kind of information helps us with our business decisions and allows us to reduce unnecessary costs.
Like most people, I am a fan of free solutions and those are the developer’s first choice when implementing a new feature. While designing, for example, login, message, event, or storage service we always struggle with the decision:
– use something ready and free, but limited
– write the necessary functionalities ourselves
– use a configurable, paid service
If the free package will fulfill our needs, then it’s an obvious choice. If available packages slightly miss our requirements, we always consider writing the solution ourselves or enhancing the free functionality.
The third option pretty much always comes as a last resort. However, it seems that this doesn’t have to be always the worst choice from the business point of view. I had the possibility to work on a few of the AWS services recently and as I hate everything that is configured by a panel, this was not so bad experience.
Besides Simple Queue Service and Simple Notification Service (which have pretty much self-explanatory names and work great by the way), the first feature that felt useful and advanced was Lambda Functions. This functionality creates a machine on the fly and runs your code only for a period of time that you need it to. It can be scheduled or invoked from many different services provided by AWS. Why keep a whole server online while you only need to process some data from time to time? This was a handy tool for scheduled tasks that updated database data asynchronously.
S3 bucket is a great place for keeping your application files and provides many features to do it efficiently. Cognito will provide you a way to handle logins and social media integration. I have worked on integrating a few of those services into the code and I need to say this was a piece of cake. I can only complain about the outdated documentation, but looking into the AWS code always resolved my issues. Every service can be configured with just a few lines of code, but only after integrating with Elastic Transcoder, I realized how good those AWS tools are.
Not knowing anything about this, in only a week I have implemented the asynchronous video transcoder which transcodes any video from an app to 4 different formats, creates a thumbnail for it, and does this without any file transfer on the app side. Simply gather requests in a SQS queue and invoke a lambda for scheduling a transcoding job for each message. Then, once done, the transcoder sends a message to the SNS topic which invokes another lambda that handles the result. This means we have ended with an event-driven feature with only a few files with code.
You may think that this must cost a fortune since I have used so many AWS features. That is fortunately not the case, since most of those services are paid per usage, so you only pay a few cents for those 7 minutes of your lambda running and another few cents for a transcode job. Also if none of your users upload a video, it is possible that you will not pay a thing. Of course, the payment plan will differ per your needs and features that you will use, however from my experience it is possible to get complex features running for a really low price and if you pay more, then it only means that your app has users and sells well.
I don’t want to judge if the AWS services are good or bad or if you should use them or not. This is all requirement specific, however, let’s remember that a paid service does not always have to be considered as last. Those solutions can sometimes be better even if the feature that we are building is really small and seems not to deserve to be handled by a paid service.
