Gordon Inggs

Twitter Profile link: https://twitter.com/Gord1ei

Fediverse Profile link: https://fosstodon.org/@Gord1i

github profile: https://github.com/cityofcapetown/service-alerts-connector/

Dr. Gordon Inggs is a Principal Data Engineer at the City of Cape Town, known for working on large, complex socio-technical systems. Raised among the penguins of Simon’s Town, he completed his undergraduate and Masters in Electrical Engineering at the University of Cape Town in 2011, followed by a Ph.D. in Computer Engineering at Imperial College London, focusing on heterogeneous systems, which was awarded in 2016. After his PhD, he returned to Cape Town to work for Amazon Web Services in 2016. He worked on the EC2 product, contributing to some of the largest computing systems on the planet. In 2018, he joined the City of Cape Town, initially as the city’s second data scientist. However, in 2021, he recognised his true calling, data engineering, and transitioned to that role, dedicating himself to practical data solutions for the City’s residents. Dr Inggs has a unique combination of advanced technical knowledge, combined with deep understanding of the social contexts within which these technologies might play a role.

Accepted Talks:

You don't need a data service, you just need an object store and some JSON files

What are you talking about?

In this talk, I will describe an approach to building highly scalable services that is both extremely reliable and dirt cheap to run. The essence of our approach is eschewing popular service frameworks such as Flask, and instead sweating the HTTP API of object stores, such as those made available by large cloud providers, or on-premise options such as Minio or Ceph, along with supporting infrastructure such as data pipelines and content delivery networks.

To illustrate this concept, I'll talk through the architecture of the City's open source Service Alert API, and how we provide a near real time data API which is well specified using an OpenAPI spec, but is really just a few JSON files in AWS's S3.

Who is this for?

This should be interesting to anyone that is nervous about having to support a large user base, but has important information that they need to make available. For small teams or those lacking DevOps capacity, we believe this is an extremely viable approach. It's also potentially a cautionary tale about what happens when the hubris of Man is left unchecked.