Top products from r/devops

We found 101 product mentions on r/devops. We ranked the 91 resulting products by number of redditors who mentioned them. Here are the top 20.

Next page

Top comments that mention products on r/devops:

u/Burnsy2023 · 21 pointsr/devops

I would be very cautious before you start this. You need to have a much better understanding of why you’re doing this before you start. I think breaking up ops teams may be an answer to a different question. That question should be: “how do I deliver better business value?”

The first step is to understand what you’re trying to achieve. Gene Kim, Patric Debois et al talk about the “three ways”. It’s essentially three steps towards embracing devops culture.

The first is all about increasing flow through the system - that system being your organisation. The idea is to look at how your organisation goes from a business need to realising business value. For instance, how do we go from wanting to provide another payment option on a website, to customers being able to use it?

One way of analysing and visualising your organisation as system is something called “value stream mapping”. This looks at how a piece of work gets requirements, gets developed and how it gets to customers (even if that’s internal customers). You need to understand the process, where the delays are, where teams hand off from one to another, where things go wrong. Ideally you want to optimise this process. One of the issues that many organisations look at just automation and essentially automate a slow and inherently crap process. This will never give the returns that many people are after. Looking at this level, you should be looking at organisation goals. How do you measure this work in a frame that other people are going to understand who are not IT? Is it how fast you can get a feature to market? Increasing individual spend? Increasing reliability of the service you provide to customers? If you’re not framing this initiative in those terms, then it’s doomed to failure. Be specific and measurable.

Once you understand your process, you can look at opportunities to optimise the feedback loops (the second way). It might be that infrastructure is required by dev teams that gets delivered by ops but isn’t what they need. There is a team hand-off here that needs to be addressed. There are many solutions to this problem, but it might be a start to move where the person provisioning that infrastructure sits. Put them in the dev team. You might still keep them as part of the ops team logically to start out with. The point is, you’re looking at the system, understanding the constraints and trying to optimise pain points.

You can achieve a lot without adding any new automation or technology solutions and this shouldn’t be underestimated, but ultimately, handcrafting systems isn’t repeatable or fast enough. This is where reorganising teams might look sensible, but you should know what outcomes you are string to achieve. That might be difficulties provisioning infrastructure fast or flexibly enough, it might be deployment of code to live being too slow, it might be that testing is too slow. Once you know you need improve, you can look at tooling to better achieve that.

/u/quailtop mentions:

>In my (admittedly limited) experience, you can solve needing faster development velocity (the first problem) through staffing a new team whose job it is to help improve the deploy, test and release process for all developer teams. Their job is necessarily cross-cutting across all dev teams. They would develop internal tooling e.g. a standardised build/release process that all teams can employ. This is a great pattern because it avoids encroaching on existing territory and is a very clear contract between engineering.

This is otherwise known as the DevOps “hub and spoke model” and is what my organisation has implemented. It’s worked very well for us and it’s a clever way to start a reorg.

