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

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)

(My notes from) Ken Scambler on ‘Two Years of Real-World FP at REA’

This evening I went to a YOW Night where Ken Scambler (@KenScambler) spoke about the introduction and evolution of using Scala at REA Group. Here’s my notes…

Functional Scala Benefits

The sprial logo of the functional programming language language ScalaThe benefits of going functional are to get to code that is: Modular, Abstract, Composable.

Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.

To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.

Abstraction should reduce changes to code, because unnecessary detail is not all across the code.

Whole systems can be composed from functional components.

Functional programming is not about picking up a hipster language. It’s about producing better software.
Continue reading

What would a Microservices PaaS Design Look Like?

Is this a Microservice PaaS?

A beekeeper looking at a frame of honeycomb from a hive. This blog looks at how a Microservices PaaS Design might be framed.Last week I wrote about PaaS and Microservices, asking, “Is a Microservices PaaS in our future?” Since then, I’ve had a number of URLs thrown at me along with the question, “Is this what you mean?”

Probably the closest in intent, based in the way they’re marketing themselves, are Giant Swarm. These guys are certainly putting themselves out there as “Simple Microservice Infrastructure”, and I think they’ve made some ground on implementing such a thing by including service discovery as part of their platform.

Does Docker == Microservices Paas Design?

However, my impression from their docs, as I explained in a comment on said previous blog, is that so far they’ve really only built a “Docker-based PaaS”, and are leaving most of the work of building a MSA, in terms of both choosing and configuring technologies, up to the developers of the system. To quote myself again: “in terms of setting me up with an architecture, it stops at ‘You’ve got Docker!'” (I didn’t realise it had service discovery when I wrote this.)

One of the Giant Swarm developers, Timo Derstappen, joined in the conversation. Continue reading

Is a Microservices PaaS In Our Future?

Last month at the Sydney Microservices Meetup, the Meetup’s organiser, Yamen Sader, presented a great talk on “A Microservices Reference Architecture“.

My own talk on the night, which was a case study about the evolution of microservices at Tyro Payments, laid out many examples of practices and tools we’ve used, but left it for people to either follow or ignore what we’ve done as they feel led. Yamen’s talk, on the other hand, was deliberately prescriptive, describing by the end what he obviously considers to be a widely-applicable framework – a “microservice platform in a box”, if you will. (He also ranked the importance of his suggestions based on a hilarious scale of Seinfeld characters, so he could recommended some ideas more strongly than others.)

Is a Microservices PaaS In Our Future?

A trendy, blue-lit data centre, the kind of place where it would be cool to run a Microservices PaaSYamen’s talk, as well as being really interesting, left me wondering about the future of microservices development. In particular, it had me wondering whether, at some point in the near future, we’ll see a Microservices Platform as a Service, or MSA-PaaS. I’m now thinking… Continue reading

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

Notes from YOW! 2014: Scott Shaw on ‘Avoiding Speedbumps on the Road to Microservices’

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.

A "Speed Bump Ahead" sign, akin to Scott Shaw's warnings in his microservices talkScott Shaw (@scottwshaw), Head of Technology at Thoughtworks, spoke about “three of the biggest issues that microservice teams encounter”. (Slides)

Scott began by listing the following as “Basics”:

He said, “If you don’t know about these things you should at least google them before you start doing micro services.”

The speed bumps he talked about were:

  • Data aggregation
  • Access Control & Security
  • Managing Change

Continue reading

Notes from YOW! 2014: Cameron Barrie on ‘Mobile at Warp Speed’

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.

A bright photo taken using a slow exposure in a train tunnel, giving the impression of moving at warp speed, such as in the topic of Cameron Barrie's Mobile talk.Cameron Barrie (@whalec), Managing Director and Principle Mobile Consultant at Bilue, spoke on “how to apply solid engineering practices to your mobile applications by understanding common mistakes made, and how to mitigate against the risks.” (Slides)

Mobile: Move Fast

He said it’s crucial to be able to move fast. If you’re not disrupting, you’re probably being disrupted.

You need to be honest about what moving fast means for your organisation: you can’t start with crappy code and processes and just start moving fast. Continue reading