BT

InfoQ Homepage Articles Key Takeaway Points and Lessons Learned from QCon London 2020

Key Takeaway Points and Lessons Learned from QCon London 2020

Bookmarks

QCon returned to London this past March for its fourteenth year in the city, attracting over 1,600 senior developers, architects, data engineers, team leads, and CTOs. The session recording publishing schedule can be found on the QCon London website.

The conference opened with Alasdair Allan, setting the scene with "The Internet of Things Might Have Less Internet Than We Thought." Allan highlighted areas where software adds value to our daily lives — everything from smart light bulbs to virtual assistants. However, he also outlined the challenges and negative failure modes and provided motivation for writing effective (and secure) software for IoT products, edge devices, and consumer goods.

Our day two keynote from Anjuan Simmons focused on "Technical Leadership through the Underground Railroad." Simmons used a historical lens to look at the importance of leaders and their associated skills when working within software projects. Sharing the technical vision, working to be constantly prepared, and being bold with your actions are all vitally important regardless of what type of software is being delivered.

The third day of QCon London contained two keynotes. The morning keynote was presented by Katie Gamanji, and discussed the "Interoperability of Open-Source Tools: The Emergence of Interfaces." Gamanji provided insight into the current cloud technology landscape and explored the evolution of related interfaces that is being driven by the Kubernetes and Cloud Native Computing Foundation (CNCF) communities.

In the evening, QCon London closed with a superb keynote from Prof Richard Wiseman, where he presented "The Apollo Mindset: Making Mission Impossible, Possible." Wiseman provided a historical overview of NASA’s Apollo project and argued that we should all aim for the stars. He stated that seemingly impossible goals can be achieved if we approach them "one step at a time."

Over the initial three days of the conference, the major trends in modern software development were well represented across the 18 individually curated tracks. The QCon London 2020 tracks featured deeply technical topics such as next-generation microservices, streaming data pipelines, cloud and Kubernetes, machine learning/AI, developer experience, architecture, modern language innovation, and more.

In addition to featuring technical leaders and software engineering practitioners from popular technology organizations, like Docker, Deliveroo, Monzo, IBM, BBC, and the FT, the conference included other practitioners from the resilience engineering and psychology fields. Dr. Laura Maguire provided a fascinating insight into the costs of coordination during outages and production incidents. Andrea Dobson-Kock discussed balancing risk and psychological safety, and how to use insight from this field to build learning organizations. In total, the conference featured 174 speakers (a 9-1 attendee to speaker ratio) over the three days of the conference.

Workshop sessions on days 4 and 5 included a remote meeting masterclass, introduction to AI/ML for software engineers, tech lead skills for developers, and courses on designing, building, and debugging microservices. Several additional workshops provided a deep-dive into specific technologies, such as Terraform, Istio, Docker, Kubernetes, Apache Kafka, and Java.

InfoQ had a number of editors at the event, and you can read the QCon London news coverage online. We’ve already started making the videos and complete transcripts from the event, available online.

This article summarizes the key takeaways and highlights from QCon London 2020 as blogged and tweeted directly by the attendees that were there.

 

Keynotes

Interoperability of Open-Source Tools: The Emergence of Interfaces — by Katie Gamanji

Twitter feedback on this keynote included:

@danielbryantuk: There are clear benefits for creating appropriate abstractions. For example, the CRI in @kubernetesio. Firm foundations support innovation @k_gamanji #QConLondon https://t.co/nCClLVPhKl

@wesreisz: Cluster API lets you provision clusters in a standard way. From AWS, GCP, to China’s Baidu. Clusters as a resource? Infrastructure as Code #FTW #QConLondon @k_gamanji https://t.co/7Kx5Fa8Jez

@charleshumble: For more from @k_gamanji, our awesome #qconlondon keynote speaker this morning, I recommend checking out this podcast… https://t.co/hk4lS92O1I

Technical Leadership through the Underground Railroad — by Anjuan Simmons

Twitter feedback on this keynote included:

@charleshumble: Leadership lessons 1: Prepare your incentives before you need them. "I like to give people time—give them the opportunity to work on something they love." –  @anjuan #qconlondon

@jagdipgrewal: Interesting kickoff for #QConLondon day 2 using the underground slave railroad to help slaves escape to align with today’s software development teams, hierarchy, and leadership. Thanks for reminding us of the harsh history @anjuan... and incentives which can help today https://t.co/HMQdmtFmwz

@charleshumble: Leadership lesson 2: Bold actions set the tone. @anjuan #qconlondon

@danielbryantuk: This isn’t a standup, this is a Shakespearean play @anjuan on over long status meetings. Be bold, take action to make changes#QConLondon https://t.co/kkWlPtPygO

@charleshumble: You’ve all had to lead a team through deep woods, maybe JavaScript. Don’t let your experience bias you. As a leader, you can get a big ego—put it aside. @anjuan #qconlondon

@charleshumble: Embrace continuous solving. In leadership, the same problems will come up again and again. Problems never die, only people do. @anjuan #qconlondon

@charleshumble: You are a leader of leaders. You use tools every day that [they] didn’t invent. You are working [with] very smart people. You have to trust them to solve problems. @anjuan #qconlondon

@ellerenad: #Qconlondon day 2: @anjuan told us the story of the underground railroad (https://t.co/Q0tYHccJuN) and showed us how to learn about leadership by looking at the history — even if the history is legacy code

The Apollo Mindset: Making Mission Impossible, Possible — by Richard Wiseman

Twitter feedback on this keynote included:

@wesreisz: The closing keynote at #QConLondon gets summarized perfectly by the incredible @RichardWiseman. When asked how do we get to the moon, one of the mission controllers said, "The same way you get anywhere... one small step at a time." Seems appropriate, no? https://t.co/UvinlqoRNG

@AnnaWeakclaw: Very inspiring talk to end #qconlondon by @RichardWiseman. -Find your passion -Work as a team -Pre-mortem: How could this fail? -Stop talking and start doing -Talk about mistakes -Do the opposite of what everyone is doing -Know your purpose: Who will benefit from your work? https://t.co/68p9jJMugu

The Internet of Things Might Have Less Internet Than We Thought? — by Alasdair Allan

Alex Blewitt attended the keynote:

… The first half talked about how a failure in a consumer product shouldn’t have a failure mode of a dead cat, (unlike some commercial providers whose pet-feeding devices had a failure that they forgot to dispense food for over a week). In particular, he looked at running TensorFlow on low-power devices, like Raspberry Pi. He has a blog post talking about running TensorFlow on various devices, highlighting that the new Raspberry Pi 4 is sufficient to do machine learning tasks, and the even lower-power spark fun edge which can do machine learning while powered with a CR2032 like a button battery. Seriously impressive stuff!