For certain ops teams, you may want to keep them together. For example, you may have a large and complicated network setup and still need a dedicated networks team. My focus then, would be putting an obligation on those teams to allow others to better consume their services. They may need to add other people to this team to make that happen. For example, if you have a complicated network, with lots of steps, look at both automation of those steps but also to allow other teams to more effectively consume them. Amazon spent a lot of effort building the culture that ever system or service is an API that should be able to be consumed easily internally (have a read here: . So, for this case, you may add a tech lead and some software engineers to build network APIs rather than splitting the team up. This may include some of your more traditional network admins to look at replacing on prem infrastructure to support this. The goal however, should always be about the organisation level goal. Improving the speed at which you can reliably deploy network changes should be in support of one of those strategic objectives.

The third way then focuses more on continual learning and experimentation. You should have embedded a set of objectives that you’re working on achieving but you’ll have lots of legacy systems, legacy processes and behaviours. Focusing on outcomes and consistent asking of “why?” will start to help. This is also where SRE becomes really relevant for me. IMO SRE isn’t something that is particularly useful to start out with. It’s best when you’re looking at elevating and existing DevOps culture to a new level. This will look more at observability of a systems and understanding where the more difficult optimisations can be done.

Let me be clear. DevOps is a long road for any organisation to change to. To really get mature it will take many, many years to properly bed in. My organisation started around 5 years ago and we still have more progress to make. One of which is to move from project based way of organising work to more long lived product teams. This organisational change is probably the biggest thing holding us back right now, and has nothing to do with automation or technical practices.

I wouldn’t start out by reading about SRE, I would start with a book called The Phoenix Project and then read The DevOps Handbook, at least twice. Start with the strategy before you make any changes. I would also look to see if you have a cloud strategy because many of these practices are much harder to implement purely on premise.


Edit: Thanks for the silver!

Edit2: One thing that's also worth noting is that for many people, moving from traditional sysadmin to DevOps is a hugely scary change. It means that many of the staff won't have the job security they thought they had and they need crucial skills they don't have. To make this work, understand this point of view and support them. This requires really mature and experienced leadership at all levels. This is a good, short and free ebook to help the more traditional sysadmins understand why they have to change.

u/mdaffin · 15 pointsr/devops

> give a vague impression that they all do the same thing.

Lots of tooling does overlap but each one has one area it excels at - some excel at the same area.


So, you have done a good job so far, it seems like most of your stuff is automated to a good degree and you have identified where your weaknesses are.

You should tackle one thing at a time, identify your largest bottle neck or problem and work to solve that first. In the same vain, only introduce one new tool at a time. Each takes some time to learn and to implement it correctly. Trying to do too much at once will just cause problems.

You have already identified the weaknesses so focus on solving these, starting with what you think is causing the most issues.

> - One server per environment is obviously not super scalable

Look into HA setups. How you do this and how much work it is depends on your application. Typically there are two parts to applications, work and state. Work (such as processing requests) is easy to scale if it contains no state. Just add another server to the environment and load balance between it. For this you need a loadbalancer (HAProxy or Nginx work well, though there are many others to chose from) and to move any state off the node you want to scale.

There are many forms of state, most will be stored in a database but you should also pay attention to session state which is sometimes stored in memory on the node - if you have anything like this you will need to do work to move it into some sort of storage, like a database or storage solution (such as your existing database or redis or memcached etc).

> - No sense of automatic provisioning, we do that "by hand" and write the IPs to a config file per environment

There are loads of tools to help with this.

Terraform for provisioning infrastructure.

Ansible or Chef or Saltstack or Puppet for provisioning nodes (I recommend starting with ansible, though any of them will work).

There is nothing wrong with using bash scripts to glue things together or even do provisioning while you learn to use these tools. I would not shy away from them, but do recognize the benefits each tool provides over just bash scripts. Take your time to learn them and stick with what you know and what works for you while you do. Introduce them a little bit at a time rather than trying to convert your entire infrastructure to use them in one go.

> - Small amounts of downtime per deploy, even if tests pass

This is easiest if you have a HA setup. You can do it without one but it involves just as much work and basically follows the same steps as creating a HA setup. In short, with multiple nodes you can upgrade them one at a time until everything has been upgraded. There are always some nodes running on either the old or new version so everything will continue to work.

You can either update nodes in place, or create new ones (if you have automated their provisioning) and delete the old ones when the new ones are up and working (see immutable infrastructure for this pattern, also canary deploys and blue/green deploys for different strategies).

> - If tests fail, manual intervention required (no rollback or anything) - though we do usually catch problems somewhere before production

Tests should be run before you deploy. These should run on a build server, or ideally a CI system. Ideally these should not only run before all deployments, but also for all commits to your code base. This way you can spot things failing much sooner and thus fix them when they are cheaper to fix. You also likely want to expand on the number of tests you do and what they cover (though this is always true).

Rollbacks should also be as easy as deploying the old version of the code. They should be no more complex than deploying any other version of your code.

> - Bash scripts to do all this get pretty hairy and stay that way

Nothing wrong with some bash scripts, work to keep them in order and replace them with better tooling as you learn/discover it.


I have mentioned a few tools here, but there are many more depending on exactly the problems you need to solve. Tackle each problem one at a time and do your research around the areas you have identified. Learn the tools you think will be helpful before you try to put them in production (ie do some small scale trails for them to see if they are fit for purpose). Then slowly roll them out to your infrastructure, using them to control more and more things as you gain confidence in them.

For everything you have said there is no one solution and as long as you incrementally improve things towards the goal you have you will be adding a lot of value to your business.

For now you need to decide on which is the biggest problem you face and focus your efforts on solving that - or at least making it less of a problem for now so you can focus on the next biggest problem. Quite often you will resolve the same problems in different, hopefully better, ways as you learn more and as your overall infrastructure, developmental practices and knowledge improves.


Also the 12 factor app is worth a read as is googles SRE book and the devops handbook. The Phenoix Project is also a good read.

Though these are more about the philosophy of DevOps, they are worth a read but wont solve your immediate issues. Reading around different topics is always a good idea, especially about what others have done to solve the problems you are facing. It will give you different perspectives and links to good tools you can use to solve the problems you face.

u/JosephPratt · 1 pointr/devops

TL;DR Google "Cost of Delay", Puppet's 2016 State of DevOps Report page 43 for rework calculations, and compare %C/A improvement to increased %Innovation (%I).

This has been a major challenge opportunity for us. I would start by aligning the conversation to Agile Principle #1's three main tenants: Customer Satisfaction, Valuable Software, and Early and Continuous Delivery. If you are in a large (and old) IT organization such as mine, these tenants are loosely held to, barely understood, or simply dismissed. However, in order to measure the success of a digital transformation, these three things must be measured. For the sake of our VSM effort's MVP, we've focused on measuring Early and Continuous Delivery. (You can also discuss this in the context of the 3-ways of DevOps. Early and Continuous relates to the first way. Customer Satisfaction and Valuable Software are feedback loops of the second way. And getting us there is the third way.)

For our first pass at measuring Early and Continuous Delivery, we discussed how we could reduce total cost of change by reducing overall lead time (LT). A simple calc is team member count * hourly rate ($/hr) * 6 hrs/day * overall LT in days. You can get specific and do that calculation per value stream process block and add it up, or keep it high level and you'll be in the ballpark - off by 10-15% at the most. If you're working in hours, then you can adjust the formula by dropping the "6 hrs/day" part. (If you're working in minutes, you should just make the case for purchasing Google Nap Pods or something. =))

The problem with relating overall LT reduction to a cost of change reduction is it's not completely accurate unless the lead time and process time (PT) are the same. So LT = PT + QT. And unless we propose that queue time (QT) is spent doing nothing related to other value-add work (which would be tough to argue), then really the PT is the total cost of change. (I'd imagine we'd both agree that context switching has some non-value-add overhead, but how much? Maybe 10%?)

What we've found is that if we're talking about reducing overall LT the best measurement to catalyze the improvement conversation is to consider Cost of Delay (also check out here and here). You can show that by reducing overall lead time, we can capture the first-mover advantage, thus reducing or eliminating Cost of Delay. We are in a competitive capitalistic market after all. Our business measurements are relatively immature, so we used hypothetical numbers to demonstrate this. Obviously real numbers would be more impactful.

Next, consider %C/A. Rework (aka waste work) is potentially one of the biggest wastes of IT budget (and more importantly a development team's time) that a VSM can capture - a low %C/A is most certainly creating rework. Check out page 43 of Puppet's 2016 State of DevOps Report as it provides a simple calculation for rework cost. It may also be important for the group creating the VSM to perform RCA on a low %C/A process block as this may actually be the principle constraint of flow.

Moreover, a %C/A problem in Production has a direct impact on Customer Satisfaction. Framing improvement work with a risk-based mindset will inform you that solving a low %C/A problem in the Prod process block has a measurable impact on Customer Satisfaction. (Two before and after short surveys to your customers, internal or external, should show a diff in Customer Satisfaction if the %C/A in the Prod process block is improved.)

The last point is more of a qualitative measurement, and that is around %Time for Innovation (%I). I hope your organization doesn't devalue development teams as I have seen from time to time, but remember, development teams contain some of the most creative and capable women and men in the entire company. It's important that they move away from doing work a machine can do through automation and focus on innovative (aka creative) work. If you research HP's printer firmware transformation, you'll see that they related %C/A work (warranty) to %I. It makes sense that if the team is not doing rework, then they have time to focus on innovation. While this doesn't directly relate to Agile Principle #1, it will likely map to Customer Satisfaction and/or Valuable Software, since %I time can be spent doing A/B testing, spiking new and relevant technology, or simply interacting with customers directly thus gaining empathy for their jobs to be done.

I also highly recommend Accelerate: The Science of Lean Software and DevOps. The first part gets into some numbers and is essentially targeting middle management and up. It will give you some scientific foundations for some of these improvement conversations.

The business justification of VSM and improvement work is a big subject, and I'm still learning. Remember that finance is as much art as it is science. I hope this gives you some ideas!

u/warpigg · 1 pointr/devops

> Looking out into the world, I'm seeing that pretty much all of the job postings (at least currently) are Linux-focused.

This is spot on. Unfortunately I am in the same situation (sort of). I am on the job market and have Linux experience from 6-7 years ago but recent stuff is Windows. The job market for windows is very very small (and shrinking IMO) - the Linux move is the best move to better future proff yourself. You are on the right track.

However, (here comes the disappointing part) - much will not be transferable. Well, your Azure knowledge is good thing to leverage - even if a lot of stuff is still AWS. The high level concepts, "yes" - you have an advantage over the totally newbie b/c you understand release management and have done it regardless of the tech. But you will almost have to start from junior level to gain traction in Linux if you havent touched it before. Everything that most are saying on this post is valid.

Learn / become familiar with:

  • Python, BASH - work on your dev skills

  • install Linux, configure mail servers, web servers, db servers, poke around on the system - read this book then read it again.

  • jenkins (and similar), AWS/GCP, hashicorp tools, ... open source web servers, databases, etc

  • using Linux locally on a laptop is good idea

  • Linux Academy - get a subscription, go crazy (well try not to go certifiably crazy ;))

  • Consider a few good Linux certs (Linux Foundation LFCA/LFCE and/or RHCSA/RHCE) as these are performance based (and you WILL learn something) and have more clout than multiple choice certs.

    Basically look at what you do now in MS focused tools, find the open source equivalents and build stuff :) Put it on github/gitlab too.

    It is sort of a lot to learn and can be overwhelming. So plan to take a little at a time and see where everything fits in the larger scope.

    Good luck - IMO as you can see in job postings, you are making the right move
u/n0phear · 5 pointsr/devops

Okay, so my recommendation is similar to many others here, except that I'd say start with(get an audible subscription),

The Goal Audio Book by Eliyahu M. Goldratt

This is a really good book to start with, reasonably easy to listen to in audio format once you get rolling. It all started with this book! It's perfect start before you seque into

The Phoenix Project

It made for a pretty descent audio book as well. I powered through both of them while commuting. And I found it to be good enough.

DevOps HandBook

This however isn't quite as good as an audio book and you are better off with the book itself unless you are tight on time.

From there, this primer is pretty comprehensive to get you rolling,
[O'Reilly Learning Path: Modern DevOps] ( which will cover a little bit of every technology you might be interested in. I haven't gone through this myself but it seems to have descent coverage, from the 3 ways, to git, containers, docker, kubernetes, ci(jenkins), swarm, aws, puppet, salt, testing, agile, compliance, etc etc..

As everyone else has mentioned, 12 Factor is a required reading.

And if you want a pretty deep dive on Docker, Docker Mastery: The Complete Toolset From a Docker Captain

Is well maintained. If you want to know AWS better, there are some descent udemy courses as well that you can pickup for $15. Anything from Ryan Kroonenburg is pretty descent. Side note Azure just started offering a managed kubernetes service that is now in preview its worth checking out.

From there, the only other thing I would say is to look at Terraform and every product by hashicorp and some more in depth content for
kubernetes and possibly Powershell if you are a windows person.

u/oinkyboinky7 · 2 pointsr/devops

No problem.

1.) Is there any option to avoid Windows cause I didn't really grew on it and Linux is much more familiar to me, I can install powershell as a snap I think but I want avoid Windows as much as possible


I'm the opposite: grew up on Windows and I avoid Linux haha.


That said, there certainly is the option to simply ignore Windows (there are a lot of Linux only shops out there), however, I would not recommend avoiding it completely.


Most IT environments that you will end up in have a mix of Windows and Linux. You will be much more attractive to some employers if you can say that you know Windows basics and are comfortable navigating the platform, rather than saying that you are Linux only.


To add, a lot of enterprises run Windows only tools (ActiveDirectory, Team Foundation Server, etc.).

In order to interface with these tools, you'll need to know some Windows basics.


At the end of the day, keep in mind that when looking at an enterprise sized network, the operating systems are just one piece of the puzzle. You'll want to be able to step back, visualize the entire network, and not really care what OS is running on the nodes. You'll want to know about the protocols the servers use to communicate (http(s), smb, ftp, etc), how to automate processes regardless of platform, and some basic security concepts.


2.) What cloud experience should I pick first, I have small budget of 13 euros for Udemy courses so I can pick only one and I want to do it wisely


