CatOps – Telegram
CatOps
5.1K subscribers
94 photos
5 videos
19 files
2.56K links
DevOps and other issues by Yurii Rochniak (@grem1in) - SRE @ Preply && Maksym Vlasov (@MaxymVlasov) - Engineer @ Star. Opinions on our own.

We do not post ads including event announcements. Please, do not bother us with such requests!
Download Telegram
For today’s Donations Monday I would like to remind you about Pavlo and Naya who raise funds for recon drones and equipment for them.

This week’s goal is to get a bit more than €10k drones and the telecommunication equipment.

- Pavlo’s requisites
- Naya’s requisites

#donations #Ukraine
👍51
In my last Kubernetes Operations Survey, there were very few Cluster API users. However, the technology is not abandoned at all.

So, if you want to know more about Cluster API, check out the learning course by VMware.

Also, check out the results of the Kubernetes survey if you haven't done that already.

#kubernetes
👍14🤔1
From our subscriber:

Till the end of June you can save up to 40% on the Linux Foundation courses with this promo code:

JUNEBBQ40

UPD. Also, AWS has extended the promo code for exam retake. So, if you fail the exam the first time, you can retake it for free. More details:

AWSRETAKE

#linux #education #kubernetes #aws
👍7
Some Friday material (also, from our subscribers, btw).

DevOps is Bullshit.

Now, once you've got clickbaited, let's talk. The premise of this article has been already repeated many times in different words: a single person cannot know everything and be good in everything, job-specialization is actually good, you can have good enough Jacks of All Trades in the beginning, but it doesn't scale.

The answer that this article provides is to build platforms. Internal platforms, specifically. You know, do Platform Engineering. And I fully agree with this statement. Yet, this article comes from a company that sells you an "IDP as a Service". So, you can clearly see some vested interest here. What I dislike specifically about this article is that instead of striving for standardization, a good platform should "accommodate all the various needs and configurations". I mean, if you sell it to others, it makes sense. If you are building an internal platform, why would you do that?

Anyway, nice Friday read. Here's a reaction video by Primeagen (this is how I actually "read" this article).

Also, if you have any interesting things to share - welcome to our chat! Chat is in Ukrainian, tho.

#devops #culture #platform
😁41😢1
OpenAI shares their story of running large Kubernetes clusters.

Their setup is quite unique since they mostly running research jobs. Still, there are couple of takeaways for running large-size clusters. For example, reducing the number of DaemonSets and the number of the node count fluctuations.

Also, as usual the most interesting part is the “Unsolved problems” paragraph.

#kubernetes
🔥9👍51
​​For today's Donations Monday I want to remind you about the Kolo charity foundation, which has a goal to raise 10M UAH for Shark UAV.

Direct link to donate.

#donations #Ukraine
Maksym Vlasov - the co-author of this channel - has written an article about how to create Terraform lockfiles for hundreds of root modules.

You can read it in:

- My blog. This is the first guest article, BTW!
- Or you can find it on Substack (don't forget to subscribe there!)

Also, the live stream with Maksym and Terraform-master - Anton Babenko - is live right now!

#terraform #hashicorp #oc
👍172
​​HashiCorp posted an article in their blog on why platform teams should run as product teams.

If you're familiar with the topic of Platform Engineering, likely there is not that much new information for you. However, I think it's important to repeat those points, because the more people see them and start acting this way, in the better shape the industry will be.

Also, this article contains links to other articles and case studies that clarify some aspects. I like it when an article is a so-called "crossroad". So, you can continue exploring a topic once you've done with the original piece.

P.S. I cannot come up with a short tag for the platform engineering related topics. So, I would appreciate it if suggest something in the chat.

#platfom_engineering #hashicorp
👍63
Kelsey Hightower said that he’s retiring from Google.

So, I would like to share with an episode of the ReadME podcast with Kelsey.

ReadME is a community podcast by GitHub. So, you may also find other interesting episodes there.

#podcast #kubernetes #github
👍3😢2
VictoriaMetrics have released their first iteration of the log platform!

Here’s the info:

The first release of VictoriaLogs!

Release page on GitHub

Documentation

Docker demos

Helm Chart

Here you can find a Benchmark for VictoriaLogs

Since I’m not a user, it’s hard for me to provide feedback right away. Yet, if you use it or want to try and want to provide any feedback to the maintainers, do not hesitate to submit bug reports and feature requests on GitHub.

#victoriametrics #logs #observability
🔥9👎1🤔1
A new episode of our voice chat chat (in Ukrainian)!

This time we spoke about job related topics beyond DevOps. Specifically:

- How often does it make sense to change a job. And what does “often” even mean in this context.
- Does it make sense to grow professionally beyond the Senior level or it can be the final stop in one’s career.

You can listen to this episode on:

- YouTube
- Substack
- Spotify
- Apple Podcasts
- Google Podcasts

BTW, since I moved the audio hosting to Substack, it makes sense to subscribe there to get new episodes right after they’re published.

#voice #career #job #ukrainian
👍11
A story from VS Code developers about how they made bracket pair colorization 10,000x faster.

I like such articles, which touch topics of raw computer science. I think such stories help us to reconnect with the beauty of our craft.

Although, it won't make me switch to VS Code from NeoVim :D

#computer_science #microsoft
👍12
A system design exercise for on-premise infrastructure. The article is called DevOps Big Picture (On-Premises). However, it only explores a single example with a limited scope and a lot of assumptions. Yet, you still can use this diagram as a baseline in system design interviews, for example.

Unfortunately, data layer is completely missing there. I mean, data layer is the most difficult one, so a lot of people are omitting it on purpose. I cannot blame them for that. So, you can have a mental exercise and think about how would you manage the persistent data in the proposed infrastructure 😉

#design #kubernetes
👍7🤔6🙈1
​​Git is simply too hard.

I have mixed feelings about this article. On one hand, Git is too hard indeed. I personally google certain Git operations from time to time.

On another hand, this article doesn't provide any alternatives or ideas on how to fix this situation. Also, a lot of Git complexity comes from its distributed nature. Distributed systems are much harder to architect compared to centralized ones. Although, currently, we're mostly using Git as a centralized system nowadays.

So, I'll just add this well-known comics here.

#git
😁28👍5
UA Responders is a foundation that raises funds for tactical medicine, protective gear, and field hospitals.

And some drones, of course.

#donations #Ukraine
👍6
Handling concurrency is hard, even if it was made simple.

The Go 1.19 Atomic Wrappers and why to use them explores the sync/atomic package which was introduced in Go 1.19 and use cases for it.

I haven't used this one personally, but we have sync.Map in one of the projects to get the results from goroutines in one place.

#go #programming
👍9