Twitter feedback on this keynote included:

@wesreisz: The Web gives us the appearance of being free. They’re not. They’re paid for with our data. @aallan #Qconlondon

@wesreisz: @aallan On failure modes and the Internet of Things... "The cat died should not be a failure mode for your app." #QConLondon

@wesreisz: @aallan moving from cloud to the edge. Edge TPU delivering 75 fps vs 2 on the cloud #Qconlondon https://t.co/RCXDoUwnM4

@alblue: Could artificial intelligence be artificially increasing our CO2 emissions? @aallan at #QConLondon https://t.co/EeCrVTKadj

@danielbryantuk: Not everything can or should be run in the cloud @aallan on the benefits of edge computing#Qconlondon https://t.co/sRAYwOHrxe

@sarahjwells: These days a tractor is really just a big computer on wheels. You don’t buy a tractor now. Firms provide ‘licenses… https://t.co/g4wguDdcdO

@wesreisz: @aallan Moving to edge computing is good for privacy. Local processing means less potential data leakage from shipp… https://t.co/gbvsy4jwTT

@alblue: Don’t throw away smart devices that have your WiFi password embedded... @aallan at #QConLondon https://t.co/7M1YltQonP

@ChaoticGloom: Take the data, act on the data, throw the data away. @aallan #QConLondon

@r39132: How resilient are some self-driving cars’ perception systems? You can fool a self-driving car to speed up when seeing a stop sign by adding stickers to the stop sign. via @aallan #QConLondon https://t.co/szLkNKlZ3r

@AnnaWeakclaw: AI and autonomous cars reading this as 45mph speed limit #Qconlondon https://t.co/0Wnp29rEsu

@AnnaWeakclaw: FordPass feature: remote control of your hired car even months after you returned it. Learned at #Qconlondon https://t.co/ni0qij2TbL

Architectures You’ve Always Wondered About

eBPF: Rethinking the Linux Kernel — by Thomas Graf

Twitter feedback on this session included:

@wesreisz: We can replace an #eBPF program atomically without crashing the Linux kernel. @tgraf__ #QConLondon https://t.co/NCoIIrB2Mt

@deniseyu21: I liked this cool talk by @tgraf__! I’m still learning about eBPF, so I definitely didn’t know you could build kernel "modules" with syscall execution hooks with added verification with what eBPF gives you out of the box. Neat stuff! #QConLondon https://t.co/Bz8IbmghLv

@RogerSuffling: Great talk on eBPF and how it’s wired into the Linux kernel. Game changer! Checkout eBPF and all it’s associated projects(@ciliumproject ). It’ll change the way you work and interact with the Linux kernel. @tgraf @qconlondon #Qconlondon https://t.co/nyhD89Z7FV

Evolution of Financial Exchange Architectures — by Martin Thompson

Twitter feedback on this session included:

@berndruecker: People that use primary-secondary in 2020 (instead of census-based systems) need to understand they are dinosaurs and move on! It is shocking how many are stuck in the past! @mjpt777 @qconlondon #QConLondon https://t.co/Uiv6DOQzqU

@wesreisz: Even humans — we all have our own view of state in our heads. There isn’t a global state. We have to achieve consensus. Distributed systems should work the same way. #QConLondon @mjpt777

@wesreisz: Even when a consensus model is formally verified, it takes 2-3 years before a new consensus system can be trusted. These are complex systems. It takes that long to shake the bugs out. #QConLondon @mjpt777

@wesreisz: Fast feedback cycles drive innovation. #QConLondon @mjpt777

@CharlyBones: The key to agile is a fast feedback cycle. Notes from @mjpt777 in #QConLondon

@lithgow: If anyone says they’re doing agile and they don’t understand queuing theory and Little’s law, they’re not doing agile. @mjpt777 @QCon#QConLondon

Lessons from DAZN: Scaling Your Project with Micro-Frontends — by Luca Mezzalira

Twitter feedback on this session included:

@wesreisz: Composing #microfrontends and how you might leverage the infrastructure edge (or where people run CDN workloads). #QConLondon @lucamezzalira https://t.co/S76CbW60Ue

@OutSystemsEng: We have been hearing about #microservices for quite some time as an alternative to monolithic backends. Today we learned with @lucamezzalira how micro-frontends can also be a good alternative to monolithic frontends. @qconlondon #QConLondon #LifeAtOutSystems https://t.co/4JAqU0QrT7

Bare Knuckle Performance

Does Java Need Inline Types? What Project Valhalla Can Bring to Java — by Sergey Kuksenko

Alex Blewitt attended this session:

Kuksenko kicked off a demo with two Java Mandelbrot generators, using a Complex class — but in the case of the faster demo (12fps vs. 5fps), the only difference was the addition of the "inline" keyword. Valhalla provides a denser memory layout for inline class (aka value types), with the plan to have specialized generics. The "inline class" rather than "value" was chosen to make it easier to update the Java Language spec with fewer changes. Inline classes don’t have identity, which means they can’t be compared with == and so avoid problems like Integer.valueOf(42) == Integer.valueOf(42).

An inline class has no identity, is immutable, not nullable, and not synchronizable. The JVM will decide whether to allocate the inline classes on the heap, or whether they’ll be on the stack or inlined into the container class. The phrase "Code like a class, work like an int" summarizes the goal of Valhalla. The performance is about 50% faster, but importantly, has many fewer L1 cache misses. The work on benchmarking the current implementation is in progress, and seems to be under 2% regression at the moment. For any kind of arithmetic types, having Complex inline classes gave an order of magnitude speedup in some cases. The Optional class will be a value class in the future, and will be a proof of concept of a migration path. Work is ongoing to reduce the performance overheads so that it can be available in the future; for the time being, the JDK14 release in the next couple of weeks will have a version available for experimentation.

Twitter feedback on this session included:

@Jim__Gough: "Code like a class, work like an int" @kuksenk0 talking about Valhalla aims. #QConlondon

Maximizing Applications Performance with GraalVM — by Alina Yurenko

Alex Blewitt attended this session:

… Talked about using Graal as an ahead-of-time compiler for generating native images. Not only does starting the application run much faster, it also uses a lot less memory than the equivalent running application under the JVM. Partially this is due to the fact that the C2 compiler doesn’t need to compile the underlying JVM classes, and partially due to the fact that the actual runtime of the application has a far lower total memory layout. Of course, creating an accurate execution profile requires running the application under an expected (simulated) load, so that the correct hot code samples can be identified and thus translated appropriately. Graal uses information gained from the initial execution to prepare appropriate code for expected types; if these assumptions are incorrect, then the executed binary will be different.

