Microservices at Tyro: An Evolutionary Tale (Presentation)


In February, I presented a talk at the Sydney Microservices Meetup titled “Microservices at Tyro: An Evolutionary Tale”.

Microservices at Tyro

I wanted to talk mostly about things we’ve been doing with microservices at Tyro Payments over the last year, but also about the almost 10 years of practice with distributed computing that has led us towards what we’re doing today.

I’ve merged my slides and the audio from the talk into a video, which you can watch below. If you’re more the reading type, there’s a transcript from the talk beneath the video. My talk goes for 40 minutes and then there’s 20 minutes of Q&A.

The talk covers:

  • Who is Tyro Payments?
  • Why are we doing Microservices?
  • Tyro’s Architecture History
  • Current development in Microservices
  • Tyro Microservices Practices
  • Asynchronous Communication Strategies
  • Helping Out Ops
  • Microservices Technologies and Patterns
  • Challenges we’ve been having at Tyro
  • Microservices pre-requisites

Continue reading

Tribal Leadership by Dave Logan et al. (Book Review)

Tribal Leadership:
Leveraging Natural Groups to Build a Thriving Organization
by Dave Logan

My rating: 5 of 5 stars

So, the story goes that our CEO, Jost Stollmann, asked Mike Cannon-Brookes, co-founder & co-CEO of Atlassian and one of Tyro’s board members, something along the lines of…

“If you had to recommend just one book to your leadership team, what would you choose?”

And Mike recommended: Tribal Leadership. I think I can see why.

What’s the book about?

The book is about the results of ten years of research by the authors and how they found that people in organisations form tribes; that each tribe has a prevailing culture; that the cultures can be roughly grouped into five different levels; that the culture of the tribe can be an indicator of organisational success; and that the culture of individuals and of tribes can be “upgraded” through the levels using actions they describe, undertaken by tribal leaders. (Note that it’s not about leaders trying to create tribes in order to succeed – the tribes are a natural phenomenon, and the benefit comes through recognising them and influencing them. It does talk about building and enhancing networks within tribes.)

The book is well-written (i.e. not boring), contains lots of case studies and interviews, has excellent summaries at the end of each chapter (no highlighting necessary!), and it doesn’t just focus on what to do to become “great” – it also covers basket case cultures and how to start progressing people out of there.

What did I like about the book?

The number one thing I like about this book, as a leadership book, is that it pretty quickly gets a thoughtful reader looking not merely at their own actions and what they can do to improve, but also at how the people around them in the organisation are acting and interacting. You start to think about how to improve the company by influencing the culture, not just about how to improve your own output and your team’s output by doing a few things differently.

The main premise of the book is pretty simple to understand and start putting into practise: people’s culture can be detected by the language they use, and also affected by the language those around them use. So, people in Stage 3 tribes (where most corporate cultures are at) are all about personal accomplishment and they’ll say a lot of things that basically translate to “I’m great”. In contrast, people at Stage 4 are all about forming and maintaining good working partnerships with people around them, and their language will come out as “We’re great”.

As soon as I started reading all this, I could see how problems which I’d observed at work were caused by the behaviours detailed in the book. I also started to see problems I hadn’t noticed before, or areas that were about to be problems, based simply on how people were talking to each other or about each other. I recognised in myself some things I’d been doing which were contributing to holding the culture back from where it could be.

The book has many examples of great companies to aspire to, and not just the ones you’re used to reading about. Yes, there’s analysis of raging startup successes like Zappos, but there’s also a lot of time spent describing a hospital that focuses on creating excellent customer experiences.

The book has great advice, much of which is easy to start following, and it changed the way I behave, even as I was reading it.

Should you read it?

If you’re in any kind of leadership position, in any kind of organisation, I highly recommend this book. Maybe it won’t change your world, and you may not have all the influence you would need in order to affect the whole organisation. At the very least it should help you to start seeing the culture around you for what it is, and start to move it forward from the position you’re in.

Buy it on Amazon

View all my reviews

Top 10 Reasons Java Programs Envy Scala (Presentation)

From the archive: Originally posted in October 2011, I was reminded today of this post from my old blog, Graham Hacking Scala. I thought I should bring it over and give it a bit of a refresh…

