A few weeks post-re:Invent the hours of sessions and conversation have had a chance to sink in. Two years ago my takeaways from re:Invent were about microservers and stateless applications being the future. In a way a lot of the focus, two years later, is still on stateless microservices. Today, however, the future seems to be abandoning servers in favor of AWS lambda and other serverless providers.
Lambda as Glue
Serverless does not have to mean entire API’s and applications backed by functions-as-a-service. Instead, we should think of Lambda as glue that lets us customize the execution of AWS backed applications. This can mean anything from reacting to notifications to using Lambda to creating more complex, self-healing architectures.
Say you have an autoscaling group that backs an ECS cluster. When one of these servers looses contact with the ECS service, it should be marked as unhealthy and taken out of service. This is something that AWS itself should offer, but doesn’t currently.
Before Lambda you’d have to setup CloudWatch alarms and SNS notifications and some other server to listen for events related to a server losing contact with the cluster so actions could be taken. That’s yet another application to maintain. With lambda, you can react to those events without provisioning and maintaining infrastructure.
Lambda becomes the glue -which you can build utilities to make AWS act however you desire. That is profoundly powerful.
It’s also kind of boring and doesn’t get nearly as much press as it should.
Monitor All the Things
Without servers, and those wonderful log files they produce, we’re without the traditional tools to debug production issues. Which leads us to monitoring. There were a ton of presentations around monitoring as well as a fair amount of vendors in the expo hall selling monitoring solutions.
These solutions are wide ranging in scope, from monitoring your infrastructure as a whole for security issues to metrics for a fully dynamic inventory of servers.
Whatever it is, you’re probably not doing enough monitoring. There’s stuff built into AWS that’s nice, but my big takeaway was application specific monitoring’s value.
By that I mean the domain-specific metrics your application can track over time. This sort of thing could be used to track performance or determine the success of feature. Got some batch process? Time it and push that metric somewhere to visualize it over time. See what sort of trends your application is operating on.
React to Metrics
The metrics your application produces can be reacted to using serverless tooling. Remember that batch process? If it takes longer than normal, alert on it so your teams can look into it. The cool thing about functions-as-a-service is that complex logic can be done to determine if an alert needs to be sent.
Similarly, security events that can be monitored can be reacted to. One presentation I attended had a lambda function that re-enabled CloudTrail whenever it was turned off in addition to alerting a security team about the event.
These reactionary or self-healing capabilities are really where monitoring and serverless come together to form an extremely useful solution.