Go with AWS 100%. They are the most popular at the moment and a lot (if not most) of what you learn will transfer to the other providers.


Try to study for the AWS Solutions Architect certification.


The practice exams here ( ) are invaluable since they will explain why certain answers are correct/incorrect.


3.) Would learning Apache, PostgreDB/mySQL be worth ?


At the end of the day, Apache is basically a web server and the other are databases.


For a DevOps role, perhaps look into automating the database component of an application deployment.


4.) Which should I pick first to learn about concept


Look into CI\CD pipelines. CI = Continuous Integration and CD = Continuous Deployment.

Basically, these pipelines deploy an application to web servers when developers check in their code.

One has to build them using different tools. Have a read here ( ).

If that interests you, this is basically the Bible on CI\CD ( ).


Any more questions feel free to ask.

u/bluescores · 4 pointsr/devops

Hello and welcome to the club! To answer some of your questions:

Books. The aforementioned The Phoenix Project and The DevOps Handbook are both great resources that will help you understand what devops aims to do. The handbook has a lot of great "what am i doing (and why am i doing it)" explanations and practical implementation advice. I would add Continuous Delivery to the list as well. Because it lacks the Goldratt-inspired language of The DevOps Handbook it's a little more to-the-point regarding "what am i doing (and why am i doing it)" imo and easier to read and understand in one pass if you're looking to dive in quickly.

