The most simple way of explaining the cloud computing is storing, accessing, and processing data over the internet instead of using a traditional client server architecture.
Just because your compute is "in the cloud" doesn't mean it isn't a server, and it definitely can still be client/server architecture
Cloud provider hosted server accessed by client = client/server architecture
Interpreted language != Compiled language
You may get more traction asking in the communities that exist for those tools: IntelliJ and Docker
8GB for two separate IntelliJ projects sounds low. You could try importing both into one instance as separate "modules" so that there is only one IntelliJ instance/window.
Depending on how you are running the VM, the host may be choking it through the host OS and leading to OOM. Especially with a tool like docker.
Edit: I see you commented usage of windows, you may need to look into wslconfig
Thanks for sharing! I will need to look deeper into build kit. Containers aren't my main artifacts, unfortunately, so I am still building them the ways of old, sounds like.
I am constantly fighting for more time coding. If you were to look at my calendar, there's only ~5 hours per week of open time. My customers are our developers, however, so for the most part I am at least in meetings about code and SDLC rather than random feature refinements and such.
Be really careful when building images that require secrets for build configuration. Secrets can be passed in as build args, but you MUST UNSET THEM IN THE DOCKERFILE and then repass them in as environment variables at runtime (or else you are leaking your secrets with your image).
Also, image != container. Image is the thing you publish to a registry (e.g. dockerhub). Container is an instance of an image.
Great call out.
Definitely their products. I think things like buck2 are rad.
~~test~~
Like this ~~test~~
Edit: You said subscript not stikethrough 🤦
Although I despise their software, I do enjoy their engineering blogs, thanks for sharing.
Hi friend, sounds like you should join us over in devops@programming.dev :)
It is important, and effective, to properly track and show to teams what effect their code changes have to the system and what "their team's process" looks like to an outsider with meaningful data.
More here https://programming.dev/post/80365
Free penetration testing 📈
In my opinion, it really depends on what type of place you would want to work. There are a lot of options out there, but (specifically for SRE) "cloud knowledge" is a must most places.
I would consider someone with an SRE title more ops than dev, and wouldn't expect much in terms of writing code. I would more expect things like advanced knowledge of availablility, reliability, performance and observability on whatever cloud provider is being used. A Site Reliability Engineer is responsible for realiability of the deployed site, so it is dependent on the site/company on what the actual day to day would look like.
This isn't to say you wouldn't have a place in DevOps with your current skills. However, it may be an easier route to start more on the dev side than the ops side as, in my experience, ops are harder to learn generically because every shop has different processes and operations.
The dev side includes things like you mentioned (e.g. build/test execution/package/artifact publish/code release) and then mixes heavy into ops during deployment which then turns into SRE type stuff when the app is deployed to a real place. Often the dev side is done by people with Software Engineer type titles (potentially a DevOps team), and may even be done directly by the developers themselves.
A lot of these processes include a developer needing to execute locally as well as repeatable execution by an automated system of some type (CI). Linux and bash knowledge is very useful for these types of things, as most of the time end deployment will be on a Linux distro, although development happens on OSx or Windows.
The industry is already trying to change buzzwords, from DevOps to DevSecOps, so it is never bad to know security as well. Things like security vulnerability detection and remediation are very valuable and part of the "shift left" in terms of software delivery.
You are welcome to read my comment history to see my feelings about python in DevOps, but they are not positive, and should just use bash, unless it is actually a python shop and other people know how to use python, or else it will most likely become a security vulnerability in and of itself.