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.

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

• DDD
• REST
• Automation
• Cloud
• DevOps
• Logging (aggregation and centralised architecture)
• Monitoring
• Resilience
• Testing with consumer-driven contracts (also check out Pact)
• Conway’s Law
• Postel’s Law

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

Microservices Speedbump #1: Data aggregation

Use the single datastore principal. Services should not reach into each other and access their data.

Bad pattern: You may note a service starts growing bigger and bigger, eating other services as it grows to accommodate functions that need aggregation for some feature.

Bad pattern: You may build a service that talks to many, many other services in order to aggregate data.

Scott has seen projects that have tried replicating to read-only databases, and tried reading from REST when needed.

Solution: Events. The aggregating service should receive event notifications about changes in all the data it cares about.

“If architecture is the thing you want to get right from the start of your project, you should be modelling the business domain as the sequence of events that occur.”

He ran through some options for implementing event notifications:

Option 1:
Chuck them in the DB. However, relational databases aren’t designed for having these ever-appending tables.

Option 2:
“Hipster batch”: Write events as data to some shared data store, e.g. S3.

Option 3:
Special purpose event stores. e.g. GetEventStore.com

Advantages: You don’t have to write the feed logic yourself and they can create projections that publish new specialised feeds for consumers to subscribe to.

Concerns: It’s just a different flavour of a centralised data store. Projections store business logic in the server.

Microservices Speedbump #2: Access Control & Security

Traditional access control for internet-facing systems has been to secure at the border (e.g. web server) and give that border service full access to the services in the backend. With microservices this is typically unacceptable (because the responsible thing to do is build defence in depth), and you’re going to want to be doing delegated access management. (I call this “Deep Auth”, deliberately using “auth” because it ambiguously includes both authentication & authorisation.)

Scott listed a bunch of options for implementing this:

• Two-way TLS
• OAuth 2.0
• OpenID Connect
• JSON Web Tokens (JWT)
• SAML v2
• HMAC Signing
• NTLM/WIF/ADFS

He added the requirement that Microservices should be stateless, which means no sessions. You should pass the auth details each time instead of using a cookie/session.

He also stated that, once you get past the border services, there’s a difference between authenticating as a user and authenticating on behalf of a user.

When reviewing authN/authZ options, you should ask:

• Have you considered both authentication and authorisation?
  • (Rules out OAuth (AuthZ only), 2-way SSL/TLS, HMAC signing)
• Are you basing it on open standards?
  • (Rules our NTLM (Microsoft), JWT (open, but not a standard))
• Simple enough to be widely used?
• Supports modern web integration strategy?
  • (Rules out SAML)
• Does it have proven implementations?
  • (Rules out OpenID Connect (too new))

Asking these questions of all the recommended technologies ends up ruling them all out! Scott’s conclusion: There is currently no perfect solution! He says OpenID Connect looks pretty promising, though.

P.S. None of this works without PKI! You either need to share secrets or share keys.
You also need CSRF protection, nonce and correct implementations! (c.f. Heartbleed)

Microservices Speedbump #3: Managing Change

If you have services talking to each other (i.e. in a circular dependency), consider whether there is a missing business domain concept that should change the way this information flows: should both those dependant services instead be talking to a third service?

Which led on to: how would you fix that? He’s suggesting migrating logic out of a number of services and into a new one. Refactoring inside a single code base is easy these days, while refactoring across service boundaries is hard. Scott table a few approaches to managing architecture change:

1. Don’t do it – live with the chaos of the distributed logic rather than the chaos of not knowing who’s responsible for maintaining the shared service.
2. One big version change – version all your services, test them together and release them together. However, Scott said *You should not have to version your services.* (Conflicting with Cameron Barrie’s advice in the Mobile at Warp Speed session: “You need the flexibility to change your APIs, and you can’t do that without versioning.”)
3. Build a temporary team (due to concern about conway’s law) to build the third service. Make sure you make the long-term ownership of the service clear after the temp team has disbanded. “Long-term ownership can’t be ambiguous.”

Microservices Speedbump Wrap-Up

In summarising, Scott said you need to shift your mindset in three ways to get over these microservices speedbumps:

• Shift from from state to events
• Shift from securing the perimeter to securing endpoints
• Shift from punctuated equilibrium (releasing versions together) to continuous evolution

Want to learn more?

 Image credit: ‘Speed Bump Ahead‘ by veggiefrog (flickr)