Day 2 Session Summaries
Managing State for Serverless Applications
This session would probably have been better named “Step Functions, and how customers are using them”. While I was kind of hoping for a deeper dive (it was advertised as level 300) into the various types of state that is required in a serverless app, and a comparison of different approaches, I was happy to learn a little bit about Step Functions. So basically, they are similar to Logic Apps on Azure, but without the nice editor experience, and without the connector ecosystem. Still it’s obvious the potential in using Step Functions to orchestrate flows in a serverless application. The talk focussed on a number of real customer scenarios; Basic ETL workflow, intricate deployment scenarios, integrating legacy applications, Large scale image processing and analysis, and (importantly) detecting if your boss has entered the team office, and (more importantly) whether or not you should be concerned based on his emotional state as perceived by ML.
Fully realizing the Microservices Vision with Service Mesh
Rob Crowley first peaked my interest in service mesh at DDD Melbourne, so when I saw an overflow for this session, and had nothing else on, I decided to go. The talk was pretty much a recap of what I’d learned from Rob at DDD, although the speaker did forget to mention that Service Mesh is essentially a Side-Car pattern (something I am grateful Rob made clear as it really helped me understand it and why it exists). Also Rob did more demos. The speaker wasn’t actually from AWS but from a monitoring company SignalFx.
So the takeaways: Benefits
- Easy to implement Error Handling, retries, circuit breaker pattern
- Load Balancing
- Request Routing
- Security: auth, encryption
He also talked about desired state versus discovered state, and how using smart algorithms, or even bots, it is possible to make timely decisions to rectify the system. He demonstrated this using a canary deployment gone bad and showed it automatically rolling back.
Ripping off the Band aid: Re-Architecting traditional 3-tier Monoliths to serverless
This was a chalk talk, and while the presenters had some important points, it was more a discussion/question session. Points made
- Yes it’s hard
- Define the destination. Don’t do it just because “microservices” or :serverless” make sure you have a clear picture of the benefit, focus on a real problem.
- Prioritize by Business Impact
- Choose features that require faster cadence
- Refactor capability rather than code.
- Practice with simple functionality first to build experience and trust
- Move on to larger chunkier pieces, don’t go too small too fast
- Find a point in the code where there is either the least coupling, or a fairly structured interface
Monitoring Serverless Applications
To be honest, this talk was little more than an advertisement for New Relic, and their beta release of their new lambda monitoring platform. What little content there was can be summarized as
Serverless introduces new challenges for monitoring. When you are doing things synchronously isn’t too hard, but once we introduce asynchronous tasks into the application (i.e. using kinesis or SQS), it gets harder to determine causes and effects, and to relate them. Certain metrics aren’t very useful, and sometimes even lie to you in Lamda (e.g. memory usage).