This post was originally published at https://skeltonthatcher.com/blog/pipeline-continuous-delivery-conf-2017-accountability-socrates-multicasting-serverless-security/ and is reproduced here for the record.
Whilst attending Pipeline Conference I noted down things which I found to give food for thought. To me this is the acid test of a talk – does it create a spark of thinking?
Automation and Autonomy
Dan North (@tastapod) gave the opening keynote “Ops and Operability“. Dan talked about both Ops and Dev in the guise of some classic novels, but as always at Pipeline there were a few things which were thought provoking.
His early quip about “managers – causers of work in other people” caused a ripple of amusement around the room but he soon moved onto discussing automation and autonomy.
I think some people with an Ops background might find resonance with the idea, that whilst generally positive things, automation and autonomy without constraint are undesirable. In this context constraint refers to accountability.
I imagine, for some of the Dev focused people in the audience that suggesting restrictions on their autonomy would cause a negative reaction. In my experience, unfettered by responsibility and without a mechanism for acting accountably developers and operations people alike exhibit poor behaviours. Indeed, I believe automation without accountability (acting as a constraint) will result in operational chaos and/or cognitive overload.
The Socratic Question
During the course of his talk, Dan used an expression I had never heard of: ‘socratic question’. From what he said, I approximated it to be:
“the art of prodding assumptions and decisions in a way to cause learning and generate questioning of assumptions”
Naturally a quick search enlightened me a little bit further, and it turns out that I wasn’t too far off the mark with my initial understanding.
Healthchecks – listen or enquire?
For the first time in ages (full time fintech employment at least) I heard mention of using TCP multicast packets as heartbeat signals. Most people seem to focus on the HTTP endpoint, so the mention of multicast was a nice reminder that there are other mechanisms. Dan took the time to mention five items which tie-up to form focal points for healthchecks:
- Instrumentation
- Telemetry
- Monitoring
- Alerting
- Predicting
Broadly, I’d map these things to existing critical operations tooling and functions which developers need to participate in. Let’s look at how these might hang together:
- Start by making your code instrumented
- Instrumented Code empowers telemetry gathering
- Gathering telemetry allows us to monitor remotely and effectively
- Effective monitoring can drive sensible alerts
- Alerting capability can enable thinking and predictive planning, allowing pro-active action ahead of problems…
Following on from Dan’s talk, I was thinking about this style of healthcheck which we might define as ‘push’ in which the operating environment is listening for heartbeat/health state, vs ‘pull’ , where we have an active enquiry say into an HTTP endpoint to determine state.
With the ‘push’ approach we can generate a picture of components in our operating environment dynamically. Whereas, with the ‘pull’ approach we take a more prescriptive view and probably already know which components we expect to be running since we are going to actively query their state.
Serverless and Security
A handful of observations in the serverless space from Robin Weston (@robinweston) which I thought were interesting. In a security context serverless seems to come with some off-the-bat advantages vs a full OS / container stack:
- Small attack surface
- No humans, no login
- No patches
- No firewalls and ports
- Filesystem read-only
Diving into these, it’s important to recognise that we’re just trading off some of the traditional security concerns to the vendor. This was a point emphasised by Robin in the context of needing to play by vendor rules. In the case of AWS lambda, this includes a 5 minute max lifetime on lambda functions and limited data payloads.
I think it remains to be seen what the security view of lambda and serverless really is. Rightly, Robin points out that a lack of thought in configuring your IAM policies can still result in ‘the wrong outcome”.
Just as we (@skeltonthatcher) recommend breaking the monolith or changing your build processes or moving to Continuous Delivery in gradual steps, Robin also recommended starting off with a small piece of functionality and trialling it as a serverless exercise.
His suggested areas included:
- Scheduled Jobs (think cron)
- Log streaming
- Webhook processing
To me the most obvious candidate is to look at the scheduled jobs you run and examine if they are suitable for conversion.
Talk Links
Slides and videos from Pipeline Conf 2017 can be found on the Speakers page
Rob Thatcher 