Twitter feedback on this session included:

@AnnaWeakclaw: #qconlondon optimize performance with GraalVM -startup speed -peak throughput -low memory footprint -reduced max latency -small packaging. Great talk @alina_yurenko https://t.co/lnwHThsksR

Quarkus — by Sanne Grinovero

Alex Blewitt attended this session:

One of the differences with a JIT enabled language is that there’s a warm-up phase when the application is reaching peak performance; not an issue for long-running applications, but can be a concern if you’re following continuous delivery, redelivering multiple times a day. If you’re deploying every 10 minutes, with every commit, then you may find that the Java application doesn’t ever reach steady-state before being shut down for a new version of the service. Quarkus has supersonic/fast boot. It is designed for GraalVM by default, takes a generated build file and uses a Maven/Gradle plugin to produce the optimized JAR, and uses ahead-of-time compiler, an ELF executable for the GraalVM. It also produces containers with a small on-disk footprint. The hot reload of code makes for a fast turnaround time, and Quarkus is opinionated about how it starts Java — like creating a debug listener on the port at the same time.

Pavel Polívka attended this session:

Maybe I am late to the party, but I discovered Quarkus at this talk. We normally use Spring Boot for our applications and we are happy with it until we want to use it in AWS Lambda. The startup time of the Boot application is so high that we would never use it in lambda.

I would not be afraid to use Quarkus there. The startup time of a REST endpoint application that is connected to a database via Hibernate can be 17 milliseconds. How amazing is that?

Building High Performing Teams

How to Debug Your Team — by Lisa van Gelder

Twitter feedback on this session included:@charleshumble: "Cycle time is a good measure of team performance because there is nowhere to hide. Velocity is not, it can be gamed. In one team I worked on we multiplied our story points by 10; a 3 point story became a 30 point story — and we went 10 times faster!" – @lisa_van_gelder #qconlondon

@charleshumble: Every team is different. Ask questions. Pair with the team. Run retrospectives. @lisa_van_gelder #qconlondon https://t.co/3pbEXtRDxX

@charleshumble: Change is very scary when it is done to you. Given engineers power to control change. @lisa_van_gelder #qconlondon

@charleshumble: Change works best when people can give you hard feedback. So reward that hard feedback, and admit your mistakes. @lisa_van_gelder #qconlondon

@charleshumble: "Sometimes you need outside help. Bring in someone really expensive to say the same thing. You might not need them to see what change needs to be done—perhaps you can see that yourself—but you might need them to get the change done." –  @lisa_van_gelder #qconlondon

@ellerenad: What do you do when your software fails? You debug it! @lisa_van_gelder showed us how to do the same with teams. Key point: high performing teams have mastery, autonomy, purpose, and safety. BUT to have autonomy, mastery and purpose are needed. #Qconlondon https://t.co/8NAg6w2qU9

How to Supercharge a Team with Delegation — by James Stanier

Twitter feedback on this session included:

@sallygoble: @jstanier in High Performing Teams at @qconlondon. Don’t confuse accountability and responsibility when delegating… https://t.co/c4m9b2oD46

@patkua: "Leaders forget there is a sliding scale of delegation. It’s not just two extremes." – @jstanier at #QConLondon So tr… https://t.co/wmsmStmX0q

Optimize for Time — by Andrew Walker

Twitter feedback on this session included:

@rkoutnik: Want to know how an engineering team is doing? Ask them how hard it is to do the simple things. @krakenind #QConLondon https://t.co/97n5V7vLrL

Chaos and Resilience: Architecting for Success

Growing Resilience: Serving Half a Billion Users Monthly at Condé Nast — by Crystal Hirschorn

Twitter feedback on this session included:

@sudoreality: Legacy is the cost of success — it means your company didn’t fail early on. #qconlondon https://t.co/dN4IOaKGIL

@nora_js: "Let’s do some myth-busting, Chaos Engineering won’t eradicate operational surprises." – @cfhirschorn #qconlondon

@holly_cummins: Complexity doesn’t allow us to think in linear, unidirectional terms along which progress or regress could be plotted. –  @cfhirschorn quoting Sidney Dekker at #QConLondon https://t.co/0cJEVLCSHZ

@nora_js: "If we focus too much on tools, we forget about the actual craft of devising chaos experiments." (as an industry we ARE focusing too much on tools) @cfhirschorn nailed it! #qconlondon

Rethinking How the Industry Approaches Chaos Engineering — by Nora Jones

Twitter feedback on this session included:

@danielbryantuk: Even the act of preparing to run a resilience game day can sometimes provide enough value to drive necessary change… https://t.co/uDtpOny4pC

Driving Full Cycle Engineering Teams at Every Level

Should We Really Run It if We Build It? — by Paul Hammant

Alex Blewitt attended this session:

… The idea was to make sure that L1 and L2 support staff are properly enabled through the creation of runbooks, produced by the developer team, and that the dev staff rotates through the L2 support staff so they gain empathy and see how they can improve the product.

Twitter feedback on this session included:

@alblue: "It seemed like quitting at the time seemed the most reasonable thing to do." – @paul_hammant at #QConLondon https://t.co/YRCXThBWB6

@charleshumble: In a toxic environment it tends to be the good people who quit because they don’t have to put up with it. @paul_hammant #QConLondon

@danielbryantuk: Watch out for communication overload and burnout. These are surprisingly common within technology organizations… https://t.co/HsbVEE9tOK

@alblue: "Moving backlog items to one tracking system to another is a total waste of time" – @paul_hammant talking complete sense at #QConLondon

@alblue: At #QConLondon @paul_hammet laying down the truth that minnows have less clout than whales; the same applies for ec… https://t.co/mHKAgXk6pW

@alblue: This is the second time "blameless post-mortems" has come up at #QConLondon today. Make it safe for people to fail… https://t.co/RqHCo5Ppu8

@charleshumble: If you are yelled at by a person in authority, you change behavior for every subsequent interaction with that pers… https://t.co/uQFMVvveak

@alblue: "Success is none of your L2 or L3 staff quitting to get away from their duties," – @paul_hammant on the importance o… https://t.co/3faenwyVx1

Evolving Java

A Year with Java 11 in Production! — by Andrzej Grzesik

Alex Blewitt attended this session:

