Hacker Newsnew | past | comments | ask | show | jobs | submit | zgoldberg's commentslogin

Gruntwork outlines four different "IaC Topologies" for managing terraform state at scale, including the "Terralith", workspaces, multi-unit and Stacks.


Gruntwork is and always has been a 100% remote company, and over the years we've learned a few lessons about running efficient engineering meetings. Some key ideas:

- Collect information in parallel - Store topics in a permanent database to be revisited with timestamped updates - Use synchronous time for high-bandwidth conversations, such as conflict resolution or information-gathering

We've modified stand-up so much that we use new name: Café

What do you think or your team's stand-ups? Would you try a Café?


OpenTofu is now more secure (state encryption), maintainable (early variable evaluation), and powerful (provider iteration) than Terraform. This is the advantage of being truly open source, foundation-managed, and community-driven.

Now is a good time to make the switch!


OpenTofu with v1.9 [0] has for_each for providers, something that HashiCorp blocked me on their GitHub, because I kept insisting for them to implement it and they kept giving excuses! One of my points there they didn't like is that instead of improving Terraform and Terraform Cloud so that it can AT LEAST run their own CDKTF, they invested time in GUI development and other useless stuff.

They also implemented the proprietary Terraform Stacks, which only work in their overpriced product now rebranded to the ridiculous HCP Terraform!

So, kudos to OpenTofu, not only is it free and fast-moving, but it now has unique features, which we were begging HashiCorp for during the years and they neglected even requests from paying customers!

Another unique OpenTofu feature is that you can use variables in places you couldn't with Terraform, for example, in the backend config. Of course, HashiCorp didn't care about that, because you don't need that if you use their paid product!

I totally understand that HashiCorp needs to make money, but they switch to BUSL, because their competitors such as Spacelift, Scalr, env0, and others were offering better and sometimes cheaper offering. Yeah, "sometimes", because some of them came out to be more expensive than even HCP Terraform, unfortunately.

The switch to "terraforming under influence (of RUM)" that HashiCorp made is a sign of disoriented greed! Basically, it pushes you NOT to use Terraform. For example, I terraformed GitHub repos. So, after their switch of pricing model, I had to pay for every GitHub repository label, for thousands and thousands of niceties, which with the RUM (Resource Under Management) turned every label to costs us money, which easily accumulated to tens of thousands of dollars!

[0]: https://github.com/opentofu/opentofu/releases/tag/v1.9.0


Gruntwork | GoLang Engineer, Marketing Manager & Sales Engineer | REMOTE (North American Timezone) | Full-Time | https://jobs.ashbyhq.com/Gruntwork

Gruntwork (gruntwork.io), the company behind Terragrunt, Terratest, Boilerplate and more is on a mission to transform the way DevOps is done. We are globally recognized both for our open source tools used by thousands of companies from startups to Fortune 500s, and our thought leadership on how DevOps should be done.

We're actively hiring 3 roles

Senior GoLang Engineer for OpenTofu - https://jobs.ashbyhq.com/Gruntwork/a6b852e6-2ab6-4eaf-b643-3...

Senior Product Marketing Manager - https://jobs.ashbyhq.com/Gruntwork/cd52f63a-aaf8-43a4-9c33-a...

Senior Sales Engineer - https://jobs.ashbyhq.com/Gruntwork/48a3b31c-ccfa-49b1-a553-f...


IMO you should place your salary range on these posts.


Thanks aaomidi! We have ranges up for 2 of the 3 roles, we'll get one up for the third shortly!


Good feedback! I was trying to get at the idea that DevOps is broad, its often invisible and its therefore often undervalued/underprioritized. I'll have another go trying to convey that.


Thanks for putting this together! I read the rest of this section and it seems solid, the into however does read like you’re suggesting to compartmentalize “devops tasks” which I think is antithetical to the original idea


the problem with the "original idea" is nobody can decide what it actually means.

The interpretation that I see banded about comes from the 10+ deploys a day talk from flickr, where they said having a team of diverse backgrounds was better than having an individual.

Somehow in that zeitgeist sysadmins got rebranded devops, so in that case it makes sense to have a "devops engineer".


We know for sure it never meant “rebrand your sysadmins as devops/platform team and be done” that’s just how middle management tend to interpret things. They did the same with agile = scrum


