patternjavaMinor
What topics should at least be included in a Java for DevOps course?
Viewed 0 times
topicswhatcoursejavaforincludedleastshoulddevops
Problem
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:
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.
Rationale
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.
I was thinking about the following topics:
- What is DevOps?
- Why should I learn Java or a programming language that the team is using from a DevOps perspective?
- 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.
Rationale
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.
Solution
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:
... and so on. But don't try to sell them "Java" as a route into "DevOps".
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
bashscript already, point out advances constructs to them (loops, functions, error handling, etc.).
- Try to get them interested in some dynamic language like
perlorrubyfor 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".
Context
StackExchange DevOps Q#4021, answer score: 3
Revisions (0)
No revisions yet.