I am preparing a course about "Java for DevOps". From a DevOps perspective, what topics should be covered during the meeting?

I was thinking about the following topics:

  1. What is DevOps?
  2. Why should I learn Java or a programming language that the team is using from a DevOps perspective?
  3. Java itself
    • keywords
    • keyword categories
    • OOP
    • FP
    • Hello World

The aim of this question is to get feedback. On one hand I think that these topics will cover "Java for DevOps", but on the other hand I would like to know whether other people agree with this or what topics they would cover if they will organize the course?

The target audience consists of Senior/Medior Quality Assurance, Senior/Medior Operations and some Junior Developers.


According to Wikipedia, DevOps is the intersection of Development, Operations and Quality Assurance.

Development: creates features, i.e. add business value Operations: ensures that the software runs stable Quality Assurance: tests the software by clicking in the UI for example

DevOps: intersection, i.e. automated, stable, tested software sooner to the customer

As development creates new feature, it would be beneficial for the company and also the developers that Testers and Operations automate more and start to fix bugs, then Development could create more features.

If everything goes well, perhaps some testers and operations could create features in a couple of months/years as well.

  • What's the reasoning behind doing a "Java for DevOps" course?
    – AnoE
    Apr 30, 2018 at 16:17
  • @AnoE The question has been updated.
    – 030
    Apr 30, 2018 at 16:28
  • Maybe the angle "DevOps in Java domain" would give more drive? Actually, we should ask Maven archetype devs to include Dockerfiles..
    – Ta Mu
    Apr 30, 2018 at 17:23

2 Answers 2


Even with the rationale you edited in, I don't really see a point.

DevOps is an intersection of Dev, Ops (and more, like Security and maybe Testing) in a cultural sense. But on a technological sense, you will always have people in a mixed team who are good at one of those but not the others, and that is fine.

For example: you might deploy something like Kubernetes or OpenShift; and then you will for sure have ops-sided people who are expert at running the low-level stuff, tuning your NAS, adapting your orchestration to a cloud provider of your choice, or to on-premise bare-metal servers and so on. You will not, usually, have all of your developers do the same; they may use those things provided by the others. The ops guys might never see a piece of application code at all; and you would still call it "DevOps".

What your devs will be able to do is manage the full lifecycle of their applications, from source code to production, using the tools provided by the ops guys. When one says that devs do jobs that ops used to do in the past, one means that the automation makes it so that the environments (dev, test, int, prod...) are mostly the same; that deploying to them is as automated as humanly possible (without requiring manual ops, and most importantly without requiring a handover of binaries etc. between devs and ops); that there is a complete, unbroken technological chain from source to prod; including things like virtual networks automatically springing into existence and so on. One does not mean that devs troubleshoot hardware or networking on a low layer.

The same goes for your ops guys. They will most certainly not try to change the application code proper after a few seminars on it, unless you are talking about really small companies with 3-person teams who need to do so out of sheer necessity.

Note that I am not saying that it is not possible to be one person who does both development and operations work. Is is an absolute gold mine to have such people available; and some companies foster that by, for example, rotating devs into low-level ops groups occasionally. But those guys are not your target audience. By the topics you listed in your question, you are targeting ops guys who have never in their life coded anything ("hello world").

If you actually want your ops guys to grow into coding instead of just clicking around in GUIs, modifying or creating config files and such, then here are some suggestions:

  • If they are writing the occasional bash script already, point out advances constructs to them (loops, functions, error handling, etc.).
  • Try to get them interested in some dynamic language like perl or ruby for a low-hanging fruit, one step above shell scripts.
  • Introduce them to go, which is really nice for standalone command line applications and especially automation tools. It should satisfy the need to learn something new which should go really well on anyone's resume, and will satisfy the naysayers regarding non-natively compiled languages.

... and so on. But don't try to sell them "Java" as a route into "DevOps".


If you want to do "DevOps Engineering" then you should examine the various tools and APIs that you are going to use with the projects that are being planned.

For example if you are going to use Jenkins, that's a Java based system you could look at that. If you are going to implement microservices you could look at the framework you are going to use and figure out how to do full delivery starting with a product request

On the other hand, if you want to do "Devops Culture" then this is a different approach. The best short explanation of it is Gene Kims 3 ways

To make this kind of cultural transformation you need to see how to map the systems ideas that you have about your organisation (maybe there is some way to map this onto Java Patterns) how to optimise this by identifying waste or feedback loops and lastly how to schedule many different solutions to the problems and opportunities identified. Maybe a Java based approach might help with figuring out what metrics are available

Sorry this isn't a detailed answer but I don't really do Java myself

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.