Implementation of an on-call policy requires answering precisely these questions: who is responsible for on-call duties for an application/service, and how is that responsibility defined? More succinctly, who owns on-call?
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.
Every week I read at least one book during my commute to San Francisco while I'm riding BART. Since I'm doing all that reading, and I love writing about what I read, I'm starting a new feature here on my blog where I'll write up little informal reviews of the books that I read, focusing on what I liked about each book and the lessons I learned from it. I'm excited to kick off this series with one of the most amazing books ever written, by one of my favorite writers of all time!
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.
In today's post, I want to share some of the things I've learned about how to structure and run these types of interviews. If you're here because you want to know how to ace the architecture interview, you should keep reading, because I think the best ways to prepare for these things is know how interviewers think about them.
I just finished writing my first book, Production-Ready Microservices, and I've gotten a lot of questions about how I approached it, how I wrote it, and what the process was like from start to finish. The book is currently in the last stages of technical review and copyediting, so I thought I'd take advantage of this little break before I dive into writing my next two books and write something up about the whole process.