In October 2011, I presented a talk at the 2nd meeting of the (then) new ScalaSyd Meetup. I talked through the “Top 10 Reasons Java Programs Envy Scala” in an attempt to give Java developers a taste of some little things that could make them much more productive if they switch to Scala.

Interestingly, in almost 4 years, very little has changed. Yes, Java 8 now has lambdas, but the standard collections library still makes very little use of them, forcing you to convert any collection to a stream before lambdas can be used, and pretty much nothing else mentioned in the talk has made its way into Java SE. People are still writing up lists of how to use Java better, but the fact is that a lot of Java best practices are either built into or easier to achieve in Scala.

Anyway, if you want get the real scoop on Java vs Scala and hear what all the Scala kids are raving about:

  1. hit play on the SoundCloud recording below, and then
  2. follow your way through the Prezi below that.

Continue reading

Book Recommendations from Sydney Technology Leaders

Last week I went to the Sydney Technology Leaders’ Meetup, which we hosted in the Tyro Fintech Hub. There was a trio of great talks, and a panel discussion with the speakers at the end.

When asked what they do to help train new leaders, one of the speakers mentioned “throwing a bunch of books at them”. So I took the opportunity to ask the speakers, if they could only recommend one or two books to a new leader, what would each of them recommend. Continue reading

Design Kata: Learn software architecture while having fun

Children practising a karate kata. This article describes design kata, where software developers practise designing software architecture.At Tyro, we don’t have anyone with the title of Architect, Designer or Tech Lead who designs software and then asks other people to build it. Instead, each team of Software Engineers does architecture and design as part of their iteration planning sessions for the stories we’re taking on.

As a Team Lead, the two main goals I keep in mind for each person are: keep them happy and keep them growing. One of the ways I try to ensure this happens is by meeting with each person regularly so we can chat about how to make sure these things are true or at least heading in the right direction.

A topic that’s come up with a few people lately is software design and architecture. Specifically, I’ve had a couple of comments along the lines of: “When we’re designing things, I want to contribute more, but I’m not really sure where to start.” Continue reading

Microservices Security: All The Questions You Should Be Asking

I spoke earlier in the year at the Sydney Microservices Meetup about the long path we’ve taken at Tyro Payments over the last decade, gradually tending towards a more fine-grained SOA approach – microservices as it’s come to be known recently.

Hacker-looking character sitting at a Mac in a dark room, checking out your microservices securityI covered a lot of ground in that talk, but something I didn’t get around to talking about was security. However, I believe that’s a really important topic to think about in microservice environments. It’s even more important than with a monolith, because in a service-oriented architecture you’re making a lot more of your system’s functionality directly exposed to the network, and that puts it in closer reach of would-be attackers, or “increases the attack surface” as a security pro would say.

So last week I presented another talk entitled “Microservices Security: All the Questions You Should Be Asking”.

Microservices Security: Let’s Share What We Know!

I want to tell people all about what we’ve been doing about security at Tyro lately. Security is incredibly important to the IT community and I think it’s imperative that we help each other improve. I want to share with the world some of the problems we’ve dealt with and some of the great solutions our team has built. Continue reading

Alan Turing: The Enigma by Andrew Hodges (Book Review)

Alan Turing: The EnigmaAlan Turing: The Enigma: The Book That Inspired the Film “The Imitation Game”
by Andrew Hodges

My rating: 3 of 5 stars

If I had to describe this book in one word, it would be: “indulgent”.

The author has obviously spent a lot of time researching many facets of Alan Turing’s life and work. (It seems he even interviewed many people who knew him.) However, he doesn’t appear to have spent much time deciding what not to put in the book. Consequently, it’s very long, and by a third of the way through it, when I was still reading about Turing’s uncomfortable years at boarding school, I seriously considered giving it up.

I didn’t give up, though, and I was glad in the end.

The middle sections of the book, explaining first Alan’s pioneering work as a young mathemetician, then his contribution to cracking the Enigma system, and then his diversion into the design and operation of early computers, were a really interesting read. The author went into quite a lot of mathematical and technical detail in parts which, as a software engineer, I quite enjoyed.

It was very interesting for me to realise that his major achievement was really in his mathematical endeavours rather than in computing. He didn’t do a whole bunch of amazing hardware stuff alone, unlike the film tried to suggest, and the team that eventually built the first working general purpose computer did it in competition with the group Turing was working with, though that project’s lack of progress was not of his making. However, his contribution to mathematics, by proving that there were uncomputable problems, was extremely significant at the time, and Hodges does a good job of setting the scene and describing how Turing’s discovery came about.

