Highlights from ScaleConf New Zealand

Hundreds of tech professionals attended the first-ever ScaleConf New Zealand on 9–10 August, 2016 at the Museum of New Zealand, Te Papa Tongarewa, Wellington. SilverStripers were there to take in all the inspiring and educational talks on web performance and scalability.

Here are some key learnings, highlights and reflections from us.

Michael Strong:

• Measure: Ensure you have the tools and setup to measure the performance of your application through its lifetime and more importantly, between releases.
• Monitor: Ensure you have the tools to monitor for failures or spikes (potential issues) in your application so that you are aware of problems early. These can be resolved quickly and before they affect a larger number of people.
• Invest: Invest time in the first two things at the start of a project and future problems will be easier to diagnose and avoid.
• Have a deploy plan: Iterate quickly and release often to reduce risk of large changes causing major or many issues. Make peer-review a small, easy task. This breeds confidence into the team and stakeholders.
• Communication: Communication between Ops and Dev teams is two-way. Ops should be included early in the process, but the Dev team should also be included afterwards. Ops need to communicate any problems that arise to the Dev teams responsible.
• Ownership: Teams should take ownership for a project.

John Oppler:

• Things move fast. There may be better alternatives to the tools you're most familiar with. Spend the time to investigate alternatives (don't write them off)!
• Make performance testing easy for developers.
• Performance is a feature. Consider early in the development cycle—add to definition of done.
• Utilising parallel testing will help ensure changes to old software are non-destructive—ensuring there is a backup plan.
• There are many excellent tools you can utilise.

Sean Harvey

• Performance as a feature. Measure performance and understand the outliers, report back to the business on the importance of performance. Have performance measurements as part of project team’s "definition of done"
• Treat performance regressions as a build failure, just as unit test failures are. This can be done with automated tools like git-rachet, sitespeed.io, and PSI.
• Metrics. Measure everything, and make it easier for developers to add their own metrics. A great post from Etsy explains this further.
• "DevOps is not about learning each other's job, it's understanding the money is made when software is actually running in production"—Dave Mangot.
• Distributed systems are complex.

Ingo Schommer

• Richard Busby from AWS blew my mind by mentioning that the average amazon.com homepage is generated through 300 micro services calls.
• Paul Stack from Hashicorp finds a great definition for a common buzzword: "DevOps is understanding that money is made when code runs in production".
• AWS Lambda and serverless architectures are becoming viable: You can run a highly scalable centralised logging service with Lambda+Kinesis+ElasticSearch through AWS pay-per-use model for $140USD a month, without maintaining a single server yourself.
• Bethany Macri explained how Etsy redeveloped their API to combine requests for faster frontend loading with team-driven function calls which combine low-level fetches. Facebook is also moving away from pure REST APIs through the powerful GraphQL concept. With an increased focus on APIs, the SilverStripe CMS backend can learn from their approaches going forward.
• Microservices raise some unique challenges: There's an increased need to trace performance of a single HTTP request across multiple service calls and servers (rather than an in-memory execution), e.g. through ZipKin.

Igor Nadj

“The first thing I saw coming into ScaleConf was the big name lineup, and I was expecting to hear these people talk about what it looks like when you’ve made it. Instead, the focus was a candid and refreshingly pragmatic look at how to slowly get there. Talkers spent a lot of time detailing the monoliths and spaghetti-systems they started with and the practical steps of getting away from that and moving towards something more manageable. Every talk felt really accessible and human, and it was refreshing to see other people having the same problems we have.

Apart from legacy systems, the other big focus was on metrics. A common theme throughout was that you need to measure everything. First, in terms of things you want improved e.g. application performance, you first need to prove that there is a problem. You need metrics and hard numbers to prove business value, and even then you need to present it in an easily digestible way. Secondly, to understand your users: if it’s not measured, it’s not important: “If a customer can have a bad experience, the metrics have to show it”. And finally, metrics can be very useful as part of your continuous delivery pipeline. A lot more than you think can be codified. You can, for example, have a build fail automatically if it increases page load times over a limit.

Value for time—this was a good one. It left me looking optimistically towards the future and the dream of a beautiful continuous delivery pipeline. We have a long way to go, but ScaleConf gave me practical tools to begin on our journey.”

The conference was concluded with a raffle run on Minecraft that was developed by Chris Pitt, which left everyone at awe. On the whole, it was a well run and inspirational full-on event that was worth every minute of it.