It’s the same as agile and communism. They’ll claim till the end of time that no one has implemented the truest version of it which would solve all of everyone’s problems with magic


Just read through your twitter thread, I really appreciate this perspective and I completely agree, a manager's job includes ensuring the right circumstances to foster intrinsic motivation. I think where I might quibble is there are often circumstances where there are genuine skill gaps and, a manager acting as coach, can accelerate someones growth and performance.


Sure -- but why drag the entire organization through a perf process to accommodate those folks? Especially when they are tied to comp, performance review processes are (in my experience) about justifying decisions that have already been made rather than actually earnestly trying to improve an employee's growth: decoupling review from comp and then additionally not having a one-size-fits-all review process allows that coaching and mentoring to go where it's most needed -- and it similarly allows for positive feedback to happen much more quickly, broadly, and earnestly.


Thanks! Fixed.


If you’re looking for that sort of feedback: leadershp->leadership in the repo description


I'll never turn down a pointer to a typo; fixed, thanks!



Ok, I’ll offer some format and spelling fixes.


Author here!

Such a book can't be written by one person alone, but this could be the kernel of such a book

Completely agree, and that's my dream for the book.

Should be named "Software Startup CTO's Handbook"

I struggled a lot with the title -- good point that it lacks the specific software reference, that should be perhaps be incorporated somehow. "Startup" as well as also important to me, as I agree, size matters and changes how you evaluate trade-offs. Implicit in the word "startup" is that time is your most valuable resource, and much of the advice in the book is based on that assumption.


These days the language has become so debased that any new business or small business is called a “startup” (and of course they have to be “tech” startups even if they just sell organic oats online — real example).

I’d set the ground rules up front so people who don’t want a high-growth business (and I see complains about that on this site which is fine) can stop reading. Likewise if your business doesn’t need the CTO function (even if they are still a four-person startup) then you can stop reading.

If your dream for your book is to be about tech startups (in the actual meaning of the two words) I’d partner up with someone else from a different domain relatively soon, then expand the scope again after you’ve got edition 1 done. And call it the “Tech Startup CTO’s Handbook”. What about the folks making semiconductors?


Appreciate the feedback. I think you've nailed something with the phrase "Tech Startup", feels more precise and universally understood/aligned with what the book is about.


Lottery.com | Backend/Fullstack Senior Software Engineer | San Francisco, CA | Full-Time | North America Remote OK

Contact us at: [email protected]

ABOUT LOTTERY.COM

At Lottery.com we’re assembling a world-class team of brilliant minds, resourceful doers and creative problem-solvers with a ‘find a way or make a way’ attitude. Founded in 2015 and based in San Francisco, California, Lottery.com is creating the next generation of lottery ticket sales & ticket management systems. We make buying and redeeming lottery tickets more convenient, secure and intelligent through our mobile application and online platform. We look for candidates that demonstrate what we call the “three Is” -- Intelligence, Integrity and Intrinsic motivation.

ABOUT OUR ENGINEERING TEAM

Our engineering team powers our entire product, both for our users and internal operations team. Engineering at Lottery.com is divided into several squads, each on the smaller side at 5-6 engineers. We bias towards passionate engineers who bring experience, well reasoned opinions and a variety of perspectives to the table. We encourage honest debate and emphasize concrete, forward-thinking solutions. We operate on a weekly schedule, have regular internal demos/tech talks, and a weekly retrospective. We’re experienced and confident but have no ego, we’re open minded and constantly looking for ways to improving ourselves and our processes.

STACK

NodeJS, Heroku & AWS, RabbitMQ, MongoDB, Serverless, Microservices

RESPONSIBILITIES

Design and implement key components of our technical infrastructure, including services supporting payments, lottery results, user management, ticket facilitation and more. Take ownership over mission-critical functionality that is consumed by our mobile, web and internal applications Work as a team with your peers, collaborating on architecture, mentoring teammates and pushing our entire stack forwards. Partner with sister squads, including frontend, growth and product teams on delivering a seamless experience across the board. Stay up to date on the latest innovations in our industry and in our tech stack. Help us push the boundaries on what a small team can produce and maintain with simple code and well thought out architecture.


This might not be clear from the ad but the Lottery.com Backend Team is currently 100% remote! An amazing company to work for if you love working remotely yet collaboratively.


Ah! Good point! A complete brainfart on my end. Definitely should've included javascript as an example.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: