Thread by @PaulDJohnston

Watching a talk on event drive architectures at #qconlondon #qcon. Interested simply to find out exactly how much #serverless simplifies everything.

Talking about Dash Buttons and how to work with them. Talking about decoupling services when a button is pressed. I think it's going to go down the road of explaining an event driven approach...

It's interesting to note that the speaker is talking about "services" that are created... in my mind, most of these things are incredibly simple Lambda functions.

"Events can decrease coupling"

Yes - this is true!

Complex event flows and notifications... he makes the point about it's very easy to "lose sight of what is going on".

This gives the speaker a "weird feeling"

I find this a lot. People want to "know what their system looks like" all the time. This I find bizarre. That's why I write about Data Flows and Data Lakes, and therefore monitoring and observability being important medium.com/@PaulDJohnston…

The speaker is now talking about the "call stack" which is, again, "technical" details that a code would consider. It's not a distributed system solution.

This comes back to one of my points that I keep going to: We don't have the tools for this new world yet

Customers are apparently putting all events into ElasticSearch and then building visualisations on top of that to see what's going on. Interesting...

Process Mining is another option... focussing on log flow analysers. These are not very "developer friendly". Which is interesting again. It's all about the "developer" again. I think he is still thinking about this as a "coder".

He's now talking about changing the "flow". I'm going to get quite intrigued as to how he goes about this.

He's talking about "changing 3 services". I'm looking at this and going "that's changing 3 lambda functions".

I can't get over the fact that the speaker is not seeing the problem of complexity in the "services" as being the problem.

Loving the tech "choreography" metaphor. Most companies think they're getting "Ballet", but they're actually getting a "mosh pit".

He's added another microservice into his system... and I'm simply looking at it and wondering "why?".

Note: I'm not hating on his system. I'm looking at it and simply seeing the unnecessary complexity.

The fact is that a service, at it's very essence, is (usually) an API with a contract. It's not code and a database with autoscaling. What is behind that API is irrelevant.

btw the speaker's "avoid peer-to-peer event chains" is analagous to my "functions don't call other functions" mantra for FaaS (if I've understood it correctly)

Interesting. Bad API design leads to "god services". It's attributed to @samnewman and I have to agree. Although I think partly mitigated partly by using FaaS and #serverless techniques.

Interestingly, the large proportion of the service interactions are "request-response" in this talk. I would suggest that the best #serverless solutions are mostly unidirectional. So there are some advantages in the #serverless approach.

I can definitely see some problems in the "reference architectures" that are being suggested in this talk that wouldn't happen otherwise.

... ok now he's mentioning state! Let's see where this goes!

Really interesting. The discussion of considerations such as scheduling, visibility, scalability... things that are already available in serverless such as CloudWatch Events, Step Functions...

Ugh! Now he's mentioning "Low-code" as a thing.

AND EVERYBODY IS TAKING A PHOTO!

This is called "confirmation bias" people.

And now he's taking aim at Step Functions, CNCF Workflow engines, etc

But "of course there are Open Source Workflow Engines"

No discussion of the trade offs of why you should or shouldn't use Open Source.

But he runs a workflow engine company so...

(Yes I am suggesting that he's showing a bias. He's allowed to. But I'm also suggesting that the listeners are showing their bias too)

Moving onto Distributed Systems... with a picture of a lighthouse?

Interestingly, he's now talking about long running tasks... and bigger services...

These are solved problems within event driven architectures, and especially within #serverless systems using exponential backoff.

This is what gets me about #serverless. We've got all these tools, such as retry, which is built in to Lambda if you know what you're doing, and people are still talking about "services" and "long running processes" within the context of "event driven architectures"... why?

For many, this talk will be great, and a lot of new information.

For a #serverless person, they will be sitting there going "why would you do it like that?"

It's a completely different way of thinking

He's definitely talking about making better microservices... but it's a little confusing as he's talking about appreciating monoliths.

Ah. ACID transactions are coming up. Bigger systems at scale really can't handle ACID apparently (according to a paper from Pat Helland).

He's constantly using the word "microservice" or "service"

I know it's a word that means something, but it's constantly used and I'm not sure it's meaning the same thing at every point.

I'm confused.

Oh. That event driven system is relatively easy in a #serverless solution with AWS Lambda. I built one like that in 2016.

Part of the problem I have is that the community that talks about "Microservices" thinks that they don't need to listen to the #serverless community.

They should be listening, and carefully. We're trying to learn from them.

Interesting. Now he's talking about an "event bus". Why not having multiple event buses?

The problem with not using cloud vendor services and building your own is that using multiple services is complex.

You build for "one" because "one" is manageable.

BIG REALISATION:

"Event driven" becomes a LOT easier when you can utilise multiple different queues and buses that you don't have to manage.

If you don't realise this, then you will think #serverless is a joke

The speaker is a really good speaker, and has a lot of good stuff I'm sure.

He's not for me of course but for a lot of things I'm sure he has a lot of value for some companies.

Honestly I enjoyed this talk for lots of reasons. I think a lot of people would do well to listen to this and take on board these points. For incremental changes in a microservices env, this is a definite improvement.