Episode #14 -- Do you own your Platform?

Available on your favorite podcast platform.

Show notes:

  • difference between a product and platform
  • platform is a collection of modules and tools
  • a platform is extensible, programmable, consists of reusable pieces and
    components
  • desirable qualities in a platform and various considerations
    • a platform is a living being to some extent
    • availability
    • stability
    • performance
    • how easy is it to fix when things break
    • adaptability
  • the iceberg analogy – most of your product is invisible, but this can cause
    problems
  • how do you select the right technology for your platform?
    • important not have bias
    • products are short-lived, where platforms last a long time, so important to
      make the right choices in your platform.
    • it is good to depend on standards to avoid lock-in to one tool/technology
    • the wrong solutions do not scale
    • have a network of experts you can reach out to and get the information you
      need
    • knowing who to ask is the superpower in this age
  • why you need some level of control over your platform
    • damage control: solve problems when they arise
    • moving things forward: can it be modified as new requirements come up
  • building platforms for reuse
    • build systems are important
    • automation
    • continuous integration
  • The Yoe Distribution and the Simple IoT project are examples of platforms that
    are re-usable and flexible, and applicable for a wide range of projects
  • recomposable platforms scale not just vertically, but horizontally, which is
    the real power of them
  • a lot of up-front discipline goes into this
  • you create a platform not only for others, but yourself
    • you respect the APIs in the same way you expect others to respect them
    • APIs as a contract become very important
  • Most people can track product costs very well. Platform costs are harder to
    track and are an investment in the future
    • example of an embedded Linux platform that goes into a product that lives
      for many years. A lot of work is required upfront to get the base system
      running, but then you can build on it for years.
    • A more constrained platform like a MCU + RTOS tends to be not as extensible
      and more limited to a product.
  • Two kinds of platforms
    • Transaction platforms: facebook, twitter, etc
    • Innovation platforms: what we’ve been talking about
  • personal platform
    • write things down
    • when helping someone, instead of emailing or messaging the solution, I write
      down the solution in some type of long lived documentation, and then share
      that documentation with them.
  • do you own your platform?
    • owning your platform is more of a mindset rather than an rigid absolute
      • are you willing to learn and own the details of your platform
    • with OSS we not only use it, but we also have the option to be part of it

Interesting comment in this recent article:

A Note on Public Cloud

In the aftermath of an outage like this, it’s natural to ask if Roblox would consider moving to public cloud and letting a third party manage our foundational compute, storage, and networking services.

Another one of our Roblox values is Take The Long View, and this value heavily informs our decision-making. We build and manage our own foundational infrastructure on-prem because, at our current scale, and more importantly, the scale that we know we’ll reach as our platform grows, we believe it’s the best way to support our business and our community. Specifically, by building and managing our own data centers for backend and network edge services, we have been able to significantly control costs compared to public cloud. These savings directly influence the amount we are able to pay to creators on the platform. Furthermore, owning our own hardware and building our own edge infrastructure allows us to minimize performance variations and carefully manage the latency of our players around the world. Consistent performance and low latency are critical to the experience of our players, who are not necessarily located near the data centers of public cloud providers.

Note that we are not ideologically wedded to any particular approach: we use public cloud for use cases where it makes the most sense for our players and developers. As examples, we use public cloud for burst capacity, large portions of our DevOps workflows, and most of our in-house analytics. In general we find public cloud to be a good tool for applications that are not performance and latency critical, and that run at a limited scale. However, for our most performance and latency critical workloads, we have made the choice to build and manage our own infrastructure on-prem. We made this choice knowing that it takes time, money, and talent, but also knowing that it will allow us to build a better platform. This is consistent with our Take The Long View value.

Hardware platforms are also super useful, both for the hardware design and for the software.

In past jobs I’ve always gotten to experience failed attempts at making new platforms because, “This time we’ve learned from the past platform failures!” But they almost always failed beyond the first set of products built off of them.

Most hardware platforms don’t scale, or don’t scale in the way which is easy based on the choices made early in their design. I guess software is similar, but software has it easier as although there’s a cost to redo software, distribution and “manufacturing” is significantly cheaper than hardware.

1 Like