4 talks we loved at YOW!Melbourne 2019
YOW!Melbourne is a leading tech conference featuring experts from all over the world, who share the latest insights and practices in software development and delivery. There were so many incredible talks over the two days, but my colleagues Chris, Natasha, Alistair and I managed to narrow it down to our top four. Here’s what we learned at each.
1. Interaction protocols: it’s all about good manners
Speaker: Martin Thompson
“What’s the difference between an API and protocol?”
“How can we optimise our systems?”
“Should we implement synchronous or asynchronous?”
These are some of the questions Martin tried to answer in his talk. Why? Because there’s a very real possibility that we’re going to run out of energy to run all of our computation by the year 2030, when the amount of computing we’ll do as a human race will use all of the energy that we currently produce. According to Martin, a lot of this computing is wasteful because of poorly optimised software.
Martin explained that we tend to design and build APIs and not protocols. An API simply describes what a consumer is able to do. A protocol also does this, but adds in how. For example, an API for managing a file in a file system could define four operations: open, read, write and close. A protocol would define that you must open a file before a read or write operation can occur, and that you must close the file afterwards.
By using protocols, we can optimise software and solve difficult problems like sequencing, versioning, error handling, batching and more. Martin also delved into sync vs async operations and explored why asynchronous computing can optimise our systems. However, for us to do this well, we need to define our protocols.
What I learned
At Xero, we’re currently working out ways to break up the monolith and move to a microservice architecture. If we carry on defining APIs and don’t think about the underlying protocols, then we may end up with a lot of poorly optimised services. It may be worth defining a protocol and using binary codecs (e.g. protobufs) as an experiment with one or two services, to see whether these will make our services more reliable, understandable, performant and resilient.
2. Scale, microservices and flow
Speaker: James Lewis of ThoughtWorks
It’s a familiar perception that the bigger an organisation gets, the slower it becomes. But what’s more interesting is understanding the relationship between revenue growth versus employee count. At Amazon Web Services (AWS), the ratio of revenue growth per unit of employee growth means that as AWS employees double in size, its revenue more than doubles.
To understand why, James spent time reviewing research from the Santa Fe institute on Complex Adaptive Systems (part funded by Jeff Bezos of Amazon). They observed patterns in biology. Very specifically, mammals. To aid an efficient transfer of blood, the blood vessels of mammals are ‘right sized’. Too small and you have blood clotting, too large and you have blood thinning. The key is getting the right balance flow of blood across the vessel hierarchy.
James argued that the flow of value in organisations is similar to the flow of blood. If you create teams of people that are role aligned (not value aligned), then queues are required to manage the arrival of work. Of course, when blood queues up, it eventually leads to a strain on the vessels and the heart. We need the right balance of work across the hierarchy, just as our bodies do naturally.
What I learned
It’s a good idea to monitor the health of your value stream regularly (including mean time to recover, time from commit to production, number of times changes need to be rolled back, and number of deploys) just like you’d have a regular heart rate and blood pressure check at the doctors.
Hierarchically organised teams suffer from sub-linear growth. To achieve super-linear growth like that of AWS, we need to embrace social networking effects to avoid the hierarchy constraining our growth.
Teams should communicate via interfaces which must be external (think public APIs). This will encourage teams to organise around business capabilities. The more of your IP that you can externalise, the better you can embrace this social network effect (consider Amazon with AWS).
3. The Unicorn Project and the Five Ideals
Speaker: Gene Kim
Gene Kim is one of the authors of the book, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. In his talk, he gave a brief overview of his new book, The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data.
Gene described the difference between low performers and high performers (measured by DevOps metrics: deployment frequency, deployment lead time, deployment failure rate and mean time to restore). High performers:
- spend 29% more time on new work
- are twice as likely to achieve organisational and mission goals, customer satisfaction, quantity and quality goals
- have an employee net promoter score that is 2.2 times higher
- spend half as much time remediating security issues
- are twice as likely to exceed profitability, market share and productivity goals
“The business value of adopting DevOps is even higher than we thought.” Gene Kim
The Unicorn Project book is essentially The Phoenix Project retold from the perspective of the developers (and the Phoenix Project is an adaptation of The Goal retold from the perspective of technology). The Five Ideals that Gene Kim talked about and describes in the book are as follows:
1. Locality and simplicity
Every team has the expertise, capability and authority to satisfy customer needs. Every team has access to the data they need, on-demand, quickly, accurately and securely.
2. Focus, flow and joy
Your energy and time is focused on solving the business problem, and you’re having fun. How long does it take to go from code committed to code successfully running in production?
3. Improvement of daily work
We should make tomorrow better than today, instead of focusing on ‘the way we’ve always done it’. Ideally, 3–5% of developers should be dedicated to improving developer productivity.
“So I would, any day of the week, trade off features for our own productivity.” Satya Nadella
4. Psychological safety
Psychological safety is one of the top predictors of performance. Can we take risks on this team without feeling insecure or embarrassed?
5. Customer focus
Functional silo managers should make decisions based on what the customer values, which helps ensure their teams have the skills to thrive in the long term.
What I learned
Gene mentions the audience for The Phoenix Project is leadership, while The Unicorn Project audience is the developer community. His hopes are to inspire transformation from both directions. The talk was a great summary of what makes a great DevOps culture. It made me think about the DevOps practices at Xero from the perspective of the five ideals he describes.
4. Evolving chaos engineering
Speaker: Casey Rosenthal, CEO and Cofounder of Verica.io
Chaos Engineering isn’t about creating chaos, but rather identifying the chaos inherent in a complex system. The other practices that commonly address availability (incident management, alerting, monitoring, disaster recovery etc) are all reactive — they focus on time to detect and time to remediate.
Chaos engineering on the other hand is proactive — finding systemic vulnerabilities before they affect customers.
Now that chaos engineering has high adoption at big tech companies and non-digital native organisations, we can look at how the practice is maturing. Our knowledge of systemic properties of complex systems is improving and leading us into a new era of Continuous Verification. However, there are a number of common myths which people have about creating reliable and stable software:
Myth 1: Remove the people who cause incidents
Myth 2: Document best practices and runbooks
Myth 3: Defend against prior root causes
Myth 4: Enforce procedures
Myth 5: Avoid risk
Myth 6: Simplify
Myth 7: Add redundancy
As a result, over the years we have evolved how we deliver software.
Continuous Integration (CI)
This is the industry norm of integrating code early to uncover issues, which are heavily promoted by XP methodology as an efficient way of uncovering misalignments or issues.
Continuous Delivery (CD)
Continuous Delivery has built on the success of CI by automating the delivery of software to production, allowing developers to promote code to production which has passed the CI stage.
Continuous Verification (CV)
CV was born out of the need to navigate increasingly complex systems. Modern organisations can’t validate that the internal machinations of the system work as intended, so instead they verify that the output of the system matches expectations. So CV is a proactive experimentation tool for verifying system behaviour.
A really important point to highlight is that tools don’t create reliability. Humans do (but tools can help).
What I learned
We need to continuously be striving to improve the way we develop and deliver software. Some of the most exciting growth periods that I’ve had have been while learning about functional programming and being exposed to different quality techniques like property-based testing.
As the myths above highlight, having good development practices like runbooks is not solving the root cause of the problems we face in building software at scale. We need to be able to target the ways we work and the value they bring.
The next YOW!Melbourne event is 3-4 December 2020 and I really recommend heading along if DevOps is your thing. Thanks to my colleagues Chris Chamberlain, Natasha Smirnova and Alistair Bush who contributed recaps of their favourite talk! Did you go? What was your favourite talk? We’d love to know.
