I am currently listening to The Phoenix Project and it seems quite nice (https://soundcloud.com/itrevolution/sets/the-phoenix-project...).

If you are into it, the DevOps Handbook is also pretty good (https://soundcloud.com/itrevolution/sets/the-devops-handbook).

Read "The DevOps Handbook", lots of great tips in there. And congratulations!

My favorite book on this topic is the DevOps Handbook. The author lays out a very clear and easy to follow path that gives you the same result: secure and reliable systems.

I think they ran out of time or ideas by that point, and intended to follow-up with another book: The DevOps Handbook, which took them a long time to finally get around to writing.

DevOps. Read the classics:
- The Phoenix Project

- The DevOps Handbook

- The Google SRE Book

I have not read The Unicorn Project (by the authors of two of the above) but it is probably more relevant to your question.

Hacking Healthcare (HC specific) and The DevOps Handbook (general) are the books I buy for everyone joining the team.

I recommend Eric Topol's books as well, including The Creative Destruction of Medicine and Deep Medicine. Lots of food for thought.

Do you think the DevOps Handbook would be useful for a working programmer in a small startup without any sysadmin? By reading the descriptions I was under the impression that it's very high level and more geared towards big organizations.

It depends on the book, and subject matter. I might turn notes on The DevOps Handbook into more of a technical format but a book like The Lean Startup might have just Chapter titles with bullet points. I don’t think I’d use it to review books though.

The Phoenix Project is a really inspirational novel, good for 'getting' the devops mindset and also as a tool to get other people in your organisation on board.

https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Busi...

The DevOps Handbook is a sister book to The Phoenix Project which is more technically oriented around the practicalities of closer integration between Dev and Ops.

https://www.amazon.co.uk/DevOps-Handbook-World-Class-Reliabi...

I'm also hoping to prune my reading list of redundancy.

Right now I've got:

- Design Patterns by the Gang of Four

- The DevOps Handbook by Gene Kim

- The Phoenix Project by Gene Kim

- Designing Data-intensive Applications - Martin Kleppmann

- Peopleware - Tom DeMarco

- Code Complete - Steve McConnell

- The Mythical Man Month - Frederick P Brooks Jr

- Growing Object-Oriented Software - Steve Freeman

- Domain Driven Design - Eric Evans

- The Clean Coder: A code of conduct - Robert C martin

- The Pragmatic Programmer - Andrew Hunt

- Building Evolutionary Architectures - Neal Ford

- The Design of Everyday Things - Don Norman

- Don't Make me think - Steve Krug

I found this line interesting, everything else considered:

DevOps is NOT…easily achieved nor implemented

Debatable, at least IMO. DevOps isn't easily achieved nor implemented if you're trying to implement ALL THE THINGS to say you did and check-off a series of "We did DevOps thing x" boxes as so many companies appear to want-at least from reading various DevOps-y job descriptions lately.

It is easier implemented if, like Gene Kim tells us in "The DevOps Handbook"-we start our DevOps transformations with a small, sympathetic team and iterate outward.

> release annually

Stop what you are doing and read either (or both) The Phoenix Project or The DevOps Handbook.

TL;DR: smaller, more frequent deploys are safer, less likely to introduce bugs, provides faster feedback for better learning, and require built in automated testing, quality checks, and solid telemetry. It makes lives better for developers, qa, ops, product, the company, and customers. This is not "not move fast and break things."

Location: Cleveland, OH, USA

Remote: Yes

Willing to relocate: No

Technologies: Kotlin, Java, Ruby, Python, JavaScript, Docker, Ansible, CI/CD, Git, Gradle, MySQL, PostgreSQL, Redis, MongoDB, AWS (EC2, Lambda, API Gateway, Elastic Beanstalk, IAM, Cognito), Spring Boot, Ruby on Rails, Serverless

Résumé/CV: https://erikthered.me/resume/

Email: erik.david.nelson@gmail.com

10+ years experienced engineer with past experience in building web apps and REST APIs on the JVM. In my current role I'm working with some Ruby on Rails apps and Serverless apps with Ruby running on AWS Lambda, in addition to some DevOps responsibilities.

I'm open to both backend and DevOps roles (I recently read The DevOps Handbook and it was awesome). I'd be game to do fullstack as well, but I'm a little rusty on frontend outside of some light React work.

For anybody wanting to learn DevOps today, "The DevOps Handbook" is the canonical text. https://www.amazon.com/DevOps-Handbook-World-Class-Reliabili...

Check out:
- The DevOps Handbook
- State of DevOps Report 2017
- Guide to Sysadmin Body of Knowledge www.sabok.org

The first thing to realize is that DevOps is an ambiguous term (at least partly by design, it seems).

My belief—shaped by many at the forefront of the DevOps movement—is that it is a cultural focus rather than a technical one. In many ways, it's an extension of agile philosophies, with a focus on fast feedback, transparency, heightened interactions between teams, etc. There is also a heavy focus on automation (CICD), but the automation is there to serve the cultural goals. Just because you do CICD doesn't mean you're necessarily doing DevOps, and you can adopt a lot of DevOps principles without doing full CICD.

Books:

* The Phoenix Project— introduces a lot of concepts (such as lean principles) that are foundational to the movement

* Effective DevOps (Oreilly)

* The DevOps Handbook

Podcasts:

* Arrested DevOps

* DevOps Cafe

Blogs:

* IT Revolution

Events:

* DevOpsDays conferences

* Local meetups

* Velocity conferences

* DevOps Enterprise Summit

Having a good grasp of both development and operations skills is helpful. But it's far from complete. If you solely focus on the technical aspects without examining the cultural, you're missing the foundation of the movement.

You clearly haven't read "the phoenix project" or "the DevOps handbook".

DevOps is about demolishing the walls between development and operations, in the sense of making both parties work together.

Basing on that, development needs some knowledge about operations tooling and operations people need some knowledge about development tools, if anything to build automation and to integrate with the software being built.

In Continuous Delivery and DevOps:

Lean software Development - Mary & Tom Poppendieck

The DevOps Handbook - Gene Kim, Jez Humble, Patrick Debois

Accelerate - Nicole Forsgren, Jez Humble, Gene Kim

Continuous Integration - Paul M. Duvall, Andrew Glover, Steve Matyas

Continuous Delivery - Jez Humble, David Farley

I disagree (politely) with your assumption about QCOW2 and BTRFS performance, if I get some time this week I'll do some objective benchmarking (I design and build Linux based storage systems) and see hey I might be proven wrong but regardless I can let you know the results if you're interested?

People not willing to update their kernel in production environments is a social problem, not a technical problem. The kernel is one of the most reliable, well tested and reviewed software projects in the world. When you upgrade your kernel 99.5% of the time you get new features, performance and bug fixes without any negotiate impact. There are of course rare corner cases especially if running propriety hardware when they are generally slower to release updates that show the benefits of a modern kernel.

The problem there is the culture and traditional slow moving operational engineered haven't all embraced the well proven fact that regular, small charges are safer and have various added benefits.

There is also a serious language barrier between many engineers and management / project managers who clearly would not be likely to understand the benefit of upgrading to a kernel version that say properly supported the new SCSI blk_mq backend for storage, so there either needs to be degree of trust and respect to (proven) engineers(ing) and teams or they need to be clearly taught the value add of a fast release cycle and practising quick (hopefully automated) patching. That's where I think books like Gene Kim's - The Phoenix Project and his soon to be released book - The DevOps Handbook which may in fact be more useful to people performing PM/PO tasks.

I'm working through reading the DevOps Handbook (the companion successor to The Phoenix Project), and in it is an entire chapter dedicated to the necessity of dedicating either the time (measured in 20%) or dedicating a small group of people who's express and specific charge is refactoring and paying down technical debt.

They pointed to Nordstrom as an example of an enterprise organization who did this as a part of their internal devops transformation, and it worked wonders at the time when it was needed.

This team didn't tackle new user stories for feature additions or enhancements, they didn't work on existing tickets. Their role was singularly focused on identifying and making payments on technical debt and operational enhancements.

Not every team can afford to focus an entire group of people to the task of paying down technical debt, but what I did take from it is that every team can't afford to not dedicate some time out of the week or month making critical fixes where necessary.