Episode 80
As mentioned in the previous Episode, about messaging on AWS, today we are going to look into the application services group. Not so long ago, the group consisted of messaging stuff too, but it was split into two as the number of services grew.
The group name is an umbrella term for services designed to work closely with web applications hosted on AWS or elsewhere. It’s not very precise, since basically all AWS services can be used from web applications via rest api, SDK or even CLI, but let’s live with that. Without further ado, let’s have a look at Simple Workflow Service, Elastic Transcoder, API Gateway and Step Functions.
Simple Workflow Service
AWS SWF is a task coordinator and state tracker, suitable for running long and multi-part workflows with parallel or sequential steps. The acronym is deceiving, since it doesn’t follow typical naming pattern, where we would expect it to be called SWS, from Simple Workflow Service, but comes from Simple WorkFlow Service. Important notions we operate on here are: Workflows, Domains, Actors, and Tasks. Workflow is a group of activities to be performed in a coordinated manner by Actors. Domain is a collection of Workflows under single AWS account. Workflows from different domain can’t interact with each other. Actors are applications, processes or Lambda functions that perform various Tasks within a workflow.
There are three types of Actors: Starter, Decider and Worker. Starters are an entry point for the entire undertaking, for example they might act upon the event of client purchasing book from online store. Deciders schedule Tasks for Workers, evaluate conditions, prepare input data, react to events during the flow and asses the result. Workers are computer processes or threads that performs Tasks. Tasks categories consist of Activity Task – an independent action to be performed, Lambda Task – the same but run on Lambda and Decision Task, that carry the current workflow status and communicate with Deciders. Task are organized in lists. Possible outcomes from the Workflow execution are: completed, canceled, failed and timed-out. The workflow duration can be as long as one year.
Elastic Transcoder
AWS Elastic Transcoder is a managed media transcoding service. As with many other services, like RDS, we can choose to use out of the box functionality for particular problem, instead of launching our own EC2 instance with a custom application that will do the same job, but has to be maintained, configured, scaled, taken care of and might sit idle if there is nothing to do while the money clock is ticking. Elastic Transcoder performs media file conversion and is charged per processing time used, similarly as Lambda function. The service components are: Pipelines, Jobs and Presets. Pipeline is a queue for organizing Jobs. It has an input S3 bucket to take files from and output S3 bucket to put converted files in. We can have several pipelines with different priorities if needed. Job is a single file conversion process according to specified Presets. Preset is a template that dictates the output file format, resolution, audio settings, closed captions options etc. Currently Elastic Transcoder is supported in 8 regions.
API Gateway
AWS API Gateway is a API management tool. I wrote about those in detail in Episode 47, mainly focusing on Apigee Edge and WSO2 API Manager and only mentioning AWS product existence. Also, back then I was doing research for infrastructure that sat on Google Cloud, but if we have our stuff in AWS, it might be a good idea to use AWS API Gateway instead of competing products, as it is well integrated with the platform. The service provides another layer of security on top of HTTP endpoints belonging to our web applications and can simplify development by removing the need to deal with authorization on our own. It provides insight into statistics, monitoring, resiliency against sudden traffic spikes, usage quotas and lifecycle management. A nice feature from the developer point of view is possibility to define endpoint stubs that will answer with predefined mock responses, which lets us quickly agree on API contract and allow many teams to integrate without the need to wait for an actual backend implementations. We can setup multiple environments, called stages and use stage variables in configuration to be more flexible and less error-prone.
Step Functions
AWS Step Functions is a new toy in the cloud arsenal, introduced in December 2016 at the re:invent conference. It is a tool for organizing interactions between system components, be it microservices or Lambda functions. Or, if you will, a managed state machine. It’s not suitable for batch jobs, where AWS Batch should be used, however it seems that it is meant as a more flexible replacement for SWF. Step Functions is also designed with support for microservices architecture in mind, as well as (or maybe primarily) as a part of serverless computing platform, to orchestrate Lambda functions. It offers visual aids to track component interactions, which might be helpful, and it sort of takes part of applications business logic out of the code and puts into the configuration files, backed up with visual block-building style tool.
Every stick has two ends, from one point of view it might speed up development and let changes to the flow be introduced almost instantly. On the other hand, it binds you to the vendor and the platform very hard. Think of it – if the service goes down (like S3 did massively in February), or even if your internet connection goes down, you are screwed, you can’t develop anymore. If you had business logic in the code, you could just run your application locally with local database and other stuff. Not that the serverless idea is bad, in some use cases it’s great, but I’m kinda skeptical of taking software development to this level, especially while tooling around it is still immature. In my opinion, real programmers write code, not drag boxes in diagrams :P Perhaps I’m getting old though…
Achievement unlocked!
That’s about it regarding AWS application services. This episode is a bit special to me, since this is the 53th of articles published consecutively each week, starting July 28th 2016. It means, that I managed to write one article per week for a year now. Ok, I’m cheating, one article was written by Kate, but I still did a foreword, found pictures and fight with WordPress to get it together. Now it’s probably time to slow down and take a little break. The next episode will appear in August though, stay tuned!
Image sources:
How To Train Your Java 
One response to “Amazon Application Services”