We don't know what what your company produces or the exact scope of resources you manage, but AWS is a big, robust ecosystem, and it's a great place to get started with devops. Don't be too worried about limiting yourself. After all, AWS is the biggest cloud platform provider in the world right now; it's a really big pigeonhole to land in. Any patterns you apply to AWS can very likely be translated to other cloud providers.

> Lastly, what are your thoughts on devops vs software engineering?

Software engineering is the "dev" in "devops". Unfortunately a lot of companies hire "devops engineers", but really they expect very little "dev" and a lot of "ops". Developing apps and infrastructure together is great way to optimize your stack and deployments. It's the quintessential devops move. Take advantage!

u/idboehman · 2 pointsr/devops

I'd make sure I have a really solid understanding of systems and networks, e.g. how Linux works. This book seems like a great overview and I love No Starch Press. There's also this book which is used by Carnegie Mellon's introductory systems course, though that might be a bit too deep to dive into straight away, more like something that could be used if you want a deeper understanding of how systems work. You should have some familiarity with C just as foundational knowledge. The guy who wrote Learn Python The Hard Way also wrote an intro to C, Learn C the Hard Way. He's added a lot more material than the last time I checked (~Dec 2012) which looks like it covers a lot of topics so it would be great to work through it.

Some more technical books on this subject that are well regarded and can be used as reference books are Advanced Programming in the Unix Environment, Unix Network Programming, and The Linux Programming Interface

