Next Stop, HashiCorp
Journal entry reflecting on past achievements and what's in store for the future. Self-assigning some Golang homework and some exploratory work into new territory.
Tomorrow, I'll be starting at HashiCorp as a Web Engineer. I'm particularly excited about this, and here's why.
In my past 2.5 years at Capsule, I started as a Frontend Engineer but quickly made my way into every part of the stack. I worked pretty diligently towards this — met all of my sprint commitments/deadlines and did a ton of coding outside of work — and was also very fortunate to have been granted opportunities to join different teams and work on a variety of projects (greenfield and existing) by my managers and directors.
I went from writing only client-side code to: (Click to expand/collapse)
- writing server-side
- writing some server-side
- writing server-side
- maintaining a multi-language AuthN/Z library (wrapper around AWS
- working with two Cloud Providers
AWS(day to day)
GCP(for an one-off MVP)
- learning how to use
kubectlto sanity-check and debug Jenkins/CodeFresh -> Kubernetes deployments/pods
- writing some
Terraform HCLfor infrastructure (following plenty of existing examples)
DynamoDBas an objectively superior alternative over the default RDS/PostgreSQL choice for a new microservice (proud of this one 😬)
- saved money (pay-per-use serverless)
- saved developer time (more mature Java/Kotlin tooling and no migrations needed)
- creating an OCR functions-as-a-service for text extraction and image cropping
- used GCP's
- used GCP's
- debugging an issue where requests originating from Java-based Kubernetes services were including duplicate
hostheaders and getting rejected by an Nginx ingress using a newer Nginx version
- enabled SRE / the entire engineering organization to upgrade and benefit from Nginx security updates
After tackling various parts of the stack, I still felt like I had one particular area that had considerable room for growth — DevOps. I never gained significant traction here, and still can't confidently say that I'd know what to expect in a DevOps role, but naturally, that makes me the most curious about it.
HashiCorp, being a company that offers cloud infrastructure automation tools like
could not be a more fitting next step.
And though I won't actually be working directly on any of those tools, being in close proximity to folks who do own those tools will be a great experience.
I've previously used
Terraform for work, but barely scratched the surface and
I've known about
Vault as it was being adopted at my previous job, but didn't
get a chance to use it personally. As for all of HashiCorp's other offerings,
I have a lot of learning to do!
Here's a fun mini-project of some Github organization data that I pulled from their V4 API to recreate the pinned repositories as seen on https://github.com/hashicorp.
The JSON data is fetched via an authenticated request inside
and passed to the
Consul is a distributed, highly available, and data center aware solution to connect and configure applications across dynamic, distributed infrastructure.
Nomad is an easy-to-use, flexible, and performant workload orchestrator that can deploy a mix of microservice, batch, containerized, and non-containerized applications. Nomad is easy to operate and scale and has native Consul and Vault integrations.
Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
A tool for secrets management, encryption as a service, and privileged access management
Packer is a tool for creating identical machine images for multiple platforms from a single source configuration.
Go do some homework
Looking at the above repos, 5/6 are written in Go so I took this as a sign that it would be a good time to start learning Go.
The first thing I googled was "go lambda function", and I learned that AWS has had an official Go lambda runtime since 2018. I guess I never noticed this.
So there were two paths I could take with this...
- Extend existing
TypeScriptAWS CDK code, and write one
- Start clean and simple, and write everything in
Go— lambda function code and CDK code
...I chose the later because I also discovered, by chance, that the AWS CDK just announced
Go support a few months ago,
so I just decided, "Why not... I'll just YEET everything in
I never noticed that
go were language options.
It's Go time 🤪!
Here's a working repository of
Go AWS CDK code to build and provision one basic Go lambda.
Here's what a barebones
Go lambda function looks like.
...to further familiarize with
- Go through the Golang tour
- Check out https://gobyexample.com/
- Make the
Golambda function do some CRUD operations on DynamoDB and/or other resources
Go, there's a ton of other new (and old) things I want to check off.
- Gain deeper understanding of Next.js inner workings
- Figure out how
- consider refactoring this site to be deployed with it so that it can benefit from SSR instead of SSG, and
be able to use other Next.js features like API routes, and
- consider refactoring this site to be deployed with it so that it can benefit from SSR instead of SSG, and be able to use other Next.js features like API routes, and
- Learn some more HCL
- Understand enough GCP and Azure to draw parallels to AWS
- Use the
- Learn about
- Figure out how CLI's like
Vaultare created and how they function under the hood
- Committing more classic algorithms to memory
So much to learn...
So little time...
Special thanks to Kyle M. 🙇🏻♂️!