Tag Archives: tips

Using Microservices to Solve Slow Build Times

Posted on by
1

This article on slow build times is part of a series on How to Choose Your First Microservices.

Switching to a new software architecture style is costly. I advocate choosing where to employ microservices first by using them to solve existing problems in the team. This helps the organisation extract value from the new architecture with each step towards the new world. This series is working through a set of problems that your org may have, and how microservices might help solve them.

Slow Build Times?

A snail crossing a road, which might happen faster your slow build time.

Does your team have an application that takes a long time to build and run tests? Is a large portion of the development team working on it? That could be a huge amount of idle time you’re pouring down the drain. The classic XKCD ‘Compiling’ comic makes light of developers enjoying the time they spend waiting for their code to build. The truth for most devs is they would far prefer to be making fast progress on their work than sitting around waiting.

Continue reading →

How to Choose Your First Microservices

Posted on by
1

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 →

Feature Flags and Test-Driven Design: Some Practical Tips

Posted on by
Reply

A country road with a fork going off to one side, symbolic of a feature flag in codeIn 2018, our team spent a lot of time working with feature flags and test-driven design (TDD).

Our project was to effect an architectural change to our system, changing the source of truth of some data, moving it out of the database owned by a legacy monolith into a new database controlled by a new microservice. However, much of the code requiring the data would remain in the monolith.*

Some examples of the types of things we feature-flagged are:

    • whether to go down a refactored code path or not;
    • whether to publish messages to a message queue when a certain event occurred;
    • how to publish those messages (we tried multiple variations of batching and transaction boundaries to achieve acceptable performance);
    • whether to just delete messages at the receiving end or actually handle them; and
    • whether to use a local source of data or remote one.

We were working on a pretty important piece of code; the kind of business function where, if we stuffed it up, someone would probably have to spend several days doing remedial fixups or making phone calls to chase up millions of dollars. Continue reading →

Why Your Resume Sucks & How to Fix It

Posted on by
1

Shredded paper in a waste bin - where the majority of resumes end up!I’ve seen a lot of software engineers’ resumes over the past few years. And most of them suck. Even the resumes of really good people who we’ve hired have often been very average.

Why is that? I’m going to tell you why, and then I’m going to help you avoid the same mistake. And while my experience is mainly in hiring for IT-related roles, this advice can be used by any job seeker. Continue reading →

Microservices Security: All The Questions You Should Be Asking

Posted on by
11

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 →

Microservices at Tyro: An Evolutionary Tale (Presentation)

Posted on by
9

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’

Posted on by
2

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’

Posted on by
1

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 →

Notes from YOW! 2014: Mary Poppendieck on ‘The (Agile) Scaling Dilemma’

Posted on by
Reply

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.

Lots of empty seats at a stadium. Can Agile scale to this kind of crowd?Mary Poppendieck (@mpoppendieck) spoke about scaling agile teams. (Slides)

She started by saying:

“There’s a big assumption that if agile is good, scaling agile must be good.”

Which made my jaw drop. I make that assumption. It had never occurred to me. Maybe agile techniques don’t work in a larger organisation?

She talked about four constraints on scaling: system complexity, organisational mindset, multi-team communication, and the time and energy of bright creative people. Continue reading →

Two REST tips for tackling tricky resource examples

Posted on by
1

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 →