Continued from Day 2, here is a summary of talks I attended on Day 3:
From the Monolith to Microservices: Lessons from Google and eBay
By Randy Shoup | Video | Slides
Another eye-opening presentation with valuable insights, such as the fact that [a big organization like Google] doesn’t need architects, it just needs standardized communication and standardized interfaces. And that one of the biggest mistakes people make with microservices is reflecting the provider’s model instead of the consumer’s model. I highly recommend his talk, because it is based on the analysis of several Silicon Valley giants, successful either in the past or the present.
Interaction Driven Design
By Sandro Mancuso | Video | Slides
Sandro’s presentation was full of real examples rather than just theory. I had never heard of the Walking Skeleton before. It was an interesting intersection of DDD (Domain Driven Design), MVC-type architectures and SOLID principles, leading up to a pragmatic way of structuring and packaging software projects. Other advice from Sandro included modeling behavior, not state and not necessarily representing repositories as first-class citizens.
WebSocket for the Real-Time Web and the Internet of Things
By Peter Moskovits | Video | Slides
Not only was it an amazing presentation with live demos, Peter was also fully prepared with a backup plan for everything – including a PDF version of his presentation. After a historical perspective & technical explanation of how WebSockets work, he jumped into Kaazing demos which you can also experience online here. The most interesting was a kind of MVP for disseminating airline telemetry data (here).
Why Is An API Like a Puppy?
By Ade Oshineye | Video | Slides
RESTful APIs are not the solution to all of the world’s problems: Ade was short, succinct and insightful. The title of his talk reflected the fact that an API is an expensive long term commitment, it’s not just about the initial cost of software development. He got a lot of attention when he revealed that Google’s most successful API is AdWords, and it’s SOAP, not REST. Although REST is theoretically good, it doesn’t usually fit well with the real world consumer’s way of thinking. Another one of his gems was that if your [public] API is not being spammed/abused, then either no one is using it, or it’s happening and you’re not aware of it.
Implementing the Saga Pattern
By Caitie McCaffrey | Video | Slides
There wasn’t anything interesting to me during this time slot, so I decided to go with this one just for the Halo reference. There was just one picture of Halo. And a lot of “so” and “like”.
Techniques and Tools For a Coherent Discussion About Performance in Complex Architectures
By Theo Schlossnagle | Video | Slides
Theo decided it would be a good idea to plaster all his slides with huge pictures of steak. Anyway, after establishing that User Experience is measured in milliseconds, and that performance is also about the time spent between service layers, he covered distributed tracing systems such as Dapper and Zipkin.
Great Engineering, Failed Product
By Marty Cagan | Video | Slides
Marty drew on decades of experience in Silicon Valley to summarize why great products and companies fail over and over again. I highly recommend watching his inspiring and insightful talk. Some of the things he touched upon while comparing successful and poorly performing teams:
- Customers and company executives are a bad source of product ideas, because they don’t know what’s technically achievable
- Developers are a good source, and so is Data (analytics, metrics, usage)
- Multi-billion dollar projects are not based on a Business Case accurately predicting future revenue
- Roadmaps are not a good indicator because Customers have other options available to them
- Think Time to Money, not Time to Market – which means more than one iteration is involved
- Product Managers are not mere [user] story writers – they need to have a deep understanding of the business, industry, customers and constraints
- Most teams work in a way that gives them probably 20% of the benefit of Agile Methodologies
- Value outcomes over output; think in terms of results, not projects
- Successful teams run as many as 20 MVP experiments in a week – even if it involves hardware
- Successful companies use an OKR approach to measure progress
- The four product development questions:
- Will the customers choose it? (Customer Validation)
- Will they be able to use it? (User Experience)
- Can we build it? (Feasibility)
- Can our stakeholders support it? (e.g. Legality)