data as dna: building a company on data – live blogging at qcon

Data as DNA: Building a Company on Data
Speaker: Cathy Polinsky @cathy_polinsky

See the list of all blog posts from the conference

“90% of the world’s data has been created in the past 2 years” – has been true for a number of years because in the age of data

Key Points

  • If the data is not visible, it is meaningless – need to be able to visualize, understand and interpret the data
  • Does everyone have access to the data – be sure to strip/mask sensitive data or aggregate data (mimimal sample size so not sharing PII data)
  • Determine what data/questions/metrics are important – need to know what optimizing for

Testing

  • Showed Amazon example of when they had two many tabs.
  • A/B testing failed because people were used to the original.
  • A/B testing doesn’t help for short term effects.
  • Don’t look at results too early
  • Be explicit about what important to you
  • Iterative testing is important
  • The colser you are to your goal, the more important it is to evaluate your goal metrics
  • Don’t want too. much or too little data – Goldilocks

Personalization

  • Personalization is not new – even the shopkeeper in a physical store made recommendations
  • Stitch Fix is a personalization company. A personal human stylist curates 5 pieces for you to try on at home. The stylist uses big data and algorithms to help.
  • Tune through feedback.
  • >Most retailers have broken feedback loops. No reason for consumer to share if too expensive, if didn’t fit right, etc. Need compeling self interest to give you data. Best way is if used to make experience even better.
  • Need to show trust nd use data responsibly to get data and get customer to continue to give you data

Hard to predict what computers can’t do. Ex: driving, understanding human speech

Freestyle chess – humans paired with computers being pure computers or pure humans. Use best of human and computer skills. Also had superior technique for how to use computers. Strategy matters!

Humans goo an interpretting query or suggesting things. Review edge cases of output.

choose your own adventure: chaos engineering – live blogging from qcon

State of Chaos Engineering
Speaker: Nora Jones

See the list of all blog posts from the conference

Known ways for testing for availability

    Unit test
  • Integration test
  • Regression Test
  • Chaos Engineering – much less common. Doesn’t replace need for “traditional” tests

Chaos Engineering

  • Most people know what Chaos Monkey is; far less know about Chaos Engineering. The former is a tool’; the later is a strategy. The former is mature; the later is emerging
  • “chaos” means different things to different companies. Common things: experimenting, distributed system, make system stronger through experiments
  • Goal is to run chaos all the time, not just on deployment

Why to start

  • Can’t keep blaming your cloud provider. Need to own failure
  • Failures will happen anyway. Why are we afraid of that?
  • Computers are complicated and they will break

“Chaos Carol”

Introducing chaos

  • think about where you are now and expected response
  • How many people should know the chaos is intentional? Helpful to know running an experiment.
  • Define “normal” system and behavior
  • Relate chaos to automated tests, SLAs and customer experiments
  • Start in QA, not Prod. This estabilishes a baseline
  • Only run during business day

Ways to create chaos

  • Start small – graceful restarts or degregedation
  • Randomly turn things off
  • Recreate things that have already happened – good once reach a steady state

Culture and implementation

  • People need to understand revealing problems is good (vs causing problems)
  • Start with opt in so people have control
  • Monitoring is important. Use dashboards to communicate
  • Automatically shut down experiment if goes too far astray
  • Have your incident/Jira/PagerDuty tickets gone down
  • Don’t forget about your company’s customers. Focus on business goals and not causing customer pain

Cascading failure

  • Try later on
  • Start in QA
  • May fail in unexpected ways – the tool broke QA for a week
  • Problems lie dormant for a long time

Testing

  • FIT – Failure Injection Testing
  • F# library: https://github.com/norajones/FailureInjectionLibrary
  • Types of chaos failures – exceptions, latency
  • After FIT, focus on minimizing blast radius and concentrating failures
  • Targeted chaos – important to have a steady state before introduce so know what caused by introduction

The choose your own adventure was a fun series of choices to think about viable options. Or not viable in some cases.

unifying banks & blockchains at coinbase – live blogging at qcon

Unifying Banks & Blockchains @Coinbase
Speaker: Jim Posen

See the list of all blog posts from the conference

Coinbase converts blockchain currency with traditional/fiat currency. Started doing that in 2012. Then added support for European banks in 2014. Then in 2015, added an Exchange.

In 2016, the Rails app was becoming a problem and the BitCoin logic started to degrade. Created first microservice at that point. Now support multiple currencies. Still maintain monolithic Rails app.

Bitcoin

  • definition – Bitcoin is a scarce digital asset and a protocol for transfering the asset over the internet. “Email” is overloaded in two ways as well.
  • Public transactions ledger
  • About 30 minutes for transactions to clear – regardless of hours and holidays
  • Irreversible payments

Coinbase architecture

  • Uploads batch file daily to the originating depository financial institution (ODFI). Clears thorough ACH operator to receiving depository financial institution (RDFI) and receiver receives
  • The RDFI has 24 hours to return for insufficient funds
  • Then the receiver can challenge/return for up to 60 days – important consumer protection, but a challenge
  • Bitcoin uses gossip protocol where nodes talk to other nodes

More happened after I left. The session was good. I had a hard stop today and had to leave.