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

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

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

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

Two REST tips for tackling tricky resource examples

After my post a couple of days ago about the first thing you should know about REST, a friend emailed me with this feedback:

Nice post. It was something I was thinking about just recently and I think I’m guilty of making these mistakes. The example which confused me was verifying a password. I wasn’t sure what HTTP method to use or what the resource was. The request needs to contain a password but doesn’t expect any response other than a 200, does this mean GET is inappropriate?  It doesn’t update anything, unless of course it fails in which case it may update a failed login counter or lock the account. Does this rule out PUT and POST?

Young man in a very uncomfortable hammock, trying hard to pretend to have a REST.Here’s the response I sent him (fleshed out with a little more detail for this blog)…

REST can be easy and REST can be hard

Yep, the examples in my blog were the easy ones. Plenty of hard ones will crop up, where the resource on the server you want to manipulate is not immediately obvious, like the one you’ve pointed out, or where coming up with a good set of URL patterns is not straightforward. As with all things that aren’t easy, spending some extra time on it is usually worth the effort.

Think like a REST Server

I think what can help is to try and think less about what the client is doing (“verifying a password”) and more about what’s happening on the server side. Continue reading

Do you even know the first thing about REST?

A sign saying 'REST AREA', with an arrow pointing up and to the right.It’s not unusual to see examples where people think they are “doing REST”, but are not. A lot of people are trying to use simple web technologies in their microservice architectures, but I suspect there’s a prevalent idea that if you are using HTTP and sending JSON back and forth, you’re doing REST, which is simply not the case. (We’re talking about the Representational State Transfer style of software architecture here, in case you’re lost.)

Spring’s REST

Spring’s Web MVC Framework documentation says in the first paragraph: “With the introduction of Spring 3.0, the @Controller mechanism also allows you to create RESTful Web sites and applications…” Further on, introducing its @RestController interface, it says: “It’s a very common use case to have Controllers implement a REST API, thus serving only JSON, XML or custom MediaType content.” So, does creating a web service using a @RestController-annotated class magically make it a RESTful service?
No. Such no.

Not so REST

The big thing I see developers getting wrong when trying to use web technologies for inter-service communication is that they continue to think about operations. Continue reading

Notes from YOW! 2014: Martin Thompson and Todd L. Montgomery on ‘How Did We End Up Here?’

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.

Cows standing in front of a burning barn.Martin Thompson (@mjpt777) and Todd L. Montgomery (@toddlmontgomery) discussed the state of the software industry at YOW! 2014, including “barbequing” a whole herd of sacred cows. (Slides)

A Dr Dobbs 2010 report into IT project success showed a correlation between higher numbers of people on a project and higher rates of failure. Even the best performing methodologies still have >10% failure. Continue reading

Notes from Microservices Talk by Zhamak Dehghani

People have started using honeycombs and hex shapes to depict microservices architectures. Who knows why?A couple of weeks ago, I went along with a couple of other Tyro software engineers to hear Zhamak Dehghani speak about microservices at a “YOW Nights” event, hosted by Optivar and sponsored by ThoughtWorks. It was so good that we asked Zhamak if she’d come into the Tyro office and give a re-run for the whole Engineering team and she kindly obliged. What a legend! Thanks again Zhamak!

I’d already read a lot about microservices (MS), mostly thanks to the excellent pages of links put together by Adrian Rossouw and Matt Stine. Zhamak covered a lot of ground that I was already familiar with, but she also touched on many things that were new and interesting to me, so I thought I would write about a few here. Continue reading