A big theme in the keynotes and conversation during Velocity Conf in NYC a few weeks ago was the role of ops in an "ops-less" and "server-less" world. It's also been a big feature in discussions on twitter and in conversations I've had with coworkers and friends in the industry. There are several things that stand out to me in these conversations: first, that some ops engineers (sysadmins, techops, devops, and SREs) are worried that they will be phased out if developers and software engineers are responsible for the operational tasks in their systems; second, that developers and software engineers do not have the skills needed to take over responsibility for operational tasks; and third, that building reliable systems is impossible without an operations organization.
Over the past few years, ever since writing "If Susan Can Learn Physics, So Can You", I've been contacted by people from all backgrounds who are inspired and want to learn physics, but don't know where to start, what to learn, what to read, and how to structure their studies...this post is a condensed version of what I've sent to people who have contacted me over the years, outlining what everyone needs to learn in order to really understand physics.
As most of you know, I left Uber in December and joined Stripe in January. I've gotten a lot of questions over the past couple of months about why I left and what my time at Uber was like. It's a strange, fascinating, and slightly horrifying story that deserves to be told while it is still fresh in my mind, so here we go.
I've been searching for the perfect monthly book club for years, one that could send me new science, math, philosophy, and technology books every month. I contacted several publishers, reached out to various existing companies, and nobody seemed to be interested. Finally, earlier this year, after hearing another "no", I decided to start my own monthly book subscription service, and Susan's Book Club was born.
I sat down with O'Reilly's Mac Slocum at the O'Reilly Software Architecture Conference a few months ago to talk about the topic of my talk and my new book: microservice standardization. They recorded the interview and shared it on their site here: https://www.oreilly.com/ideas/why-you-should-standardize-your-microservices
After reading Philip K. Dick's Do Androids Dream of Electric Sheepover the Thanksgiving holiday and watching the very first few episodes of The Man in the High Castle TV series on Amazon, I just had to read The Man in the High Castle, and I'm so glad that I did. Neither book is exactly pleasant to read: PKD's writing is extremely choppy, and the surface plots don't quite come together or make much sense. It was only after I read both that I realized why the plots were so strange: they aren't quite the stories that the books are telling.
In this post, I cover the four layers of microservice architecture - the hardware layer, the communication layer, the application platform layer, and the microservice layer - and what each of them contains.