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

How to Choose Your First Microservices

Are you early in your microservices journey? Maybe you’ve decided you need to start deploying applications outside your monolith but you haven’t cut any code yet. Or maybe you’ve put your first few services into production and addressed some of the first pains that happen when you start on that path.

A large number of interacting LEGO cogs making one large machine, similar to a monolith from which you want to break out your first microservices

A common question that comes up for teams at around this time is:

“What should we split out into a microservice first?

And why?”

Continue reading

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

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

(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

Murphy’s Law Should Appear In Every Line Of Your Code

A graphic from a 1930s German pamphlet showing a woman being electrocuted because she touched an overhead lamp and a gas pipe at the same time. Murphy's Law aims to stop these kinds of catastrophes.You know Murphy’s Law, right? Or at least you know the way most people remember it: “Anything that can go wrong will go wrong.” It’s a fairly depressing way of summarising life, but we all recognise a large portion of truth within it. Things go wrong. All the time.

There’s actually contention over whether this is the original form of the law, which is named after aerospace engineer Capt. Edward A. Murphy, and there are several differing accounts of how the saying came about. My preferred account is that relayed by Australia’s Dr Karl Kruszelnicki, whose record of Captain Murphy’s original exclamation is:

If there are two or more ways to do something, and one of those results in a catastrophe, then someone will do it that way.

I like this version because it’s easier to see the qualified optimism that Murphy juxtaposed with his frustration. As Dr Karl explains, there is a hope embedded in this form of the law because it starts with a proposition: “IF there are two or more ways to do something…” Continue reading