Raw notes from Randy Shoup.

VP of engineering at Stitch Fix. Did consulting in a "CTO as a service", before that was Director of Engineering at Google and chief engineer at eBay.

About Stitch Fix. Reverse of standard retail. Fill out style profile, get five handpicked items, keep what you like, return the rest.

Behind the model is a lot of Art and Data Science.

1:1 Ratio of engineering and data scientists

Apply intelligence to every part of the business

Buying, inventory management, logistics, styling, demand prediction

What is styling: personalized recommendations based on algorithmic recommendations with a human curation layer.

Modern software dev: org, practices, culture,

small teams, devops

Small teams: aligned to domains, cross functional, depend on other teams for help as well.

practices: TDD. Motherhood and apple pie. Continuous delivery: most applications deployed multiple times per day. Release smaller units of work, easier to roll back and role forward. Better for AB testing.

Culture: The amazon model: you build it, you run it.

Microservices

Architecture Evolution

eBay: Monolithic Perl, Monolitic C++, Java, Microservices.

Twitter and Amazon had a similar evolution. It's ok to start out as a monolith.

The micro of microservice is: single purpose, simple well defined interface, isolated persistence (each one keeps its own state). It's SOA done right.

Approach 1: operate your own data store. Store to your own Postgres, ie.

Approach 2: Use a persistence service and store to your own tables, operated as a service on your behalf. Slice is isolated.

Maintaining interface stability

backward/forward compatibility of interfaces. Can never break your client's code. Semantic versioning. major.minor.patch

Often maintaining multiple deployments and interface versions. Need an explicit deprecation policy.

Went through procress from extracting services from the shared DB.

Principle: single system of record. There can be copies of that.

Approach 2: Async event+local cache. Customer service sends events. Order service listens to events.

Approach 3: Shared metadata library. Read only metadata, basically immutable.

Events as first class construct. This was from Martin's talk. Event means: statement that something interesting has happened.

Fourth fundamental building block. Presentation, Application, Persistence, Events

Events and Microservices go well together.

Service interface includes: Synchronous request response. Events the service produces/consumes.

Joins: monolithic databases make joins very easily. How to split it out?

Approach 1: Service that materializes the view. Service that materializes the view.

Approach 2: Join in the client.

Note that mashup style web apps do this.

Microservice Techniques: Workflows and Sagas

Problem: Monolithic apps make this trivially easy. Splitting data across services is hard. So, transactions turn into Sagas: Model the transaction as a series of steps coordinated by events. It's like a workflow. Rolllback by applying compensating operations. Many common systems already do this. For example payment processing and approval workflows (expense reports).

Ideal use for functions as a service. Very lightweight logic, stateless, triggered by an event. Healthy companies in the future will be doing some or all of this.