Andrzej Grzesik, better known as "ags," talked about the path that Revolut had in migrating to Java 11 over the last year. They moved over to Java 11 as the compile engine and as the runtime engine for all of their apps over the year, following up with various bugs reported against OpenJDK as they went through, and some of the pitfalls of their experience. The main one seems to be updating all of the dependent libraries and build tools; for example, moving from Gradle v3 to Gradle v4 and v5, a step at a time. They are keen to try keeping up with the latest JDK releases, although their use of Gradle and more specifically Groovy is holding them back from migrating at the moment. Making sure that all of the dependencies worked seemed to be the biggest challenge, though most (non-abandoned) Java libraries work at this stage.

Java in Containers: Part Deux — by David Delabassee

Alex Blewitt attended this session:

David Delabassee gave an overview from Oracle about how to best drive Java applications inside Docker containers. His examples and slides (to be uploaded later) showed how to use a multi-stage Docker build along with jlink and the --no-man-pages and --no-header-files along with compression to build a custom base image which was about 20% of its original size. He also highlighted using Alpine as a distribution and Musl as a replacement for glibc, but noted this wasn’t officially supported; project portola aims to provide a means to do this in the future. By using AppCDS he was able to shrink the launch time down further, and talked about the evolution of Docker and docker rootless.

Modern Banking in 1500 Microservices — by Matt Heath & Suhail Patel

Tim Anderson attended this session:

Monzo’s session at QCon was in stark contrast to Monday’s presentation in which Sam Newman warned that a microservices architecture is a "last resort." Senior engineers Matt Heath and Suhail Patel described how microservices work well for the bank, founded in 2015 and now with over 4 million customers.

As a new business that hoped to grow substantially, Monzo had a requirement for a technology platform that was extensible, scalable, resilient and secure. The idea was to start with a few basic banking services, and then be able to add more as time and resources allowed.

Monzo was convinced early on of the value of a distributed system. The bank did not want a single, big resilient system with a complex failover that you hope never has to run.

On the coding side: "We use Go as our primary programming language," said Heath. "It’s quite simple, it’s statically typed, and it makes it easy for us to get people on board." Go has a backward-compatibility guarantee, meaning that when a new version appears, you can simply recompile existing code, getting the benefits of updates to features such as the garbage collector. Go is also well suited to strict policies about error handling.

"We have static analysis to make sure that you are not papering over errors," said Patel.

Each Monzo microservice runs in a Docker container. "One of our biggest decisions was our approach to writing microservices," said Patel. There is a shared core library, which is available in every service; this is essentially copied in every container, though the build process will strip out unused code. This means that "engineers are not rewriting core abstractions like marshaling of data." It also enables metrics for every service so that after deployment it immediately shows up in a dashboard with analysis of CPU usage, network calls and so on. Automated alerting will identify degraded services.

How do developers work on their code, given that running 1,600 microservices is not going to work on a laptop? "You are running a subset," said Heath. "We have an RPC filter that can detect you are trying to send a request to a downstream that isn’t currently running, it can compile it, start it, and then send the request to it."

Why do microservices work for Monzo, whereas in some cases they add complexity without delivering much benefit? The Register has attended many QCon events, and while software development trends have changed from year to year, some things have remained consistent. One is that the way developers interact with each other in a team (and with management) counts for more than whatever development methodology they espouse. Another is that an incremental approach wins over occasional large changes. "An iterative process is generally what we take to heart at Monzo," said Heath, "both from an infrastructure perspective but also from a product perspective. By making small changes frequently we make sure we are going in the right direction."

Heath and Patel made a great case for the value of microservices. Note, though, that Monzo uses a lot of custom, in-house tools and libraries that are not easy to replicate. Further, many of the principles they presented — like writing clean, readable and disciplined code, focusing on a few carefully chosen pieces of technology, and taking an incremental approach — are winners in any software architecture.

Kubernetes and Cloud Architectures

A Kubernetes Operator for etcd — by James Laverack

Twitter feedback on this session included:

@cfhirschorn: Scaling up was easy but scaling down was a much harder challenge. You want to destroy/clean up resources but the PVC also remains. If you scale down then back up again, it can inadvertently pick up stale data and config. We solved this with a "finalizer" hook. #QConLondon https://t.co/6rev8myZeX

Cloud Native Is about Culture, Not Containers — by Holly Cummins

Twitter feedback on this session included:

@cfhirschorn: Reasons for *not* choosing Microservices: -small team -not planning to release independently -don’t want comp… https://t.co/OAcmkmshTz

@cfhirschorn: CI/CD is something you do, not a tool that you buy." – @holly_cummins #QConLondon https://t.co/muHsHJbLuU

@cfhirschorn: It’s a bit too easy to spin up new infrastructure...and forget about it. YESSSS happens so much! This is why I’d r… https://t.co/NfDXTRDYkk

Kubernetes Is Not Your Platform, It’s Just the Foundation — by Manuel Pais

Twitter feedback on this session included:

@danielbryantuk: Kubernetes is not your platform. It’s the foundation... @manupaisable #QConLondon https://t.co/VwofolMhGR

@danielbryantuk: Cognitive load is the total amount of mental effort being used in the working memory. We want to reduce the cognitive load. @manupaisable #QConLondon https://t.co/u2gFioRyj0

@danielbryantuk: Agreed!! -> "Treat your [infrastructure] platform as a product." – @manupaisable #QConLondon https://t.co/AM5BFOpf4K

@danielbryantuk: Guidance from @manupaisable on adopting a new platform, both from a technical and organizational perspective. #QConLondon https://t.co/1ODcNDYbla

Lessons Learned from Reviewing 150 Infrastructures — by Jon Topper

Twitter feedback on this session included:

@danielbryantuk: 79% of teams using the cloud well-architected framework score "high risk"’ in planning for disaster recovery...https://t.co/mq5PFPom3S

@danielbryantuk: It’s all too easy to accidentally check dotfiles into version control with cloud API keys. This can result in a la… https://t.co/Hoikr5gTlO

@danielbryantuk: Resilience practices scored badly with two-thirds of companies having "critical improvements needed" scores. No tea… https://t.co/zEixizjrlm

@danielbryantuk: Although the industry has adopted the CI and CD tooling, it would appear that we are still working with large batc… https://t.co/H8KKZWYRe8

@KaraMarck: Interesting CI/CD stats #QConLondon @jtopper : Most teams have adopted CI/CD tooling, but many are still making big… https://t.co/OyDc6VQw4A

@patkua: Key learning from evaluating 150 cloud architectures by @jtopper #QConLondon "Teams are bad at thinking about failure… https://t.co/mJZGmUmZh7

@patkua: And consequently "Teams are bad at monitoring for failure modes." – @jtopper #QConLondon https://t.co/RodEoXzigj

