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

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

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