Also in addition to Python I'd also suggest learning some Ruby (Practical Object-Oriented Design in Ruby and Programming Ruby 1.9 & 2.0 are two resources I'd recommend), it's what Chef is/was implemented in and is fairly nice to work with.

u/jrnt30 · 3 pointsr/devops

I think all of those things you've listed are valuable in their own right, however I think a bit of focus may help. First, determine what you are actually trying to accomplish because learning all those at once is not really feasible. Break that long term goal down into more meaningful steps.

For example, a good long term goal may be:
> Deploy an source controlled application on AWS using a configuration management tool, leveraging Infrastructure as Code to make it repeatable and Immutable Infrastructure to provide stability.

Breaking that down we have a series of things to learn:

  1. Getting comfortable with source control systems (Git is obviously popular but others work just fine as well)
  2. Learning the core constructs of AWS
  3. Configuration Management
  4. Infrastructure as Code
  5. Immutable Infrastructure

    These things can be done somewhat in parallel, but I would say focus your efforts will most likely provide the best value. The order in which I've listed these I find is the most useful to instruct people that are new to the area.

    Building A Scalable Web App on AWS

    General Cloud Architecture
    The Practice of Cloud Systems Administration

    Git Book
u/OHotDawnThisIsMyJawn · 5 pointsr/devops

It's kind of dumb but there are two different "CD"s.

The first level is CI, which is committing code and having something that builds it automatically and runs all the tests.

The next level is CD (Continuous Delivery), which is a process that takes your successful integration builds and pushes them out to some set of environments (e.g. UAT or staging or whatever). From there you might have some set of additional tests that run, maybe load tests or integration tests with live external systems.

The third level is CD (Continuous Deployment), which is a process that takes your successful delivery builds and automatically pushes them to production.

In a true continuous deployment pipeline there's no gating step where people sign off on UAT (this doesn't mean there's no people involved anywhere, for example code review pre-merge is fine). You write your tests, you merge your changes, and if everything passes the changes just show up in production.

The part of your process that makes it not "true CD" is the human sign off in UAT.

That being said, TRUE AUTOMATED CD IS NOT RIGHT FOR ALL SITUATIONS! There are many business reasons that you might not want to or be able to apply a true continuous deployment model.

IMO the best book on this stuff that's out right now is

u/cstoner · 2 pointsr/devops

Pretty much un-related, but I have a question about going from the Ops side of the aisle over to Dev.

A bit of background on me:

  • BS in Computer Science

  • Been doing Linux Ops work for the last 5 years

  • Config management, automation, version control, blah, blah, blah.

  • I've been picking up Python for a bit, and am working on some Django based stuff in my free time.

    Anyway, on to some questions:

  • Do you have any book recommendations that don't treat me like I'm new to programming? Looks interesting. But the vast majority of material moves far too slow for my taste. I haven't done a lot of web development, so something that shows me how all the pieces fit together quick would be great.

  • How hard did you find it to break into dev with a few years of ops experience? Can I safely assume that getting a website up with some custom code hosted on github would be enough to get my foot in the door?
u/spaghetti_boo · 2 pointsr/devops

DevOps is broad - very board. Some say it's not even a "thing".

Your request is quite broad.

I'll do my best, and feel free to ping back any specific questions as all DevOps requirements are conditional based on your working context.

Considering your background, and your current approach to DevOps, I'd suggest reading up on DevOps culture, generic tooling (in various classes), amongst various other topics (apologies for the ambiguity here, but there is too much without more specific context).

DevOps Tooling Classes:

  • Source control: Strive for all your day-to-day activities to be represented as code in some form.
  • Automation using CI pipelines (Git, Jenkins/Teamcity, etc).
  • Automation from a configuration management perspective (Ansible, Chef).

    (Naming a minuscule fraction of the available tooling.)

    Ask yourself these questions to help you with your Google'ing:

  • What is a CI pipeline?
  • Can I read JSON and YAML?
  • What is Kanban?

    If I had to sum it all up, and give you the best vectors to approach this:

    Think of DevOps as being able to deliver a business requirement using reliable and reproducible techniques:

  • "Everything-as-code."
  • "Community effort."
  • "Monitoring"
  • "Simple is key."

    As I mentioned before, DevOps is very broad.


    Ping back for help! That's what DevOps is all about!
u/jerseylegend · 5 pointsr/devops

I can't quite envision a devops engineer without a good foundation of linux, especially if 98% of the servers are linux based. I also ask some basic scripting questions(if they tell me they do script). If the interviewee has never scripted, that's unfortunate. If you struggle moving around the infrastructure, it's going to be a difficult and stressful job, and more importantly, more work for us if we underestimated his/her skills and we have to babysit to help someone on what we perceive is essential and crucial to function. We do have numerous tools, processes, etc in aws, especially now where more and more companies are migrating to the cloud and doing serverless, but I have found that some of the bigger(little older) companies have tons of linux hosts to manage. And many of those aws resources are prob ec2's - you can ssh in, you can't escape linux!