@patkua: On top of that, #security is a big topic too. #QConLondon https://t.co/FpM0AKWY4Z

@cfhirschorn: Security is still poorly implemented and understood in most organizations. Jon pulls out some of the top OWASP vuln… https://t.co/4EsUZ7n1ky

@danielbryantuk: This is the hot take well-architected cloud slide from @jtopper at #QConLondon "Everyone is better at building pl… https://t.co/IGqJZTmebF

The Evolution of Distributed Systems on Kubernetes — by Bilgin Ibryam

Twitter feedback on this session included:

@cfhirschorn: @bibryam dives into the Dapr architecture. This is quite an exciting addition to the Kubernetes ecosystem! Strengths are bindings, providing state abstractions, managing pub/sub, and instrumenting observability such as distributed tracing. #QConLondon #Kubernetes https://t.co/CwDx92qENS

@cfhirschorn: @bibryam predicts that the next pattern to emerge will be a Multi-Runtime architecture. Dapr and Envoy are the two projects getting close to realizing this goal. #QConLondon https://t.co/YImhOveBy8

@holly_cummins: What comes after microservices? @bibryam predicting a pullback from function-as-a-service towards coarser granularity, but with infrastructure concerns handled with off the shelf and isolated to their own containers (or sidecars): "mecha-architectures" #QConLondon

Leading Distributed Teams

Remote Working Approaches That Worked (And Some That Didn’t) — by Charles Humble

Twitter feedback on this session included:

@anjuan: IBM and Yahoo are two examples of big companies that tried remote work but reverted back to co-located teams… https://t.co/RwPDISsWWQ

@anjuan: Other advantages of working remotely. #QConLondon https://t.co/3DN5oCXSOG

@anjuan: However, for every advantage of remote work, there’s a downside. Flex time can be dangerous if you’re a procrastinator. You mitigate this by being disciplined. GTD, Omnifocus, and Pomodors are examples of techniques and tools. #QConLondon https://t.co/1e7jzALHNx

@danielbryantuk: Many great examples for succeeding when remote working, from @charleshumble at #QConLondon https://t.co/EKBMEwXJQf

@anjuan: Having no commute means that you have less time for the things you did on your commute. Mitigation: schedule time for yourself. #QConLondon https://t.co/oN0XBuhAmk

@anjuan: Freedom to tailor your office means that you can accrue a big bill building out your home office kit. #QConLondon https://t.co/jTaEIpze6q

@anjuan: The ability to work alone may result in feeling lonely. Make building a social life a top priority. #QConLondon https://t.co/uREuRHubJl

@anjuan: Hiring is hard and remote work can make it harder. Onboard with great care. #QConLondon https://t.co/qIGD0R5DkT

@anjuan: Trust and transparency are critical for remote work to be successful. #QConLondon https://t.co/HizyxP5LBI

@herecomesjaycee: "Transparency starts at the organizational level, not on the personal level." – @charleshumble #QConLondon https://t.co/U3RL6ZMBJx

@anjuan: C4’s remote company meeting cadence. #QConLondon https://t.co/BqpqJKd7Zu

@anjuan: Tooling for remote companies. #QConLondon https://t.co/spaW0k1vRE

@anjuan: Scaling a remote company requires a strong commitment to documentation. #QConLondon https://t.co/pyvkIwrzQV

@anjuan: A great wrap to a great session at #QConLondon! https://t.co/G6ofOaSQhI

Tough Call: Handling "Difficult" Remote Conversations Like a Pro — by Judy Rees

Twitter feedback on this session included:

@anjuan: Remote work as a combination of skillset, mindset, and toolset. #QConLondon https://t.co/bYeUEgKGSf

@charleshumble: The quality of your attention can determine the quality of another person’s thought. @judyrees quoting Nancy Kline at #QConLondon.

@charleshumble: If you are in a conversation with someone and they are angry, listen to what they are angry about. Then you can as… https://t.co/rO8owQDtI0

@anjuan: Skills for Remote Meetings. "Paying attention to what people are doing enables you to know what they’re thinking a… https://t.co/mMevtMSs50

@charleshumble: "People seem to think that excellence is only open to others, not themselves." – @judyrees quoting Laszlo Polgar #QConLondon

@sarahj0wells: A periodic table of business meetings at @judyrees #Qconlondon https://t.co/cBZf5lZUbm

@charleshumble: Some handy links on remote meetings from @judyrees #QConLondon https://t.co/6OiPlmezcn

@charleshumble: For more on Remote Meetings, this eMag was curated by @judyrees and is well worth a ready — free, but does require regis… https://t.co/6uVxIiBeiv

Next Generation Microservices: Building Distributed Systems the Right Way

Beyond the Distributed Monolith: Rearchitecting the Big Data Platform — by Blanca Garcia-Gil

Twitter feedback on this session included:

@AnnaWeakclaw: #qconlondon #BBC processes billions of messages per day, they used #Microservices+big data. Benefits: 1. Team can choose tech fit for purpose. 2. Easier to change and replace. 3. Isolated failures. 4. Organic system growth. Thank you for sharing your experiences. @blanquish

@ellerenad: @blanquish shared with us their experience redesigning a big data platform at the BBC, my main takeaways: 1) Design to not let a single failure stop the whole data pipeline. 2) Empower your team to operate, so that even the new members can do it. #QConLondon https://t.co/q4M7PaY2is

Monolith Decomposition Patterns — by Sam Newman

Tim Anderson attended this session:

Sam Newman, author of Building Microservices and Monolith to Microservices, told attendees at the QCon developer conference in London that  "microservices should not be the default choice."

Microservices have become today’s equivalent of "nobody ever got fired for buying IBM," a common catchphrase back in the ‘80s, said Newman. "With half of all the clients I have worked with, I have told them microservices are not for you."

In case you should doubt him, another session at QCon described how Segment, a data analytics company based in San Francisco, went "to microservices and back again…"

The implication is not that microservices are no good, but that developers have adopted them too readily, persuaded by the benefits. The idea of microservices is that decomposing an application into small independent services makes it possible to update it more quickly and safely and to scale more efficiently, whereas applications that are compiled into a single large executable — monoliths — require all-or-nothing deployments that are harder to coordinate.

Explaining the benefits of microservices, Newman said, "There are lots of reasons why we might pick a microservices architecture, but the one I keep coming back to is this property of independent deployability."

"Monolith has become a replacement for the term we used to use, which was legacy. It’s a problem because some people are starting to see any monolith as something to be removed. That’s deeply inappropriate. The monolith is not the enemy. This is not the problem that you’ve got."

