Distributed Transactions: The Icebergs of Microservices

An antarctic iceberg which, much like distributed transactions in microservices, can be hard to see and can wreck your ship.Why are distributed transactions icebergs? It’s not because they’re cool and beautiful and you have to look under the surface to comprehend them.

Distributed transactions are icebergs because (1) it’s easy to not see them, even when they’re right in front of you, and (2) if you run into one, it’s got a great potential to sink your ship. Continue reading

Why “Don’t Use Shared Libraries in Microservices” is Bad Advice

A man licking an ice cream while a dog tries to lick it as well. Reminiscent of the kind of undesirable coupling created by shared libraries in microservices

Sharing isn’t always a good idea.

If you’ve read a bit about microservices, you’ll probably have come across the mantra, “Don’t use shared libraries in microservices.” This is bad advice.

While the sentiment is borne from real issues and there’s real wisdom to be gained in this area, this little statement is too pithy, lacking the relevant context to make it useful. Consequently, it’s open to misinterpretation, in particular to being applied too liberally, and I’ve seen it misunderstood a number of times recently.

What’s the Context for Understanding Shared Libraries in Microservices?

Only recently, I’ve picked up that different people mean different things when they talk about using shared libraries. Continue reading

My Key Takeaways from APIdays Australia 2016

On March 1 & 2, 2016, I attended APIdays Australia in Melbourne. (Actually, I also spoke! I’ll write more about that later.) I’m a chronic note-taker at conferences and I like writing my notes up afterwards both for my own reflection and so I can share them with others. Here are the key platform and API takeaways I’ve pulled out of my notes from #APIdaysAU16.

Innovation

APIdays Australia 2016 welcome poster: "API days - Platforms for Innovation"Innovation has been established as the main driver of economic change.

If people have to fill out an application to innovate, it’s not going to happen.

An innovation model for organisations based on the way ants achieve the colony’s goals:

  1. Powerful central mission with loose structure
  2. Maximise learning and sharing of learning
  3. Constant experimentation
  4. Freedom to look for the next horizon

Elon Musk: “Failure must be an option. If you’re not failing, you’re not experimenting enough.”

People in your organisation who think differently to others may well be key innovators. Don’t shut them out of the organisation.

Building Platforms

“Platform” is chiefly an idea to expose the core of your business in a way that can be used to compose new business ideas more easily, either by your own business or by others.
Continue reading

Are You Being Too Agile?

Man lying under a tree daydreaming about the future. Proabably not what you'd call "too agile"Confession of a Chronic Futurist

I have a confession to make. I used to be a dreamer at work. Worse than that, I used to invest significantly into putting my dreams into motion.

What did that look like? It meant that when I was tasked with building a Model-2 presentation framework for the company I was working for, I bunkered down for over a month and came out with this massive framework that was going to be a solution to the whole world’s problems. It was basically most of what Struts did and some parts of what Spring does, before either of them existed. There were good things in there, and the company used the framework for many years, but I’m sure more than half the code I wrote never got used. I’d latched onto a good idea and run a marathon, but the team really only needed me to walk a mile.

Pragmatic Redemption

Then came the revelation of my software engineering life: agile. 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

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: 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

Notes from YOW! 2014: Ed Kmett on ’Stop Treading Water: Learning to Learn’

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.

Ed Kmett (@kmett) started by asking: “What is the cost of using the wrong solutions, integrated over your entire career?” (Slides, Video)

Then he revealed that the topic he’d chosen for the talk was…

“How to be a genius”.

Portrait of genius physicist Richard FeynmanHe talked about a strategy for solving big problems described by famous theoretical physicist Richard Feynman (pictured):

  1. Keep a bunch of your favourite problems in your head.
  2. Every time you hear a new idea -> test it against one of your problems to see if it helps.
  3. If it does, tell people about the breakthrough, and they’ll think you’re a genius.

Note that, in Feynman’s approach, genius is attributed not necessarily to those that come up with new ideas, but often to those who figure out where to apply them.

Developers and Researchers

He noted that developers are in the business of solving problems, searching for solutions, while researchers often have solutions, but are searching for the right problems to apply them to. As a developer, it can be good to keep abreast of what researchers are discovering in hope of finding a solution to one of your favourite problems.

Memory Retention

He discussed human memory retention and the need to revisit topics over time to retain knowledge about them. The brain remembers far better information that is used or revised repeatedly. Knowing this, you can hack the brain by intentionally repeating material that you want to remember. (For example, after going to a conference, you could write a blog about the important points from each talk you went to.)

He chatted a little bit about jargon, saying that if you’re going to use jargon, you should always be willing to explain what it means.

Image credit: Richard Phillips Feynman (1918 – 1988) (unknown)