Uber's Michelangelo vs. Netflix's Metaflow

-
  Uber's Michelangelo vs. Netflix's Metaflow Michelangelo Pain point Without michelangelo, each team at uber that uses ML (that’s all of them - every interaction with the ride or eats app involves ML) would need to build their own data pipelines, feature stores, training clusters, model storage, etc.  It would take each team copious amounts of time to maintain and improve their systems, and common patterns/best practices would be hard to learn.  In addition, the highest priority use cases (business critical, e.g. rider/driver matching) would themselves need to ensure they have enough compute/storage/engineering resources to operate (outages, scale peaks, etc.), which would results in organizational complexity and constant prioritization battles between managers/directors/etc. Solution Michelangelo provides a single platform that makes the most common and most business critical ML use cases simple and intuitive for builders to use, while still allowing self-serve extensibi...
Post a Comment

The Best Intro to Distributed Systems

-
I recently switched teams at Facebook.  I went from working on user-facing search technologies to running the distributed systems that allow other teams at my company to move fast.  To be clear, I used to bake the break, now I build the bakers an oven!  Although I had some background in these systems, things change quickly and the field is deep with decades of knowledge to pull from and build upon.  I needed a refresher!

I found one - a friend recommended a book called 'Designing Data Intensive Applications'.  It sounded a bit off-topic - the title didn't have 'distributed' or 'systems' in it!  Turns out it gave me exactly what I needed.  DDIA is the best introduction and deep dive into all the areas of expertise that the DS specialty has to offer - and wow is this field deep!  The book requires a bit of background - you'll need to have a bachelor's in CPSC or similar experience, as the first few chapters build on that knowledge.  Once the foundation is set, the book goes into very important concepts that anyone who's been working in a software infrastructure environment like AWS, Google Cloud or Facebook infra, would need to know.  The foundational chapters cover reliability, maintainability and scalability and then go on to talk about how to think about and handle data - for example, how do you decide what encoding technology to use when starting a software project?

Then, in part II, the book goes into the real meaty parts of distributed systems - the things that are absolutely essential to know for anyone to be successful if you're going to go oncall for AWS or a team that owns & maintains an instance of ZooKeeper.  Replication, Transactions and the fundamental problems that the field of Distributed Systems is trying to solve - these are a few of the topics that Part II covers.

Lastly is the most fascinating part of the book - and it's really the reward after getting through all of the previous material - these are the newest and most interesting concepts that the field has to offer at this time.  Part III does a deep comparison between batch and stream processing and makes the argument that stream processing is the Next Big Thing in software architectures.  If batch processing was one of the most important developments at Google's inception, then stream processing will be the most important development in the inception of...well, whatever the next Google is!

After finishing the book and having taken a few notes & flashcards (which I'll post up somewhere for others to use when I get around to it), I was much more confident going into meetings and discussions about how our systems work, how they're currently broken and how they could be better.  The book was a watershed moment in my career, and I'd encourage anyone in software engineering role in a DS-focussed team to read it.  This one needs to go to the top of your 'software career-ing' reading list.

And please do send me a note if you end up reading it (or have already) and tell me your thoughts!

Comments

Post a Comment

Popular posts from this blog

ChatGPT - How Long Till They Realize I’m a Robot?

-
Image
I tried it first on December 2nd... ...and slowly the meaning of it started to sink in. It's January 1st and as the new year begins, my future has never felt so hazy. It helps me write code. At my new company I'm writing golang, which is new for me, and one day on a whim I think "hmmm maybe ChatGPT will give me some ideas about the library I need to use." Lo-and-behold it knew the library. It wrote example code. It explained each section in just enough detail. I'm excited....It assists my users. I got a question about Dockerfiles in my teams oncall channel. "Hmmm I don't know the answer to this either"....ChatGPT did. It knew the commands to run. It knew details of how it worked. It explained it better and faster than I could have. Now I'm nervous....It writes my code for me. Now I'm hearing how great Github Copilot is - and it's built by OpenAI too...ok I guess I should give it a shot. I install it, and within minutes it'...
Read more

Architectural Characteristics - Transcending Requirements

-
Image
Building a system means meeting a set of requirements dictated by the customer.  But the customer isn't always going to translate what they want into engineering terms.  Even if you say please, they might not even know how.  If they ask for an online ordering system, they probably won't specify that it needs to be available 24/7 and auditable for tax purposes.  Yet these aspects could mean the difference between project success and failure.  Those unsaid aspects are called anything from 'nonfunctional requirements' to 'Architectural Characteristics'. In their book 'Fundamentals of Software Architecture', Ford and Richards define Architectural Characteristics to have 3 criteria: Specifies a nondomain design consideration Let's dive into these bullets to better understand them. Aspects of Architectural Characteristics Specifies a nondomain design consideration If you're building an ordering system, then order numbers, customers, items and prices ar...
Read more

Laws of Software Architecture

-
Image
As the discipline of software engineering matures, few things remain constant.  A few years ago, a large portion of the community thought that TDD was always the best methodology to use - after all, you move faster by being thorough and preventing bugs.  Nowadays it's clear that unit tests do not ensure a successful project - when you're A/B testing new features or products and you're not even sure if your code will be around 3 months from now, it's better to churn out production code and test it in prod.  You can clean up the mess later, if the business value makes it worth it. But despite the pace of change in software engineering , in software architecture  there exist a set of 'laws' which don't change over time and which apply to all architectural endeavors.  I'd like to talk about 2 of them in this post as they are important ideas to keep in the back of your mind as your skills grow past coding, past design and into architecture. Laws of Software A...
Read more