Given that microservices are not the right solution in every case, what are the clues that an existing monolithic application might actually be a good candidate for decomposing into microservices? "You’ve tried all the easy stuff," Newman told The Register. "Have you done some value chain analysis? Have you looked at where the bottlenecks are? Have you tried modularization? Microservices should be a last resort."

Even scalability may not be a good enough reason to adopt microservices. "My clients say, my application doesn’t scale. I ask, have you tried running 10 copies of your monolith? And they haven’t. Do all the easy stuff first."

Alex Blewitt attended this session:

He discussed the ability to refactor in-place from a monolith to a modular monolith, and by using an HTTP(S) proxy to sit between the client and the back-end implementation, which provides a control and dispatch point for diverting between new and old versions, either in a live-live, red/green or phased deployment.

Twitter feedback on this session included:

@manupaisable: Monolith != Legacy - key insight by @samnewman now at @qconlondon. #qconlondon https://t.co/gtdFMjjpbu

@RogerSuffling: Just when you thought monoliths were in the rearview mirror. Maybe not! A great talk on decomposing monoliths. @samnewman @qconlondon #Qconlondon https://t.co/B7OQzkcUtz

@wesreisz: Great slide... Think of this as NuGet, Maven, or Ruby gems... We still ship a monolithic deployable, but this is a perfectly viable architecture. Not everything needs microservices. #Qconlondon https://t.co/2H0S9BCEEA

@alblue: For many organizations I work with, they’d be better off with a modular monolith rather than a set of Microservices. – @samnewman at #QConLondon https://t.co/gTa4T6N0f7

@KaraMarck: @samnewman at #QConLondon: Why choose microservices as an architectural pattern? To enable independent deployment of services ✨

@alblue: Can also separate the data in a modular monolith which makes it easier to refactor later if needed. – @samnewman at #QConLondon https://t.co/AiI74ZKt9Q

@manupaisable: if you have a release manager in your org, chances are you have a distributed monolith. – @samnewman on the worst possible monolith: increased operational complexity and still no real decoupling between teams and services. This is a key point in @TeamTopologies book. #qconlondon https://t.co/PTqoGynWG6

@cfhirschorn: I like the idea of a "hedging architecture" in @samnewman’s talk e.g. an engineer hedging their bets / sensing that they *might* need to move the architecture in a particular direction as a stepping stone to a more finished result. See this all the time. #QConLondon

@leontebbens: When you deploy your microservices together, you have a "distributed monolith." The worst of both worlds. #qconlondon https://t.co/YjKUFtsh7J

@wesreisz: @samnewman The release train is a remedial step. If you stick to a release train too long, you will end up with a release train. The goal is to replace it. At a minimum, work to enable each team to have their own release train. #Qconlondon

@alblue: "The distributed monolith. For when life isn’t difficult enough." – @samnewman at #QConLondon https://t.co/ijzN9JcBrh

@MathewRBurns: This distributed monolith described by @samnewman is a scary reality. #Qconlondon https://t.co/cOr05FbzNn

@kasia_balcerzak: The monolith is not the enemy @samnewman #QConLondon

@wesreisz: @samnewman The monolith is not the problem you have. What is the problem that you’re trying to fix? When you answer that, you’re on the right path. #Qconlondon https://t.co/saEBCLMu5q

@hamedoracle: Microservices not for every use cases #QConLondon#microservices https://t.co/8iA4o3Menj

@danielbryantuk: The monolith is not the enemy @samnewman at #qconlondon, suggesting that microservices should not be the default choice. You also won’t feel the pain until you run microservices in production... https://t.co/A55Kn7SnRW

@wesreisz: @samnewman Really powerful pattern for introducing a service is to simply introduce a proxy. Key is to get it into production ASAP. Even if it’s just the proxy. You’ll learn all kinds of things about your codebase, your release process, and your network. #QconLondon https://t.co/gdKWSv57Xo

@wesreisz: @samnewman Introducing an abstraction to existing code and then implementing the new functionality (perhaps using a feature toggle) is another great strategy for decomposing the monolith. Nice call out to @mfeathers book on Working Effectively with Legacy Code. #QConLondon https://t.co/VOIrAuVjDV

@danielbryantuk: A shout out to "progressive delivery" by @monkchips et al, via @samnewman at #Qconlondon "We need to separate deploy and release. And we need to be able to observe the results of a release." https://t.co/2yMnQzAwLa

@cfhirschorn: The "parallel run" pattern allows you to run the same service side-by-side against old, trusted implementation. It not only allows verification of functional requirements but non-functional requirements too e.g. "Did X return within a given milliseconds threshold?" #QConLondon https://t.co/WyL7usS9Co

@soerenkrengel: Better start with a modular #Monolith to learn more about your application context and the boundaries. https://t.co/VijtqcpAm2 @samnewman at #QConLondon: "#Microservices should not be the default choice [...] Microservices should be a last resort." Nice one :)

To Microservices and Back Again — by Alexandra Noonan

Alex Blewitt attended this session:

Alexandra Noonan’s talk on "From monolith to microservices and back again" was entertaining, and talked about the difficult issues they had in the transition, the subsequent explosion of services, and then the requirement to bring them back together again. The issues they had in the first instance were due to slow development; moving to microservices sped that up, but then the explosion meant that library updates weren’t consistent, and so bringing them back to a monolith fixed that problem.

Why Distributed Systems Are Hard — by Denise Yu - GitHub

Alex Blewitt attended this session:

The style of presentation (caution: cats included) and takeaways were one of the best I’ve seen; in particular, the fact that in the traditional CAP theorem, viewing it as a see-saw rather than a triangle (you don’t get to choose ignoring partition tolerance) means you have to decide whether you want to have availability at the cost of consistency or vice versa.

Twitter feedback on this session included:

@danielbryantuk: Learning a bunch about why distributed systems are hard from @deniseyu21 at #Qconlondon Denise’s art is amazing,… https://t.co/zgrjSrDX85

@alblue: The slides by @Deniseyu21 for #QConLondon are available here: https://t.co/2a50e9VzNY

@alblue: The example mentioned by @deniseyu21 at #QConLondon of the Monzo distributed services is here: https://t.co/MMRvgOTn7c

@danielbryantuk: A great take on the classic eight fallacies of distributed computing, via @deniseyu21 at #Qconlondon https://t.co/sde0yRzTwu

@alblue: The CAP theorem, revisited: choose either availability or consistency; you don’t get to forfeit partitioning. – @deniseyu21 at #QConLondon https://t.co/Z7W3L11Yrw

