QCons are the place where senior software engineers, tech leads, and architects come together to learn, share, and push each other to drive innovation in the software industry.
The 8th edition of QCon New York (June 24-26, 2019) was no exception and featured software thought leaders discussing innovations from AWS (around control theory in practice at EC2), distributed tracing from the Jaeger tech lead, the hash realities of serverless today, and real advice on how Alibaba runs thousands of pods in a K8s cluster. In all, QCon NYC featured over 100 talks, workshops, panels, open spaces, and keynotes across three days.
In addition to deeply technical topics from some of software’s most innovative shops, there were talks on culture, personal growth, and team building (all with the lens of software engineering at its heart). The day three keynote presenter was Looker’s Nick Caldwell. Nick gave easily one of the most practical talks you’ll ever hear on Igniting the Fire of leadership in your teams. This talk featured “the golden question,” leadership traits, advice, and stories to inspire. If you watch nothing else from QCon NYC, take the time for this. Whether you’re a team lead or a team member, spend forty minutes with Nick and you’ll come away inspired and energized.
QCon NYC 2019 wasn’t just a software conference, it was the software conference where shops like Slack, Google, Uber, and Netflix opened their doors and connected with 1200 of the world’s most innovative engineers. There are more stories than we can list, but InfoQ reported (and recorded podcasts) with a number of speakers during the event. This article presents a summary of QCon New York as blogged and tweeted by attendees.
If you were at QCon NYC this year, thanks for joining us and making it so special. If you weren’t able to make it, we hope this summary helps you make the most of your time consuming the highlights. Our next English QCon is in San Francisco November 11-15th. QConSF 2019 features tracks on microservices, resiliency, front ends, edge computing, devops, team building, software supply chain, machine learning/AI, edge computing, and so much more. Join us!
- Keynotes
- Track and talks
- 21st Century Languages
- Architecting for Success when Failure is Guaranteed
- Architectures You've Always Wondered About
- Building High-Performing Teams
- Data Engineering for the Bold
- Developing/Optimizing Clients for Developers
- High-Performance Computing: Lessons from FinTech & AdTech
- Human Systems: Hacking the Org
- Machine Learning for Developers
- Microservices / Serverless (Patterns & Practices)
- Modern Java Innovations
- Modern CS in the Real World
- Software Defined Infrastructure: Kubernetes, Service Meshes, & Beyond
- Speaker AMAs (Ask Me Anything)
- Workshops
- Opinions about QCon
- Takeaways
- Conclusion
Keynotes
Ignite the Fire - How Managers Can Spark New Leaders by Nick Caldwell
Jeanne Boyarsky attended this keynote:
Leadership vs Management
- Management – stability, short team, plans around constraints
- Leader- change, long term, sets/leads direction, long term
- “Leadership is working with goals and vision. Management is working with objectives”
- Position leadership doesn’t scale – don’t have to be a manager to lead.
- Everyone is potentially a leader
- People want opportunities to lead; not just positions.
- Opportunity to lead outperforms financial incentives on retention surveys...
Leadership
- Top leadership traits said to be: vision, empathy, empowerment, charisma and expertise
- But there are counter examples
- Steve Jobs wasn’t empowering
- Jeff Bezos isn’t known for empathy
- Elon Musk – burn out? should delegate more
- Mark Zuckerberg not known for charisma
- Passion is leadership fuel
- Survey: Most millionaires started with goal of passion not money...
Mentor vs sponsor
- Mentor – gives advice, makes suggestions, discusses
- Sponsor – opens doors, shares hard feedback, pushes to strive for more, creates opportunities, advocates for you
- [I think there is some overlap. Mentoring doesn’t just have to be about the positive. You can share hard feedback too..]
Twitter feedback on this keynote included:
@schultzdustin: 'Tech Lead', one of the most nebulous titles we have in the tech industry. If you ask 5 companies what a tech lead is, you'll get 7 answers " - @nickcald #QconNYC
@schultzdustin: Nick Caldwell - "We took 'Tech Leads' and split them into Managers and Architects. #QconNYC <'” couldn't agree more with this idea
@jasonhand: "Leadership isn't management @nickcald” #QConNYC
@danielbryantuk: Several great thinking points from @nickcald at #QConNYC about leadership vs management, and how to encourage people to find their place to provide the most value https://t.co/Ue9yTBLfsH
@wesreisz: Absolutely love this advice and I commit to start practicing it... Start asking people you work with, what would you do with an extra pair of hands? You'll be amazed at the opportunities laying around. @nickcald #QConNYC https://t.co/0sFu0SBBCB
@randyshoup: "Leaders take responsibility for what's next” @nickcald at #QConNYC https://t.co/ENfYvEc4EY
@danielbryantuk: "Feedback is vital in order to grow as a leader. Taking ownership is valuable, too, and create leadership moments for your team" Excellent keynote from @nickcald at #QConNYC https://t.co/RmnTE2W2h5
No Moore Left to Give: Enterprise Computing After Moore's Law by Bryan Cantrill
Jeanne Boyarsky attended this keynote:
Moore’s law
- Not about speed, # transistors, density or per dollar
- Not coined by Moore
- Came from paper in 1965 – “Cramming more components onto integrated circuits:
- Term coined in 1971 when Carver Mead was talking to a journalist
- Moore also predicated home computers and computers onboard cars. Predicting 40 years out accurately is hard.
- Predicted lower costs
- In 1975, Moore updated the law to be a doubling of transistor density every two years. Meant to be a way of motivating engineers.
- An Intel executive said 18 months (vs 2 years) and that got quoted all over.
Implications
- Apps don’t get twice as fast.
- Hit memory wall
- Moore’s Law could add more caching, but that can only get so far
- Need Symmetric Multi Processing to increase throughput
- Speculative execution tried to pre-execute code and then became a security issue
- Cost matters. It’s not about increasing speed at any cost
End of Moore’s Law
- Samsung trying to 3 nanometer.
- Many unsolved problems
- A silicon atom is .2 nanometers.
- This is the end. Can’t physically make smaller. 3 nanometers is only 15 atoms across
- 7 nanometers might be the smallest size at a reasonable cost.
Beyond Moore’s Law – Quantum
- Quantum computer is surprisingly really
- Need large refrigerator. Must be close to absolute zero
- Problem domain is very limited
- Scale is tiny
- Don’t yet have ability to scale qbits
- Quantum computing may be relevant one day for the enterprise, but not any time soon
Twitter feedback on this keynote included:
@edgar: Gordon Moore predicted the future of the industry in 1965 #QConNYC https://t.co/5u56k3Kk1N
@danielbryantuk: A typical high-energy #QConNYC from @bcantrill, exploring Moore's Law "As much as we've heard the cliche about Moore's law and lazy developers, I've never actually seen an engineer simply stop working and instead wait for this law to speed up their code" https://t.co/O4ebkwUJ1N
@blackllama: "Moore law ends like life frequently does. With dementia and confusion." - @bcantrill‚ #QConNYC
@randyshoup: Compute is moving everywhere - onto the NIC, into the hard drive, etc. "If you are young, you are just filled with excitement. I am old, and it fills me with equal parts excitement and terror! @bcantrill at #QConNYC https://t.co/6v1qiRFYkp
@Joab_Jackson: #MooresLaw irrevocably came to an end in Aug 2018 when GlobalFoundries stopped 7nm chip production, citing costs and lack of demand. @bcantrill #QConNYC @QCon https://t.co/qVe9BNE1Wn
@jessitron: In which @bcantrill geeks out over transistor sizes and the history and future of Moore's Law (Spoiler: there is no future) #QconNYC https://t.co/frCM5KRL4G
@jessitron: His favorite futuristic architecture is chiplets. Yes, this looks like microservices in the CPU. Decouple your transistor sizes! Add an interlocutor layer! #QconNYC @bcantrill https://t.co/qTLmCOGuVj
@floydmarinescu: Gordon Moore, co-founder of Intel predicted home computers, cell phones and self-driving cars in 1965. #QConNYC Morning Keynote https://t.co/s8RDQ0WXkQ
@jessitron: The computers of the future are even more complicated. Prepare to think about the system more broadly than software. #QconNYC @bcantrill https://t.co/izEQUxGr91
@bcantrill: Slides for my #QConNYC keynote this morning on the end of Moore's Law -- and the ramifications for the future of enterprise computing: https://t.co/iIUrUcIvQA
Tracks and talks
21st Century Languages
Making 'npm install' Safe by Kate Sills
Jeanne Boyarsky attended this session:
General
- Building financial software in JavaScript
- 97% of code in a modern web app comes from npm
Security issues
- All packages are risky
- Imports and global variables
- Effects opaque
- Can be from dependency many levels deep...
Realms – draft proposal
- Want to be able to create realm without overhead of an iframe
- Featherweight compartment – shares primordials/context
- There is a realm shim now
- Self/window not defined in the compartment
Twitter feedback on this session included:
@justincormack: The maintainer problem. Code review takes 10x the writing time. @The_Maintainers #QConNYC writing code is fun but it is the easy part. https://t.co/uoJfdVeFXi
@Kensan42: Maintainability was item 1C in the Steelman language requirement, out of which Ada came: "The language should promote ease of program maintenance. It should emphasize program readability. The language should encourage user documentation of programs. https://t.co/KmdTwILOdV
Multi-Language Infrastructure as Code by Joe Duffy
Twitter feedback on this session included:
@justincormack: All developers are (or will become) cloud developers @funcOfJoe #QConNYC https://t.co/qn72aXdoXc
Architecting for Success when Failure is Guaranteed
Graceful Degradation as a Feature by Lorne Kligerman
Twitter feedback on this session included:
@relix42: "We expect technology to just work Tech systems are fragile. We need to do more so that our users aren't impacted by failures. #QConNYC @QCon @lklig https://t.co/Be8rEbDNqp
@relix42: How do we think about designing for failure? Stuff everyone in the org should understand. #QConNYC @QCon @lklig https://t.co/WrLLNI9Lgc
@relix42: "Inject Failure By Breaking Things On Purpose The big idea behind chaos engineering. It allows you to verify that your systems do what you expect them to in failure situations. No more guessing - testing gives you assurance. #QConNYC @QCon @lklig https://t.co/2Umvd3GqYI
How Did Things Go Right? Learning More From Incidents by Ryan Kitchens
Twitter feedback on this session included:
@relix42: "Failure is so important that it's no longer interesting. Failure is the normal state” #QConNYC @this_hits_home https://t.co/f6QSTDbTrK
@jonesc5: Glitter + truth about failure being a normal state. "You're going to have incidents. You can't choose not to. @this_hits_home #QConNYC https://t.co/OC8gYxptnB
@relix42: "In a complex system, none of these are entirely possible” #QConNYC @this_hits_home @qconnewyork https://t.co/kivKbsqPA2
@_elergy_: ...because there is no root cause (@this_hits_home at #QConNYC) https://t.co/nJZ23UuGur
@relix42: "People are doing the same things everyday - the performance variability that leads to all your successes are the same actions that leads to failures” #QConNYC @this_hits_home https://t.co/WtYO2X3kYA
@relix42: "In the traditional view, we focus on only a very, very small portion of or available information; the failure data. We need to stop ignoring all the success data we have”. #QConNYC @this_hits_home https://t.co/NFST2LbGH4
@jasonhand: "Availability is perceived The 9's .. aren't accurate nor do they matter!” @this_hits_home #QConNYC
@relix42: "How hard are people working just to keep the system healthy? Invisible work that keeps you successful”. #QConNYC @this_hits_home https://t.co/X2Y1aoc0RO
@jasonhand: Question: How do we communicate the state of our socio-technical systems when everything seems ok? "Engaging with engineers ONLY when they blow their error budget doesn't give you the whole story! (Especially re: burnout) @this_hits_home #QConNYC https://t.co/mh1cDpEz62
@relix42: Saying "Be more careful after an incident has never prevented an incident or made people feel more supported and successful. #QConNYC @this_hits_home https://t.co/fm5gPTmBuE
The Trouble With Learning in Complex Systems by Jason Hand
Jeanne Boyarsky attended this session:
Complex system
- Causality can only be examined/understood/determined in hindsight
- Specialists, but lack broad understanding of system
- Imperfect information
- Constantly changing
- Users good at surprising us with what system can/can’t do
Learning
- Takes time
- Takes success and failure. Need both
- Learning opportunities not evenly distributed
- Sample learning opportunities – code commits, config changes, feature releases and incident response. Commits occur much more often than instances
- However, the cost to recovery is low for the more frequent opportunities
- High opportunity – low stakes and high frequency. GIt push is muscle memory
- Low opportunity – high stakes and low opportunity
- Frequency is what creates the opportunity
Twitter feedback on this session included:
@jeanneboyarsky: like that @jasonhand made NYC his example of a chaotic system #QConNYC
@relix42: "In complex systems, causality can only be examined, understood, and determined in hindsight Commentary on the realities of complex systems” #QconNYC @QCon @jasonhand https://t.co/gKxc0SJoVR
@relix42: "Our opportunities to learn are not consistently available or predictable. This makes regularly learning more difficult because the inputs aren't consistent. #QconNYC @QCon @jasonhand https://t.co/JQOu8MX0dJ
@relix42: "High stakes events that don't happen very often give us low opportunity to learn. And it's these things that have the most impact to our businesses. That's unfortunate. #QconNYC @QCon @jasonhand https://t.co/d9z6i6JxIE
@relix42: "Incidents are the continuous feedback of your complex system Incidents are just data '” and they're good data! Stop calling your incidents bad. #QconNYC @QCon @jasonhand https://t.co/h52MiHj30P
@relix42: "A critical component of high resilience in organizations is continuous learning from events, 'near miss' incidents, and accidents. #QconNYC @QCon @jasonhand https://t.co/i4N7j40kSY
@relix42: "Invite a broad and diverse group to the conversation Get more perspectives from more people and share learning much more broadly. #QconNYC @QCon @jasonhand https://t.co/Yjmaw9q95O
What Breaks Our Systems: A Taxonomy of Black Swans by Laura Nolan
Twitter feedback on this session included:
@relix42: Black swan events: unforeseen, unanticipated, and catastrophic issues. These are the incidents that take our systems down, hard, and keep them down for a long time. There's still a lot to learn from them. #QConNYC @QCon @lauralifts https://t.co/6l5q1pX55Y
@relix42: "Failing fast is better than failing slow An infinite retry against a failing service is the distributed systems equivalent of "the beatings will continue until morale improves #QConNYC @QCon @lauralifts https://t.co/v65Fnf7ZOu
@relix42: Coordinated demand is a common cause of Black Swan events. What drives these events? Customers? Maybe. Systems? Assuredly. #QConNYC @QCon @lauralifts https://t.co/5QylU1Hnjx
@relix42: "Google erases its CDN Meant to target 1 rack of machines, but, a regex inadvertently targets the entire CDN. #QConNYC @QCon @lauralifts @guycirino https://t.co/Wg5PMZIt8n
@this_hits_home: Ironies of automation! #QConNYC @lauralifts https://t.co/euJq3RcjSE https://t.co/UNge33K6dl
Architectures You've Always Wondered About
Machine-Learned Indexes - Research from Google by Alex Beutel
Twitter feedback on this session included:
@randyshoup: Machine-learned database indexes: a key insight is that an index structure like a B-Tree *is* a predictive model - it maps a key to a predicted page @alexbeutel from Google at #QConNYC https://t.co/OH52Pc1Y45
Scaling Infrastructure Engineering at Slack by Julia Grace
Twitter feedback on this session included:
@jeanneboyarsky: "Monoliths are great. Single code base, atomic commits, etc "it might be a if ball of mud, but you love that ball of mud #QConNYC
@randyshoup: Building an infrastructure team in a product-led organization like Slack: evangelize your value from day 1 @jewelia at #QConNYC https://t.co/NzdegUcQUn
@danielbryantuk: Great analogies from @jewelia for scaling infrastructure when @SlackHQ found product/market fit. "We built a great pedestrian bridge, and then someone asked if they could drive a car across it. Actually they were already driving cars over it..." #QConNYC https://t.co/IyMAeeF5sX
@randyshoup: Communication Risk: an under-appreciated part of software, particularly infrastructure work. You need to make sure your clients know what your code names mean, and how your systems work. @jewelia at #QConNYC https://t.co/ypJhrHrZnQ
@jchyip: Scaling quickly requires a greater desire to be connected to reality than the desire for stability. #QconNYC
@jerenkrantz: Yes, lots of great lessons..."taking Slack chats and converting to product specs" as a job description for a product owner is hilariously spot-on...and difficult to find! =)
@schultzdustin: Was really quite great to hear @jewelia point out the flaws in the interview process for hiring engineers. Hire for the type of engineer you need. Don't just blindly follow other companies' way of hiring. Whiteboard interviews and CS questions aren't always the answer. #QConNYC
Tackling Computing Challenges @CERN by Maria Girone
Twitter feedback on this session included:
@randyshoup: Dr Maria Girone, CTO of @CERN openLab, amazes #QConNYC with the scale of their computing challenges: 1 billion collisions and 1 petabyte of data per second! https://t.co/2SNulFTgQt
Video Streaming at Scale by Lysa Banks
Twitter feedback on this session included:
@randyshoup: Video Streaming at Scale by @LysaBanks from IBM. Incredibly cogent and detailed walkthrough of a modern video serving stack. #QConNYC Building High-Performing Teamshttps://t.co/EcJhYuVrjS
Building High-Performing Teams
Context Matters: Improving the Performance and Wellbeing of Teams by Shawn Carney, Zofia Ciechowska
Twitter feedback on this session included:
@wesreisz: One of my favorite ways to think about organizing teams and mindsets. #QConNYC https://t.co/6VhgM0mpag
@wesreisz: "High performing teams mitigate in times of chaos, not problem solve." Love this! Get out chaos mode as quickly as possible @zociechowska @shawncarney #QConNYC
@wesreisz: This is great! It's a slight twist on the way the Agile Manifesto does it. While we find value in the things on the right, we find more with the things on the left.#QConNYC https://t.co/MjXgB4W7qc
@wesreisz: Holding retros for decisions you make, fast feedback, helping teams empower how decisions are made all help build psychological safety. #QConNYC https://t.co/FbBZfZCWbs
High Performance Remote and Distributed Teams by Randy Shoup
Jeanne Boyarsky attended this session:
Remote
- You to not often interact face-to-face with the people that you work with
- Models- single site, multi site, remote first
- Anti-pattern; Centralized HQ control. Most things and all decisions done at HQ. Others get work doled out to them
- Anti-pattern: Site + Satellite Remote – One or several site where people work every day and one or two on own
- Remote first – everyone on video and slack. Model that Ok to interrupt b/c net slow
Benefits
- Larger talent pool
- Take advance of localized supply and demand
- Parallel hiring – can grow teams in parallel. Not tied to a recruiting team. Each site can hire in parallel
- Geographic hedge – can hire more in one region if things slow down in one
- Diversity and inclusion – flexible location/hours, geographic/cultural, neurodiversity (b/c communication styles vary)
- Retention – can live different places, employee satisfaction, productivity
- Little/no commute
- Flexibility
- Personalize work environment
- If at HQ and work with remote people, more flexibility because your teammates are remote
- Ensure each team full stack so not relying on team in another country for communication
- Follow the sun. Round the clock triage, on call handoffs
- Close to customers. Local presence, customer empathy, local implementation/customization
Challenges
- Local laws (hire/fire/severance)
- Local recruiting norms
- Local compensation – pay everyone as if at QA or by local market. But must be consistent
- Local currency – do you pay in US dollars or local currency
- Local regulation – laws, taxes
- More travel. Problem to never see teammates
- No commute == no exercise
- Solitude/isolation
- Time management. Easy to keep working
- Best to be single site or remote first. That way don’t have onsite conversation and inform (Or forget) remotes later
- Don’t have one site dole out work. That’s outsourcing
- Managing time zones – respect time zones over others. Watch DMs off hours. Trade off inconvenience. Use overlapping hours well
Twitter feedback on this session included:
@YiGeNaNa: Talent is evenly distributed, opportunity is not. High Performance Remote and Distributed teams with @randyshoup #QConNYC https://t.co/aRyL7vZQRg
@danielbryantuk: Interesting examples of the remote work spectrum, from single-site to remote-first, via @randyshoup at #QConNYC https://t.co/XMepnJHxby
@danielbryantuk: Great advice for hiring, training, and working as a remote employee, via @randyshoup at #QConNYC https://t.co/UP4CfCL3Xz
@danielbryantuk: Great advice from @randyshoup at #QConNYC in regard to managing remote teams "Remote 1-on-1s should be sacrosanct, both with direct reports and skip-levels. This is because of the lack of day-to-day casual in-person interactions and management" https://t.co/t0re9HuyJj
@danielbryantuk: Love this advice from @randyshoup in regard to written communication within a remote team "Always start by clarifying what problem are you trying to solve" #QConNYC https://t.co/ZU9GfZLi37
@sai_donthi: High bandwidth comms with remote teams at summits and so many more interesting learnings shared by @randyshoup at #QConNYC https://t.co/yELn6CzNFR
Navigating Complexity: High-Performance Delivery and Discovery Teams by Conal Scanlon
Jeanne Boyarsky attended this session:
Key areas of discovery work
- Maximize learning – accelerate discovery, MPVs
- Want to encounter problems as quickly as possible
- Learning is messy and doesn’t easily fit Scrum process
- MVP goal – maximize learning while minimizing risk and investment
- MVPs can be paper prototype or a single use case
- Better ideas – idea flow, collective intelligence
- Levels: Psychology safety, dependability, structure & clarity, meaning, impact
- Validate with people outside team
- Closer relationships with specific customers so can see reaction as progress
- Alignment – OKRs, Briefs, Roadmap
- OKR = objective and key results
- Think about where want to go and how get there
- Should understand why vs an aspirational goal
- Alignment and autonomy are orthogonal
- Product brief – map from strategic level to feature going to build. It is not a requirements or architectural doc
- Roadmap – show on larger ranges of time
- Metrics – 3 levels, correct category (delivery vs discovery)
- Business, product and engagement metrics.
Data Engineering for the Bold
A Dive Into Streams @LinkedIn With Brooklin by Celia Kung
Joab Jackson attended this session:
LinkedIn’s Brooklin, which the company plans to release as opens source shortly, serves as a central data bus for the company, connecting the many back-end databases and data stores with user-facing applications….
Brooklin, is about connecting multiple data sources to multiple destinations, said Celia Kung, the LinkedIn engineering manager in charge of the pipelines group at the company….
Brooklin addresses the challenge of how to do data streaming to multiple end-nodes when the data is coming from multiple sources. Today, LinkedIn uses Brooklin to support over 200 applications. It passes over 2 trillion messages a day from Kafka alone, spanning tens of thousands of topics. These capabilities can be configured individually by the developer and dynamically deployed — no need to manually change configuration files or manually deploying to the cluster.
While initially LinkedIn stored most all of its user data in Oracle, it since adopted a wider variety of data storage systems, especially since Microsoft purchased LinkedIn in 2006. Now user and operational data is captured in Kafka, MySQL, Microsoft Event Hubs, the company’s own Espresso data store, and Amazon Kinesis, among others. …
LinkedIn uses Brooklin for a variety of use cases, including change data capture (propagating changes in the database to applications), eliminating the overhead to run queries against the data source itself. Brooklin can also refresh caches and build search indices. It can work as s streaming bridge, able to move data from one source to another, such as from AWS to Microsoft Azure. It can be also be used to re-partition data. It can be used to set up a data warehouse, eliminating the need for extract transform and load (ETL) tools, by shipping data to a Hadoop File System (HDFS).
Datadog: A Real Time Metrics Database for One Quadrillion Points/Day by Ian Nowland
Twitter feedback on this session included:
@wesreisz: Unofficial cloud storage characteristics... @inowland #QConNYC https://t.co/mqlWK2jh1o
@kellan: "What database does @datadoghq use? - @inowland #QConNYC https://t.co/3YPX4ZR6s5
@wesreisz: Aggregation portion of the talk starting with @JoelBarciauskas #QConNYC https://t.co/txiIyb3ckg
@wesreisz: Where aggregation happens. #QConNYC https://t.co/CdIvr8uskX
Scaling DB Access for Billions of Queries Per Day @PayPal by Petrica Voicu, Kenneth Kang
Joab Jackson attended this session:
PayPal’s Hera, released recently as open source, is a database proxy built specifically for pooling and managing database connections for microservices …
At present, the company has 2,000 database instances holding a total of 74PB of data and the busiest ones field nearly 1 billion calls an hour. As with any online service, response time is crucial, and one of the biggest culprits are database connection times, which can range up to 100ms each. Worse, each database instance has a set number of connections it can handle at once. The more connections a database instance, the worse its performance gets.
One possible way of smoothing over performance is to establish a connection pool, which fields and queues the requests for multiple microservices. This is what PayPal’s Hera does,
Hera has been running in production for a year, and sits in front of hundreds of database instances.
Hera manages both reads and writes. It picks a particular node to send all the writes to, thereby cutting minimizing a lot of back-and-forth handshaking, thereby speeding traffic for all the other instances that can be focused on fulfilling reads requests….
Hera also comes with some built-in resiliency and recovery safeguards: It can balance connections across the remaining nodes when one goes out. In times of overload, it will immediately terminate the SSL connection, so the app can immediately launch into failure mode, and not leave the user hanging when there is no clear path to the data. It also offers migration capability, facilitating the database shards safely from one node to another, even while transactions are still being processed.
Developing/Optimizing Clients for Developers
Front End Architecture in a World of AI by Thijs Bernolet
Twitter feedback on this session included:
@ANeyzb: "One of the fundamental issues of marrying AI and UI is shared state - @recyclerobot speaking about Building Front-end Architecture for AI @qconnewyork #QConNYC https://t.co/qcJLwQcvKf
NYJavaSIG Meeting
Jeanne Boyarsky attended this panel:
Quotes
- “If you don’t create garbage, you aren’t going to have a problem with the garbage collector” – Kirk
- ”Performance is in the eye of the beholder” – Bert
- “Once you see it you can’t stop seeing it” – Kirk
- ”Need to adjust containers in a sensible way” – Kirk...
General
- First question is whether what customer wants is possible – Todd
- A lot of the tools lie to you – Kirk
- Profile disruption – Kirk
- Have more than one tool – Todd
Tools
- Async profler – Todd
- Flight recorder Todd. Looking at adding perf data – Kirk.
- perf on linux – Todd
- Remove/reduce logging – Todd. Seconded by Kirk. Good at finding the problems that have already been solved and likely won’t occur again.
- perf – Kirk
- GC logging – Kirk
- Jmeter and other tools. Use with cloud based apps – Bert
Twitter feedback on this session included:
@jeanneboyarsky: Tongue in cheek start to question about performance "If you don't create garbage, you aren't going to have a problem with the garbage collector #QConNYC @nyjavasig
@jeanneboyarsky: "It's something that is there and have to live with. The more you understand it, the less it seems like magic. - Todd #QConNYC @nyjavasig
@jeanneboyarsky: "HashMap not a word used in business terminology. Missing a domain term in model - Kirk #QConNYC @nyjavasig
Not Sold Yet, GraphQL: A Humble Tale From Skeptic to Enthusiast by Garrett Heinlen
Darryl K. Taft attended this session:
Tasked to build a new data integration system, the Netflix content engineering team chose Apollo GraphQL and TypeScript as the system's foundational technologies, Heinlen said. The team selected GraphQL over both REST and Falcor, an open source JavaScript library created at Netflix for data fetching….
GraphQL enables users to define a schema that models their business domain as a graph. Heinlen's team built a single-entity graph over the last year to support several downstream integrations, including Java, Ruby and REST integrations.
The back-end stack doesn't matter, because GraphQL can connect with any back end, Heinlen said. "We define a GraphQL schema ... and then we build UIs around that," he said….
After the success of Heinlen's group with GraphQL, they have helped other Netflix teams over the last year spin up "many dozen" applications using single-entity graphs, Heinlen said….
Although GraphQL simplifies the process to query data and build APIs, it is not a silver bullet, Heinlen said. Netflix still faces challenges such as schema management, error handling and distributed writes when it comes to the technology.
It took several months before Heinlen became sold on GraphQL, and it wasn't the technical merits of the technology as much as how it changes how teams and organizations behave and communicate, he said….
Despite Netflix's choice to use GraphQL, Heinlen expressed support for REST, which "has gotten us a very long way and has a lot of good things about it," he said. But GraphQL goes further to help an organization's teams communicate more efficiently and combine multiple product schemas, he said.
"GraphQL promotes a new type of service, a higher-order service. It's like a giant map function in the cloud, and countless clients can develop against it," he said.
Jeanne Boyarsky attended this session:
GraphQL
- Express what is possible
- Can get just data need
- Schema is the source of truth
- Can focus on product
- Optimize exploration over documentation
Disadvantages
- Rewriting code. But don’t have to change everything
- Multiple entity graphs require managing release cycles
Consider
- Designing graphs
- Talk to others who have already done
- Whether focus is data or clients
- UI or entity centric schema
- Who owns the schema? ex: ivory tower committee, informed captain per entity
- DIstributed writes. Reading is far easier. For now Netflix is limitting updates to single entity
- Error handling
High-Performance Computing: Lessons from FinTech & AdTech
Achieving Low-latency in the Cloud with OSS by Mark Price
Jeanne Boyarsky attended this session:
Hydra
- System built on OSS
- Opinionated framework to accelerate app dev
- Clients communicate with stateless, scalable gateways
- Persistors – manage data in memory.
- Gateway – converts large text message to something smaller and more efficient
Design choices
- Replay logs to reapply changes. Business logic must be fully deterministic. Bounded recovery times
- Placement group in cloud – machines guaranteed to be near each other. Minimizes latency between nodes
Human Systems: Hacking the Org
Liberating Structures @CapitalOne by Greg Myers
Jeanne Boyarsky attended this session:
General
- Few meetings include engagement
- Many tech managers consider meetings for their staff
- Can help with white elephants – the things we don’t normally talk about
- There are 33 defined liberating structures http://www.liberatingstructures.com
- Retain more info because face to fact and involved
- Planning poker is a diversity initiative. It’s about the discussion, not the #...
Meeting Elements
- Invitation – Common negative “invitations” are “listen to me” and “tell me what I want to hear”
- How space is arranged – want to signal and reinforce activity
- How participation is distributed – how invite. Want to belong and not just be tolerated
- Sequence of steps and time allocation – think about what whole group needs
Twitter feedback on this session included:
@jeanneboyarsky: "Planning poker is a diversity initiative. It's about the discussion, not the # #QConNYC
Psychologically Safe Process Evolution in a Flat Structure by Christopher Lucian
Twitter feedback on this session included:
@heidihelfand: Regular retrospectives are key for safe process iteration. @ChristophLucian #qconnyc https://t.co/QX0i6bcmFf
@heidihelfand: Kindness, consideration and respect... @ChristophLucian talking about fostering psychological safety #qconnyc cc: @WoodyZuill https://t.co/FtllomLEiW
@heidihelfand: How do you stop doing things that are accepted as the status quo? @ChristophLucian talking about the importance of eliminating process that is no longer needed. #qconnyc
@jimmy0x52: What's old is new again: extreme programming (~1999) -> pair programming (~2001) -> mob programming (~2019) #qconnyc
@kcasella: Psychological safety helps ideas flow more freely by @ChristophLucian @qconnewyork
@heidihelfand: "We found that high availability of product managers to the team correlated with lower cycle times. @ChristophLucian at #qconnyc
Using Bets, Boards and Missions to Inspire Org-Wide Agility by John Cutler
Jeanne Boyarsky attended this session:
General
- People seem interested and want to try. Then there is fear and nothing happened. Then people give up.
- Confusing own needs, continuous improvement and specific ideas
- It’s hard for everyone.
- Some companies are healthier than others. Range to get rid of a toxic employee is 12 months to forever
- Companies thinking they want a magic tool or framework
- Common Problems: Structural, culture/alignment, strategy, decision, making, revenue pressure, deal closing, feature factory, busyness high utilization, constraints
- Angst is easy to trigger. People want certainty, impact and coherence.
- Coherence != agreement. Coherence means understand.
- Want flow of impactful stories
- How know if in a feature factory: https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2
Key ideas
- Product development is a beautiful mess
- Efforts to simplify/standardize often backfire. If can reflect mess back, becomes a change agent. Mirrors are beautiful. Ad libs for bets: https://dazzling-allen-f0bcd2.netlify.com
Twitter feedback on this session included:
@jeanneboyarsky: "Professional canary can tweet something wrong but doesn't change - @johncutlefish #QConNYC
@jchyip: "How long does it take to remove the most toxic person in your organisation? The answers range from 7 months to never. @johncutlefish #QConNYC@heidihelfand: Healthier orgs sense and respond faster. @johncutlefish #qconnyc https://t.co/qh6pfjU5AL
@jchyip: Making certain things easier is a more useful way to standardise than imposing a policy. #QConNYC
@jchyip: "Feature factory makes me think too much distance between problems and problem solvers.” #QConNYC
@jchyip: I suspect the "bet” phrasing works in some cultures and is problematic in others. #QConNYC
@heidihelfand: A: Let's build X. B: That's an interesting bet. Shift the conversation to be about "bets.” #qconnyc @johncutlefish https://t.co/rQgVDlF3C8
@jchyip: This work type mapping stuff looks interesting. Is there something written about this? @johncutlefish #QConNYC
@jchyip: It really seems that everyone uses JIRA for finer grained work tracking. #QConNYC
Machine Learning for Developers
Panel: ML for Developers/SWEs by Hien Luu, Jeff Smith, Brad Miro, Ashi Krishnan
Jeanne Boyarsky attended this session:
General
- Many problems repeat so can get ideas from others
- Important to have organizational alignment
- Make sure to train on realistic data
- Deep learning is very successful use case of ML
- ”AI is the new electricity”
- Limits of Moore’s law. Physical limitations with Quantum
- Research on how to get algorithms to train theselve
Learning resources
- Jeff’s book – Machine Learning Systems
- Andrew Ng’s Coursera ML course
- Coming out this year “AI is for everyone”
Time Predictions in Uber Eats by Zi Wang
Joab Jackson attended this session:
Estimating the perfect times for drivers to pick up food delivery orders for a number of different restaurants can be one of the most difficult of computational problems. Think of it like the Traveling Salesperson NP-Hard combinatorial optimization problem: The customer wants food delivered in a timely manner, and the delivery person wants the food ready when they roll-up. If the estimates are off by even a tiny bit, then customers are unhappy and delivery people will work elsewhere.\nYet, car-sharing service Uber is building a global service, called Uber Eats, that will rely on accurate predictions to succeed. The secret to its success will be machine learning, built from the company’s in-house ML platform, nicknamed Michelangelo….
Timing is the key. Uber Eats wants to dispatch the delivery person to arrive just when the order is ready. If it is too early then the delivery person will wait around unnecessarily, losing money from other possible orders. But wait too long and the food may arrive late, or cold, to the hungry customers….
All data is collected by Kafka and pushed to a streaming engine for pre-processing and storage in a Cassandra data store, where it is processed by Spark for data modeling. Models that are trained and are ready to use are stored in Cassandra model repository….
Prior to ML, Uber Eats used a Greedy algorithm for determining when to dispatch a delivery person, which solved the problem by estimating the best local answer for each delivery, without optimizing the problem space for all the drivers in that area. This did not work well for the service as a whole, as it led to late deliveries and delivery people waiting in the restaurant parking lot for orders to be finished….
With ML in place, a travel time estimate can be taken from the history of all travel times, and for all restaurants in the area, given all the jobs and all the available drivers. Uber Eats’ approach combines historical data, near-real-time data and real-time data….
The order preparation time, however, can be tricky, in no small part because there is no way for Uber to be there to see how long it takes the kitchen staff to prepare the food. It can be estimated by when the delivery person leaves the restaurant, though this is of limited value, as the food may already be finished by the time the delivery person arrives.
This is where ML can provide insight, with additional contextual clues, both historical, and in near real-time: This system draws from such factors as average food prep time in the past week, the number of outstanding orders and how much each order cost, and even what day of the week it is. Even real-time indicators can be used, such as how many other orders are being handled at the time, even those from other delivery services.
“Combining all these features helps us make much more accurate predictions than just relying on a single one of them,” he said.
Microservices / Serverless (Patterns & Practices)
Conquering Microservices Complexity @Uber With Distributed Tracing by Yuri Shkuro
Twitter feedback on this session included:
@YiGeNaNa: Observability: the ability to ask your system questions. Conquering Microservices Complexity @Uber with @YuriShkuro #QconNYC
@suksr: "In microservices architectures the number of failure modes increases exponentially" - @YuriShkuro from @Uber talks about "Conquering Microservices Complexity @ Uber with Distributed Tracing" at #QConNYC https://t.co/RbevRRas8m
@copyconstruct: Making distribute tracing easier with more sophisticated visualizations - @YuriShkuro The first is color coded by service graph. The second is a heat map #QConNYC https://t.co/DyezQ9H59H
@copyconstruct: And the diff tool deals with aggregate traces. You can then drill down into an individual trace. @YuriShkuro at #QConNYC [ed - this. This so freaking much. Starting with a trace is like being in a hiding to nowhere. Need to begin with an aggregate view.] https://t.co/vglIhnxr2U
@suksr: "Comparing traces make it's easier to find anomalies" by @YuriShkuro from @Uber at #QConNYC https://t.co/jyho5SVhnj
@danielbryantuk: Fascinating insight into the distributed tracing tooling that @UberEng have created, via @YuriShkuro at #QConNYC Distributed tracing is very valuable at a certain scale, but the UX/tooling is super important https://t.co/LlAndep4xv
@copyconstruct: Here's a tool that's internal to Uber that helps with "root cause (sic) analysis to drill down from business metrics to app level telemetry. @YuriShkuro at #QConNYC https://t.co/gcvwKTofMQ
@danielbryantuk: More debugging and observability tooling from the @UberEng team, via @YuriShkuro at #QConNYC https://t.co/6B50nkkEBu
@copyconstruct: The hardest part of doing all this analysis is application instrumentation. Doing the analysis is easy for us (Uber) - getting almighty fidelity data is the challenge. - @YuriShkuro at #QConNYC https://t.co/b3jjVQ9Hmu
@copyconstruct: In summary: - tracing really becomes usable when you have creative visualizations - engineers don't really know how their services work. Tracing helps unlock unparalleled insights. @YuriShkuro at #QConNYC https://t.co/KqDy3S9Qnn
@copyconstruct: Uber doesn't use tracing for latency analysis. We use it for root cause analysis. - @YuriShkuro at #QConNYC
PracticalDDD: Bounded Contexts + Events => Microservices by Indu Alagarsamy
Twitter feedback on this session included:
@suksr: "A product can have different attributes in different contexts. Unified models are hard." - @Indu_alagarsamy in her "Practical DDD" talk at #QConNYC https://t.co/G23SXFK65f
@suksr: "Split the model according to transactional consistency, to teams or departments, to business processes" - @Indu_alagarsamy at #QConNYC about identifying DDD Bounded Contexts https://t.co/g6DsPKrGPn
@jessitron: At #QConNYC @Indu_alagarsamy explains how to actually get autonomous, scalable, small services: with the discipline of domain driven design. https://t.co/Pk9hvLNB6P
@jessitron: Unified models are not the way to go. You wind up speaking the language of none of the business, translating everywhere, and slowing down all change. @Indu_alagarsamy #QConNYC
@jessitron: The bounded context is a safe space, where models are consistent and also free to change. @Indu_alagarsamy #QConNYC https://t.co/EJ9zrXjbia
@jessitron: Commands are special because they can fail. @Indu_alagarsamy #QConNYC Only Events can move between contexts, because the receiving context is not allowed to deny the sending context's reality. https://t.co/YxKZHoYhOs
@jessitron: Event storming: because sticky notes are cheap, and writing code is expensive. @Indu_alagarsamy #QconNYC https://t.co/SVKwlOhCTM
@jessitron: Naming things is hard. Use the language of the business; Don't fill yours with CRUD. @Indu_alagarsamy #QConNYC https://t.co/Ojqqx5XUVx
@jessitron: Refactor with an obsession for domain language. @Indu_alagarsamy #QConNYC https://t.co/jjOqSkStsR
@carlmasak: Interesting. In that sense, a bounded context mirrors the abstraction boundary set up by a class, or by an aggregate.
The Not-So-Straightforward Road From Microservices to Serverless by Phil Calçado
Twitter feedback on this session included:
@danielbryantuk: A definite trend at this #QConNYC is speakers driving home the point that microservices and DIY cloud platforms are probably not appropriate unless you have product/market fit and are operating at a certain scale Here is @pcalcado joining that club https://t.co/s5oj6CsC0l
@suksr: "Keep your monolith for as long as possible", but what "if you waited so long microservices aren’t hype any more..?" - @pcalcado during his talk about "The Not-So-Straightforward Road From Microservices to Serverless" at #QConNYC https://t.co/0h3RpNiKs2
@danielbryantuk: Keeping track of FaaS Functions at scale can be challenging... "We had lots of (presumedly test) functions with a developer's name as a postfix. We deleted some of them and we accidentally broke our billing system" @pcalcado #QConNYC https://t.co/GSuQX4VFzS
@DangerHandsDan: "If you have a DevOps team - you don't have DevOps." @pcalcado discussing the Road from Microservices to Serverless #QConNYC https://t.co/peNmVaQtIw
@suksr: Challenges @Meetup faced when going from #Microservices to #Serverless - @pcalcado at #QConNYC https://t.co/33XUNXRhBH
@danielbryantuk: Interesting commentary around @ctford's idea about the danger of creating a "pinball architecture" when using serverless, via @pcalcado at #qconnyc "Events may whizz around your system, but it's really had to figure out what's going on" https://t.co/c55KZLl03O
@danielbryantuk: An interesting discussion of fronting FaaS Functions with an API gateway in order to create "services" @pcalcado was clear to say this may not be a best practice, but there were advantages for his team #qconnyc https://t.co/IkeluOKR7C
@danielbryantuk: Channelling his inner William Gibson, @pcalcado at #QConNYC "The serverless future is here, but it's not quite evenly distributed" https://t.co/ws8w5INnZF
@nWaHmAeT: @pcalcado 's session really thought provoking ... Defining microservices in terms of *application architecture* instead of tech makes a good match with @Indu_alagarsamy 's DDD session. Makes serverless/functions just a VM running your business logic, esp w/ API gateway #qconnyc
Modern Java Innovations
Are We Really Cloud-native? by Bert Ertman
Jeanne Boyarsky attended this session:
Cloud Computing
- Not new
- Market growing fast/analysts on rise
- “Java EE is dead, long live the Cloud” – cloud coming at expensive of Spring, etc
- “There is no cloud. it’s just someone else’s computer” – 5 years ago was just virtualization elsewhere. No longer does it justice
- Evolution – IaaS -> PaaS -> Serverless
- Serverless is the evolution of virtualization or compute
- Re-imagine middleware or higher level services as managed services that can call via an API
- Cloud native is the step after serverless...
Evolution and problems
- 80-90% of IT budgets are spent on maintaining existing systems
- Experiment with new tech/process comes out of time left
- Don’t save money by simply moving the app server to the cloud. Often costs more.
- Then tried spring boot with a fat jar which turned into an inverted app server
- Adding Docker makes it more portable but doesn’t actually use benefits of cloud
- Next tried microservices in Docker. Waste more resources because need more virtual machines. Introducing problems while solving other problems. Modularity is good and microservices are a modularity tool. However adding cost due to network/config/dependencies/versioning/etc
- Next tried Kubernetes. Everyone shouldn’t have to run/manage in prod
- Agile adoption took a few years because needed business buy in. DevOps isn’t just learning tools. DINO (devops in name only)
- Cloud native is a dev ops journey. Continuous journey with new services and components. Services can be short lived. Think about managing a mix of software and infrastructure and scale
- Get to a mix of serverless and non-serverless services.
- Technologies or frameworks are not cloud-native, it is the way you use them
Twitter feedback on this session included:
@jeanneboyarsky: Technologies or frameworks are not cloud-native, it is the way you use them - @BertErtman #qconnyc
Java Futures, 2019 Edition by Brian Goetz
Jeanne Boyarsky attended this session:
General
- Java is approaching middle age. Almost 25 years old
- Keep promises to users
- Prime directive is compatibility
- Backward compatibility matters ex: generics. Don’t need to recompile old code
- Patterns ex: single method interfaces for lambdas rather than having to rewrite libraries
- Languages features are forever. Interacts with others; even future ones
- Waited 10 years for generics until had right story/timing. Knew copying C++ was the wrong choice
- No language is ever finished
- Languages are never good enough because hardware changes, new problems, developer expectations change
- mid-2019 edition because things change so fast
Cadence
- Used to release based on a feature rather than a data
- Often didn’t feel worthwhile to do small feature because got stuck behind big ones
- Now doing about two years of six month release schedule.
- Release management overhead went down to almost zero
- Same rate of innovation; just changed rate of release
- Java 13 already in rampdown. Released in September.
- Already working on Java 14…
Current initiatives
- Amber – right sizing language ceremony. Includes local variable type inference and future changes like pattern matching
- Valhalla – adapt form modern hardware, value types, generic specialization
- Loom – Fibers
- Panama – Native code and data
Twitter feedback on this session included:
@jonesc5: Learning about how Java adds new language features without breaking existing projects from @BrianGoetz #QconNYC https://t.co/HGVMuBalBG
@jeanneboyarsky: Boilerplate bad because a place for bugs to hide - @BrianGoetz #qconnyc Excellent quote!
@jeanneboyarsky: Java ? pattern matching in switch looks cool. Looking forward to getting it and then waiting for the Java 17 LTS to use it in real code! #qconnyc
@jeanneboyarsky: Hmm. Java Record is a promise that it is a dumb data carrier. Does this discourage adding instance methods to the "right place" in the future? #qconnyc
Maximizing Performance with GraalVM by Thomas Wuerthinger
Jeanne Boyarsky attended this session:
GraalVM
- Supports JVM languages, Rubby, Python, C, Rust, R etc
- Can embed in node js, oracle database
- Standalone binary
- Community Edition and Enterprise Edition
- Can run with OpenJDK using Graal JIT compiler or AOT (ahead of time compiling)...
Choosing
- GraalVM JIT – when need peak throughput, max latency and no config
- GraalVM AOT – use when need fast startup time, small memory footprint and small packaging size
Twitter feedback on this session included:
@jeanneboyarsky: "Optimizing on too few benchmarks is like overfitting on machine learning" - @thomaswue #qconnyc
The Trouble with Memory by Kirk Pepperdine
Jeanne Boyarsky attended this session:
General
- Slow database queries, inefficient app code and too many database queries are most reported problems
- Once drill down, over 70% of all Java apps are bottlenecked on memory churn. It’s not reported because hard to observe
- Tend to put logging around past problems.
- If apply instrument to a system, it will always tell you something. And then you act on it
- Cheaper to predict than react...
Problems
- Large number of temporary objects quickly fills Eden
- Causes frequent young cycles. Causes premature promotion which means will go to tenured too early
- Heap becomes more fragment
- Allocation is quick. No cost to collect if objects die quickly. However, still slow if you do something quick enough times.
- Large live data set size. Data consistently live in your heap. Increases time to copy/compact. Likely have less space to copy to. Think about Windows defragmenter. [Do people still have to do that?]
- Memory leak from unstable live data. JVM will terminate if you are lucky.
- Out of memory – 98% of recent time spent in GC with less than 2% of heap recovered. If don’t meet that criteria, app is just really slow, but don’t get the out of memory error.
Twitter feedback on this session included:
@jchyip: >70% of applications are bottlenecked by memory churn. @javaperftuning #QConNYC
@jeanneboyarsky: fun stat from @javaperftuning definition of out of memory error is 98% of recent time spent in GC with less than 2% of heap recovered #qconnyc
Modern CS in the Real World
Leaving the Ivory Tower: Research in the Real World by Armon Dadgar
Twitter feedback on this session included:
@danielbryantuk: Serf (powering Consul) was produced by taking ideas from many different algorithms and papers @armon #QConNYC https://t.co/YECHmogXNL
@danielbryantuk: Paraphrasing wise words from @armon "academia provides lots of great ideas and algorithms, but the constraints of industry means that some are better to implement than others. We like to keep things simple at @HashiCorp" Exploring the creation of Consul, at #QConNYC https://t.co/IqRussL3xN
@danielbryantuk: The @HashiCorp team share @adriancolyer's Morning Paper within internal Slack channels, and ponder whether the ideas could be integrated within products @armon #QConNYC https://t.co/SbD7uq3Km0
@adriancolyer: So cool to see the penetration of research ideas into engineering discussions. Thank you @HashiCorp, made my day :)
@schultzdustin: Quite enjoyed @armon talk on using academic research in industry. We most certainly have a bad case of NIH-syndrome in the tech field. Can almost guarantee a problem you have at your org, is and already has been solved. #QConNYC
@danielbryantuk: "Raft is somewhat like the Rails of Paxos. It's highly opinionated, and this, of course, has tradeoffs" paraphrasing @armon at #QConNYC https://t.co/KD5glULo6v
PID Loops and the Art of Keeping Systems Stable by Colm MacCárthaigh
Jeanne Boyarsky attended this session:
Control Theory
- PID loops are from control theory
- Feedback loop – present, observe, feedback, react
- Hundred year old field
- Different fields claim to have invented it. Then realized fields had same equations and approaches
Furnace example
- Classic example is a furnace. Want to get the tank to a desired temperature. Measure water temperature and react by raising/lowering heat.
- Could just put over fire until done. But will cool off too fast.
- Can overheat because lag
- Focus on error – distance of error to desired state.
PID
- P = proportionate. Make change proportional to the error
- P controller not stable because oscillates a lot
- I = Integral. Oscillate far less
- D = Derivative. Prevents all oscillation
- In real world, PI controllers are often sufficient.
Twitter feedback on this session included:
@copyconstruct: The most classic example of control theory in practice is a ... furnace. Control theory has a lot to teach us about how to effectively operate a furnace. The biggest thing it has to say is - measure the system in terms of the errors. @colmmacc at #QConNYC https://t.co/yCaH0vQGDH
@jeanneboyarsky: excellent explanation from @colmmacc #qconnyc P = proportionate. Make change proportional to the error P controller not stable because oscillates a lot I = Integral. Oscillate far less D = Derivative. Prevents all oscillation In real world, PI controllers are often sufficient.
@copyconstruct: AWS recently launched machine learning based forecasting. To @colmmacc this is a fancy integral (the I component of the PId controller) #QConNYC https://t.co/GyEDEicZ1i
@jeanneboyarsky: "Sometimes they do things, but they don't know why. So they pressed another magic button and it fixes everything" -@colmmacc scary! #qconnyc
@copyconstruct: Chaos engineering and observability help close "open loops. Measures that can help "close open loops. @colmmacc at #QConNYC H/t @caseyrosenthal @nora_js https://t.co/2KAdY6I21t
@jeanneboyarsky: "if we have something that is happening once a year, it is doomed to failure" -@colmmacc example: 1-3 year certificate rotation. Happens infrequently. People forget or leave #qconnyc
@justincormack: The most critical systems at AWS run in constant time. Eg send all the data not just changes. @colmmacc at #QconNYC https://t.co/g4v3UMbtHd
The State of Serverless Computing by Chenggang Wu
Jeanne Boyarsky attended this session:
General
- 2000 students in intro class at Berkeley last year. Put them in concert hall
- How make them more productive so can work on cheap machines like Chromebooks
- Hosted infrastructure/cloud
- Companies dedicated to making serverless easy
FaaS (Function as a Service)
- Run code and pay for only what use
- ex: AWS Lambda
- Optimized for simplicity
- Good at
- embarrassingly parallel tasks – video processing, translation
- workflow orchestration
- Limitations
- Limited execution time – AWS increased from 1 minute to 5 minutes and then again to 15 minutes
- No inbound network connection
- IO is a bottleneck
- Doesn’t support specialized hardware
- Not designed for functional programming because real applications share state. Also, no natural way to chaining/composing functions. Using hacks to get around that introduces latency. AWS Step Functions even slower than hacking with S3 or Dynamo.
Twitter feedback on this session included:
@copyconstruct: The ideal scenario is when we can get both autoscaling and low latency. DynamoDB has a transaction mode which gives you stronger isolation models but at the cost of latency. Building real stateful applications is a non-starter today. @cgwu0530 at #QConNYC https://t.co/gY2oKdo7H0
@justincormack: Lattice is associative, commutative and idempotent, so get convergence @cgwu0530 #QConNYC https://t.co/jrFQQitQQ9
Software Defined Infrastructure: Kubernetes, Service Meshes, & Beyond
Introduction to SMI (the Service Mesh Interface) by Brendan Burns
Twitter feedback on this session included:
@danielbryantuk: "The challenge with some of the cloud native technology, like service mesh, is that this can add complexity that doesn't balance out against the benefits" paraphrasing @brendandburns at #QConNYC https://t.co/pOFyHGrzDG
@danielbryantuk: Nice overview of the goals and basic traffic routing functionality of the @SMI_spec from @brendandburns at #QConNYC https://t.co/XNGDGa82Ul
@danielbryantuk: An overview of the @SMI_spec traffic splitting and metrics specification, via @brendandburns at #QConNYC https://t.co/U3DudSuDYk
Speaker AMAs (Ask Me Anything)
AMA w/ Ashi Krishnan by Ashi Krishnan
Twitter feedback on this session included:
@jessitron: Our eyeballs do edge detection. Our cerebellums predict our position. We process at many layers, feeding back "pay attention! to the earlier layers. @rakshesha #QConNYC https://t.co/jgsSWAlC5T
@jessitron: We are stories telling ourselves. @rakshesha #QConNYC https://t.co/k3J0qpa47R
Workshops
Chaos Engineering in Practice by Matt Davis, James Wickett
Twitter feedback on this session included:
@wickett: At #QConNYC @dtauvdiodr is dropping some @ri_cook knowledge bombs https://t.co/OCPTow2XlY
@wickett: Resilience is not a property that a system has, resilience is a something that a system does. @allspaw #QConNYC cited by @dtauvdiodr https://t.co/qfpGuRLajk
@wickett: Joint Activity. We have agreed to choreographing independent joint actions toward a common goal. @dtauvdiodr #QConNYC
@wickett: Common ground is the most important part of joint activity @dtauvdiodr #QConNYC https://t.co/8DWQYFOXL3
@wickett: Fundamental breakdown of common ground in an incident @dtauvdiodr #QConNYC https://t.co/ftr3Ixbkfv
@wickett: Game days are happening at #QConNYC with @dtauvdiodr https://t.co/VbJlKgcy3S
@wickett: To understand failure, study success. #QConNYC @dtauvdiodr https://t.co/JdrTmr90wj
@dtauvdiodr: "The growth of complexity in society has got ahead of our understanding of how complex systems work and fail." @wickett preaching the good words of @sidneydekkercom #QConNYC https://t.co/VDxQP26R6M
@dtauvdiodr: "Security incidents are not effective measures of detection because at that point it's already too late." - @wickett sharing wisdom from @aaronrinehart #QConNYC https://t.co/F6mGkEwBut
@dtauvdiodr: 5 Why's and RCA fail in Complex Systems !!! @wickett #QConNYC https://t.co/MXVv0n27lQ
Opinions about QCon
Impressions expressed on Twitter included:
@jonesc5: This is both the easiest and most clever way I've seen a conference handle session ratings. #QConNYC
@jeanneboyarsky: I'm really impressed with the "behind the scenes" organization at #qconnyc. Giving each track lead a "bag of wires and adapters" is smart. One of my speakers needed one and it was seamless to get it from the bag
@jonesc5: I really love how #QConNYC sets high level topics for Open Spaces and time boxes internal ‘tracks' to keep things moving and people engaged.
Takeaways
Takeaways from QCon London included:
@rsbecker: @qconnewyork - thank you for another AWESOME conference! Every year I take back a handful of ideas or techs to make us better. #QConNYC\n
Conclusion
QCons are produced by InfoQ.com. With a deep focus on practitioner-driven content without the marketing fluff, each of our conferences is organized by an independent committee of expert software practitioners. We believe in real engineers talking about their successes and failures. The content you see above from QConNYC is a great example of what we’re about.
Our next English QCon is in San Francisco November 11-15th.