Microservices: The Benefits and Costs

'Mycenaean Bronze Scales' - a set of ancient, bronze scales. Any tech team should weigh microservices benefits against their costs before deciding whether to make the switch. Photographed by Mark Cartwright.

If you work in tech, you’ve almost definitely heard about microservices: the trendy style of software architecture where a system is split into multiple, independently-releasable services, that are modelled around business domains, and communicate via a network. Some people rave about all the amazing things they’ve achieved by using microservices’ benefits. Others rant about how much of their time it wastes and how much they hate it.

Like pretty much everything in tech, microservice architecture is a trade-off. Will it do great things for your organisation or not? That depends largely on how well set up you are to take advantage of the benefits and to absorb the costs.

Microservice Architecture is a trade-off. Whether it's going to do great things for your organisation depends on how well set up you are to take advantage of the benefits and absorb the costs. Read more: Microservices: The Benefits and Costs Click To Tweet

If you’re looking to make a decision about whether to use microservices in your team (or reverse one!), here’s a list of many of the pros and cons which you’ll want to consider.

Continue reading

“This work kinda sucks right now”: Staying motivated in the uninspiring phases of long projects

In April 2015, I was the technical project manager of six software teams all working on one gigantic project. It was the biggest challenge the company had ever taken on. The goal: create and stand up a transaction account product for small and medium business so that we could apply for an unrestricted bank license.

Tired marathon runner with hands on hips

We were 12 months in and were about to finish the project bang on the week we’d estimated, when the inevitable happened: we received a new raft of requirements that would add at least another 3 months of work. The extra work wasn’t glamorous; it was mostly security enhancements, disaster recovery preparation, and a complicated behind-the-scenes tweak of the product that added little benefit for users but was a requirement from a regulatory point of view.

Understandably, morale took a hit, but we needed to keep the pace up or we’d risk missing the deadline we’d been set for acquiring our license. After an interesting discussion with my father-in-law about the project, I found a new perspective on where we were at, and it prompted me to write the internal blog below to help motivate the team towards our final goal. 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

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

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

Notes from YOW! 2014: Mary Poppendieck on ‘The (Agile) Scaling Dilemma’

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.

Lots of empty seats at a stadium. Can Agile scale to this kind of crowd?Mary Poppendieck (@mpoppendieck) spoke about scaling agile teams. (Slides)

She started by saying:

“There’s a big assumption that if agile is good, scaling agile must be good.”

Which made my jaw drop. I make that assumption. It had never occurred to me. Maybe agile techniques don’t work in a larger organisation?

She talked about four constraints on scaling: system complexity, organisational mindset, multi-team communication, and the time and energy of bright creative people. Continue reading

Notes from YOW! 2014: Jeff Patton on ‘User Story Mapping: Discover the Whole Story’

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.

Jeff Patton (@jeffpatton) was billed to present a “fast paced workshop [where] you’ll learn the concepts of story mapping by building a map collaboratively with others”. He shared lots of great insights about stories but (I felt) really only touched on Story Mapping briefly near the end of the time. Still, I collected some good notes about stories that made me re-think a few things…

He started by showing this great list of wrong things he used to think about stories. Stupid stuff Jeff Patton used to belive about Agile stories Continue reading

Notes from YOW! 2013: Michael T. Nygard on ‘Five Years of DevOps: Where are we Now?’

I attended Day 1 of YOW! Sydney 2013 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.

Small child in a field looking into the distance with binoculars, as someone surveying the current state of DevOps probably wouldn't do.Michael T. Nygard (@mtnygard) is probably best known as the author of the 2007 book ‘Release It!‘, which teaches developers how to look beyond just getting their code working and instead design it from the outset to handle the harsh conditions of production environments. He has since become a DevOps luminary and now works at Cognitect. He spoke at YOW! 2013 about ‘Five Years of DevOps: Where are we Now?’.

Michael started off setting the timeline by pointing out that Chef and Puppet were preceded by CFEngine in about 1993!

He explained how his own experience has contributed to his DevOps insight: he worked as a Dev in Ops for some time, showing the Ops team how to solve some of their problems with Dev-like approaches, but also finding lots of problems with the way Devs created software, which was the chief inspiration for his book. Continue reading

Notes from YOW! 2013: Jeff Paton on ‘Safety Not Guaranteed: How Successful (Agile) Teams Ignore the Rules to Create Successful Products’

I attended Day 1 of YOW! Sydney 2013 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.

Two people dressed as crash test dummies with their thumbs up. Does following Agile processes to the letter mean your team will be safe and succeed?Jeff Paton (@jeffpaton) is an independent consultant, teacher and Agile coach, and (I believe someone said) the inventor of Story Mapping. He spoke at YOW! about ‘Safety Not Guaranteed: How Successful Teams Ignore the Rules to Create Successful Products’.

Jeff started his talk by announcing that he hated agile development since the moment he first heard of it, but went on to explain that he doesn’t really hate agile now and that an important part of this has been to learn to pay a lot of attention to what he’s doing. Continue reading