This year was the 11th for QCon London; it was also our largest London event to date. Including our 140 speakers we had 1435 team leads, architects, and project managers attending 112 technical sessions across 18 concurrent editorial tracks and 16 in-depth workshops.
Alasdair Allan's opening keynote "Security War Stories: The Battle for the Internet of Things" highlighted one major theme for the event, which was looking at the underlying differences between the Internet of Things and the digital Internet that cause IoT-specific security issues. Latency and performance also featured prominently at the event this year, as you might expect for a conference in London. The UK is something of a centre for computer language design, and we had a number of talks and sessions looking at the topic, with Joe Duffy's keynote on Wednesday talking about concurrency, Java Language Architect Brian Goetz discussing parallelism in Java, and Pony language designer Sylvan Clebsch discussing how the design of Pony's type system and run-time influenced each other. Later in the day we brought this group together, along with Richard Feldman, for a panel discussion exploring "What's next for our languages?" hosted by Martin Thompson.
Attendees had near-instant access to video from almost all of the sessions. We're making these available to everyone as quickly as we can, and have already started publishing them at the rate of six per week. The publishing schedule for presentations can be found on the QCon London website.
InfoQ had a number of our reporters at the event and you can read our coverage here. This article, however, summarizes the key takeaways and highlights from QCon London 2017 as blogged and tweeted by attendees.
- Keynotes
- Applied JavaScript - Atomic Applications and APIs
- Architecting for Failure
- Architectures You've Always Wondered About
- Containers - State of the Art
- Dark Code: The Legacy/ Tech Debt Dilemma
- Engineering Culture @ { {Cool_company} }
- Fast & Furious: Ad Serving, Finance, & Performance
- Java - Performance, Patterns and Predictions
- Modern CS in the Real World
- Modern Distributed Architectures
- Modern Learning Systems
- Observability Done Right: Automating Insight & Software Telemetry
- Performance Myth-busting
- Security: Lessons Learned from Being Pwned
- Softskills: Essential Skills for Developers
- Workhorse Languages, Not Called Java
- Sponsored Solution Track I
- Workshops
- Opinions about QCon
- Takeaways
- Conclusion
Keynotes
Security War Stories: The Battle for the Internet of Things
Tim Anderson attended this keynote:
It was an entertaining and disturbing résumé of all that is wrong with the mad rush to connect everything to the internet though short on answers; our culture has to change so that organizations such as hotels, toy manufacturers, appliance vendors and even makers of medical equipment take security seriously but it is not clear how this will come about unless so many bad things happen that customers start to insist on it.
Samuel Lesuffleur attended this keynote:
The conference started with an entertaining keynote from Alasdair Allan. He gave us some disturbing and recent examples on how internet of things (or more generally the software industry) has been failing humans. It included: a pet feeder, smart bell, medical equipment, hotels radio, smart toy… Smart objects are more more present in our daily lives and future is scary. It is our duty to make them secure.
Engineering You
by Lynn Langit, Martin Thompson
Samuel Lesuffleur attended this keynote:
The first part of the talk was a deep look at the root of the term “Software Engineering”. It’s good to hear that most of the concepts that we are using nowadays have been defined years and years ago (50 years!). On the one hand technologies are evolving extremely fast; and on the other hand the core concepts and good practices are not evolving. The second part of this talk was on how we should keep engineering “ourself“. In disorder: dedicate 20% of your job time to personal learnings/practices; keeping to learn and improve, do maths, read open source code, do maths again.
Twitter feedback on this keynote included:
@charleshumble: Copying and pasting from stack overflow. This is how we do engineering these days. @mjpt777 #qconlondon
@sbisson: 2017 is the 50th anniversary of software engineering. Happy birthday industry! #qconlondon
@CHPConsulting: It's always great watching @mjpt777: "What language would I choose to build high-performance applications? Java." #QConLondon
@AbrahamMarin: Think Agile and all that mushy stuff is revolutionary? Think again: this was part of a Software conference in 1968… https://t.co/GqodtgOMNg
@danielbryantuk: Reliability really is a design issue @mjpt777 and @lynnlangit #qconlondon https://t.co/BjTAISFvy1
@danielbryantuk: When I work with software architects, I always ask 'what was the last thing you coded?' Architects must code!… https://t.co/xhe0EUV43c
@charleshumble: I think #noestimates is BS speak for "I don't want to talk to you product owner." @lynnlangit #qconlondon
@AbrahamMarin: NoEstimates is just too simplistic, it's a way to avoid the hard communication issues @lynnlangit #qconlondon Busting myths.
@danielbryantuk: Looking honestly at the state of the industry is important. Diversity is a real issue @lynnlangit #qconlondon https://t.co/xzm19Q0n2q
@charleshumble: What should we learn? Algorithms, design fundamentals, programming paradigms, decomponostion, abstraction, mathematics" @mjpt777 #qconlondon
@danielbryantuk: Daily practicing of algorithms/data structures, and learning the fundamentals for software development is essential https://t.co/25bI97uQhV
@charleshumble: Learns maths. Maths doesn't go out of date. Your JavaScript frameworks will be out of date next week, like milk @mjpt777 #qconlondon
@kriswager: Great list of things that @mjpt777 and @lynnlangit think are important to learn as programmer/architect/software engineer #qconlondon https://t.co/wLYYBax4vm
@danielbryantuk: As a freelance consultant, I often ask if I am spending 20% of my time learning @lynnlangit on adapting Google's approach #qconlondon https://t.co/DI0poVSdrJ
@charleshumble: In order to learn you need time. Automate boring, repetitive tasks. Not doing so is in an abuse of humans. @mjpt777 #qconlondon
@sarahjwells: The real challenge now isn't recall, but how to reason through all info presented to us and choose the good stuff. @mjpt777 #qconlondon
@charleshumble: With Google [search] recall is irrelevant. What matters is how to reason. @mjpt777 #qconlondon
@danielbryantuk: Don't always think like a techie 'scrum this, sprint that'. Sometimes it's simply about experimenting/delivering fast" @mjpt777 #qconlondon https://t.co/b2oiKnkg7Y
@silbs16: No estimates hurt our industry @lynnlangit #qconlondon
@techwob: #qconlondon : be more commercial - don't always act/speak like a techie! https://t.co/veu9lsNHDz
@tsunamino: Flush your mental cache - take a break when writing code and then revisit & refine later @mjpt777 #qconlondon
@AbrahamMarin: So professional: "A large percentage of production errors come from code areas that have a 'FIXME' or 'TODO' comment" @mjpt777 #qconlondon
@danielbryantuk: Margaret Hamilton can be credited for software engineering as a discipline. She often asked 'what can go wrong?' … https://t.co/9uM7W9dLVI
Our Concurrent Past; Our Distributed Future
by Joe Duffy
Twitter feedback on this keynote included:
@fluffyponyza: Concurrency, distribution, and parallelism: @xjoeduffyx explains how they're long-lost brothers. #qconlondon https://t.co/XYIhaOxk8I
@kriswager: Concurrency has gone from something handled by a domain expert to something [every programmer] must deal with - @xjoeduffyx #qconlondon
@danielbryantuk: With modern architectures and cloud platforms, we are all becoming distributed systems engineers @xjoeduffyx… https://t.co/vkL3DDURM2
@charleshumble: The focus on structured communication has been undervalued, but is coming back (Akka, Thrift, Go, CSPs, gRPC) @xjoeduffyx #qconlondon
@charleshumble: Security may not be the highlight of ur week but it could be the downfall of your career @0xkitty #qconlondon
@danielbryantuk: We must program all the cores! Erlang and @golang got this right @xjoeduffyx #qconlondon https://t.co/5M86y9e5wt
@danielbryantuk: We can learn a lot in computing from looking back at CS papers from the 60s and 70s. Often just abstraction change @xjoeduffyx #qconlondon
@danielbryantuk: E.g. modules –> microservices OS schedulers => @kubernetesio @xjoeduffyx #qconlondon https://t.co/bElnC3lAgq
@techwob: We didn't invent a single thing! (a lot of the fundamentals in use today have firms roots in old school computer science) #qconlondon
@charleshumble: We've learnt a lot about distributed transactions. Mainly not to go there @xjoeduffyx #qconlondon
@danielbryantuk: Amdahl's law is cruel [in regards to parallelism] @xjoeduffyx #qconlondon https://t.co/ZjYan1x2tJ
@charleshumble: Intel would ship faster&faster processors, & microsoft would ship slower&slower software. Lots of people got rich.@xjoeduffyx #qconlondon
@mihai_burada: 2000: No more "Andy giveth and Bill taketh away" virtuous circle - Joe Duffy #qconlondon https://t.co/gjIIS0AWBC
@SteveRwanda: #qconlondon after the multicore world, and limitations of Amdahl's law, distributed programming returns. 1960s and 70s CS still relevant
@wesreisz: The lines between the boxes are as important as the boxes themselves. @xjoeduffyx #qconlondon
@danielbryantuk: In a distributed system, the lines between the boxes often matter more than the content of the boxes @xjoeduffyx… https://t.co/cCPv4qoExO
@danielbryantuk: Safety in a distributed system is vital. Message passing suffers from race conditions too @xjoeduffyx #qconlondon https://t.co/hzc2h0SsGY
@techwob: The unavoidable price of reliability is simplicity - Tony Hoare #qconlondon https://t.co/Ky29DMEk5R
@danielbryantuk: In a distributed system it's often easier to move code to data, rather than the other way @xjoeduffyx #qconlondon https://t.co/KqLaD8k0M3
@prla: The world is really event-driven so programming like that actually feels natural -@xjoeduffyx #qconlondon
@timanderson: Programming clouds of machines will become as easy as multi-core says Joe Duffy #qconlondon
@danielbryantuk: Great #qconlondon keynote about concurrency by @xjoeduffyx! Key takeaways –> https://t.co/ZbuysF7z7H
Applied JavaScript - Atomic Applications and APIs
Adventures in JavaScript and the IoT
by James Hall
Twitter feedback on this session included:
@ouertani: Issues: If you give people quick wifi, they will use it #IoT #JS #qconlondon #wisdom https://t.co/mSlbwPHmA7
@anatomic: Basically, if you want to build internet connected installations, someone, somewhere is going to pull out the plug #qconlondon @MrRio
Full-scale Elm in Production
Twitter feedback on this session included:
@vitkon: Elm in production talk claims 0 errors in runtime #elm #qconlondon
@vitkon: JavaScript and React is a legacy code for us in 2017 #elm #qconlondon https://t.co/jLSzphxijl
@lithinn: Elm is surprisingly hard to crash #qconlondon @rtfeldman https://t.co/gZJMaGiHRP
@lithinn: Elm is surprisingly hard to crash #qconlondon @rtfeldman https://t.co/gZJMaGiHRP
@anatomic: Elm doesn't have a representation for null values. Use language features to describe the absence of values #qconlondon #elmlang
@anatomic: The Model in Elm is an immutable value that represents your entire application state. It's the base of your application #qconlondon #elmlangs
@anatomic: Debug mode in Elm looks absolutely brilliant! Time travelling debugging is a massive feature #qconlondon #elmlang
@anatomic: Reducing technical debt by embracing static types #elmlang #qconlondon https://t.co/G9Wyjja0hq
@SteveRwanda: @rtfeldman on Elm web development - give it a try. "Full scale elm begins with small scale elm". #zeroruntimeexceptions #qconlondon
Microservices at the Heart of BBC iPlayer
by Cem Staveley
Santoro Simon attended this session:
- they had a big monolithic java app that did not meet demand.
- so they had to do something: refactor the app to a lot of little apps.
- had to pre-warm the caches before even putting the service online.
- step by step re-architecting the app
Reasons to choose node:
- it's fast
- they already knew js
Response times before where 5seconds, with node 10ms. 100ms now is slow.
Team workflow is now better: everyone can focus just on the piece that concerns them. TDD development with pairing. There is a test for almost everything, and everyone has a backup. No one person owns a service anymore. The team owns all of the services.
Problems faced: Redis was a central point of everything, so there was no confidence in changing something that involved Redis. Solution: abstract Redis with an API, and use multiple Redis databases, one for episodes, one for shared stuff, etc. Use Yeoman to automate the creation of the small apps. This reduced the amount of configuration essentially to 0.
The team is just 4 people, with no PM. Consumer contracts help a lot with independence between client and API services. Moving from Redis to Postgres for some service because the requirements become more complex. Redis is just a store, Postgres can have complex SQL reports.
The Hitchhiker's Guide to Serverless JavaScript
Santoro Simon attended this session:
Why serverless?
- ops:
#noops - #lessops
- benchmarks
- fallbacks
- load testing
- monitoring
- scaling: up AND down
- single function deployments
Vendor lock-in? yes, It is a problem. the Serverless framework tries to abstract that away, hopefully we will get there.
Tim Anderson attended this session:
Steve Faulkner gave a session on serverless JavaScript, or more specifically, using Amazon Web Services (AWS) Lambda and API Gateway. Faulkner said that the API Gateway was the piece that made Lambda viable for them; he is Director of Platform Engineering at Bustle, a busy content site based in the USA. In a nutshell, moving from EC2 VMs to Lambda has yielded both financial savings and easier management. The only downside is performance; each call to a Lambda function takes a minimum of 100ms whereas the same function on a VM might take 20ms. In the end it is not critical as performance remains satisfactory.
Faulkner said that AWS is ahead of its competitors (Microsoft, Google and IBM were mentioned) but when pressed said that both Microsoft and Google offered strong alternatives. Microsoft’s Azure Functions are spoilt by the need to specify a maximum scale, rather than scaling automatically, but its routing solution is in some ways ahead of AWS, he said. Google’s Functions will be great when out of beta.
Twitter feedback on this session included:
@lominart: 'Serverless' architecture is a terrible buzzword says at #qconlondon. It's about functions-aaS.
Architecting for Failure
Building and Trusting a Cloud Bank
by Greg Hawkins
Samuel Lesuffleur attended this session:
Greg Hawkins, the Chief Technology Officer at Starling Bank, gave us a good overview of their architecture and how they achieve resilience. They are in the early stages of developing the next generation of bank. We were impressed by what they have built in only 1.5 years with a small team. They are able to rebuild their entire stack in less than an hour and often play at killing servers (they even have a slack bot to kill servers – we need one too).
Building Reliability in an Unreliable World
by Greg Murphy
Michele Ricciardi attended this session:
Greg Murphy gave a great talk where he spoke about the key areas they focused on to prevent and recover from failure:
- Minimize the failure domain - in other words when failure happens, contain the damage
- Segregate workloads
- Manage computing resources effectively: identify hotspots, highlight anomalies and track trends
- Automate fixes for your data problems - for example auto-indexing fields that are often used for lookup
Practice failures
You can predict what may happen when part of your infrastructure goes down or when your API gets flooded with requests, however until you artificially construct those scenarios you will not be certain of how they will affect your system.
Practicing failures in your system will uncover scenarios that haven't been considered before and will give you the reassurance that you know what to do when failures occur.
Twitter feedback on this session included:
@sarahjwells: Expect failure. Expect things to fail in ways you didn't imagine. If people can do dumb stuff, they will. Greg Murphy at #qconlondon
From Microliths to Microsystems
by Jonas Bonér
Samuel Lesuffleur attended this session:
Jonas Bonér gave us good practices to move from a Microlithic to a Microsystems architecture. It focuses on how to build resilient services, reactive systems and event-driven DDD. We were glad to hear that “there is no such thing as a stateless architecture, it is just someone else’s problem“. We will definitely add his (free) book to our reading list.
Aaron Bourne attended this session:
- Reactive Design Principles help when developing microservice architectures
- Separate stateless behavior from stateful entities in a microservice architecture — this helps with scaling
- References to Pat Helland’s paper “Data on the Outside versus Data on the Inside”
- Use Domain Driven Development, but don’t focus on the things (nouns), instead focus on what happens (events)
- CQRS and Event Sourcing mentioned as a useful techniques
Twitter feedback on this session included:
@RogerSuffling: #microservices the monolith killer? Check out @jboner distributed systems tech talk for the inside track #qconlondon https://t.co/wyI8VIWERd
@danielbryantuk: With distributed systems we are always looking into the past in regards to what's happening @jboner #qconlondon https://t.co/xTYLjZOguk
@AbrahamMarin: No one wants eventual consistency. It's not cool. It's just a necessary evil @jboner #qconlondon
@seymourmania: Reality is only eventually consistent - Jonas Boner Sat's we need reactive systems & event-driven DDD #qconlondon
@danielbryantuk: In regards to communication within distributed systems "silence is golden". Minimize unnecessary chatter! @jboner… https://t.co/Ku6TphvMgZ
@lominart: Entering „a wild ocean of non-determinism:“. @jboner is talking about distributed systems at #qconlondon.
@aslongasican: Applying reactive programming to microliths. @jboner @ #qconlondon https://t.co/aYeFTY6mXt
@sarahjwells: There is no such thing as stateless architecture - you're just making it someone else's problem. @jboner #qconlondon
@sarahjwells: The truth is the log. The database is a cache of a subset of the log. Pat Helland quoted by @jboner #qconlondon
@AbrahamMarin: CRUD is dead, you can only create and read, facts cannot be updated or deleted. We hadn't killed anything yet at #qconlondon @jboner
@aslongasican: It's how the world works. @jboner @ #qconlondon https://t.co/4fM00MM2Bb
@ferreiratiago_: Separate the stateless behavior from the stateful entity Yes. Please! #qconlondon @jboner https://t.co/o79PuvTHyB
InfoQ also recently recorded a Podcast with Jonas Bonér.
Latency Sensitive Microservices
by Peter Lawrey
Twitter feedback on this session included:
@RogerSuffling: Interesting low latency design tech talk by@PeterLawrey. Speed costs money. How fast can you go? #qconlondon https://t.co/pf5Aw2pt7M
@ixchelruiz: Recording all the events will make replaying a sequence simple. Debug & analysis becomes easier. #qconlondon @PeterLawrey
@scottejames: @PeterLawrey : storage costs are proportional to the size of an organisation. #observant #qconlondon
Architectures You've Always Wondered About
Architectural Overhaul: Ad Serving @spotify Scale
Twitter feedback on this session included:
@r39132: Welcome to @Spotify scale: 100M+ MAUs, 50M+ subscribers, 30M+ songs, 2B+ playlists, $5B paid to rights owners, 60 global markets #qconlondon https://t.co/mYuRWYvufq
@weavermj: The early wireframes of @Spotify look much like the app does today, says @_kinshukmishra, with the Freemium model part built in #qconlondon https://t.co/yjnSnM8f3E
@danielbryantuk: Evolving architecture is challenging while keeping the business running, but often necessary for the future… https://t.co/AMzPlIZY4f
@r39132: The original @Spotify Ads server used a stateful hash ring architecture #qconlondon https://t.co/lqJ6PDzMCh
@danielbryantuk: Design systems to be a master of one thing @_kinshukmishra on separation of concerns at @SpotifyEng #qconlondon https://t.co/MzqO341kDI
@danielbryantuk: Great advice for anyone rearchitecting a system -> "Think for tomorrow, solve for today" @_kinshukmishra #qconlondon https://t.co/kox9jmNabA
Low Latency Trading Architecture at LMAX Exchange
by Sam Adams
Aaron Bourne attended this session:
- Manage to get impressively low latency using “plain Java”
- Makes great use of the Disruptor Pattern — lots of Ring Buffers
- Focus on message passing
- Minimise the amount of network hops
- Uses in-house hardware, not the cloud
- Uses async pub-sub using UDP
- Low latency
- Scalable
- Unreliable
- Mention of Javassist
- Stores a lot of things in memory, not the database
- Describes using an Event Logging approach
- Java primitives over objects for performance/memory management reasons
- Makes use of Java Type annotations for type safety
- Mention of the fastutil library
- Mention of using the @Contended annotation
- Uses the commercial JVM Zing for improved garbage collection and performance
- Mentions manually mapping Java threads to CPU cores using JNI/JNA for increased performance
Scaling Facebook Live Videos to a Billion Users
Santoro Simon attended this session:
“There are local PoPs where users connect, and PoPs send data between them on big pipes.
Facebook live is different from other video platforms, because
- the videos are created in real time and can thus not be cached
- we do not know what video becomes most popular
We want to go from 0 to production in 4 months and to all users in 8 months.”
Broadcast client –> PoP –> Datacenter
The PoP has scriptable logic: for example it can decide on which datacenter to store the video based on load balancing logic.
Complicated logic with video IDs to handle cell phone disconnections and datacenter encoders downtime.
Low bandwidth has to be handled with adaptive bitrate and buffering on the client.
Twitter feedback on this session included:
@m4tthall: 1.23 billion people access Facebook every day #qconlondon
@r39132: @facebook Live was a hackathon project of a live-streamed clock #qconlondon https://t.co/mdQDCwSW0Q
@r39132: Facebook Live went from hackathon to Production for 1.23 billion users in 8 months #qconlondon https://t.co/hroxxmEBpk
@r39132: Facebook Live uses a cache TTL of 3 seconds. #mindblown #qconlondon https://t.co/WnszzLAVCq
@r39132: Looking forward to 360 degree live video streams on Facebook live #qconlondon https://t.co/Up8hpUoxaS
@weavermj: 4 considerations when choosing a broadcast protocol for the @facebook live platform #qconlondon https://t.co/OIXUGiGCKY
Scaling Instagram Infrastructure
by Lisa Guo
Aaron Bourne attended this session:
- Instagram runs on AWS
- Python + Django, Cassandra, Postgres, Memcache and RabbitMQ.
- Postgres for users, media and friendship
- Cassandra for user feeds and activities
- Memcache is used to avoid constantly hitting the DB
- Uses perf_event on Linux
- Focus on reducing latency
- Sometimes migrates regularly used code from Python to C for improved performance — Cython mentioned
- Always-on custom performance analysis in production – a performance hit but for for a lot of insight
- Disabled the Python garbage collector for performance reasons
- Uses Python asyncio where there was previously sequential service calls
- Uses Tao linked DB
- 40-60 deploys per day to 20,000+ servers with each deploy taking about 10 minutes!
The Distributed Pit of Success @Deliveroo
by Greg Beech
Twitter feedback on this session included:
@danielbryantuk: Interesting thoughts about not including payloads in messages due to "transfer of authority", from @Deliveroo at #qconlondon https://t.co/e7EVpQLtpf
@frathgeber: #Distributed Pit of #Success @Deliveroo: Greg telling @qconlondon that #microservices are no panacea, #data needs to be #owned #qconlondon https://t.co/s3uTMTqus5
Containers - State of the Art
cgroupv2: Linux's New Unified Control Group System
by Chris Down
Santoro Simon attended this session:
Why care about cgroups?
- 100.000+ servers
- many thousands of services
- want to limit failure domains
Need to limit resources to make them available to stuff that needs it.
Continuous Delivery the Hard Way with Kubernetes
by Luke Marsden
Aaron Bourne attended this session:
- Weaveworks use their git master branch to represent production
- Weave use Gitlab for their delivery pipeline
- Katacoda was used to give a Kubernetes live demo and it all worked rather well
Deliver Docker Containers Continuously on AWS
Aaron Bourne attended this session:
- A big pro for Amazon EC2 Container Service (ECS) over other container orchestrators is that you don’t have to worry about the cluster state as this is managed for you
- AWS CloudFormation is the suggested way to manage an ECS cluster, although there was also a mention of Hashicorp’s Terraform
- Suggested to use Amazon’s Docker registry when using ECS
- AWS CloudFormat or the CLI suggested for deployment
- There are 2 load balancers to choose from, the Application Load Balancer (ALB) and the Classic Load Balancer (ELB)
- The ALB only uses HTTP, but has more features
- The ELB does HTTPS, but only allows for static port mapping — this only allows for one service per port per VM
- ALB required for scaling on the same VM
- Suggested to use load balancing rules based on memory and CPU usage
- ECS does not yet support newer Docker features, such as health check
- The Elastic Block Store (EBS) volume is per VM and doesn’t scale that well
- The Elastic File System (EFS) scales automatically and is suggested
- You can have granular access controls in ECS by using AWS Identity and Access Management (IAM)
- Challenges currently exist when using the EC2 metadata service in a container
- ECS does not support the Docker Compose file
- ECS does not natively support Docker volumes
Dev to Prod in 5 Minutes: Is Your Company Ready?
by Carlos Leon
Michele Ricciardi attended this session:
Carlos Leon delivered an incredibly engaging talk where he went through a real world scenario of a company trying to adopt too much all at once.
Carlos used this real world scenario to emphasize something we should all be aware by now: moving to a DevOps model does not only require a shift in tooling and processes, but also require a shift in culture and skills.
If you are a decision maker considering shifting to a DevOps model you need to ensure that:
- You have the right skills in your organization – Developers and Ops will require training
- Focus on one project at the time – make sure you don’t spread yourself thin trying to do too much all at once
- Try to get it right from the start – your first project will be considered a role model across the organization so you should try to get your first project right rather than trying to run against time.
Santoro Simon attended this session:
Cultural changes are hard. At Netflix if you deploy it you own it.
If you try to bring change in the company, think of you as someone who cannot do this by yourself, nobody listens to you, you don't have the influence.
- choose allies
- build the right team (take the people that read hacker news, that look at now technologies, that go to conferences, ...)
- choose the right project
- small iterations
- embrace failure (the project may fail, but you will see what went wrong, iterate)
- be ready for inception (people don't like change, but when they see git push and brrrr they will come)
- seek professional help (the idea is that you are going to be the baseline for the company, so if you start with a bad example, people will follow that, because they don't know. so try to make it right.)
When Containers Attack!
by Anne Currie
Twitter feedback on this session included:
@sarahjwells: Specialization is what led to the industrial revolution. Not steam or water power. @anne_e_currie at #qconlondon Fascinating
@merybere: Tasks changing is really expensive @anne_e_currie at #qconlondon
@danielbryantuk: What's the software equivalent of a generalist? A 'fullstack engineer'? The field is too big @anne_e_currie on sp… https://t.co/K80TaMmu2m
@danielbryantuk: We like generalists, as they are easier to manage than specialists interesting thoughts from @anne_e_currie at… https://t.co/O7fIlSjw1K
@danielbryantuk: The dangers of looking for silver bullet tech at conferences "Conference speakers are professional enthusiasts"… https://t.co/FyGssci9pe
@lmarsden: Even better to avoid lock-in we could encode knowledge about operating services in code, cf Kubernetes operators #qconlondon @anne_e_currie https://t.co/tOmjwnWV9U
@danielbryantuk: Are cloud services the modern software equivalent of Adam Smith's specialists? @anne_e_currie #qconlondon https://t.co/xHZuysxGsE
Dark Code: The Legacy/ Tech Debt Dilemma
A Crystal Ball to Prioritize Technical Debt
Tim Anderson attended this session:
Adam Tornhill spoke on A Crystal Ball to prioritize Technical Debt, another session in the dark code track. This was my favorite of the day. Tornhill presented a relatively simple way to discover what code you should refactor now in order to avoid future issues. His method is based on looking for files with many lines of code (a way of measuring complexity) and many commits (suggesting high importance and activity), the “hotspots” in your projects. For more detail and some utilities see Tornhill’s blog.
Why do we end up with bad or risky code in our software? Tornhill said that developers often mistake organizational problems for technical problems and try unsuccessfully to fix them with tools.
He also mentioned an example of high-risk code, the file gc.cpp which performs garbage collection in .NET Core, the next generation of Microsoft’s .NET Framework. This file is over 36,000 lines and should be refactored. There is a discussion on the subject here. It exactly bears out Tornhill’s point. A developer proposes to refactor the file, back in March 2015. Microsoft’s Karel Zikmund defends the status quo.
Twitter feedback on this session included:
@danielbryantuk: We often try to address the technical symptoms of an organizational issue @AdamTornhill on technical debt at… https://t.co/Au6qs637Qg
@mfeathers: Hotspots all the way down #qconlondon @AdamTornhill https://t.co/NKWaQUnfab
@danielbryantuk: Most code bases I've seen follow a power law in terms of distribution of changes per file. Look for hotspots… https://t.co/pUyDZF2ckR
@mfeathers: Change frequency at the function level @AdamTornhill #qconlondon https://t.co/5YOp3oCySp
@timanderson: Tornhill discussing how on earth gc.cpp (in .NET Core) got to be over 36,000 lines long #qconlondon - see also here https://t.co/gmDjt6b5jR
@mfeathers: Hotspots are areas of code with low cohesion #qconlondon @AdamTornhill https://t.co/urgF2QV7Aj
@danielbryantuk: Layers do offer a separation of concerns, but as changes ripple through layers, are they the right concerns?… https://t.co/nKcAzgMLza
@danielbryantuk: Watch for 'microservices shotgun surgery'. Track changes across services via work ticket id @AdamTornhill… https://t.co/sy6mypbqUi
@mfeathers: Feature Teams are collective chaos [yes they are!] #qconlondon https://t.co/U2Qzc32RVZ
@timanderson: Tornhill says find "hotspots" in your project that have many lines of code and frequent commits, then refactor them #qconlondon
Crushing Tech Debt Through Automation at Coinbase
by Rob Witoff
Aaron Bourne attended this session:
- We need to move fast to survive, technical debt slows us down
- Build in automated guardrails to ensure that we can move fast without bringing down production
- Everyone at Coinbase can deploy a tested master branch to production
- Focus on building a blameless culture
- Create archetype projects to speed up creation of new services
- Do security checks in the build pipeline
- Hashicorp’s Vault mentioned again here
- Coinbase uses Docker — no container lasts for more than 30 days
Twitter feedback on this session included:
@ianbond: Moonshot players are powered by engineering velocity and fade away with technical debt. - Rob Witoff #qconlondon https://t.co/MtsLH9DFC5
@mfeathers: Coinbase's approach to technical debt. @rwitoff #qconlondon https://t.co/QRHX64YPYO
@charleshumble: Engineering velocity requires tools and guardrails to empower engineers to work without fear. @rwitoff #qconlondon
@charleshumble: .@coinbase aim for 16 (4/week) successful production deploys/person/month. Actually varies from 2.9-6.5 @rwitoff #qconlondon
@charleshumble: Have machines waiting on humans, not the other way round. Humans are more expensive. @rwitoff #qconlondon
@mfeathers: Increase permissions to enable engineering and reduce debt #qconlondon https://t.co/uI3r9QoGPV
@charleshumble: Poor permission models handcuff your best engineers. Real value is protected by consensus engineering. @rwitoff #qconlondon
@charleshumble: https://t.co/US8NQtrKwS - how fast are you shipping? @rwitoff #qconlondon
Refactoring Mount Doom - Tackling Legacy Code
Twitter feedback on this session included:
@mfeathers: Peaceful zone and war zone @Singsalad #qconlondon https://t.co/2p35pa15FO
@AbrahamMarin: The real refactoring loop :) @Singsalad #qconlondon https://t.co/jDQlDYM5rk
@mfeathers: Interactive Exploratory Testing to understand legacy code @Singsalad #qconlondon https://t.co/Xq0hUS5aO6
Strategic Code Deletion
Tim Anderson attended this session:
Michael Feathers spoke on strategic code deletion, part of a track on “Dark code: the legacy/tech debt dilemma.” This was an excellent session; code is added to projects more often than it is removed, and lack of hygiene in this regard has risks including security, reliability and performance. But discovering which code is safe to remove is not always trivial, and Feathers explored some of the nuances and suggested some techniques.
Aaron Bourne attended this session:
- If you don’t already have it, a test coverage metric is a great place to start measuring tech debt
- Mutation testing is an even better way of measuring true test coverage, but the tooling is pretty lacking
- If code has very little value, consider removing it
- Mentions of using Martin Fowler’s “Strangler Application” approach
Using Quality Views to Tackle Tech Debt @Tesla
by Colin Breck
Aaron Bourne attended this session:
I recommend that you checkout Colin’s blog post for the details on Quality Views.
- Mentions of the “Big Ball of Mud” paper
- Mentions of the book “Thinking Fast and Slow” by Daniel Kahneman
- Color Brewer mentioned as a great source of effective gradients
Engineering Culture @ { {Cool_company} }
Enabling Innovation at Uber Speed
by Aurore Kervella & Sudhir Tonse
Twitter feedback on this session included:
@merybere: Great ideas come up in Workation, work and vacation! @stonse at @Uber talk #qconlondon https://t.co/jt0WhnQf31
@merybere: it's ok to fail #aurorekeevella @stonse @Uber at #qconlondon https://t.co/Bvh0AQvYld
The Holistic Detective Hunt for Great Tech Culture
by Doug Talbot
Twitter feedback on this session included:
@kriswager: The hypothesis of talk is that process etc is less important than behavior and leadership when it comes to great team/culture #qconlondon
@tumbarumba: Key success criteria for great tech culture from @douglastalbot at #qconlondon https://t.co/7duwcfFBHX
@charleshumble: Leaders need to understand and have skills to develop people, not just efficiency. Doug Talbot @OcadoTechnology #qconlondon
@charleshumble: Lots of reading list ideas from @OcadoTechnology at #qconlondon - https://t.co/jb19iF0thn - comes up a lot
@charleshumble: Great tech culture = fn(behaviours, leadership) Doug Talbot #qconlondon
Fast & Furious: Ad Serving, Finance, & Performance
Achieving High Load in Advertising Technology
by Peter Milne
Twitter feedback on this session included:
@charleshumble: Every second of the day in Europe the value of the advertising market is about 1 million euro/second. @helipilot50 #qconlondon
@charleshumble: Adform DSP technology - 12x Nginx load balancers, 102 .NET bidders. Moved from Cassandra to Aerospace @helipilot50 #qconlondon
@charleshumble: Adform DMP architecture - Restful API, micro-services, OAuth 2, Lambda like architecture for data flow, Kappa-like for real-time #qconlondon
Policing the Stock Market with Machine Learning
by Cliff Click
Twitter feedback on this session included:
@tpuddle: @cliff_click talk at #qconlondon about fraud detection in financial trades. Searching 1 billion trades a day "is not that big". !
@charleshumble: Why Python? I don't know, but the data scientists seems to like it that way. Cliff Click #qconlondon
@charleshumble: .@Neurensic running parallel clustering for ML with Python and Java (Jython). #qconlondon
@charleshumble: Something I see in about 95% of the trading data sets is there are a small number of bad guys hammering it. Cliff Click #qconlondon
@charleshumble: What does this picture mean?I don't know, but it means something to every compliance officer I've ever shown it to.” Cliff Click #qconlondon https://t.co/dkwYWXGAve
@EricHoresnyi: Great analogy in #qconlondon to explain spoofing by @cliff_click with real estate sale with fake intention https://t.co/7sUPhKJdyV
Predictability in ML Applications
Twitter feedback on this session included:
@charleshumble: Ad exchange. 100 billion bid request/day, 100 ms response time. @claudia_perlich #qconlondon https://t.co/B9nuKvtsQn
@charleshumble: My job it to try and look good in your chosen metric. @claudia_perlich #qconlondon
@PaulAnkho: Stop talking about how big your companies are, start talking about tech/architectures that make you different! #qconlondon #hearingLotOfAds
@charleshumble: Distillery builds about 3000 ML models a day. @claudia_perlich #qconlondon
@charleshumble: Predicting gender based on FB likes gets an overall accuracy of about 83%. And not everyone likes stuff. @claudia_perlich #qconlondon
@charleshumble: One thing in machine learning is if it looks too good to be true, it is too good to be true. @claudia_perlich #qconlondon
@charleshumble: I know you are the car dealership if you enabled GPS to find it and are playing Candy Crush while waiting. @claudia_perlich #qconlondon
@charleshumble: Models will create biases because they will pick things that are easy to predict first. @claudia_perlich #qconlondon
@Piersjthompson: Fake sites serving ads to bots. The weird world of online advertising. #qconlondon @claudia_perlich
Java - Performance, Patterns and Predictions
Thinking Strategically about IoT
Twitter feedback on this session included:
@charleshumble: All of us who do #IoT just want toys. Some of us get better toys than others @holly_cummins #qconlondon
@charleshumble: @holly_cummins making popcorn with #IoT at #qconlondon
@charleshumble: #IoT things of questionable value for example a £160 internet enabled hairbrush that brushes your hair. @holly_cummins #qconlondon
@charleshumble: After Alasdair Allan's keynote on Monday you'll disconnect everything from your house and never do #iot again. @holly_cummins #qconlondon
@charleshumble: Anyone can do #IoT. Any device can be casually connected to the internet. @holly_cummins #qconlondon
@charleshumble: My life is not improved in any way if my coffee machine need to reboot before it can make coffee @holly_cummins #qconlondon
@holly_cummins: Just poured melted butter all over my top and trousers packing up my demo. #unexpectedIoTrisks #qconlondon
Modern CS in the Real World
Panel: What's next for Our Programming Languages?
by Martin Thompson, Sylvan Clebsch, Joe Duffy, Brian Goetz & Richard Feldman
Twitter feedback on this session included:
@timanderson: Write code that is so simple that you cannot possibly misunderstand it says Brian Goetz (Java language architect) #qconlondon
@timanderson: Java evolves slowly because we spend so much time writing specifications says Goetz #qconlondon (a good thing he says)
@charleshumble: Formal verification, much like fashion power, is the future. It has been for about 20 years and will be for the next 20. #qconlondon
@charleshumble: Lots of love for the Dafny language in the panel at #qconlondon https://t.co/oIwlVQicij
@charleshumble: Sylvam mentioned "Gradual typing is morally incorrect; we're all monsters now." - Timothy Jones' repudiation of his own work #qconlondon
@adriancolyer: The programming languages panel at #qconlondon is wonderful. So much experience up on the stage!
@charleshumble: When Twitter moved from Ruby to Java/Scala their hardware bill went down about 100x @BrianGoetz #qconlondon
@charleshumble: I'm not just saying this because I'm formally required to do so by my employer @BrianGoetz #qconlondon
@evilpilaf: OO vs FP is a false dichotomy #qconlondon
@evilpilaf: You should learn OO, you should learn FP and then rise above them #qconlondon
@evilpilaf: You may think your application doesn't need to run fast, but it does need to run cheap, so performance is critical #qconlondon
@karltinawi: Good languages promote good APIs ... Awesome session with these legends #qconlondon https://t.co/0DKOqd33Wd
SQL Server on Linux: Will It Perform or Not?
by Slava Oks
Twitter feedback on this session included:
@timanderson: The Drawbridge tech used to run SQL Server on Linux was developed for Midori, a managed OS project at Microsoft - Slava Oks #qconlondon
@timanderson: Idea of Drawbridge was to run legacy Windows apps securely on Midori #qconlondon
@timanderson: There are cases where SQL Server on Linux outperforms Windows says Oks #qconlondon though in most cases Windows is faster, gap narrowing
@timanderson: We just enabled SQL Server HIgh Availability between Windows and Linux says Oks #qconlondon
InfoQ also recorded a podcast with Slava Oks.
Modern Distributed Architectures
Spotify's Reliable Event Delivery System
by Igor Maravic
Samuel Lesuffleur attended this session:
We were not too surprised to hear that Docker was a common source of issues in modern architecture (and in the Spotify event delivery system). But it was impressive (right word?) to hear that every hour they had to restart their services due to these issues.
The Q&A brought up an important point: they don’t have end-to-end testing; it is hard to test hundreds of microservices.
Modern Learning Systems
Deep Learning @Google Scale: Smart Reply in Inbox
Aaron Bourne attended this session:
- Google Inbox’s smart reply learns all responses from data
- Explains deep learning concepts using a feed forward network which uses logistic regression and gradient descent
- Data fed into the network must be a vector of floats
- All words in a dictionary are given an numerical index
- A string of words is converted into a vector of its equivalent numerical representation
- Dimensionality reduction is employed to produce an “embedded vector” — essentially a lossy compression algorithm
- Deep Learning models allow for automatic feature learning
- See the paper Distributed Representations of Words and Phrases and their Compositionality
- A Recurrent Neural Network is used by this project and by natural language processing in general
- See the paper A Neural Conversational Model
- The project can’t match tone — yet.
- A whitelist is used to prevent bad language
- The current approach doesn’t always give diverse answers
- Google Translate uses a very similar model
- Mentions colah.github.io for more information
Observability Done Right: Automating Insight & Software Telemetry
After Acceptance: Reasoning about System Outputs
Twitter feedback on this session included:
@danielbryantuk: Testing modern software systems (with typically a very large state space) cannot be exhaustive @thenewstef… https://t.co/Mw7AbgR9bg
@danielbryantuk: How can a system break that's been pushed down a typical build pipeline? The answer is production data… https://t.co/uLNswv0yWA
@danielbryantuk: Using a generator to create 'production sized' test data in order to create more presentational states, with… https://t.co/QoyrjNhaMu
@danielbryantuk: Using a 'data sanitiser' to continually cleanse production data for testing in a build pipeline...@thenewstef… https://t.co/K6PwKQB8JE
@danielbryantuk: Considerations for running data migration tests in a pipeline. State the benefits, pool DBs, send tests to prod...… https://t.co/Krw84suhKk
@danielbryantuk: It's much better for data testing to be slow in CI, than to have catastrophic failure in production @thenewstef… https://t.co/l6wLbFqinc
Avoiding Alerts Overload from Microservices
by Sarah Wells
Alfa Systems attended this session:
Distributed systems made up of many services are often extremely complex. Having a clear picture of how they are behaving can become difficult, and we watched several teams talk about their experiences with monitoring and telemetry systems.
At the Financial Times, a team responsible for a system made up of more than 300 microservices discussed the changes they’ve made to avoid being overwhelmed by floods of alert emails, sometimes generated when no intervention was needed. Monitoring is a key production requirement; they have standardized health-check APIs for every production service, they test their alerts, and they concentrate on aligning each alert to the relevant business function. This theme was echoed in several conference tracks – whether it’s service up-time or performance benchmarking, it pays to measure the real impact on users and the business.
Twitter feedback on this session included:
@kriswager: The problems with failure is that you get told a lot - @sarahjwells on failure alerts and alert overloads #qconlondon
@danielbryantuk: You only want an alert when you need to take action @sarahjwells #qconlondon https://t.co/CCoElz73GM
@danielbryantuk: As much as i like them, microservices make monitoring harder @sarahjwells #qconlondon https://t.co/oBOKppGs4u
@kriswager: Microservices themselves are simple, but there is a lot of complexity around them - @sarahjwells #qconlondon
@kriswager: One of the problems w microservices are that there's a large number of them, leading to many system check calls - @sarahjwells #qconlondon
@anne_e_currie: FT - a one in a million issue happens 16 times a day @sarahjwells great talk on real-world microservices #qconlondon https://t.co/sN1kJCXIlp
@danielbryantuk: When we implemented a zero-downtime deploy, thanks to Nagios being unaware, it wasn't a zero notification deploy @sarahjwells #qconlondon
@kriswager: We have taken the approach of 'let's monitor things where we have seen a problem' - @sarahjwells on their logging strategy #qconlondon
@danielbryantuk: Make metrics first class citizens. Parsing logs is OK, but we decide on what's interesting, and report this" @sarahjwells #qconlondon https://t.co/m8U4I0MxAh
@kriswager: It is really useful to know about problems before the users do @sarahjwells #qconlondon
@danielbryantuk: Synthetic transactions running continually in production has kinda replaced acceptance tests for us at the FT… https://t.co/nu7gyTSOvO u
@kriswager: FT checks publishing functionality continuously, not just when someone tries to publish an article - @sarahjwells #qconlondon
@kriswager: Alerts go into slack at FT, but not team channel as they get in the way of other conversation - @sarahjwells #qconlondon
@danielbryantuk: We agreed on how to use Slack emojis to indicate we had seen/fixed alerts. There were too many dancing hamsters @sarahjwells #qconlondon
@kriswager: You need to make your alerts good, since the person reacting might not know much about the functionality - @sarahjwells #qconlondon
@kriswager: Make sure to review alerts and improve them, including getting rid of them - @sarahjwells #qconlondon Also add missing alerts, obviously https://t.co/adIPEBX77D
@danielbryantuk: Setting up an alert is part of fixing any problems @sarahjwells #qconlondon https://t.co/9ABydyodW5
@kriswager: FT has a chaos snail. Named so because it is smaller than a monkey and written in shell - @sarahjwells #nerdhumour… https://t.co/maBwC17lAy
Do You Really Know Your Response Times?
by Daniel Rolls
Twitter feedback on this session included:
@danielbryantuk: Important questions to ask when monitoring distributed systems, by Daniel Rolls #qconlondon https://t.co/HUMqsVYrX9
@danielbryantuk: Types of metrics that SkyUK use with the DropWizard metrics library, from Daniel Rolls #qconlondon https://t.co/agNr7AGWhm
@sarahjwells: We trust and depend on dashboards - but we rarely understand them and we lie to ourselves and to our managers with them. #qconlondon
@danielbryantuk: Taking the arithmetic mean of two services response times can lead to invalid results #qconlondon https://t.co/2GPLUXdPhP
@sarahjwells: When data points are put in front of us, we will compare them, even if we know they are wrong - Daniel Rolls at #qconlondon
@sarahjwells: Developers are not statisticians, which is why they decide to average percentile times (big mistake) - Daniel Rolls, great talk #qconlondon
@danielbryantuk: Even if data is meaningless, given sets of data we will compare them - it's human nature Daniel Rolls on using bad dashboards #qconlondon https://t.co/G51sScKPZY
@danielbryantuk: Watch for metric imbalance visualized. At Sky we use one response data reservoir per endpoint Daniel Rolls… https://t.co/90FMnRNHiF
@sarahjwells: The old (wrong) dashboard numbers were a bit like story points - meant something to the team, meaningless for others. #qconlondon
@danielbryantuk: Great talk about metrics and dashboards at #qconlondon by Daniel Rolls. Beware of human bias, and keep it simple! https://t.co/IzsISPIWWF
Monitoring Serverless Architectures
Twitter feedback on this session included:
@danielbryantuk: Serverless is not exactly FaaS... You could argue it's a true cloud-native approach to PaaS @RafalGancarz #qconlondon https://t.co/QwMvMFQA5D
Observability, Event Sourcing and State Machines
by Peter Lawrey
Twitter feedback on this session included:
@danielbryantuk: I never managed to use all of the 128kb of my first computer, but now you can get a 2Gb SSD to play with… https://t.co/G4HL0ZiEkz
@danielbryantuk: Looking at the Lambda architecture with chained services, via @PeterLawrey at #qconlondon https://t.co/G0CUIz2GYq
@danielbryantuk: You must be able to test microservices without the framework or a transport @PeterLawrey #qconlondon https://t.co/qGcCphAYbp
Performance Myth-busting
High Performance Managed Languages
Twitter feedback on this session included:
@charleshumble: Inlining is THE optimization @mjpt777 quoting Cliff Click at #qconlondon
@charleshumble: Generational GC: "Only the good die young" @mjpt777 channeling Billy Joel this afternoon at #qconlondon
@EricHoresnyi: A story of tenure&generation by @mjpt777 on garbage collection in modern servers 4 performance with managed languag… https://t.co/g0gpSLKieQ
@frathgeber: Managed and garbage collected languages don't have to be slow! @mjpt777 #performance #MythBusting @qconlondon… https://t.co/hVlum4KFNG
In-memory Caching: Curb Tail Latency with Pelikan
by Yao Yue
Samuel Lesuffleur attended this session:
We finished the first day with a very technical talk from Yao Yue of Twitter. First of all, thank you for chasing ghosts for the last 5 years and giving us all the lessons you learn from your battle scars: lockless architecture, prioritize requests “data plane” vs “control plane“, pre-allocate memory when possible… On top of that, most of the lessons learned about caching can be applied to other kind of services.
Twitter feedback on this session included:
@sarahjwells: Good cache performance = predictable *tail* latency @thinkingfish #qconlondon
@kriswager: Generally cache is very fast, but there are some gliches (performance ghosts) - @thinkingfish at #qconlondon https://t.co/vLtO9cKow0
@nitsanw: The ghosts of latencies past at @thinkingfish talk #qconlondon (longer tails are coming to get us...) https://t.co/mRzMj0cyvU
@kriswager: It took @thinkingfish 6 months to learn and implement cache, but 5+ years to fix the ghosts #qconlondon Great that she is sharing findings
@frathgeber: #tail #latency determines overall latency! #performance #MythBusting, @thinkingfish @qconlondon: hide expensive ops… https://t.co/wNAeO2wijD
@Piersjthompson: #qconlondon @thinkingfish Twitter "we can guarantee 2ms 999 latency [in our cache]". Nice.
Security: Lessons Learned from Being Pwned
Building Secure Player Experiences at Riot Games
by David Rook
Twitter feedback on this session included:
@kriswager: We have to think on how it affects the players when we introduce some security @davidrook on added player dimension in games #qconlondon
@kriswager: We don't want to be like Taliyah, building walls - game reference by @davidrook while describing security versus development #qconlondon
@0xkitty: . @davidrook on security at Riot Games: "Be like our champion - Braum. Protect, support and defend" #qconlondon @qconlondon @riotgames
@kriswager: Security team needs to understand what developer teams are trying to do, and try to figure out how they can help - @davidrook #qconlondon
@kriswager: Most of @davidrook's work isn't tech work but rather communication and learning from POs and devs #qconlondon Helps embed security in org
@kriswager: Because Riot's security team put product teams first, the teams wants to work with security team @davidrook #qconlondon obvious but uncommon
@kriswager: Riot uses ESlint rules and github api to run security rules on every JavaScript changes - @davidrook #qconlondon
@kriswager: The majority of code that Riot ships is not written by Riot but is 3rd party. This is a security risk @davidrook #qconlondon
@burythehammer: Riot games proactively scanning GH repos for security concerns and notifying devs in slack #qconlondon https://t.co/6THLMVabLO
@kriswager: Riot has a portal for dev teams to create review requests, allowing for easier communication between security and dev @davidrook #qconlondon
@kriswager: My takeaway from @davidrook's talk is that good/easy communication across teams makes for higher security #qconlondon
@kriswager: The focus of Riot security team is to create tools to make it easy for dev to do security sweeps - only need to be set up once #qconlondon
@kriswager: Riot has changed security risk explanations so they starts of by telling how they affects players - @davidrook #qconlondon
@kriswager: Reddit and pastebin is not the ideal way of finding out about a security problem - @davidrook on why pay for security holes #qconlondon
@kriswager: Data can show how different teams struggle with different types of security issues, and where to focus - @davidrook #qconlondon
How to Backdoor Invulnerable Code
Twitter feedback on this session included:
@kriswager: We work to keep the fear alive. We are bogeymen @FuzzyNop on the role of his team when looking for security problems #qconlondon
@kriswager: Security is not just about writing code without bugs, but also about all other aspects that goes into developing - @FuzzyNop #qconlondon
@kriswager: We can never have perfect security but we can think like an adversary and try to see the hidden issue - @FuzzyNop #qconlondon
@kriswager: Social engineering is not just another way of lying. It can be positive according to @FuzzyNop #qconlondon Probably not in security context https://t.co/QrDK01iQ9Q
@kriswager: Then they start threating to drone strike my house @FuzzyNop on making fun with IRS phone call scams #qconlondon
@kriswager: Truth by @FuzzyNop #qconlondon Is this really surprising? That has happened since before the www. https://t.co/S4xqsdDMwh
@kriswager: Powershell is great for admins etc, but it is much more useful for hackers - @FuzzyNo #qconlondon but there are similar tricks on all OS
@kriswager: Continuous integration setups are pretty bad when it comes to security according to @FuzzyNop they're often not set up secure #qconlondon
Making the Most out of a Bad Day as a Developer
by Wim Remes
Twitter feedback on this session included:
@kriswager: Groundhog day becomes the everyday life of penetration testers. Same problems show up time after time - @wimremes at #qconlondon https://t.co/PN0oT94IwB
@kriswager: Developers don't go to work, thinking "today I want to do insecure code", but security ppl might begin to think this @wimremes #qconlondon
@kriswager: You have to set clear expectations when doing security bug hunting, otherwise you'll spend a lot of time debating… https://t.co/PenVmNiBxI
@alexwlchan: “What you can write is worse than what already exists” — @wimremesaka don’t roll your own crypto. No, really, don’t. #qconlondon
@kriswager: SSL is difficult to work with for a reason - @wimremes #qconlondon Don't disable it, even in test
@kriswager: You need to be able switch crypto algorithms and hashing methods in your code, so you can switch when compromised - @wimremes #qconlondon
@kriswager: You need people with different skills matching the different parts of penetration test scope - @wimremes #qconlondon
@kriswager: Penetration test reports should look at classes of bugs rather than individual bugs - @wimremes #qconlondon helps uncover same type bugs
@alexwlchan: “Security for third parties is not solved by 400-question questionnaires” — @wimremes #qconlondon
@kriswager: I used to believe in [security] awareness. Unfortunately I have found that it does work - @wimremes #qconlondon
@kriswager: Risk awareness is expensive and is undone by the actions of just one person. Risk exposure is almost unaffected - @wimremes #qconlondon
@kriswager: Security tend to focus on state actors, but those will always get you, so focus on other levels - @wimremes #qconlondon
@kriswager: What are we protecting? is an important question to ask before looking for vulnerabilities - @wimremes #qconlondon
@kriswager: Sometimes you have things in your system which is not obviously valuable for you but is valuable for a hacker @wimremes #qconlondon
@kriswager: You transfer risks you can't fix to the user through end user agreements- @wimremes #qconlondon #ProbablyJoking
@m4tthall: Complexity is the enemy of #security #qconlondon
@kriswager: Security teams are, at best, an advisory team. Dev teams own security. @wimremes #qconlondon
Out of the Browser Into the Fire
by Joe DeMesy
Michele Ricciardi attended this session:
Joe DeMesy spoke about how to exploit vulnerabilities in hybrid apps to download files or to gain shell access to a victim's machine. This was both amusing and terrifying.
The exploits used vulnerabilities in Web Views inside native applications and also frameworks like Electron and Apache Cordova. If you use any of these frameworks or a WebView inside your native apps I really urge you to verify you have all the safeguards in place such as sanitizing your inputs, use CSP policies and everything else you may implement to keep a web application secure.
As Joe explained, when you use any of these technologies you have all the APIs that a browser has, but so does the attacker.
Think about the Audio/Video, Geolocation APIs etc. etc. as well as the ability to use the file:// protocol or even establishing connections using WebSockets! Whilst in a fully fledged browser you may get a permission request when the window is trying to access some of those, you may not be prompt with the same permission request in a WebView.
If by this point you're still not tempted to double-check your application, you will after looking at this GitHub project called Little Doctor.
Softskills: Essential Skills for Developers
Building a High Performing Team
by Patrick Kua
Twitter feedback on this session included:
@ouertani: Conflict is part of high performing teams #qconlondon https://t.co/lohbKE0hHK
@Geek_Manager: Individual incentives can sometimes destroy the qualities we want in a high performing teams @patkua #qconlondon
@bunufi: Shared goal, meaning, conflict and leadership are ingredients of a high performing team. #qconlondon @patkua https://t.co/Dmq2SdMHOt
@Geek_Manager: Devs who don't want to talk to each other have git commit wars ... Refactoring each other's code passive aggressively @patkua #qconlondon
@Geek_Manager: When a team has multiple different ideas run spikes ... Of each other's suggestions @patkua #qconlondon #genius
@Singsalad: Characteristics of unhealthy and healthy conflicts in teams with @patkua #qconlondon https://t.co/qiKmFV1dAN
@kriswager: Conflict is part of a high performance team, but it has to be healthy conflict according to @patkua #qconlondon https://t.co/9NOlB6s19z
@Singsalad: Ask people what they care about when you define your team's ways of working - @patkua at #qconlondon https://t.co/vOOSnvIIkv
@Geek_Manager: High performing teams use- ways of working (expectations)- retrospectives (create safety)- feedback (peer-to-peer)@patkua #qconlondon
@kriswager: When people give feedback they often try to increase their impact by making the other person doing something - @patkua #qconlondon
@Geek_Manager: Effective feedback:- peer-to-peer- more frequently- strengthen confidence and have more impact- share perceptions @patkua #qconlondon
@Geek_Manager: It's up to the person _receiving_ feedback to decide what to do with it (or not) @patkua #qconlondon
@Singsalad: This is so important - encouraging leadership at all levels @patkua at #qconlondon https://t.co/tixaTv7gyK
@haacked: I like to frame feedback as strengthening confidence or improving impact. - @patkuaI love this framework! #qconlondon
Creating Space to Be Awesome
Twitter feedback on this session included:
@kriswager: Something I made went into space when I was 16. It has been downhill since then - @Geek_Manager #qconlondon 2/2
@haacked: At their core good managers are shot umbrellas and protect their people from the crap around them. - @meriwilliams #qconlondon
@Singsalad: Data based advice on leadership recommended by @Geek_Manager at #qconlondon - Reading "First, break all the rules" https://t.co/eRm46ULjkn
@mrmlk: #qconlondon do I get to do what I do best every day. @Geek_Manager
@Singsalad: Make people amazing at what they're good at instead of mediocre at what they're bad at @Geek_Manager at #qconlondon https://t.co/aQLz6W0kTE
@tsunamino: Managers- if you call people "resources", they get to call you "overhead". @Geek_Manager #qconlondon
@tsunamino: Managers are usually in either the top right or bottom left of this @Geek_Manager #qconlondon https://t.co/jC9JedBDAX
@kriswager: Most managers either are micro-managing or completely hands-off but there are other squares - @geek_manager… https://t.co/96IXDJTRAO
@Singsalad: Evaluating a workplace- sums it up quite nicely: "someone like me can be successful here" @Geek_Manager #qconlondon https://t.co/77PIQNQJHU
@evilpilaf: You can learn anything you want to learn, except how to care @geek_manager #qconlondon
Lending Privilege
Twitter feedback on this session included:
@haacked: Leonard Nimoy was for equal pay for equal work before it was cool. @anjuan #qconlondon
@tsunamino: Diversity is sending invitations to your party, inclusion means your guests feel welcome @anjuan #qconlondon
@kriswager: Leonard Nimoy provides an example on how people can lend their privilege to help other people - @anjuan #qconlondon
@tsunamino: Inclusion means you have empathy and respect for people's differences - this takes effort @anjuan #qconlondon
@tsunamino: The Cathedral and the Bazaar is the first example of inclusion in tech @anjuan #qconlondon
@alexwlchan: “It is far more powerful to lend your privilege to someone who lacks your privilege” — @anjuan #qconlondon
@kriswager: Lending privilege is not just something you try once. It has to be a philosophy of life - @anjuan #qconlondon
@kriswager: The Founding Fathers build in a pull request system in the Constitution. It is called amendments - @anjuan #qconlondon
@alexwlchan: “I’m not sure the Magma Carta had a Creative Commons license, but I thought I’d add some attribution.” — @anjuan #qconlondon
@tsunamino: When we make tech inclusive, we all win because we no longer put limits on our industry @anjuan #qconlondon
@kriswager: Most people know somebody who has been through the justice system @anjuan I think this is more common in the US than outside #qconlondon
@kriswager: Good point by @anjuan. The way we write job descriptions can be a barrier #qconlondon I need to look into this when I get back home
Shaving My Head Made Me a Better Programmer
by Alex Qin
Twitter feedback on this session included:
@kriswager: Why don't you become a really badass programmer advice by male friend to @alexqin #qconlondon 1/2
@kriswager: Unsurprisingly this didn't work. @alexqin became one, but still didn't get any respect. #qconlondon 2/2
@lithinn: @alexqin describes so well how women are looked at among programmers. The less feminine you look, the more respect you get? #qconlondon
@kriswager: By shaving her head @alexqin was suddenly considered a good programmer by others #qconlondon #shavedmyhead https://t.co/22t7vIjLyF
@kriswager: Real measurable results will only happen if everyone is completely committed to it. Important message by @alexqin #qconlondon
@kriswager: Bad reasons to care about diversity/equality according to @alexqin #qconlondon I agree. I care because it is right… https://t.co/dWB34wtook
@kriswager: Remember to amplify underrepresented groups rather than speak on their behalf - a good reminder by @alexqin #qconlondon
@kriswager: Let's do inclusion work like we do programming. It is OK to make mistakes as long as you learn from them. - @alexqin #qconlondon
@kriswager: Lack of diversity happens by accident, however a inclusive/diverse environment happens on purpose - @alexqin #qconlondon
@burythehammer: Tips for interviewing with inclusion in mind #qconlondon @alexqin https://t.co/PAxAHULE91
Workhorse Languages, Not Called Java
Building a Bank with Go
by Matt Heath
Samuel Lesuffleur attended this session:
We were very excited to attend to this talk by Matt Heath, a Distributed System Engineer at Monzo. First, we (many of us at Sandtable) are early users of Monzo and we love it! Secondly, we are particularly interested by the Go language: it is a good candidate to replace Python for some of our microservices. We were not the only ones to attend this talk (the room was full) and to appreciate it (it was given one the best rating of the day’s talks). Go has an excellent concurrency abstraction, is statically typed and has a managed memory. That’s why it’s a good candidate for simple and small network services. We were happy to get an overview of the Monzo stack and well… as a user, we can confirm it works well!
Twitter feedback on this session included:
@danielbryantuk: Why use @golang to build @monzo bank? @mattheath explains at #qconlondon https://t.co/E8xC9MldS5
@danielbryantuk: Interesting to hear that @monzo are running @golang binaries in scratch @docker containers, running on @kubernetesio @mattheath #qconlondon https://t.co/aCqWcKArFq
Testing Programmable Infrastructure with Ruby
by Matt Long
Twitter feedback on this session included:
@danielbryantuk: "Programmable infrastructure is awesome, but we should invest more in automated testing in this space" @burythehammer #qconlondon https://t.co/QdO1QoeAD1
@danielbryantuk: What do we want to validate with infrastructure testing? Thoughts from @burythehammer at #qconlondon https://t.co/k9KUlVhmcv
@danielbryantuk: Unit and integration testing for programmable infrastructure, with @burythehammer #qconlondon https://t.co/dCgzAM1JbE
@danielbryantuk: Good to see that both @cucumberbdd and Ruby still being recommended for testing, this time for programmable infrastructure https://t.co/e0PuKhAIBV
@danielbryantuk: Mapping the test pyramid to infrastructure testing... with @burythehammer at #qconlondon https://t.co/I0NAn2YdVQ
@danielbryantuk: The good, the bad, and the ugly with testing programmable infrastructure... with @burythehammer at #qconlondon https://t.co/IZncRSUQkf
@danielbryantuk: As a tester, building infrastructure has helped me gain mechanical sympathy for what happens within cloud tech @burythehammer #qconlondon https://t.co/xjt9s92UeP
@danielbryantuk: We must strive to test programmable infrastructure @burythehammer #qconlondon https://t.co/qzeGIyTXgn
Why We Chose Erlang over VS. Java, Scala, Go, C
Aaron Bourne attended this session:
- Develops Outlyer monitoring system
- Version 1 was a MEAN stack monolith with a Python data collection agent
- Version 2 was microservices
- Focus on separating stateless behavior services from stateful services for scaling reasons
- Uses RabbitMQ for async communication between services
- Uses Riak for time series data
- Added a Redis cache layer to improve performance
- Erlang the movie?
- Erlang uses the Actor Model, let it crash!
- Erlang has pre-canned “behaviors“
- Erlang has an observer GUI — allows for tracing and interaction with a live application
- Erlang offers live code reload
- Erlang has a supposed weird syntax
- Elixr is a newer language that runs on the Erlang VM — supposedly has a syntax more like Ruby
- Mentions using DalmatinerDB
- Outlyer blog for more information
Sponsored Solution Track I
Continuously Delivering Security in the Cloud
by Casey West
Aaron Bourne attended this session:
- A moving target is harder to hit so regularly create and destroy containers — this helps to ensure an attacker does not gain persistence
- Secrets can be rotated using a secrets manager like Hashicorp’s Vault
Twitter feedback on this session included:
@DanielSawano: The future of security is build pipelines. @caseywest #qconlondon
Workshops
Paradigms Lost, Paradigms Regained
Twitter feedback on this workshop included:
@bunufi: Great quotes at #qconlondon @KevlinHenney https://t.co/uZknS81HpQ
@dthume: The use of the word "pragmatic" often means "not" (e.g. Pragmatic agile == not agile) - @KevlinHenney at #qconlondon
@FarzadJalali: If it's not necessary to change , it's necessary not to change !#qconlondon #paradigmlost #paradigmregained
@bunufi: 'You have already written all of the loops you need in your life.' @KevlinHenney #qconlondon
Opinions about QCon
Impressions expressed on Twitter included:
@caseywest: I get to see this on my walk to #qconlondon each morning. ?? https://t.co/3tbp1DToNh
@RogerSuffling: Great tech talks and fantastic views #qconlondon https://t.co/u8Ybj9zmHC
@graph1ZzLle: Thumbs up #qconlondon for great organization and food quality
@goforcd: #qconlondon volunteers - looking stunning today https://t.co/FGKACAaKgU
@neilpadgen: You know it's a good conference when you sit in the wrong room and the talk is *still* fascinating #qconlondon
@fergoid: What I like most about QCon is that after 11 years it still provokes and still takes the pulse of tech. #QCONLONDON
@gerryhatric: #qconlondon is superbly challenging my mindset this year.
@alexwlchan: So speaking at #qconlondon was an unexpected treat. Everybody’s been so friendly. ??
Takeaways
Aaron Bourne’s takeaways were:
As a longtime reader of InfoQ, QCon has always been on my radar. In its 11th year, I managed to attend QCon London. … Overall, I found the conference to be of a superbly high quality. The talks were relevant and well delivered, the venue ideal and the food abundant.
Santoro Simon’s takeaways were:
What is QCon?
- key topic: performance
- keywords: serverless, automation, scaling, iot, containers, git, devops, ci, mobile, javascript
- more keywords: drive change, innovation, diversity and equality in the workplace
- waterfall is absolutely dead: agile/scrum is what it is since 2008. since 2012 it's about scaling agile and scrum.
- soap is absolutely dead. nobody even mentioned it. rest/swagger is what it is.
Samuel Lesuffleur’s takeaways were:
- Dedicate some time to learning new stuff, trying new technologies, testing tools.
- Pay attention to history, look at (relevant) academic papers, read more and more books.
- Monitoring is essential, better understanding of the system.
- Design for failure.
Alfa Systems’ takeaways were:
As usual, we had a great time at QCon and we will use what we learned to help us improve our products and services. This year, we’ve picked out many of the sessions that were directly relevant to our cloud hosting offering at Alfa, but we also took away how to attract and build diverse teams, tips on optimizing Java performance, machine learning techniques, and an idea of what the future of the internet of things looks like. See you next year, QCon.
Takeaways from QCon London included:
@dthume: Another #qconlondon over. As ever, I doff my hat to the fantastic @qconlondon and @QEIICentre staff.
@g_dudek: It was amazing conference! Thx #qconlondon https://t.co/nbtJ5zaP6B
@frathgeber: What a week @qconlondon @QEIICentre learning about #containers #performance /f @LMAX @github @Spotify @Google… https://t.co/T2DyXyblI8
@limestream: And today the post #qconlondon hangover struck with full power. Luckily I have a couple of videos left to look at.
@tomkriech: what a busy week at #qconlondon #GB perfect organization. just back in #AT again; have to discuss several topics with my colleagues
Conclusion
InfoQ produces QCons in 5 cities around the globe. Our focus on practitioner-driven content is reflected in the fact that the program committee that selects the talks and speakers is itself comprised of technical practitioners from the software development community. This week QCon will be in Sao Paulo. We're then in New York in June, Shanghai in October and San Francisco in November. We'll be back in London on March 5th 2018.