Richard Rodger

Hi Ty,

The way to solve this problem is to think about microservices as components exchanging messages.

A message to Create/Read/Update/Delete does not have to go directly to the service that talks to the DB. You can write an authentication service to intercept these messages and handle that piece, before forwarding the messages.

I talk a little about these composition patterns here: https://youtu.be/9VC6YeQeZVk?t=19m59s

Instead of adding new features to an existing service, add new services.
(Other questions in this forum deal with the latency implications of that approach)

Thanks Everyone!

Still answering follow-up questions, and a few I missed last week

Richard

Hi German,

Chapter 4 goes into detail on the implication of microservices for transactions. Basically, you can't really do transactions between microservices, unless you want all the fun of distributed transactions.
Better to try to keep transactional stuff inside individual services.

Consider also if you need transactions in the first place. The correctness/complexity/latency trade-off might not make business sense

Hi Brian - actually I sort of answered this question in another thread - I'll post the answer again:

---
Not all microservices face the outside world. In fact, most do not.

Internal microservices talk to each other in much the same way, conceptually, that components inside a monolith talk to each other with function calls. The fact that there is a network in the middle is not a fundamental concern.

Microservices in fact lend themselves to better architectures such as capabilities: https://en.wikipedia.org/wiki/Capability-based_security
---

Hi John,

Not all microservices face the outside world. In fact, most do not.

Internal microservices talk to each other in much the same way, conceptually, that components inside a monolith talk to each other with function calls. The fact that there is a network in the middle is not a fundamental concern.

Microservices in fact lend themselves to better architectures such as capabilities: https://en.wikipedia.org/wiki/Capability-based_security

At the infrastructure level, absolutely, you can add extra facilities such as encryption layers over the network.

Hey Kim,

To answer your important question about papers - No! it's a relatively short book, sorry
(short books are better - only say what you have to once)

Language is not really a factor, as Godfred says, although some language platforms like Js and Go are lighter weight and thus easier to deploy as containers etc.

But consider that Erlang OTP offers what many consider to be a microservice-like platform, so there are many takes on this idea.

Hi Mainak,

Yes I discuss design questions quite a lot in the book. It's not really a coding book (only chapter 9 has code), more of an architecture guide.

Web services can be implemented with microservices certainly, but they are different things. A web service is an API abstraction offered over HTTP - it's implementation should be hidden.
It could be a monolith, or microservices, behind the HTTP interface.

Microservices are not necessarily little web servers either - this is a common implementation, but not essential. For example, you could use a message bus instead to communicate between services.

In the book I introduce the design concept of "transport independence" which makes this explicit - microservices send and receive messages, but how that happens should not concern the service.

Richard

Hi Vijitha,

Microservices do introduce higher latency. The payoff is that you get more flexible development, and can respond to requirements changes more quickly.

In the early stages of a project, latency is not so important, as your focus will be on correct implementation of the business requirements.

Once you reach the later stages, you can assess where the bottlenecks are, and merge services if necessary to avoid network overhead.
This works because, like most things, performance needs are concentrated on a small number of important process pathways, rather than all of them.

Your messaging layer should make this merging possible without changes to business logic code, as the message transport becomes an internal function call.

I discuss this issue in chapter 6.

I only provide “definitions” to tear them down.

It’s like asking for a definition of general relativity. You get fluff. You should maybe put in the time to grok linear algebra and differential calculus if you want to do anything useful.

How does a definition help you? Are you going to suddenly be able to build large scale microservices applications on the back of a sentence or two? I feel we need to acknowledge the complexity and lean into it.

I did give a talk a few years back and took the “100 lines” position - and was rightly embarrassed by intelligent audience questions.

So I wouldn’t seek a rigorous definition, or indeed hold your teams to one. Better to think hard about what is needed, and possible, in your own contexts.

I’ll comment on SOA first. If we do not learn from history then we are condemned to repeat it.

SOA is microservices, but in those days deployment was much harder

Everybody doing microservices should read https://www.manning.com/books/soa-patterns - this is the book! I learned a lot of stuff from it. It’s a heavy and serious reference work that I still use.

Hey David,

So I’m a little radical when it comes to service discovery these days - I like to use SWIM https://asafdav2.github.io/2017/swim-protocol/

The weak point in any component model ( that’s what microservices are!) is identity. Component A has to know about component B to send B messages. A also has to know what messages B can accept.

Example: network location, rest URLs, message bus topics, kubernetes host env vars, ... all the same thing.

To remove the concept of identity, you want to be able to just send messages without knowing where to send them.

This is fundamentally impossible of course, but you can weaken identity significantly by using something like SWIM. Essentially each microservices builds its own internal, but hidden, routing table.

In practice this reduces your configuration work drastically - it’s pretty cool.

Nonetheless, the radical approach above does not invalidate other approaches. I’m a happy user of consul etc in many contexts. For local dev I often used hard coded ports. This has minimal impact on business logic so long as you have a message abstration layer that  hides your message transport choices.

I’ve given a talk on this subject a few times: https://youtu.be/67POODXANi8

Note that if you put this together with message pattern matching and the “general-to-specific” strategy, then versioning issues sort of dissolve away.

I try to explain this more rigorously in the book!

Richard

Hi David,

Is there one service per team, multiple services per team, one service per dev, or multiple services per dev. Who owns a service - a team or a single dev?

In the book I try to analyze the consequences of these configurations. In practice with my teams I’ve always ended up with multiple services owned by a team. To get there, your services need to actually be micro.

I see people using large “macroservices” which maps to a service per team, but you lose most of the benefits with that approach.

Your org and project has a lot of people and moving parts. This is where pattern matching rather than strict schemas  really pay off. It forces all teams to handle multiple versions of other teams messages, so the whole system stays functional. This mindset takes a while to feel natural - you get a lot of push back.

The other thing that you need here is message mocking services - your system is probably way too big to fit on a dev machine!

What message architecture are you using? A bus or http or something else? Also, how do you do service discovery?

Richard

Hi Vijitha - I cover this topic in the book. It is not only technical but also requires navigation of organizational politics.

The solution is to break the old system systems
into “macroservices” where possible so that you can leverage the rapid deployment system that microservices give you.

When this is not possible, you wrap the old systems using proxy services, so that they are abstracted by message flows.

Richard

Hi Everyone!

I'll check-in regularly over the next few days - ask me anything, as they say.

I've just updated the example in https://github.com/rjrodger/wo/tree/master/example to include a kubernetes configuration (since I'm building something with kubernetes at the moment!).

Richard

This is a known JDK bug, see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4766061
for details