During the narrative of these later parts of his life, many of the episodes and observations from Turing’s early life are linked into the story, showing how his upbringing contributed to, and sometimes adversely affected, his pursuits. However, the same links could probably have been drawn with far less detail spent documenting his childhood.

The documentation about his eventual demise leads into some nice, reflective wrapping up about his whole life. This too, though, is probably more long-winded than it needed to be.

All in all, I learnt a lot about the man, about his achievements, about the war, and a few things about maths and computing. I would have preferred it to be a whole lot shorter, though.

PS – I read this book because the movie had come out and I wanted to read the book first. The movie is so far from what is documented as reality in this book that having read the real story actually ruined the movie for me. If you want to both watch and aread, I suggest you watch the movie first, understanding it strays very far from the truth, then read the book afterwards to get the true story.

Alan Turing: The EnigmaBuy it on Amazon

View all my reviews

Notes from YOW! 2014: Simon Brown on ‘Agility and the Essence of Software Architecture’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Simon Brown (@simonbrown) spoke on “Agility and the essence of software architecture”. (Slides, Video)

He started with a great Dave Thomas quote:

“Big design up front is dumb.
No design up from is even dumber.”

Whiteboard covered in a circuit diagram, which looks pretty similar to a typical software architectureSoftware Architecture Agility

He went on to tell us…

Delivering software in an agile way doesn’t guarantee that you’ll develop an agile architecture.

A good architecture enables agility.

He asked “Are monolithic architectures agile?” and proposed the answer, “Well, they could be. Just because you have to deploy it all at once doesn’t mean it’s not agile.”

Which naturally lead into a discussion of what does agility mean? Continue reading

Notes from YOW! 2014: From Monoliths to Microservices at REA

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Microservices at REA (Real Estate Australia)Beth Skurrie (@bethesque) from DiUS, Evan Bottcher (@evanbottcher) from Thoughtworks and Jon Eaves (@joneaves) from REA group spoke about migrating realestate.com.au to a microservices architecture. (Slides, Video)

Why REA migrated to microservices

They started by talking about why they started doing microservices:

  • They had a long release cycle,
  • they were doing coupled releases,
  • with coupled rollbacks,
  • and they had a long defect fix time.

How do you get self-empowered teams to change the whole architecture?

However, there was a realisation that changing things at REA is a bit hard, partly because the teams are very self-empowered, they’re trusted, and they value their independence.

In order to convince teams that trying a new architecture was a good idea, they came up with a vision of where they wanted to go, which included: Continue reading

How to Avoid Making Huge Mistakes with Life’s Big Decisions

The Mistake

A condemned three-story house in DetroitWhen my wife and I had been married for a year, we made a decision to purchase an apartment. It remains, to date, the worst decision we’ve ever made.

To start off with, we probably shouldn’t have purchased anything at all. But there was pressure from parents, the peer pressure of our friends doing the same thing, and the constant fear in Sydney-siders of “getting left behind the market”. Looking back now, I see the bigger factors that we’d been married for one year, we were both very early in our careers, we had very little savings relative to our incomes, and we were living in a friend’s place for low rent. There weren’t really any good reasons to buy.

The big mistake, though, was the place we bought. Continue reading

Notes from YOW! 2014: Troy Hunt on Security: ‘Hack Yourself First’

I attended YOW! Sydney 2014 and thought some people might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Troy Hunt (@troyhunt) spoke about “developers building up cyber-offence skills and proactively seeking out security vulnerabilities in their own websites before an attacker does”. (Slides, Video)

Hackers Are Security Experts

A stereotypical security hacker, using a computer in a dark room while wearing a guy flakes mask and a black hat.He started out with the obvious but perhaps too often forgotten observation: “You can’t defend your app unless you actually understand how the hacker’s technology works.”

He described how hackers only need to “get it right” once. Those developing and deploying the system need to get it right every time. (This is sometimes called the “Fortification Principle”. Apparently DARPA are working on evening out the playing field.)

Know Where Security Applies

He asked: If your company has a Twitter account, who chose the password? The marketing intern, or the Security team? Continue reading