@alblue: Jepsen has a hierarchy of consistency at https://t.co/xqlOSmvsDS @jepsen_io – called out by @deniseyu21 at #QConLondon https://t.co/OmHjsOYGPZ

@charleshumble: The updated CAP theorem paper, mentioned by @deniseyu21 at #Qconlondon, can be read here - https://t.co/xhUiN82zQX

@alblue: The two options in CAP: choose one – @deniseyu21 at #QConLondon https://t.co/KAdI8a7mBN

@charleshumble: @deniseyu21 discussing "impossibility of Distributed Consensus with One Faulty Process" by Nancy Lunch et al. #qconlondon https://t.co/8GdJmrhfcE

@DevSecOps_LG: Blameless discussion @deniseyu21 #qconlondon #qcon https://t.co/CP2EUE3GL9

@sarahjwells: Fantastic talk from @deniseyu21 on the complexity of distributed systems. Great art - slides here: https://t.co/h7xwohhuXz - and I learned lots (for example, that the RAFT algorithm doesn’t stand for anything, it’s just a bunch of logs tied together). #Qconlondon

@cfhirschorn: @deniseyu21 covers Human Factors in her talk about Complex Dist Systems, with a fave quote from @ddwoods2: "As the complexity of a system increases, the accuracy of any single agent’s own model of that system decreases rapidly." #HumanFactors #ResilienceEngineering #QconLondon

@charleshumble: In postmortems, don’t accept human error as the root cause. Dig deeper. @deniseyu21 #qconlondon

@JarleEide: The more fault-tolerant we try to make our systems, the more complex they inherently become. Taking presentation slides to a new level. @deniseyu21 #Qconlondon https://t.co/0uDwTCEQ5b

Scaling Security, from Device to Cloud

Keep Calm and Secure Your CI/CD Pipeline — by Sonya Moisset

Twitter feedback on this session included:

@vixentael: Developers push api keys to github all the time. @SonyaMoisset #QConLondon https://t.co/kLWXuuxRxe

@vixentael: How to prevent vulnerabilities in dependencies? #Security #devsecops -remove unneeded libs -download libs from… https://t.co/li6YqQ7Hon

@ellerenad: @SonyaMoisset shared a big list of tools to integrate security to the CI/CD pipeline, e.g. codecov, codacy, codefactor, deepscan, LGTM, guardrails, depshield, dependabot, webhint... more at https://t.co/L2IIRn2ECE Key takeaways attached #Qconlondon #ITSecurity https://t.co/z8wJXz8V4E

Security Vulnerabilities Decomposition — by Katy Anton

Twitter feedback on this session included:

@vixentael: Some security problems we can’t find until the application is ready, only then can we run integration tests. Instead of waiting and trying to test all at once, it makes sense to test every software component one by one. @KatyAnton at @qconlondon #QConLondon https://t.co/II5v2yXULs

@vixentael: Things to do to detect a possible attack: -authN/authZ failures -input validation bypass -obvious code injections -high use of some functions. @KatyAnton at @qconlondon #QConLondon https://t.co/OFAg7KvNo9

@vixentael: Means to minimize attack surface for your apps: -wrap 3rd party components with adapters and use only subset/ required functionality -divide and conquer -validate the design of your software. @KatyAnton @qconlondon #QConLondon https://t.co/nRRn5Sj5b2

@vixentael: "Focus on security controls instead of focusing on vulnerabilities."  – @KatyAnton at @qconlondon #qconlondon https://t.co/lsBVkXZhhx

The Future of the API: REST, gRPC, GraphQL, and More

A Brief History of the Future of the API — by Mark Rendle

Twitter feedback on this session included:

@mihai_burada: @markrendle I asked them: so how do I edit a file? Use VI they answered... So I spent the next 6 months learning VI... #QConLondon https://t.co/8Pt3ozci18

@danielbryantuk: Right, I’m going to provision the "integer" service in us-east-1 @markrendle at #QConLondon, on the dangers of being too granular with microservices https://t.co/1CmehBrDm4

@mihai_burada: @markrendle : So basically soap wraps XML with a bunch of things that start with soap. #QConLondon https://t.co/ovYTohnwLJ

@mihai_burada: @markrendle If you are not writing APIs yet, you will soon...because that’s the future. #QConLondon https://t.co/l5SBrIbLrN

Introducing and Scaling a GraphQL BFF — by Michelle Garrett

 

Twitter feedback on this session included:

@cfhirschorn: @msmichellegar making clear distinctions between the use cases for REST vs. GraphQL  #QConLondon https://t.co/6xYx8beePL

@cfhirschorn: Common use cases of the Backend-for-Frontend pattern include: wrapping legacy services, aggregating many downstream calls, migrating to microservices and migrating from one API to another. – @msmichellegar #QConLondon

@cfhirschorn: @msmichellegar covers the not-so-obvious positive effects of adopting GraphQL including: increasing developer happiness, productivity, reduction of tangling view/data logic, and decreasing cognitive load on the humans building and operating the software. #QConLondon

@MikeLaptev: #Duplication is cheaper than the wrong #abstraction ©️ Sandi MetzNice quote and nice talk "Introducing and #Scaling #GraphQL BFF" by Michelle Garrett from @condenasteng at @qconlondon / @qcon #QCon #QConLondon https://t.co/QfXUL9Cj8L

The Future of Cloud Native API Gateways — by Richard Li

Twitter feedback on this session included:

@danielbryantuk: Adopting microservices encourages teams to move to full-cycle development. Developers are now often on call. This changes the workflow. @rdli #QConLondon https://t.co/yNaAflutKY

@danielbryantuk: Separation of deploy and release is important. If you’re using @kubernetesio you’re already defining deploy via a policy. Why not do the same with release using an API gateway? @rdli #QConLondon https://t.co/GUuTT8pMaC

@danielbryantuk: If you are moving to microservices, then the LESS strategy can help:-Locate biz functionality -Empower full-cycle dev team -Strangler fig pattern -Share knowledge @rdli #QConLondon https://t.co/k1sQwL6hkS

@danielbryantuk: Sharing knowledge within an organization is the hardest part of tech migrations or process changes. @rdli #QConLondon https://t.co/y0bSjkgX87

@danielbryantuk: The history of the edge and API gateways, via @rdli at #QConLondon And an overview of how the changing app arch and workflow have impacted this https://t.co/nfykEcCwPO

When Things Go Wrong: GDPR, Ethics, and Politics

DevOps Is More Complex and Harder Than You Think. Personal Lessons — by Patrick Debois

Twitter feedback on this session included:

@douglastalbot: "Hopium," the drug taken in product development companies when we keep believing we’ll get the sales next month. #QConLondon @patrickdebois