I personally don't care which linux you know, i care more that you know how it works. However I am particular to CentOS, and Ansible.

I've had to interview a few people recently and i ask them sub-groups of questions: AWS, linux, networking, tools (jenkins, docker, config management). My hardest questions are linux. The tools, with the exception of docker, are the least significant because they can be learned; Generally the good linux candidates, for example, probably have already written scripts that do some of the functionality a config management tool was designed for. I think networking is very important but my questions are very basic. Generally the people with the aws cert/xp have already seen a lot of aws networking; Fortunately for the candidates, Ops manages the vpc's, acls, sg, routes etc so the devs don't break anything and therefore we don't rely on too much networking knowledge. But you gotta know how systems are communicating with each other.

My linux, aws, and networking(most) questions are scenario/exercise/conceptual based on real world problems/scenarios i've seen throughout the career. I simply ask what they've done with config management and jenkins or other CI and other tools they have listed on their resume.

On a maybe unrelated note - in my personal opinion, i think devops eng should learn how to use docker and know it a little in depth. It is an invaluable tool especially for development/testing work. Docker Up & Running and Docker In Practice are very good books

I'm in nyc, if it matters.

I recommend Unix and Linux System Administration Handbook The first 6 chapters (skip2) are a good start.

u/redsymbol · 3 pointsr/devops

While cringing at the 2.0 meme just as much as anyone, I have to recommend my favorite technical devops book right now, which actually has "devops 2.0" in the title:

It's written by a stellar engineer, for engineers... focused on the technical challenges in implementing devops, rather than hand-waving about culture and vague ideas. All substance, no fluff. Marvelously well written. Opinionated, in the good way (i.e. takes a stand on things and explains his reasoning, leaving you free to disagree).

My only concern is that it's so specific to the technologies of 2016 that - when the current edition inevitably becomes outdated in a year or three - the author will break my heart by declining to put in the work to make an updated version.

u/andrewjsledge · 2 pointsr/devops

> Do you have any book recommendations that don't treat me like I'm new to programming? Looks interesting. But the vast majority of material moves far too slow for my taste. I haven't done a lot of web development, so something that shows me how all the pieces fit together quick would be great.

Unfortunately, not really. Most of the programming experience came from 'I need to accomplish X, how do I do that?' types of scenarios. Honestly I learned more from The Pragmatic Programmer and various discrete math books than any technology-focused book (though Learning Python has been pretty invaluable).

> How hard did you find it to break into dev with a few years of ops experience? Can I safely assume that getting a website up with some custom code hosted on github would be enough to get my foot in the door?

I was lucky and a former employer had an opening for a webdev, and having left on good terms they gave me a shot. Worked my butt off and got proficient, played around with other languages and frameworks in my spare time and built up a portfolio. So yes, play around with some different thing and build up a github account, but don't be afraid to commit to other projects either. In fact, if I were to go back I would have done a lot more of that since most of the code you will work on in your career will be to work on existing code. In my current role I do defect fixes only - never writing any new code. When I was doing raw web development, it was about 70% new 30% old - read as much code as possible to see how other people do things.


u/Purplemarauder · 2 pointsr/devops

If you've not got a copy of Continuous Delivery bu Humble and Farley I'd really recommend it. It's chock full of best practices with reasons as to why, what etc.

Sometimes it's easier to point to something that's published rather than have it seem like it's just your opinion I've found. :)

u/gsaslis · 2 pointsr/devops

I would recommend the Continuous Delivery book ( as a starting guide for what you need to do on the CI/CD front.

It doesn’t go extensively into testing, which is basically your safety net. The Clean Code book ( is a good start here.

On the whole Agile Software Development methodologies front, it’s important to understand some principles behind each framework. I’ve found this book useful on that regard:

I know this might sound overwhelming, but so is what you’re describing... : ))
Reading books is an investment that will pay off on this journey you are setting on.

Good luck!

u/Metal_Raiden · 2 pointsr/devops

Starting with the solution architect associate, I recommend this book.

this official study guide comes with a lot of sample tests to help for the real test.

About how difficult is the exam... depends your level/experience with AWS, everyone is different, if you are a guru already, it should be ok for you but it's not easy easy... is... the reference, those guys are really good to help you pass the certification. (you can find the same course from in Udemy for 10$, then claim it to their website if you wish)

most of the questions are from the FAQs, so read them and read them again and... understand them as well :).

u/fallspectrum · 2 pointsr/devops

I highly recommend The DevOps Handbook; I'm in the midst of reading it now, if you appreciated The Phoenix Project then this comes across super practical and to the point.

u/EgoistHedonist · 5 pointsr/devops

Ouch! Sounds like you don't have any part of a continuous delivery pipeline ready. I would start from there before doing anything else. This book covers the whole concept nicely:

We were in exactly the same situation year ago when I started. The production was last deployed months ago because it was so painful. Now we deploy over ten times per day and the whole 15min process is automated. Deployments have become a non-issue and there's no need for anybody to be on-call or lose their sleep because of it. :) It has also made a huge difference to our productivity and allows us to crush the competition via rapid innovation.

u/skarlso · 3 pointsr/devops

I found that a lot of the concepts it employs and hooks and the top-down design view only came into focus and understanding for me once I've read the book kubernetes up and running. The documentation is nowhere near the simplistic explanation of this book which made everything painfully clear.

Once I've read that I was able to come up with this post: Deploying clustered applications with Kubernetes where I'm deploying a multifaceted, distributed application with it.

Granted I still found some troubles along the way, but once I did that, everything made sense. :) I also wrote a bunch of beginner explanations which clarifies the main design of it. Hope this helped a little.

u/lazyant · 1 pointr/devops

For Linux internals read , you only need the intro to each chapter (before he gets to code).

For general Linux read

You need to know some concepts very well, like life of a process and signals (may not pass initial screen interview without those), as well as basic networking (both google and facebook have a networking interview although it’s valued less than the others).

Btw there’s also an interview about designing a distributed systems, best source to learn is to read about tools at google, facebook and AWS.

For troubleshooting, there’s no book, it’s all practice with real problems. If I had the time or rather the priority, I’ll publish a bunch of broken things in docker containers as exercises but it’s a lot of work.

I do have a troubleshooting framework , with things like verify given information, trying to break the problem space in two , do first easy quick tests etc

u/Ashex · 3 pointsr/devops

You guys need to change how Dev works with you, I'll elaborate once I'm at a computer.

Edit:And I'm back

Where are these apps coming from? What's the driving need for them? Do they serve a business purpose? If so, do they drive revenue or productivity? You guys need to have a chat with the development managers or Director to figure out what their roadmap is for all these apps. They have an idea of their purpose but they're not involving Ops which is a major deficiency when we're looking at adopting a DevOps culture.

When looking at Ops being the constraint, what particular aspect is the constraint? A specific person or process? Isolate the constraint then protect it, if it's a person you're pulling off projects you need to figure out why they're getting pulled off them and remedy that.

As for a technology to look at for a solution, start using Docker. Create standard Docker templates and provide Dev with those as their platform, if they're creating apps for production then you need to provide the standards they deploy to/develop for.

Now go read The Phoenix Project, I'm deadly serious about reading that book as you have a major communication breakdown that is resulting in an insane amount of projects being thrown your way.

u/paradoxops · 7 pointsr/devops

Make sure you checkout What is DevOps? in the welcome section of this subreddit.

If you have some time, get your hands on The Phoenix Project as well. It will give you some perspective.

u/Terny · 1 pointr/devops

I recommend the Kubernetes: Up and Running book.

The demos are amazing and it explains everything you might need.

u/BadCorvid · 1 pointr/devops

Start him with for the basic Linux admin stuff. Then teach him bash and git. Those are long term basics. Anything else gets learned on the fly.

After he has those pretty well on the way, start on whatever higher level scripting language you use, plus your configuration manager, CI/CD and in-house cloud fads (infra, containers, orchestrators, etc.)

Let him know that the "common" stuff changes every two years, so he'll have to learn new languages and technologies constantly as the fad of the month changes. It still beats Windows helldesk and unscrewing .pst files.

u/chappel68 · 1 pointr/devops

I liked Steven's TCP/IP Illustrated Vol 1 (Addison-Wesley). It does a great job of breaking down exactly how the core protocols work at a very low level.

u/FetchKFF · 11 pointsr/devops

You've got a lot of foundational knowledge to pick up if you're going to successfully complete this. And fair warning: for people with excellent domain knowledge, the task ahead of you can take months. My suggestion would be to read the following resources, to figure out what extra knowledge you need from there.

Jez's book on Continuous Delivery -

Paper on CI with Docker -

Pattern of CD with New Relic -

CI/CD in the web development space -

u/michaelandrews · 3 pointsr/devops

This is a great (and short) introduction to what the DevOps mentality is. You and your boss should read it before you start hiring "DevOps Engineers".

It's not a "thing" but a philosophy on making sure Developers and Operations (SysAdmins) work together within your organization.

u/btvn · 6 pointsr/devops

Might as well get the follow up:

The book is good, but again a little too Google focused.

u/mattstratton · 2 pointsr/devops

The title is a little misleading, but the latest version of The Practice Of Cloud System Administration is excellent.

u/ejb50 · 2 pointsr/devops

best way for beginners is to get the book

study up over say 3 months and then pass the aws certified solution architect exam.

Interview questions are all a bit of luck. Sometimes they ask questions you know and sometimes you don't but you only need one job offer so just be persistent. -)

google for aws interview questions and remind yourself before an interview.

u/studweiser83 · 1 pointr/devops

You wanna be devops? Read how the best does it then take classes to answer everything you have questions about

