Civics Review #492:
The First Amendment does not constrain people or companies. Only the government can violate the 1st amendment. Or any of the other parts of the Bill of Rights, for that matter.
This is not a sophisticated constitutional theory, rather basics civics from middle school social studies.
“anyone can buy a family size bag of chips, they literally never check”
infra is a misleading term for cloud things
infra used to mean mostly physical things “irl-infra”
irl-infra is the domain of operations
creating a storage bucket in AWS is not really infra, “cloud-infra”
By calling the services ecosystem you create in a cloud service “infrastructure,” you have planted the idea that the creation, care, and feeding of these services is in the domain of those who traditionally “have root,” are the only ones who can restart a VM, and optimize the mechanisms for backing up servers.
Infrastructure-as-code is tongue-in-cheek, since the phrase is intended (among other things) to highlight the shortcoming of using that term when talking about cloud-infra.
“cloud infrastructure”?
Maintaining separate career ladders for technology and management professionals provides a number of benefits, key among which is helping organizations recruit and maintain the best IT talent.
The Conference Board’s survey of global CEOs highlighted “Failure to attract and retain top talent” as organization’s number-one obstacle. Many organizations feel the pain. Some have started taking useful steps.
The traditional model for an IT career path is one charted something like this: Work in a technical support or generic junior programmer role. Work to advance to a developer or engineer role. Make the final step to architect, arrive at the technical dead-end, and then move into management in order to move up.
But the success factors for management are rather different than those for technical contributors, and conflating their paths is fraught. (We can skip for now the conversation about how an architect is not simply a more experienced developer/engineer– an equally widespread mistake but a separate subject.)
The result of this misaligned career funnel is that smaller or less-optimized organizations end up with unnecessarily technical management and restless and frustrated senior technical teams. A colleague in the tech community who is an IT Director related to me the concerns he had about a set of shell scripts he authored and is known to help rack and plug in servers in the data center. There is no harm in leadership being able to code, pitching in, and knowing where things are plugged in, but there is something wrong if this sort of thing is commonplace. To wit, management with widespread login authorization is a worrisome sign.
To counter the broken historical model, organizations have recognized the need to fix the career funnel. In reality, many of the finest IT managers can’t write a lick of code. That’s a feature, not a bug. Managing people and software engineering, for example, are are skill sets that simply don’t overlap much. If you hire good technical teams, Managers and Directors can look to those team for technical answers instead digging into the details, which wastes critical management bandwidth. Technical people need their management to be management.
So how are organizations fixing this? Both Oracle and FedEx have an HR “grade” which contains both some managers and some senior technical staff, under the modifier “principal”. This prevents the “Technical Principal” or “Principal Architect” from thinking that becoming a manager is the appropriate or necessary next step on the career ladder. Or just being annoyed and chasing pay elsewhere. Or chasing startup adrenaline. Or…
As a step beyond, the FedEx “Technical Fellow” position is more senior than starting managers. Next? Fellows can advance to a “Technical Director” position, and report to the CIO.
At this level, the Technical Directors and Managing Directors can look to each other as peers (and HR-grade equals). Obviously, there are not a lot of these positions, even in the largest organizations, but a path to positions that report to C-level executives is a successful career path strategy for some top companies who have embraced it.
Employees care about career advancement. The danger is that they care enough about it to follow the awkward paths they are forced into. Organizations who do not adapt to this reality will always fail to attract and retain top talent.
Some additional thoughts elsewhere… www.mckinsey.com/business-…
Regardless of where your code runs, there are benefits to using containers during the development process itself. You might think you need a development VM, or that you are on a Mac, and you know the runtime will be Linux and consistency would help. Or all the modules or libraries or tools that you install will conflict with the versions on your laptop, or that you will lose track of all the stuff you installed when it comes time to take another step towards production.
Getting you feet on the ground with using Docker simply as a development environment should not take more than a few hours, but if you are like me, you have only random slices of time to think about or work with unfamiliar tools. The intent here is to give you a little slice towards the whole pie.
Step zero is to install Podman (or Docker CE). The two are roughly interchangeable, so either will do. If you are using Podamn, create a symlink so that you can use others’ docker-based examples transparently.
On macOS…
brew cask install podman
On RHEL8, Podman is available be default…
sudo yum module enable -y container-tools:1.0 sudo yum module install -y container-tools:1.0
For other platforms look here.
Start an example centOS host the verbose way…
docker run –interactive –tty –rm –name cent centos bash
…or the short way…
docker run -it –rm -n cent centos bash
You will drop into a root shell of a container instance. Prove it to yourself with…
yum install git
Anything you do in this environment will disappear entirely when you exit. That may seem to make this config far less useful, but not only is it useful, it encourages some good practices and you can change that behavior if you need.
Principles that this practice encourages:
The server/vm/container you are using does not matter, and should be thought of as disposable. [ Ephemeral Infrastructure ]
The server/vm/container you are using does should not even be changed. In fact, it is better if it is a read-only environment when it goes to production. [ Immutable Architecture ]
Also…
You can still bring data and config in, write it to databases externally, remote syslog, etc., even if you treat the environment as ephemeral.
You can run it as a persistent container that can be started and stopped. Not a big deal during development, but the closer to prod, the more beneficial it gets.
If everything is smooth up to that point, you have a sandbox to play with.