I am sorry, but if you need someone else to provide you with a list like that, you should NOT be doing this. It is the wrong approach on so many levels.
Maybe I should clarify why. I am a full stack engineer and I am familiar with the basic AppSec stuff you need to launch a service at a FAANG company. However I am not familiar with the basic IT Security stuff you should setup when forming a new company. When I was researching what I should setup for IT security the documentation began referencing things like DMARC, DNSSEC, DKIM etc. and I realized I don’t know what is the basic level of security I should setup.
So I just want to know what is the basic security stuff an early stage company should setup before hiring their first security engineer. The answer to this question can’t be “you should NOT be doing this” because you should still need security even before your first security hire or before you can afford a security consultant.
I run several Arch boxes, a couple I believe is on 15+ years. One such installation has even been mirrored from one disk to multiple other disks and put into other machines, just because it was already set up as needed. Only once did a package I ran require manual intervention during upgrade, but as always, that was clearly described on the Arch website.
No. It adds nothing but unneeded complexity to the stack. Learn how to package your software and use the package manager. You can combine that, if you must, with any kind of config manager like Ansible or something else.
So many companies are doing what's "trendy and shiny", and it can almost look like it is becoming a de-facto standard, but they will eventually realize the mistake.
Learning ansible in 2022 would be what's a waste of effort as every company that I know is phasing it out in favour of immutable infrastructure via OCI images.
It's been 7 years. Kubernetes isn't trendy or shiny. The teams using it use it because of legitimate reasons.
Ansible is not a waste of time. It's a tool for a certain set of tasks.
I learned Ansible in 2021 after mainly having used Kubernetes, Helm and Terraform at work.
I did that because I needed to deploy self-hosted Kubernetes nodes, virtual machines and VPNs; while there are Terraform providers (drivers) for open-source hypervisors, you still need to get your OS from vanilla to installed-and-configured. Ansible does that.
And yes, you could build install images and deploy them directly on your hardware. But with certain non-cloud datacenters, the pick-your-image option is sometimes limited. Being able to pick some preferred vanilla image and run the same commands to get the same node up and running is just so easy to experiment with, and it works even before your image registry server is up and running.
I'm not sure how you can replace your infrastructure with an OCI image, provided that OCI image means a container image?
I don't think Ansible is a waste of effort. For example, we have OpenStack images that we spawn, but use Ansible to have repeatable builds of those images. Additionally, you can learn enough Ansible in a weekend to be dangerous. IMO the payoff is there, it's a very simple yet effective framework, depending on your usecases.
I cannot believe how big of a monstrosity systemd has become. It started out as an init system and was promoted as such and I started out liking it. Then the wording suddenly changed to "a suite of basic building blocks for a Linux system", then came the hardcoded DNS servers, then the shitload of bugs that has been ignored since about 2015. Now instead of fixing what's broken and making things more secure, more and more cruft keeps getting added.
> We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option. (Doug McIlroy).
We keep things as close to the bare metal as possible and avoid complex layers as the plague.
We have only negative experiences with frameworks and big layers. They solve problems quickly in the beginning, but they always end up causing problems. Years later, debugging strange errors, security issues, etc. The more layers you add the less useful and good the application becomes.
we use the standard library and a couple of slim and well written external libraries, such as sqlx and go-sql-driver.
I have written my own HTML form validator and custom error handler - once you get that done, web development in Go becomes MUCH easier.
We don't use ANY JavaScript on the front-end unless it is a minor custom enhancement to the UI (it must be able to run without). Everything is pure HTML and CSS.
However, I personally do find the HTML templating tedious, but I have always found templating stupid and annoying, this is not specific to Go. I prefer to write HTML inline in PHP (when I do PHP) i.e. the old fashion way. I hate templating in any language!
It's easy to make mistakes in Go HTML templates, make sure you test that part of your code well!
Writing big web applications from scratch is great though, and it's really fast in Go, faster than PHP, as long as you do it right! Documentation, documentation, documentation. Anyone who inherits your code, whether you're alone or on a team, needs to know and understand your thinking and rationale.
The main reason why projects fail when they build tailor made software is because of laziness regarding documentation.
The correct way is to regard missing documentation as a bug! Write the documentation WHEN you write the code. If you change the code, change the documentation right away, when you can still remember what you're doing and why - this is the most important part and why so many code bases are horrible to inherit. Missing or poor documentation.
Never use "clever" code, make code that is easy to read and understand. Don't worry too much about design patterns and philosophy, they mostly belong in the books and in theoretical discussions!
Web development in Go is not for everyone, it requires experience and thoroughness. The build fast, deploy and forget strategy - that most people use these days - doesn't belong in Go.
Go will reward you in the end with really good performance and very easy future maintenance. Nothing suddenly breaks because a third of the standard library has suddenly been changed in the next version upgrade, such as with PHP.
