O'Reilly's First Software Architecture Conference

O'Reilly is really good at conferences, and I highly recommend going to at least one in your lifetime. This conference even had a conference specific App, which was handy when exploring what to attend. I loved the mix of people. In attendance was a broad palate of gender, race, nationality, interest and point of view. I thought the mix of topics and schedule was relevant and timely. The topics had two or three strong themes with welcome counterpoint within those themes. If O'Reilly decides to create another software architecture conference next year, I plan to be in attendance.

Image

Microservices and Docker Containers were a few of the major themes, in fact among the speakers, it became a bit of humor after a while. "The recipe for a hip presentation is simple, just utter Microservice thrice, Docker twice and finally Conway's Law." There were a few topics for which I did not have time but was interested in: Event Sourcing and Reactive Programming. From a security standpoint, this make-it-smaller-and-quicker-to-deploy trend is going to introduce some interesting problems for us to tackle but I'm optimistic we will be able to find solutions.

• This presentation by Michael Montgomery was not as .Net-focused as I had imagined, which personally, was nice.
• Take away: "Technical Empathy." Specifically, be kind by giving something to every party – developers, DevOps, tech. writers and support.
• Another take away was making it easy for devs to use design patterns through common APIs, this was the speaker nod toward WCF's standard API for communications, but good advice generally.
• Fun idea: build an AMQP interface.

• Given by Adrian Cockcroft, recently of Netflix fame. His calm, composed character I felt was evidence of his knowledge and success.
• Mr. Cockcroft gave props to Tripwire founder Gene Kim's book "The Phoenix Project." Go Gene! (Go Tripwire!)
• Among many things, Mr. Cockcroft illustrated the incredible shrinking trend in computation and process from Datacenter Snowflake to Virtual Machine to Docker container, to the new "weighing in at 3 seconds," ultra-slim AMS Lambda process. This will definitely present a challenge to Tripwire in terms of monitoring change and vulnerability.
• Immutable processes is a security boon. What does this mean for Tripwire Enterprise? I've got a few ideas.
• If you want a screaming deal (up to 80% off) on cloud computing, you've got to have your technical ducks in a row with respect to scaling processes up and (more importantly) down, be a big buyer, and have savvy finance chops.
• Mr. Cockcroft is tinkering with his own system builder called Spigo. While he admitted he is no U/I genius (asking for help in that area), at the outset it proved useful for the presentation.

• The presentation by Mr. Uwe Friedrichsen started an ever widening, looming landscape of architectural drivers and influencing trends in which to set context. I felt like I was drowning in the vastness and then he threw the audience a lifeline.
• What followed was a nicely de-composed and opinionated view of the latest 10 architectural "hot topics," which he calls his "5+2 architecture"... relief!
• Here (and in Mr. Cockcroft's presentation) "Bounded Contexts" was mentioned, taken from "Domain Driven Design."

• Mr. Jon Moore pulled a fun "time out" audience trick by walking out of the room (with wireless mic) asking… after a well-timed pause… "How long will you wait for me to come back?"
• Nice design tip: consider designing microservices along failure boundaries, creating small resilient services where resiliency is needed and where design or construction failure and re-engineering may be required.
• Another nice tip: Remember the idempotence of HTTP's PUT method and leverage that when possible. Idempotent operations can be re-executed without negative side-effects, which is what you want when systems fail.
• Queueing theory came up in this session, specifically Little's Law "N = XR" which gave me an idea about Mr. Cockcroft's Spigo tool... apply queueing theory to system models to illustrate breakage.

• Simon Brown's C4 maps is Google Maps for your Code. I love it… why didn't I think of that? Also, his Structurizr is a nice way to visualize the output from the Structurizer tools. It made me want to leverage Clojure's meta features to allow his tools to organize Clojure code.
• The Component idea was a nice counterpoint to the irresistible bright black light attraction to Microservices.
• In a setting where there was much said about new and shiny things, Brown's call for deeper investment into design, specifically modularity and granularity was a good dose of old fashioned English sensibility. Thank you.

• I was flagging a bit at this point in the day, but Edward Fagin's dynamic tone kept me engaged.
• A good comparison between batching and streaming, and uses cases, which I agreed with mostly. However, I would quibble over one detail, batching should be used for large data windows and streaming for short data windows. I actually think streaming should be used for long data windows, really long data windows… approaching infinite, those that are impossible to fit into memory, particularly reducing operations.
• Amazon has added yet another feature: Kinesis, a stream processor… its hard to keep up with Amazon's break neck pace these days, not to mention Azure and Google.

• Fueled by caffeine, public servant hero Michael Brunton-Spall presented How to Leverage Agile Teams to Create Secure Systems.
• Lots of great advice, particularly for a security company like Tripwire. For example, embed a security focus engineer on each team, introduce Anti-personas. Mis-use Cases, Risk Stories and Attack Trees (for building Mis-use Cases). Nice!
• Record Risk decisions in an open place (Wiki or similar) to keep track of what decisions were made.
• Mr. Brunton-Spall was an advocate for ISOS27001 and upon inspection had some ideas on how to ingest such a tome of information.
• Another reference to Michael Nigard's book: "Release It!"

• Mr. Johann Schleier-Smith dove into how data scientists work and how architecture can help them in a REPL-y way (in the large that is).
• Tripwire is familiar with logging events and Mr. Schleier-Smith presented a compelling case for using an Event Logging model for handling data. I've had some similar ideas… confirmation is so comforting.
• I love the idea of moving from Extract-Transform-Load to Log-Transform-Use. For me, this had some nice tie backs to Mr. Fagin's "Breaking the logjam: Moving From Batch to Stream"