Notes from GOTO Chicago 2017

I have never before attended an industry conference, and GOTO 2017 was a pretty awesome first conference. I tried to jot down some notes on most of the talks I attended. I plan on watching a few more of them online, as I couldn't see all of the talks I was interested in. There were some very hard decisions to make!

Martin Fowler: The Many Meanings of Event-Driven Architecture

Martin talked about a few different patterns he sees in systems described as “event-driven”. When we talk about event-driven systems, if we can figure out which of these patterns we really mean, we will have a more accurate framework in which to discuss the design. Event-driven designs will employ one or more of these patterns.

Event notification

This pattern uses events to reverse dependencies in a system by allowing system A to notify anyone who cares about an update. System B can listen for the event, and act accordingly. This means system B knows about A, but A does not need to know about B. This reverses the traditional dependency of A knowing about B in order to make a call directly to B’s API.

Event Based State Transfer

This builds on top of Event Notification be making the notification contain all the information needed by consumers. This means system B no longer has to make a call directly to A for more information. B is now coupled to the message schema rather than the API of A. This is not a “go to” pattern, but is good in the right circumstance.

Event Sourcing

This pattern entails writing a record of a change first, which will then trigger the system to go and do that thing. With this pattern, we get built in audit logging, and the ability to recreate an application state from the logs. This can be paired with snapshots for optimization.

CQRS (Command Query Responsibility Segregation)

This pattern separates the read mode/API from the write mode/API. This pattern can introduce complexity, but can be powerful in the right situation.

Tim Gross: Software-Defined Culture

http://0x74696d.com

Tim talked about how technology decisions can impact your culture. We should be mindful of this as we make technical decisions. Many of his examples showed how technology choices can drive a wedge between teams and lower morale. For example, platforms are hard to run locally, introduce tight coupling, and prevent the developers from having ownership over their service. This will frustrate developers and hurt moral. If services/applications are self contained, they can own their own lifecycle and be platform independent. This lets the development team have ownership and responsibility for their service, as well as the infrastructure, since it is contained within the service’s code.

Fred George: Managing Managerless Teams

use for fuzzy / complex problems

when management becomes scared of a mistake, waterfall creeps back in.

bring work to the team. don’t break up the team BUT rotate team members to avoid complacency.

Appraisal and coaching is at conflict

You can’t measure individual effectiveness objectively. You can measure the team’s effectiveness, then ask what contributions each team member made.

Mentors should be external to the team, and should not talk with the appraiser

Antipatterns:

status report: always ask how the information will be used

signoffs

Sam Newman: Feature branches in a post github world.

Lightweight branches in git have brought feature branches back en vogue. But they are still inefficient. Co-located teams should commit straight to master. PRs are still useful for external or untrusted contributors.

My Take: if doing trunk-based development, put controls in place to reject integration failures BEFORE accepting the commit to master, or at least revert it after the fact, so that master is always green.

Peter Sbarski: The Future of Serverless

When building serverless systems:

hybrid is OK

micro-service principles still apply (Don’t share databases, etc.) carve the system into virtual microservices.

Peter uses serverless framework and cloudformation

Bryan Cantrill: Debugging Under Fire

This was a very entertaining talk, and I am a bit disappointed that I only jotted down a couple important takeaways:

Human fallibility is more dangerous in semi-automated systems.

Monitoring and alerts are no substitute for understanding how the system works.

Daniel Bryan: The New 7 deadly Sins of Microservices

Lust: using cutting edge tech. Evaluation is a key skill

Gluttony: Communication overload. Delegate communication to side car (service mesh). sometimes events are better. API gateway can become an ESB.

Greed: What’s mine is mine organization. Microservices are about people as much as tech. Beware of cargo culting.

Sloth: getting lazy about non-functional requirements. The last responsible moment for some non-functional requirements is up front. Test NFR in the build pipeline.

Wrath: blowing up when things go bad. define responsibilities. do you really want to build your own platform?

Envy: shared single domain and datastore fallacy. Do context mapping and event storming. choose datastores appropriately

Pride: testing in the world of transience: API simulation

Llewellyn Falco: Mob Programming

Driver is at the keyboard and not allowed to think. Navigator tells driver what to do. First express intent, then location, then details. Rotate every 5 min. At first, there is one navigator, but there will be more as you improve. If everyone in the mob is contributing or learning, then it a good size/makeup. If not, remove people. If the mob is blocked, you need to add to the mob.

There was a practical segment where volunteers from the audience were chosen to mob program fizzbuzz in python. Only one of the volunteers knew python, and one of the volunteers was not a developer. It was pretty awesome to see this in action.

Randy Shoup: Effective Microservices in a data-centric world

4 quadrants of software development:

Organization: small teams: teams aligned to domains. crosss functional

Practices: TDD & CD: tests help you go faster, better code. “Don’t have time to do it right? NO Don’t have time to do it twice” No bug tracker. they are fixed immediately.

Culture: devops

Architecture: microservices

Events are first class construct. “Significant change in state”.

Linda Rising: Meeting Resistance and Moving Forward

We fence with each other using rational arguments. We think that is the way to change people’s minds, but behavioral economics tells us that people do not make rational decisions. Watch out for confirmation bias and the backfire effect (we reject evidence that we are wrong and cling to our beliefs even harder). Here are more useful approaches:

Fear Less

Listen with intent. Have a rational explanation, but not to convince. This is a tool that can be useful, but you can’t stop there.

Personal Touch

Address a genuine user need. You “all” will never do anything. An adoption curve is unavoidable, and is a evolutionary trait. Use the 6 pillars of morality to frame the discussion in terms that align with the values most important to your audience.

Trial Run

Do a trial run. This will almost never be objected to, since it does not require a commitment or admission of rightness/wrongness. However, once someone has tried something, they are much more likely to buy it.

Listen

Sometimes, you can improve someone’s feelings about you if you just listen to them

Movement

Talking a walk together is a physical metaphor for seeing things from the same perspective, as opposed to an adversarial facing each other across a table.

Ask for Help

Ben Franklin Effect. Asking someone for help is an act of humility that ingratiates you to the other person.

Know When To Stop

Is there anything I can say or demonstrate to you to change your mind? If no, time to stop. ALSO ask this question of yourself.