In this week's podcast QCon chair Wesley Reisz talks to Randy Shoup. Shoup is the vice president of engineering at Stitch Fix. Prior to Stitch Fix, he worked for Google as the director of engineering and cloud computing, CTO and co-founder of Shopilly, and chief engineer at Ebay.
Key Takeaways
- Stitch Fix's business is a combination of art and science. Humans are much better with the machines, and the machines are much better with the humans.
- Stitch Fix has 60 engineers, with 80 data scientists and algorithm developers. This ratio of data science to engineering is unique.
- With Ruby-on-Rails on top of Postgres, the company maintains about 30 different applications on the same stack.
- The practice of Test Driven Development makes Continuous Delivery work, and the practice of having the same people build the code as those who operate the code makes both of these things much more powerful.
- Microservices gives feature velocity, the ability for individual teams to move quickly and independently of each other, and independent deployments.
- Microservices solve a scaling problem. They solve an organisational scaling problem, and a technological scaling problem. These are not the problems that you have early on in the startup.
- In the monolithic world, if you're not able to continue to vertically scale the application or the database or whatever your monolith is. And so for scaling reasons alone you might consider breaking it up into what we call microservices.
Subscribe on:
Notes
Data Science and Stitch Fix
- 1m:57s - Stitch Fix re-imagines retail, particularly for clothing. When you sign up, you fill out survey of the kinds of things that you like and you don't like, and we choose what we think you're going to enjoy based on the millions of customers that we have already. And we use a ton of data science in that process.
- 3m:00s - That goes into our algorithms and then our algorithms make personalised recommendations based on all the things we know about our other customers... there's a human element as well: we have 3,200 human stylists that are all around the United States and they choose the five items that go into the box [of clothing].
- 3m:29s - What we like is that this is a combination of art and science. Modern companies combine what machines are really good at, such as chugging through the 60 to 70 questions times the millions of customers, and combining that with the human element of the stylists, figuring out what things go together, what things are trending, what things are appropriate... Humans are much better with the machines, and the machines are much better with the humans.
About the Stitch Fix Team
- 4m:38s - We've made a lot of investment into the data science and algorithmic side [of the business], and the proof is in the resources. On the engineering side, there are about 60 engineers, and there are 80 data scientists and algorithm developers. That ratio of more data science to engineering is unique in the industry.
- 5m:45s - We have 60 people in our engineering group. We're headquartered in San Francisco, but most of our engineers are remote so they're all around the country.
- 6m:00s - We have teams that are directly paired with pieces of the business. We have a team that builds software for the people that buy the clothes, called merchandisers. We have a team that builds software for our warehouses and inventory management. We have a team that builds software for the 3,200 stylists that are making the personalised choices on behalf of our clients. We have teams that build software for customer support. We have a team that builds our website and our mobile app. Our model is to have small, full stack teams that are each responsible directly for a business function.
Stitch Fix's Stack
- 6m:54s - Our stack is primarily Ruby on Rails on top of Postgres, and we're starting to do more back end services in Go. We maintain about 30 different applications all on roughly the same stack that are targeted at particular areas of business function.
- 7m:25s - We didn't build a monolithic application, we built a bunch of individual not-quite-micro applications all on micro services. Mini applications that are responsible for particular areas.
- 7m:50s - Our largest application is the application that our stylists use that help serve personalised recommendations for the stylists and help them to choose the individual items of clothing for a particular clients. In our warehouse we have an application that does returns, a picking application; the idea is to build an application for a particular function and do exactly what you need for that thing and no more.
Microservices and Processes
- 13m:11s - We're very heavily into Test-Driven Development, we practice Continuous Delivery, we practice Dev Ops: and we started this way. There's no argument that it's a lot easier when you start start these practices from the beginning. Everybody who works here has worked at places where we didn't practice those things, and so they learned what that means.
- 13m:55s - These practices work synergistically with each other and they build they build on each other. The practice of Test Driven Development makes the Continuous Delivery work, and the practice of the same people building the code as operating the code makes those both much more powerful.
- 15m:56s - Being able to provision quickly and being able to deploy applications quickly are absolutely prerequisites for being successful in Microservices. You've got to be able to move quickly and deploy quickly in order to get the benefits.
- 16m:39s - What are you looking for out of microservers? You're looking for feature velocity, you're looking for individual teams to move quickly and independently of each other. You're looking for independent deployments... and you're looking for scaling, the ability to scale up the size of the infrastructure, and individual applications and services independently of each other.
Shifting Your Organisation
- 17m:23s - Conway's Law says that the architecture reflects your organisation, in particular that the communication paths within your organisation are going to be directly reflected in your architecture.
- 18m:59s - There are two things that you can do if you're middle level. One is don't assume that your engineering leadership magically knows these concepts.
- 19m:29s - The other thing is, within the scope of the organisation that you control, you can absolutely do this. If you have eight people or 10 people in the area that you're working, for example, rather than having that be one team that works on one thing, subdivide those teams into working on this service or that service of that application. Even if you don't control the entire organisation you can organise the work of the area of the scope that you're working in along these lines.
- 20m:35s - Stitch Fix doesn't have a monolithic application, but we do have a monolithic database. All of the interesting entities that we operate on in Stitch Fix are in one shared database. We are in the process of going through and pulling that apart and creating microservices out of them. Should we have started with microservices in the beginning? No.
- 22m:03s - Microservices solve a scaling problem. They solve an organisational scaling problem, and a technological scaling problem. These are not the problems that you have early on in a startup.
Signs You Need Microservices for Scaling
- 23m:27s - If it's really painful to bring on new engineers and make them productive, or if it's very difficult to make the existing teams productive because they're stepping on each other's toes inside the monolith, that's a warning sign that you need to you need to think about breaking it up.
- 23m:41s - In the monolithic world, if you're not able to continue to vertically scale the application or the database or whatever your monolith is, for scaling reasons alone you might you might consider breaking it up into what we call microservices.
- 24m:03s - The other one that's also common is what is called deployment independence, and that's where you want different parts of your overall system to have different life cycles. In situations where you have radically different life cycles between different parts of your overall system that's another indicator that you might want to consider breaking it into smaller pieces.
People mentioned
Companies mentioned
Languages mentioned
Products mentioned
Processes mentioned
