SystemD bashing aside :p Talos is pretty awesome for setting up clusters. At home I just run talos with matchbox for PXE bootstrapping it works like a charm. Been really easy to maintain too. I normally just update matchbox and then reset a machine at a time with talos ctl for a clean install. It's something very reassuring with completely reset your machines so you know you could reinstall or replace them easily.
Granted just used in a home setting running smaller workloads for backups, private projects, git etc.
Lots of comments about issues with dependencies and Graal. I suggest looking into Quarkus. Have had great success with and mandrel (a patched version of Graal for Quarkus). Quarkus focuses on creating Web APIs so wont cover it all but if thats what you want to do its great and builds native images quite easily.
I think the issue is that any energi i spent on trying to make my apps have a less of a co2 footprint would be better spent engaging in climate questions instead, preferbly using ones profession.
Ie doing stuff like writing applications that scrapes metrics and show how green the energi grids are realtime, doing real time stuff around planes current climate effect given the amount of planes up in the air etc.
If thats not an option just vote with climate in mind and engage in public discussion around these issues would probably have a lot more potential
This is a great paper, did my master thesis on adapting in to autonomously navigating large bodies of water with a boat/ship or similar. For which it worked great!
It's almost weird it haven't gotten more attention yet! Awesome post ^^
Generally in my experience, a company that's looking for a DevOps engineer does not know what DevOps is.
DevOps is great, but it's not a title. It's beautifully summarized in "The DevOps Handbook" and it's fictional counterpart "The Pheonix Project". It's about culture.
Some people might feel different and want to re-evaluate due to so many company adapting it in a similar vein many companies want to adapt agile. But make no mistake, you can't define it then, since then the context of the company defines the word. Thus sadly the word is slowly loosing its meaning.
This is likely due to lots of management people wanting to adapt the buzzword without understanding it. This since it has have had such a great success in many companies that actually know what it is, have taken the DevOps culture to heart and implemented processes in line with it.
Whoever gets too hung up on this must've never had to hire people to do what the DevOps culture they so want to implement needs.
If your plan is to just hire software engineers, you're going to have confused applicants, if your plan is to hire sysadmins, they probably will have a different skillset than you need. Most real companies hire DevOps engineers because that's the way to get the people with the skillsets you need.
Being so purist about this sounds to me like useless debate, but maybe you have better suggestions.
At my current place we stopped hiring DevOps and started hiring SREs + software engineers for specific internal teams, but for a few years there between 2010-2020, good luck getting people with DevOps skills without actually advertising DevOps roles.
I think that it's less important to make the distinction nowadays because systems engineers use developer tools and modern practices. 25 years ago when I was a "Junior Linux systems administrator" my peers kept their vast collection of shell scripts on a file server if you were lucky - some hoarded their own "craft" and kept them on their personal workstations. Scripts got copied onto machines and executed. There was no CI/CD because in most places, systems folk didn't use version control. The best we had back then was a PXE boot server + kickstart files + custom packages. Married to virtualization, this gave you a pretty flexible way to roll out big changes without having to run around with CDs and then manually install and configure software. If you were really lucky, some bright spark put the package source files in CVS, and maybe even triggered RPM automatically, so newly built or rebuilt servers were in an almost ready state from the start. But system state would begin to drift immediately, and you could almost guarantee that the Apache config in one box wouldn't match the next. While frequent automatic server rebuilds were the gold standard, few shops actually implemented that. That meant that systems engineers needed to be able to fix anything. Manually. This required intimate familiarity with the content of system files for GRUB, PAM, dhcpd, init scripts, if-scripts, LDAP, NFS, Apache, SendMail... In fact, the ability to manually hack on those things were the skillset for a systems engineer. Look at the RedHat 6 RHCE exam curriculum!
If you could write complex shell or perl scripts, and you knew how to dig into performance metrics on the fly, you were a god. (Yeah, capturing and displaying system metrics was in its infancy, and most shops simply didn't know how to do it)
While some systems were built to be "horizontally scalable", you were lucky if you worked with systems that weren't SPOFs. You were happy with redundancy via active/passive failover (and that was probably a manual affair). Maybe if you were really lucky, you worked for a SaaS that served a monolithic website via a fleet of webservers behind an F5 loadbalancer. "Wooooah!". But you still set up those F5 VIPs and pools manually.
The modern systems engineer rarely has to do anything like this, even though the underlying technology is similar. These days everything you care about is in git, and is mostly testable on git push. Modern companies, including tiny 4-person SaaS startups, can have infrastructure-as-code, configuration-as-code, packer configs, dockerfiles, container orchestration, CI/CD, metrics collection, USE/RED metric graphs for every system with alerting, pager, incident handling runbooks...
At some point over the last 25 years, the term Systems Engineer could mean that you're an expert in the old ways or the new ways. When you advertised for a DevOps engineer, it left no doubt that you were looking for the modern variety and expected that experience and skillset.
I supposed instead of saying DevOps has lost its meaning it has been co-opted from it's original meaning to something else. Problem is just that it isn't well defined. I like a definition like this, but as an earlier comment talked about a DevOps role is about facilitating the DevOps culture values, which is quite the different thing.
On another note, how amazing it is to define our systems so we can more systematically iterate on them and improve. I love it when developers get integrated into the process as well.
The general consensus where i work is that everyone does DevOps, you develop the app, you make sure you deliver the app, if there's any issues you debug. You ain't done until your ticket is in production, and you can't point to other to solve it for you, only help you.
Improving pipelines. Dealing with downtime on the CI. Improving performance of the CDN. Writing better tooling for the devs to deliver value even faster.
You can also advertise for zookeeper or chef, but if you want people doing X, a good bet is to advertise for X.
I asked for alternative suggestions and offered what we use. If you have suggestions of alternative titles you've successfully used to hire without slowing things down I'm all ears.
> What's DevOps skills in your opinion?
The most important skill is knowing to not fall for the bait that is this question so that you can actually work.
But if you want Software Engineers that will take up DevOps skills and responsibilities, surely you'd want to advertise this DevOps culture instead of a role? Advertising this as culture is likely to attract people that want to work in a place without a DevOps/SE stratification.
I think the only reason to advertise for it as a role, is when your tooling is too complex and you've given up looking for Software Engineers that could do it on the side. Which is fair enough, I guess, though providing a Golden Path nowadays is probably more popularly done by hiring Platform Engineers.
Generally, in my experience, an individual who says, "DevOps is a culture, not a title", does not know what DevOps is. It can be both, and exclusive, at the same time.
I think there's a point to the blog article itself, but i think you miss a vital point in the conclusion. The way a DevOps position that is described in the blog post is a valid position that could have DevOps in the title. But that's not usually how the DevOps role is used. This can be easily seen in many listings of the job title.
The analogy with agile is pretty good here. Sure you could have an Agile Engineer, that works primarily with making sure the agile process is actually used and help facilitating that. Normally that would not be a position itself though, especially not an engineering one.
My argument, in both cases, is that devops can be a title, and that the blanket statement "Devops isnt a role", is incorrect.
Sure, maybe some job postings are still wrong, but that doesnt mean they are all wrong.
If you are out there interviewing for a DevOps job and you hear things like this: run. Every meeting you have with this person will be a living hell. Endless debates on semantics and definitions while your project is due today.
So you think the issue is semantics and not understanding? Being due today and having 5 developers thinking the end goal is different and working against each other is way worse then spending some time building consensus and work toward the same goal
In many way the adoption of DevOps has many similarities with the larger adoption of agile development. It just looses it original meaning in a world of little reflection and just surface level knowledge.
Those who can manage to surpass that though can get great productivity from it though.
Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured, community engagement, track record, performance and usability.
Call me crazy, but how does the language you do this in become relevant? As a reference perhaps? Only the best of intentions here, have i missed a paticular pov that makes this extra relevant?
* For projects where one of the main purposes is for the author of the project to learn said language
* For projects which expose an API in their implementation language. In the case of an implementation of a programming language, they might offer embeddability in the host language, or a foreign function interface with the host language.
Why do we consider it normal that APIs are exposed for the implementation language of a project (library, interpreter, application, whatever) but usually not other languages?
Is there any evidence that the "user" of an API is likely to prefer the same language that was used for the original thing?
(BTW this does not seem to be the case for networked APIs such as REST services).
The only really stable, standardized, well-supported ABI out there is the C ABI. Communicating across it is a chore. On the side of the language publishing the API, you need to write a C-friendly façade that translates everything your language has that C doesn't into a much more Spartan semantic space. You'll be losing or having to re-implement pretty much everything you like about that language: any sort of dynamic dispatch, memory management semantics, exceptions, etc. And then, on the client language side, you probably want to write another façade in order to, to the extent that it's feasible, restore all those sorts of niceties.
Direct FFIs are possible, but generally don't happen except in exceptional cases because of the cost involved in writing a new FFI (and accompanying set of gotchas) for every possible language whose packages you might want to consume. The best and worst thing about the C ABI is that it's pretty much the least common denominator.
Even in platforms like Java and .NET that theoretically smooth over these problems, we find that it never works out that well in practice. Scala and F# users end up having to write compatibility layers in order to preset Java and C# friendly APIs, and they end up writing their own versions of just about every possible library in order to have packages that don't feel awkward to use in their language of choice. The only real exception I know of to that pattern on the JVM or the CLR is between C# and Visual Basic, and that is only because Microsoft was very careful to ensure that the two languages' semantics were similar enough to virtually guarantee no cross-language friction.
I am surely an outlier being a developer, but I like to know the project language without clicking as an overview of what people are doing.
I'd suggest that in many forums it is irrelevant to most and should be left off, but I suspect HN is not a representative sample of the general public and many may share my sentiment.
Yeah, but why? Is it a feeling? Is it because it's not relevant if you can't immediately read the code since it's not a language you usually read/write in? Once again just curious :)
it's relevant in this case because most simple Lisp-like interpreters are written in... Lisp (or at least one of the many other Lisp-like languages).
Interpreting a simple lisp-like in lisp is borderline trivial. Interpreting a simple lisp-like in an imperative language demonstrates a significantly more fundamental understanding of how lisp-like languages work.
I like it actually as a mental filter. If the language is the main defining quality it usually means the project is nowhere near production ready, and can be safely ignored for now.
> Might be a little off topic, but what’s with the ”written in” obsession? From my perspective it’s so irrelevant compared to well tested, design, architectured, community engagement, track record, performance and usability.
As far as I am concerned there is one aspect where I think it is relevant for me, as I compile all software that runs on my machine. If it written in C or in C++, there are good chances that I won't need to compile an horrible chain of dependencies (or most likely, try and fail at compile that chain).
That matters to me, because I try a lot of alternative/niche/toy languages, and if I consider those published within, say, the last ten years, half of them won't even compile. It is a disaster. If it is written in shell + C, I can fix a couple errors easily (if there are more I give up because there is no point in wasting my time on something that claims to be next programming marvel and yet is itself programmed like shit). People want to be fancy and pick up toolchains that are not battle-tested like Autotools+C or CMake+C++, and that's the recipe for pain.
For example, today I tried to compile two languages written in Ada, and I had to give up. A mess. Each time I tried to build an Ada project which wasn't mine, it has been horrible. That's antinomic to the image of Ada (clean and strict to the point of being stiff) but that's my repeated experience with building.
I am not even talking about the anti-feature which is compilers which are written in the very language they aim to compile and do not even provide a bootstrapping minimal compiler written in C or similarly fundamental and widespread language. They're generally very proud of their accomplishment :-/
So yes, a project in C (or C++) offers the best chances of success (for building, which is the point I developed here).
Also, considering toy language, I often want to make a dirty hack to add a missing features. If it is written, say, in Haskell, there is zero chance I can do it. Good old imperative languages like C, Python, Pascal, I have a chance and I have already done it.
There is also the case of all the languages built over the JVM. There are really many. But even when they look good to me, they are limited by the opinionated choices of the JVM, and I don't wanna undergo the multiple programming neuroses of Gosling. Also anything Java based has always been terribly, awfully, painfully, excruciatingly slow on any of my machines; I suppose it not an universal experience, but it has always been mine.
------
> compared to well tested, design, architectured, community engagement, track record, performance and usability.
To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects.
But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading.
Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)
First off: Interesting thoughts! I couldn't agree more about the importance to make things easy to build. I'm not sure i agree about C++ and C applications being particularly easy to build though. Personally i have not seen any particular correlation with any language, but have too small of a sample size to say anything definitive. Would make for an interesting deep dive though.
>To each is own: I care about well tested, usability, and depending on the intended use, performance. I also care a lot about proper exhaustive documentation, which is missing from your list and from most programming languages projects.
~But I don't give a damn about its design and architecture, what matters to me is the external features, not the internals. Language designers care way too much about the internals and neglect the outside, which is what matters to the end user. I don't care if it make your parser more complicated, it if makes your grammar irregular, if you need more passes, if you need to dirty your hands with context; I want that source code using your language flows, for writing and for reading.
I think there's a disconnect here between good design and architecture and the result of it. You can't by definition have a good design and architecture that makes your program difficult to use and illogical externally. You can't have good tests without a good design and architecture. Good design and architecture goes hand in hand with usability too.
To go into a deep dive is beyond the scope here. But concisely said, good designs and architectures makes the software easy to understand and easy to change to external changes of requirements. Since its easy to reason about it's also easy to understand and reason about bugs when they inevitably shows up. If the software does not have these features, it does not have a good designs and architecture. You might think a certain architect cares more about the internals then the external, but then the architect is bad, and should study and should step back a step and think about the end user and heading of the software project. Or perhaps there's a communication issue going on, human <-> human style.
Good designs and architectures also is the equivalent, actually superior to, having good documentation. Documentation that defines the external goals are not required if you have good tests that shows them. Hell documentation about the code is not needed if the design and architecture is good. And the self documenting code can never lie. Is it difficult to achieve? Yes. But not trying will put you into a corner you can't get out of and inevitably lead to the rewrite-from-scratch. Unless of course you have a very strictly defined end goal and complete definition of done, but you could still paint yourself into a very difficult corner to get out of.
>Community? I don't really care, and I have seen it being detrimental to many projects, which lose their compass by wanting to incorporate every feature request and following the mood of the year; I'd rather they were developed between closed doors and only published when they reach beta status, to maintain consistency, instead of jumping from an unpolished feature to the next. I am aware that's totally against the current trend, where people publish repositories with a README.md before writing the first line of code or documentation :-)
Not sure i see the correlation between pushing readmes with intent and publishing unfinished feature upon unfinished feature. Isn't readme:s infact documentation? Well well :p i believe you can work in the open without jumping to unfinished feature to unfinished feature. Polish can come in the middle of a development cycle, not just the end. A vibrant community around a software also is equivalent with many contributors etc, which makes the software resilient to people moving to other things etc.
I might have sounded critical, but enjoyed reading your response. Thank you for your response :) I also believe you gave me clues to why the "written in" header is so popular.
The way you interpret certain values i gave was also insightful. I certainly don't have the same opinions, but non the less i can see where you come from. So i just had to respond to it :) Thank you!
This demonstrates a modern distortion in software engineering where people are trained to hate other languages they don't use and reinvent the wheel in each new language. Each new language that is introduced seems to reinforce this incorrect perception and it seems that we can barely do anything else than reinventing the same old, well-tested libraries in the next "language du jour".
Brilliant. It's a really good compliment to strangling certain parts of a large code base.
As always the key is getting the information to the right people at the right time, and making it more difficult to make the wrong choices then the right choices.
Exactly. What's nice about this approach is it factors in the "behavioural economics" of developers. As the author puts it...
> At the end of the day, everyone needs to get work done, and if they see a code-path already being used from 10 places in the code-base despite these soft warnings–it doesn’t seem crazy to introduce another.
Even the best person with the best intentions will take a short cut under some circumstances, meaning to fix it later then getting distracted before that happens.
The idea of deprecation and death of code assumes that those using it can easily stop.
That’s not always the case.
When Flash dies Jan 12, 2021, you’ll see what I mean.
There’s been so much misinformation about it, but there’s an OS datetime check in the Flash viewer code, browsers will disable the plugin even for some older versions not just new releases and have or will remove PPAPI and NPAPI support, and Windows already has an optional update to kill Flash support that will be part of regular updates in Summer 2021.
Even with three years of warning, it’s not ok.
It’s an extreme case of deprecation, being attempted by the best in the business, but it is inherently bad, and there’s hardly a good way of doing it.
At this point if you/your company is still using Flash I find it hard to sympathize with you. How did the company come to the conclusion that using Flash was a good business decision? It's been largely unsupported/disabled in mainstream browsers for _years_ now. They also knew for 3 years it was officially going to be deprecated in 2021. Sounds like despite that they continued to develop on the technology anyway?
Sure. Can't have it both ways though: you're welcome to choose to implement on a soon to be deprecated tech stack but you don't get to bitch about it or expect the maintainers of said stack to suddenly change their minds about deprecating.
> My point is that deprecation is by its very nature going
> to hurt something that isn’t prepared for its demise.
TFA describes techniques for deprecating code paths that do their best to notify and prepare the folks working with that code.
You're describing the end of Life of Adobe Flash that hits at the end of 2020.
Deprecation is different from EOL (Flash has been deprecated for some time now), and deprecating/EOLing a creation tool/product line has little similarity with tooling to deprecate internal APIs gracefully.
Although I do think that you and TFA agree on how difficult it is to deprecate functionality that folks rely on, it seems like you're talking about two wildly different facets of that statement.
Granted just used in a home setting running smaller workloads for backups, private projects, git etc.