How We Broke the World Record for Computing Digits of Pi (31.4 trillion!)
Emma Haruka Iwao, Google
This was the opening keynote of Day 3 by Emma Haruka Iwao, a developer advocate for Google Cloud Platform – and world record holder. It was a talk of two parts; one about the technical hurdles of achieving the World Record and the other about Emma’s personal story.
Knowing nothing about pi world records, this talk surprised me. I learned this was the first-ever attempt to break the world record using Cloud computing, taking 4 months, 200TiB of storage and a cost of $200k. The record answered questions about things they didn’t know such as single instance uptime and the durability of SSDs over months.
Emma touched on the importance of Mechanical Sympathy, an idea which embodies the idea that to get the best out of software, you need to understand the hardware you are running on. This idea was introduced to computing by Martin Thompson and the term was originally coined by the racing driver Jackie Stewart:
“You don’t have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy.”
Another key takeaway was to always prepare for the unexpected and have an effective Disaster Recovery plan. Emma succinctly hammered this point home:
“If you haven’t restored from backups, you don’t have backups”
I thought the talk was great. It underlined how the Cloud enables you to iterate quickly and experiment at little cost. It outlined success also requires the right tooling, culture and good teamwork.
This tallies with my experience here at OpenCredo. Using the Cloud enables me to prototype different solutions which can lead to a better understanding of the problem and solution. When done I can just throw away things that didn’t work without a huge cost.
How to Break Builds and Influence People – Ordnance Survey’s Ongoing Cloud Native Journey
Andy Bridle & Phil Peters, Ordnance Survey
The talk by Andy Bridle & Phil Peters, focuses on the experience of the Common Engineering Team in Ordnance Survey. It detailed the challenges and successes they faced instilling DevOps and Cloud practices.
One of the early issues they faced was one of scale. The team was outnumbered by application developers, they had to be smart with the resources they had. They solved this problem by treating developers as customers.
The team built a brand for themselves, along with a logo, so they had an identity and were recognisable. They used Slack as a self-service mechanism for supporting developers. They used internal consultancy, pairing with developers, for skills and knowledge transfer. They attended stand-ups to understand what was happening. Their approach worked and they knew it. Developers had started helping each other without intervention from the team.
One thing I liked about the talk was the honesty. It portrayed a realistic account of what you can encounter making the Cloud Native journey. It again underlined that the journey is not only about technology. You need to bring people with you and there is a cultural shift.
The talk also demonstrated the importance of management buy-in to support the transformation. Attempting this organically would likely be a fruitless endeavour. When we help clients, we recognise that the tech is only one aspect of the problem. If you don’t consider the whole picture, you will end up solving the wrong problem.
Quality for ‘Cloud Natives’: What Changes When Your Systems Are Complex And Distributed?
Sarah Wells, Financial Times
The closing keynote of the conference was by Sarah Wells who is the Technical Director for Operations and Reliability at Financial Times. Sarah spoke about how traditional tools and techniques were not enough for microservice and serverless architecture.
In part of the talk Sarah described how they had a problem with the acceptance tests. They were brittle, had a high maintenance cost and were not providing value. To tackle the problem, Sarah spoke of the need to “push testing right”, in other words closer to production.
One of the techniques they used to push testing right was Synthetic Monitoring. This is where you run a test against your live system, for example publishing an article. Such a test gives confidence that an aspect of the system is working that would otherwise be difficult to find out pre-production.
Sarah also touched upon the importance of separating the delivery of features and fixes and remarked that finding problems quickly was useless without being able to fix them quickly.
The talk also delved into observability, chaos engineering and using gamification for creating system operational information.
For me, this talk was really thought-provoking talk and an excellent end to the conference.