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 Share on X

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

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: 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! 2013: Hadi Hariri on ‘Refactoring Legacy Codebases’

I attended Day 1 of YOW! Sydney 2013 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 stack of stickers showing the word 'refactor' in a stylised, death-metal-like font.Hadi Hariri is a Developer and Technical Evangelist at JetBrains. He spoke at YOW! about refactoring legacy codebases.

Hadi started by offering reasons for refactoring:

  • increase the understandability of the code
  • decrease the impact of change
  • reduce the cost of change

He described how refactoring relies on culture: Continue reading