Dear DevOps Abby

PaaS, scheduled tasks for ECS, and containerizing your services.

In this week’s “Dear AWS Abby”, I’m answering a few more user questions!  Got a question you’d like to see me answer?  Let me know on Twitter with #askawsabby



“What’s my best bet among AWS services if I just want a “pure” PaaS (i.e. take my app or service and run it a la Heroku/Pivotal/App Engine). Let’s pretend we don’t want to don’t want to know/care about the underlying infrastructure. #askawsabby”@satxsam

Depending on how you want to structure things, I’d go with Lambda or Fargate.  With both of these, you focus only on your unit of work:  a function or a container.  You don’t need to touch the underlying EC2 infrastructure at all.  With Lambda, you can execute your function in response to events, for example, trigger a Lambda function to send an email every time a new customer is added to a table in DynamoDB.  With Fargate, you can run any containerized application:  you just pass a Task Definition, and Fargate handles the rest.

Alternatively, if you were looking for a simplified experience, you could go with Lightsail.  This provides a simplified AWS experience that allows you to easily deploy from a template, like a WordPress site.  You can also connect to other AWS services.

“@abbyfuller Hey Abby! Do you know when scheduled tasks for #ECS #Fargate will be available? Would be really nice to have #aws”@bitbrain_

Good news!  You can already run scheduled tasks for ECS!  Couple of different ways to do this:  the most common way is through the service scheduler, this means you create a service, register a Task Definition, and give it a desired count, and then the service scheduler keeps it running.  This is most useful for long-running jobs.  You can also either a) manually run a task with RunTask (for example, in response to an event), or b) you can schedule a task with a cron-like expression (for example, run this task every day at 2am), or c) implement a custom scheduler with StartTask.  You can find out more about all of these options here.  If reference architectures are more your speed, you can find one here.


“Would love to see an ECS or Fargate post for those of us starting at ground zero, who are not using containers at all. Something like “How to containerize your existing microservices”. #askawsabby”@kimkan_

I think “how to containerize your existing microservices” is a great topic!  There are already some AWS-specific resources out there.  I think this tutorial looks like a good place to start. I’d also recommend some of the blogs/talks around microservices architectural patterns.  Here’s some personal advice, though:

  1. Break down your monolith based on job, or function.  For example, a set of functions that send customer emails become an email service.
  2. Better yet, break down AND abstract out.  If you have several functions that all individually send emails, think about how you could write a single email service that handled multiple use cases.
  3. Don’t be afraid to break into multiple services.  Once a service handles multiple jobs, perhaps it’s time to make that two separate services.
  4. Avoid writing interconnected services.  You should be able to deploy each service without having any knowledge (or touching) the other services.
  5. Communicate via the public API.  Have services talk to each other via an API, like you would for any other client/resource.  This a) helps you write good services since you’re also now a consumer/client, and b) removes dependencies.

This isn’t an exhaustive list, just a couple things to think about.  Maybe I should write a whole blog on this!


Abby Fuller

Abby Fuller

developer relations | agony aunt at amazon web services. abby tweets @abbyfuller, or you can email her at