joseph

https://cloudboss.co/docs/unobin

My original idea for this was to compile an Ansible-like playbook to a binary. I made a POC for it around 2020, and then it sat on the shelf. More recently I picked it up again following a more Terraform-like model. It compiles IaC to a binary with all dependencies included, standardized CLI options, autogenerated configs, optional visualization in the browser, and lots of other features.

To people who say just use Terraform: I do, a lot. But it still bothers me enough to try building something different.

I haven't used Pulumi heavily, but unobin code has its own syntax more similar to terraform that compiles to Go. You can drop into Go for writing libraries however.

I haven't gotten around to it yet, but it's on my TODO list to add an embedded mode so a "factory" can be imported as just another library in a Go program. As of now, it compiles to a standalone binary with the same CLI options as every other factory, so there is a uniform interface.

  Location: Atlanta, USA
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Python, Terraform, Kubernetes, Rust, Zig, any CI/CD system. AWS and GCP.
  Résumé/CV: https://docs.google.com/document/d/142HbgfYmFBUdfbKKzPvEgYC1jdFiKEvTMp67EhOxm0M
  Email: rjosephwright@gmail.com

I'm currently working on a "better Terraform" called unobin. https://github.com/cloudboss/unobin

SEEKING WORK | Atlanta, GA | Remote Hi, I'm Joseph. I have a special love for the cloud and infrastructure as code. I have 20 years experience doing development, systems engineering, DevOps, and data engineering. I've worked with companies to greatly improve uptime and profits and get their processes under control. I've worked in heavily regulated environments and helped companies prepare for major audits and become certified in frameworks like HITRUST and FedRamp.

I'm currently working on a "better Terraform" called unobin. https://github.com/cloudboss/unobin

My tech stack is largely Go, Python, Terraform, Kubernetes, Rust, Zig, any CI/CD system. AWS and GCP.

Website: https://cloudboss.co

GitHub: https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

Sometimes I do this if I want to cherry pick commits from another repo already on my machine. Add the other repo as a local remote and then I can "import" that code while keeping its history in the new repo.

I haven't used the Framework 12, but I got a Framework 13. It really is modular and easy to repair, and they give great instructions and all the tools you need. For example, I dropped mine and bent the screen while carrying it. I ordered a new screen and when it arrived, it took maybe 15 minutes to replace. But the reason I dropped the laptop was because the hinge really sucked. It swings freely. So as I was carrying it, it suddenly swung wide open and threw off my balance.

The caps lock key, which I remapped to control, got a crack in it because I use it a lot. Worst of all, it doesn't stay pressed, depending on its mood. So maybe I'm pressing ctrl-a to get to the beginning of a line and it decides to type the letter a instead.

I really wanted to like it, but alas, the quality was too bad and I won't buy another one.

  Location: Atlanta, USA
  Remote: Yes
  Willing to relocate: No
  Technologies: Go, Python, Terraform, Kubernetes, Rust, Zig, any CI/CD system. AWS and GCP.
  Résumé/CV: https://docs.google.com/document/d/142HbgfYmFBUdfbKKzPvEgYC1jdFiKEvTMp67EhOxm0M
  Email: rjosephwright@gmail.com

SEEKING WORK | Atlanta, GA | Remote

Hi, I'm Joseph. I have a special love for the cloud and infrastructure as code. I have 20 years experience doing development, systems engineering, DevOps, and data engineering. I've worked with companies to greatly improve uptime and profits and get their processes under control. I've worked in heavily regulated environments and helped companies prepare for major audits and become certified in frameworks like HITRUST and FedRamp.

My tech stack is largely Go, Python, Terraform, Kubernetes, Rust, Zig, any CI/CD system. AWS and GCP.

Website: https://cloudboss.co

GitHub: https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

SEEKING WORK | Remote

I have 20 years of experience in software development, infrastructure automation, and CI/CD. These days I mostly write Go or Python, but I’ve worked in a range of languages as needed.

Strong Linux background (and other Unixes), AWS experience going back to the early days (when the CLI was a JAR), with time spent in GCP and Azure as well.

Open to interesting problems and even boring ones too, especially if they touch infra, automation, or systems engineering.

GitHub: https://github.com/cloudboss, https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

SEEKING WORK | Remote

I have 20 years of experience in development, infrastructure automation, and CI/CD. I'm a polyglot but nowadays I default to Go. Most of my time is spent on Linux and I have experience with other Unixes as well. I've been an AWS customer since 2006, when the cli was still an executable jar, and I have experience in GCP and Azure.

GitHub: https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

I've been working on https://github.com/cloudboss/easyto, a tool that converts docker images to EC2 AMIs.

I've also written some Terraform modules that deploy machines from images created with easyto.

One is https://registry.terraform.io/modules/cloudboss/airport/aws, for managing Concourse CI.

Another is https://registry.terraform.io/modules/cloudboss/tailscale-su..., to quickly spin up a tailscale instance in a VPC.

SEEKING WORK | Remote

I specialize in infrastructure automation and Kubernetes. I'm a polyglot but nowadays I default to Go. Most of my time is spent on Linux and I have experience with other Unixes as well. I've been an AWS customer since 2006 and have experience in GCP.

GitHub: https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

This is kind of a problem with non-paid support I think. I had an AWS account with some credits that were going to expire and decided to use them to spin up a bare metal instance. My account was immediately flagged and I got locked out. I finally managed to reach someone who made me jump through hoops changing my password and rotating my API keys. It still took a few days before I was able to log in again, and by then my credits were expired. Luckily I wasn't doing anything important in my account, but someone running a business would have been screwed.

