This article doesn't make any sense to me. DevOps from my perspective is CI/CD defined with a YAML file and using Docker biuld containers or custom GitLab Runners (or the Github equivalent), not something where programming in Python or Golang is needed.
I'm assuming dev teams that are responsible for deploying, observing, and maintaining microservices (which obviates the discussion about shared services). For cloud the physical servers/infrastructure is managed by AWS/GCP/Azure; for on-prem k8s the infrastructure team (what older devs used to call "sysadmins") provide the hardware onto which to deploy our convoluted microservices.
It pushes all the complexity to the interfaces between teams (what used to be a unit test in a monolith becomes a continuous manual operations task), so that no one is empowered to or responsible for making the application work properly.
Then, it explicitly eliminates the teams and mechanisms that used to manage the complexity of budgeting hardware, forecasting demand, etc, which kills margins and also somehow simultaneously forces developers into unexpected load shedding exercises caused by hardware shortage, leading to roadmap slippage and team churn.
On top of that, it ensures that production issues will be harder to debug because the infrastructure team has no visibility into the application, and the development / ops teams have no visibility into underlying hardware issues.
Thankfully, many smaller/growing companies are explicitly rejecting most of this nonsense (since they wouldn’t be able to succeed otherwise).
All the competent devs I know either hate ops work, are bad at it, or happily transferred to an ops team, because being split between dev and ops meant they could do neither well.
The term DevOps has been bastardized so badly that nobody really knows anymore. At my current company, 'DevOps' are what we used to call sysadmins.
When I first heard the term, it was described to me as 'developers do their own operations.' Next it was 'developers work with operations.' Then it was 'operations, but working to support developers.' Now, it mostly means something between sysadmin and terraform wrangler, I think.
Go is good for infrastructure as code and automation since it compiles to native binaries.
Unfortunately the article neglected to mention that, which imo is the most useful aspect of go for devops, since no one wants to deal with runtime dependencies for hundreds of machines.
The frontend and backend dev teams should be making major platform decisions based on the problem domain and their own expertise. Whatever they choose, packaging and deploying and monitoring it is not going to be a showstopper.
And there are other languages that ought to at least be considered for scale and concurrency: Scala, Rust, Erlang …
This reads like it was written by ChatGPT and provides no specific insight into Golang or Python from a devops perspective. It doesn't talk about which one is easier to use to actually automate your ops (definitely Python) or which one is easier to deploy (definitely Golang.) Flagged, waste of time.
I hope we quickly arrive at a social standard where posting AI-written content is viewed as extremely disrespectful to your audience.
EDIT: based on previous submissions it looks like aoms is the author of this post. Aoms, am I misunderstanding something here? Why are you doing this?
Yes, it's a typical article written by ChatGPT, there is almost no content and the same could be written in 4 sentences. I assume the author is running some experiments.
As someone who has done devops-y stuff with both, I highly prefer Go just because I can plop in one binary + config file and it'll just work.
With Python I need to install Python, the virtual env manager du jour and all the required packages. And I need to keep them up to date. And everything is just one step harder if I don't, for some reason, have root privileges on the environment in question.
The Go version has been running for days in the time the Python one has all it's dependencies in order =)
Since the article is meaningless, I'll offer my take on the current situation. There is no battle: Go is used for testing Terraform, for writing Kubernetes operators etc. In CDK, every language except Typescript is a second-class citizen and you need to translate the examples to your language since TS has the best docs. As for Lambda, practically speaking you will use the same language that is used by the rest of the company. As a DevOps,you pretty much have to understand the idioms of a few languages - at least HCL, Python, Java, JS and Go - and TypeScript if you use CDK.
22 comments
[ 1.8 ms ] story [ 52.6 ms ] threadWhat am I missing here?
It pushes all the complexity to the interfaces between teams (what used to be a unit test in a monolith becomes a continuous manual operations task), so that no one is empowered to or responsible for making the application work properly.
Then, it explicitly eliminates the teams and mechanisms that used to manage the complexity of budgeting hardware, forecasting demand, etc, which kills margins and also somehow simultaneously forces developers into unexpected load shedding exercises caused by hardware shortage, leading to roadmap slippage and team churn.
On top of that, it ensures that production issues will be harder to debug because the infrastructure team has no visibility into the application, and the development / ops teams have no visibility into underlying hardware issues.
Thankfully, many smaller/growing companies are explicitly rejecting most of this nonsense (since they wouldn’t be able to succeed otherwise).
All the competent devs I know either hate ops work, are bad at it, or happily transferred to an ops team, because being split between dev and ops meant they could do neither well.
Most of the times devs doing ops works ends in a nightmarish setup which is hard to maintain.
There is a reason specialization exists, and having seperate ops folk can save you a tremendous amount of money on resources or/and hardware.
When I first heard the term, it was described to me as 'developers do their own operations.' Next it was 'developers work with operations.' Then it was 'operations, but working to support developers.' Now, it mostly means something between sysadmin and terraform wrangler, I think.
Unfortunately the article neglected to mention that, which imo is the most useful aspect of go for devops, since no one wants to deal with runtime dependencies for hundreds of machines.
“Python is strong because of x. On the other hand Golang is strong because of y. Conclusion: it depends. “
It looks like a template article where *devops* could be replaced by any other topic like: cm/s, e-commerce, microservices or whatever.
And there are other languages that ought to at least be considered for scale and concurrency: Scala, Rust, Erlang …
I hope we quickly arrive at a social standard where posting AI-written content is viewed as extremely disrespectful to your audience.
EDIT: based on previous submissions it looks like aoms is the author of this post. Aoms, am I misunderstanding something here? Why are you doing this?
As someone who has done devops-y stuff with both, I highly prefer Go just because I can plop in one binary + config file and it'll just work.
With Python I need to install Python, the virtual env manager du jour and all the required packages. And I need to keep them up to date. And everything is just one step harder if I don't, for some reason, have root privileges on the environment in question.
The Go version has been running for days in the time the Python one has all it's dependencies in order =)