Six Questions for Yan Cui, instructor of Production-Ready Serverless

By Frances Lefkowitz, Development Editor, Manning Publications

Bio: Yan Cui has worked with AWS for almost a decade, and has contributed his knowledge of production AWS Lamda to the Well-Architected whitepaper published by AWS. Based in London, he travels all over the world giving talks and workshops on serverless. This year he has presented in Copenhagen, Milan, Las Vegas, Portland, Tel Aviv, Krakow, and many more. His blog on The Burning Monk covers his favorite topics, including AWS, serverless, functional programming and chaos engineering.

Read more interviews from our Six Questions series.

When I say “a holistic view,” I mean that the operational challenges are interconnected, so it’s not a case of tackling one of the challenges and you will be “production-ready.” You really need to tackle all these problems, at least to some degree, to be confident that you can operate your serverless applications reliably in production.

The biggest mistake I have seen is when you go straight from a monolithic system to serverless and think you can skip all the lessons of microservices. That’s usually where things fall apart. Remember, when you’re building systems with serverless technologies like AWS Lambda, you are still building microservices. Microservices is never about containers or VMs, and when you’re building APIs or event-processing systems with Lambda you are still building them as microservices, each with its own bounded context with a narrow scope of responsibility and authoritative ownership of its data. Sure, individual Lambda functions can be deployed independently, but that’s an implementation detail.

Making a video takes easily 10 times as much work as writing or speaking! That said, you’re able to teach at a much deeper level, and do a lot more with video than in a one-hour talk where you rarely have the opportunity to go beyond the basics. With video I can take a complex topic and break it down into many small, digestible modules. I also use a demo project to take the user through building something themselves–which is a very effective way to learn.

There’s no trick to it, you just make time to do it. If it’s something you’re passionate about then you’ll always find time for it. I’m also a terrible procrastinator, and I like to write when I’m procrastinating on something else; you’d be amazed how many articles I managed to write when I really need to complete my tax return! Maybe next time, I can hand over all my tax filing work to a tax resolution firm so that I do not get to make any excuses further.

F#. Not that it’s a difficult language to learn, but it was a paradigm shift for me at the time, having only been exposed to mainstream OO languages such as C# and Java at that point in my career.

The hardest part was having to unlearn many things I held as reality. The funny thing is, after you persist through a paradigm shift once, the next one becomes so much easier, your mind is less rigid and you’re more likely to accept a different point of view. That’s the great thing about learning a new paradigm, it teaches you a different way to look at a problem. For any engineers looking for the next language to learn, I highly recommend jumping out of your comfort zone and learning a language that is as far away as possible from what you’re used to. That will have a transformative effect on how you problem solve!