It's not that. We don't want to switch shell syntax between workstation and server, for example. The fish users I've known moved very slowly when they had to hop on a server, or build a new container image where it involved a 'docker run' into the shell to test it out. If you know bash or sh well enough to do those things quickly then there is no incentive to use fish.

I use bash and also have no patience for configuring tooling. Your fish dotfiles are more complicated than my bash ones. I used to work on a team where many of the other engineers used fish. I never saw it doing anything I couldn't do in bash, although it looked a little fancier. But the annoying thing was when they asked me for help, and none of the commands I gave them worked in fish. It made for very slow troubleshooting sessions.

How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.

I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.

I have a small amount of experience making cheese, and have only made it with pasteurized milk as it is not easy to find raw milk where I live. However, in the US at least, there is both pasteurized and ultra pasteurized milk. Pasteurized uses a lower temperature for a longer period than ultra pasteurized. The vast majority of milk in the US is ultra pasteurized. My understanding from reading articles on cheesemaking is you can't really use it to make cheese as the curd doesn't develop correctly. While I haven't made cheese with raw milk, there is no doubt it tastes better than processed milk. I know because I worked on a dairy farm when I was young, and used to drink it practically straight from the cow. I did get sick once though, so it's an actual risk.

Always talk about a second application. For each abstraction, the “app” is the layer above it. For example, a filesystem is an app for a block device; TCP is an app for IP. You should be able to describe the functionality of a layer without ever referring to the specifics of the app (e.g., you don’t need to know what a file is when talking about an SSD’s internals).

This is so true. It’s very common to see infrastructure being built in terms of the application that will run on it instead of designing the application to run on the infrastructure. A lot of brittle, unmodifiable messes are the result of this.

When I was a kid, I watched a slug eat a dandelion leaf. I could hear the snap as it took each bite. I hadn't really thought of them as having mouths before. I must have imagined they somehow absorbed their food through all of the slime. It was also a revelation as I'd seen so many of those leaves with holes in them and suddenly I knew how they came to be that way.

SEEKING WORK | Remote

I specialize in infrastructure automation and Kubernetes. I'm a polyglot but nowadays I default to Go. Most of my time is spent on Linux and I have experience with other Unixes as well. I've been an AWS customer since 2006 and have experience in GCP.

GitHub: https://github.com/rjosephwright

LinkedIn: https://www.linkedin.com/in/rjosephwright/

SEEKING WORK | Remote

Your toolbelt is full of Docker, Kubernetes, Terraform, and Istio. They were supposed to help you, but you're still overloaded with Toil. I can help get your Infrastructure as Code under control and help make machines do most of the Ops, so you can focus on your business problems.

I'm well versed in IaC tools like Terraform and Ansible, general purpose languages like Golang, Python, and C if necessary, and I know when to switch between them. I treat cloud infrastructure as a software problem, because it's fully programmable. I make a point to layer code so most of the effort can be focused on a development cycle that doesn't break production; changes get tested before rolling them out,and an automated pipeline applies actual production changes.

I started my career on bare metal Linux and FreeBSD systems, then moved into AWS and later GCP. I love working in the cloud and on lower level things like firecracker VMs on bare metal.

GitHub: https://github.com/rjosephwright LinkedIn: https://www.linkedin.com/in/rjosephwright/

I was referring to how and where we store it. Feel free to email me if you have more questions.

It also defines the state in a standard way, toggles CLI configuration if it is present in the root module, and does some validation.

For me there is a benefit in having a single abstraction layer, the Terraform root module, to make IaC changes, and specifically one that is in the form of data rather than a script. The data incidentally contains everything required for reproducibility (all dependency versions are pinned, etc), and it always calls only versioned modules that are published independently. There is one Terraform wrapper script that runs from CI/CD and it is the only script, no matter what kind of change is being made, Kubernetes or otherwise. Teaching someone how to make a change is easy, they just need to make a change to the data and apply it. If the data layer doesn't support the necessary change, then work can be done to add the capability to one of the modules and then publish a new version. For simple needs this might be overkill, but in my environment it helps to keep things from getting out of hand. Helm and Kubernetes are abstraction layers, but very specific ones, whereas Terraform is a generic one that ties it all together.

I made a small example at https://gist.github.com/rjosephwright/f1485cddcc12dd651ec965.... There is no YAML, I use HCL for values as they are easier to validate and less error prone, then convert them with yamlencode().

I do manage Kubernetes with Terraform. I'm not a fan of Helm, however it is useful due to the community of available charts. Since I use Terraform to manage most everything else, I typically wrap the chart in a Terraform module too. This lets me do other things I usually need, such as creating IAM roles or other associated resources that the chart requires. Sometimes this means using the Kubernetes provider to add something needed by the chart, for example pulling a password from SSM or somewhere and creating a Kubernetes Secret from it.

The benefit is being able to build full stacks with only Terraform without needing to orchestrate multiple tools together. Building the cluster itself is done with Terraform, as is deploying the charts and other resources I need to build a "base system", all from a single root module. This also simplifies CI/CD as I only need a simple template to run IaC jobs and they all follow the same pattern of just running Terraform and not much else.

I don't have Azure experience but AWS Lambda is overcomplicated for REST APIs IMO. One reason is each function now has a deployment instead of just one deployment for the application. Frameworks can simplify it, but they don't eliminate all the moving parts. Lambda is great glue for filling in gaps in AWS itself.

Serverless can also mean something like EKS with Fargate. You get to use Kubernetes without managing any servers. Azure AKS has something similar with virtual nodes as I understand, though I haven't used them. I do think this model is better for long running services than serverless functions.

I've thought the same, but reading your comment made me realize it's probably the wood.

https://imgur.com/gallery/TpA1e