u/Kaelin · 2 pointsr/devops

This one

Site Reliability Engineering: How Google Runs Production Systems

Free Online:


u/kiyanwang · 2 pointsr/devops

Have you tried the DevOps Handbook?
The Devops Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations

u/Trospar · 3 pointsr/devops

Both you and your boss should read this "fictional book" so that you are both on the same page.

The Phoenix project is the best description of the problem that devops is trying to solve IMHO.

u/leemachine85 · 7 pointsr/devops

My advice, don't worry about coding or experience in this or that solution.

Read, Read, Read!

Learn the discipline, the fundamentals, know what DevOps is.

Start with this:

u/tevert · 1 pointr/devops

The DevOps Handbook has some good stuff on these topics, in addition to what others here have said.

u/nvanmtb · 10 pointsr/devops

Highly recommend you read this book:

It details a fictional story around someone in a very similar situation to yours and is kind of a DevOps bible at the same time.

u/drawsmcgraw · 1 pointr/devops

Do you mean this book?

Searching for 'Continuous Delivery' returns a fair amount of noise...

u/levi_mccormick · 4 pointsr/devops

"The Practice of Cloud System Administration" is my bible. Every time I have a question like this, I find the answer in here.

u/unborracho · 14 pointsr/devops

The Jez Humble / David Farley book on Continuous Delivery is a must read from a standpoint of teams that deliver solutions in an automated way. More oriented towards software developers than operations / IT but really a must read for both types of folks for us to all come together as "DevOps".

edit: Amazon Link:

u/dasmim · 3 pointsr/devops

I personally haven't used it or read it, but I've seen be recommended on here (and other places) before

u/EnergyCritic · 3 pointsr/devops

/u/HostisHumaniGeneris has a pretty exceptional definition.

The only thing I'd add is my own personal experience. DevOps is a philosophy -- not a team name or a position. For example, a developer can be a "DevOps developer" or a company can be a "DevOps company" as if it's a quality of their performance, but not a purpose. Your actual role shouldn't really include the word "DevOps" because at the end of the day you're still doing IT, or Operations, or Systems, or Development.

The reason being is that for DevOps philosophy to be implemented, all levels of the team need to be on board with the philosophy.

Read "the Phoenix Project" -- for example -- to get some ideas about what DevOps is really about.

u/MisterItcher · 1 pointr/devops

This is the Holy Bible of DevOps. Well, it's the Old Testament. The New Testament is

u/rjhintz · 1 pointr/devops

I'm not clear on the pipelines from developers' machines to production deployment, both today and as you'd propose given current restrictions.

Also, you might want to revisit your Vagrant/Ansible thoughts in the context of what your corporate peers are considering. It's not unreasonable that they are considering rearchitecting their current dev-->deployment strategy and you don't want to be seriously out of step with it to avoid a lot of wasted effort.

Of course, what you'd really want is to work collaboratively with your peers to come up with a strategy to iterate to a modern dev-->deployment workflow that everyone could use, targets Rackspace or generic public IaaS provider, and "breaks down some of the legacy silos" as the saying goes.

It's not irrational to think that the current restrictions could be rethought, You'd need to get the infosec, compliance, and bean counters on board. Needs exec sponsorship.

Have you read the Phoenix Project? Often cited as a starting place. Cheesy in spots, but an interesting read on the process. Not the detailed cookbook you were asking for, but those exist, too. Just need the earlier clarifications.

u/Dctcheng · 11 pointsr/devops

According to Accelerate

  • Lead time, the faster you get a feature out the better. Top companies do this in 1 hour
  • Deployment frequency, the more you deploy, the faster you can get features out and fix issues. Top companies do this on demand (several times a day)
  • Mean time to recovery, how fast you recover from downtime. Top companies do this in under an hour
  • Change rate failure, what feature when delivered is incomplete and requires more work. Top companies have a failure rate of ~10%
u/metamet · 2 pointsr/devops

Here's your homework:

u/robohoe · 3 pointsr/devops

Look into Network Warrior. It's network-heavy but goes over some of the most common things you would do as a network engineer.

u/ildiroen · 2 pointsr/devops

The DevOps Handbook, Team Geek and Debugging Teams come to mind.

I don't think there is something specifically for "devops managers" (what is that even?). General leadership books would work for you as a manager I suppose. Just keep the principles of DevOps in mind when you do manage away.

u/caligolae · 2 pointsr/devops

By its very nature, DevOps roles are typically not "junior", and you'll have to have earned your mid-level stripes in systems/operations/cloud engineering to graduate on into DevOps.

Read [0] "The Phoenix Project" and [1] "Leading the Transformation" for an introduction to what DevOps theory/philosophy is all about. It's really worth taking the time to study these books, even if what is in them may not be something you're going to apply at your current job.

Get an [2] AWS certification. As a difficult and rare exam, companies looking view those who hold the DevOps Engineer certification in high esteem.




u/keftes · 34 pointsr/devops

Networking is networking. There's no difference who does it.


Regardless, this is a timeless book: