Hello out there, I want to say thank you if you have been tuning into my introduction to Amazon services blog series. We are now on part 3 of our topic of AWS, and this week we will be diving into application services through Amazon. Typically when we think of building applications, you start with an idea and a whiteboard, and start putting it to work through a code editor, then compiling and using the final build. While similar, what if there was another way? A cloud way? Well, let’s get started by breaking down some workflow concepts.
AWS Step Functions (SF): Step functions, in a nutshell, make it easy to coordinate the components of distributed applications and micro-services using a visual workflow. Giving an example, you may want a second function to always follow the first function, and only run when the first succeeds, or even run two functions in parallel. The glory here is you define your application logic and flow, visually, as a series of steps.
Amazons Simple Workflow Service (SWF): While very similar to step functions, Simple workflow concentrates more on coordination through a business model as a whole. This comes into play down the road after you have started your application with simple Step Functions.
Amazons Simple Notification Service (SNS): A flexible and fully manageable messaging service used to collaborate data flow. What that means is you can create a topic, via a problem, workaround, or solution, etc, and users can subscribe to that topic to keep in the loop about the topic. Recently integrated is push messaging for mobile platforms.
Amazons Simple Queue Service (SQS): While this one may sound like SNS above, it holds the potential to be very powerful, let me explain. This is a fully managed queuing system, that makes it easy to decouple your applications from prompt. What this means is it allows messages to build up in a queue, until the processing server can catch up and process the data.
Let’s take a look at an example where we can decouple an application from its demands. If you tuned into my previous AWS blogs, these things should start coming together.
So here we have an application, using auto-scaling of EC2 instances, running on a process server. As the user interacts with the application, information on their interactivity comes through as a demand, and as we discussed before, auto-scaling handles increased demands by creating new instances. Like horizontal scaling, vertical scaling handles data spikes the same but by always leaving an instance open / or your program running. Now to handle the spike in usage Amazon stores the requests in a queue until they are properly managed and distributed to elastic cache load balancing. Here is where SQS shows just how tough it is, by allowing smooth processing of high demand in requests. What this means is we have successfully decoupled our demand from our application. This is amazing since our application and data management are handled separately, making the process quick and in-disruptive. But Jared, What if our instances are unhealthy and can’t perform the needed tasks? Well, we can simply set up a cloud watch metric, which will alert us with an SNS notification, stating that we need to investigate the back-flow and fix our instances.
While this is just a small example, we can kind of get an insight into how these services work together, to help you manage your application. This may all be daunting at first, but the services offered by AWS, work together, and help to alert messages on damages, overload capacity, and resources. I hope you enjoyed the read, stay tuned for Analytics and Machine learning as part 4. Thank You.