@wesreisz: A great question on the health of your CI/CD pipeline. If your CI/CD pipeline disappeared, would you deploy the same way manually? @patrickdebois #qconlondon

Managing for Mental Wellbeing in the Tech Industry — by Michelle O’Sulivan

Twitter feedback on this session included:

@BenLinders: Feeling unwell looks different for people. Don’t try to overdiagnose. If you suspect that someone is feeling unwell, ask them. – Michelle O’Sullivan on managing mental wellbeing at #QConLondon

When All the Things Go Wrong — by Colin Humphreys

Alex Blewitt attended this session:

… Talking about what can go wrong as part of a deployment of a new massively online player game, Monopoly City Streets. Essentially, an underfunded project with a massive marketing budget ended up attracting a few more than the 20,000 expected gamers —1.7m, to be exact. A lot of this talk was how to survive under pressure, how 56-hour stints are not to be recommended, how a load of over 400 on a dual-core system is not great, and how PHP is full of facepalm. But the takeaway for this was a plea to allow others who have experienced failure (and failure at scale) to come and share their stories so that others can learn.

Twitter feedback on this session included:

@danielbryantuk: One company who spent $30 million on an agile transformation removed the retrospectives. If they spent that much money, they weren’t prepared to change anything... @hatofmonkeys #qconlondon https://t.co/Rh35RJz5Qo

Sponsored Solutions:Track I

Fast and Efficient Java with GraalVM and Helidon — by Alina Yurenko, Peter Nagy

Twitter feedback on this session included:

@Jim__Gough: Listening to @graalvm platform talk. We’ve gone from Run Anywhere to Run Faster Anywhere. The difference now is the range of languages and target platforms. For open source, is your best bet Graal as a JIT and jaotc? #Qconlondon https://t.co/TgCZVzQlR8

Sponsored Solutions: Track II

Kubernetes for Developers, Architects, and Other People — by Michael Coté

Michael Coté presented this session:

... Large organizations that are managing and modernizing thousands of applications are planning out their new application platform, likely to be used for the next decade. This talk covers how to start planning for that platform:

  1. Understanding what Kubernetes does and what you’ll need to add on.
  2. Planning for large scale app modernization, like the 2,000+ apps at AirFrance-KLM.
  3. Meatware re-platforming — to take advantage of your new platform, like The Home Depot and Daimler, you’ll need to change how you work.

Opinions about QCon

Alex Blewitt attended the conference:

This year, of course, QConLondon is being held with the backdrop of the Coronavirus starting its worldwide tour. Already we’ve seen a few global conferences canned (such as the GDC and the Mobile one) and I had feared that QConLondon would be the next in the list. Fortunately, the planning staff for both the conference itself and the QEII Centre have been remarkably well prepared; there were hand sanitizers on the way in, personal sanitizers handed out, and instead of the usual help-yourself-lunch that have been a staple of prior conferences, this year there are pre-packed bento boxes. In fact, the only unpackaged food has been the bananas and oranges on the fruit stands, and arguably, they come in their own packaging. Together with that, the code of conduct, and the pronoun badges, I think QCon is showing the way to go for other conferences.

Michael Man attended the conference:

… Unlike my experience with other conferences, QCon scheduled a 25-minute interval between talks. This allowed attendees to stretch their legs, grab some refreshments, and navigate their way to their next talk. The conference was held at the Queen Elizabeth II Conference Centre in Westminster, London and covered 5 floors — so having 25 minutes was perfect. The breaks allowed me to digest the previous talk and to prepare myself for the next. This worked really well especially with the last talk scheduled for 17:25. I was amazed that I was not exhausted. Another plus for this well-organized conference.

My overall impression was that the speakers were experts, able to communicate their subjects with ease and confidence, and all supported by a slickly organized and smoothly run conference infrastructure. It opened my eyes to the speed with which development technologies are evolving and the huge breadth of technology choices that we in security are going to have to deal with.

Impressions expressed on Twitter included:

@alblue: Good to see that #QConLondon is taking the code of conduct responsibly. https://t.co/11DVZCDN4Y https://t.co/dJFys9i4BB

@jkriggins: This is why #QConLondon pays the big money to @QEIICentre. Flawless service and adapting with packaged food (though not excessive plastic) and fruit smoothies. https://t.co/eWVRjuya4A

@cfhirschorn: I’d usually be annoyed but...there’s actually a queue for the ladies toilets at a tech conference! #QConLondon

@Kylar: So many amazing y’all choices at #Qconlondon. Every slot today has 2-3 choices that I want to see.

@leontebbens: I vote "Green" for the good #vegan lunch options today! #QConLondon @qconlondon

@ianbond: One of the key things I like about #QConLondon is meeting up and catching up with old (and current) colleagues. https://t.co/P1E4P5FhmI

@vixentael: I ❤️ @qconlondon for all these small details, like binary code on speaker cards. So nice. #QConLondon https://t.co/WD5z8c2kQk

@sallygoble: One of the great things about #QConLondon has been hanging out with other speakers — lovely to share a bit of time with @msmichellegar too. @claireinez you’d have been proud of us.

@AboutSaiMon: Last day at #QConLondon. This was my first experience at this conference and it was great. Thanks @QCon @qconlondon for organizing this awesome tech forum.

@deniseyu21: Bye #QConLondon! It was so fun to be part of my first ever QCon, and meet so many new friends and see so many old friends.

@lucas42: Had a great few days at #QConLondon. I got to do a talk, be on a panel, join an AMA, watch so many amazing presentations and meet tons of brilliant people (not to mention the delicious food) Can’t wait for a good night’s sleep tonight though!

@rmoff: Kudos to the #qconlondon team — a really well organized and run conference.

@9gunpi: Talked this week at QCon London — first time in a while. I’d like to publicly praise a conference on the amazing quality of organization. Well done, #qconlondon, you are an example of how a large, multi-track conference should be organized.

Takeaways from QCon London included:

@Jim__Gough: One of the biggest takeaways from @qconlondon #QConLondon is move to the latest version of Java! Sounds obvious, but there are a few support/build hurdles to plan for. The Java track was awesome.

Conclusion

InfoQ produces QCon events in multiple cities across the globe. All of our sessions are practitioner-focused with a skew towards early adopter topics. Our goal is to provide actionable takeaways that attendees can immediately put into practice within their own organizations when they return to their office. Every editorial talk is hand-picked by a fantastic team of track hosts and program committee members, who themselves are also practitioners and leaders from within the software delivery industry. The session recording publishing schedule can be found on the QCon London website. We’ll be back in London in the spring of 2021.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.