You had to write all that orchestration code yourself.
That said, I completely agree with you, and utilize the same arch at dayjob.
There are “app tier” cattle, and there are a few special pets (databases) that are backed up, loved, hand-held, etc. because database failover is still painful for users for seconds-to-minutes. When you’re serving thousands of requests per second, that’s a lot of angry users.
RDS, Azure SQL, Cassandra, Aurora, whatever still cause measurable pain for the end user during node failure.
You had to write all that orchestration code yourself.
With the Windows VMs I had to:
- integrate TopShelf to make it a Windows Service
- write the code to poll the queue (no big deal but still)
- create two Cloudwatch alarms to monitor the queue to tell the autoscaling group when to scale in and out
- define the launch configuration for the autoscsling group
- define the autoscaling group
- add health check functionality to the Windows service to ensure that the Windows service was running that could be integrated with the sutoscaling group (well I didn’t have too but to be complete)
Alternatively with lambda all I had to do was
- add a method that took in two parameters - the SQS event and the lambda context.
- add the SQS event to trigger the lambda.
Of course both stacks were created with Cloudformstion. One I had to do myself, the other I just basically set everything up in the web console, exported the CloudFormation template and made some minor changes.
You had to write all that orchestration code yourself.
That said, I completely agree with you, and utilize the same arch at dayjob.
There are “app tier” cattle, and there are a few special pets (databases) that are backed up, loved, hand-held, etc. because database failover is still painful for users for seconds-to-minutes. When you’re serving thousands of requests per second, that’s a lot of angry users.
RDS, Azure SQL, Cassandra, Aurora, whatever still cause measurable pain for the end user during node failure.