To me, it's not the time - but the energy. I have about 4 solid "mentally productive" hours in a day that use up the majority of my mental brain energy. Trying to cultivate that energy to do a side hustle after kids are asleep is the real challenge.
For sure, you're only going to have a few hours of 10x productivity, but you can still get something done outside of that optimal time interval.
I've been kinda weaseling lately and just working on my startup during my best hours before work. Mr. Fangman will be satisfied even if I just "meet expectations", and I'd rather put my best efforts into something that can pay off bigger than a 5-6 figure yearly bonus
> Product teams painstakingly craft their product specs to ensure they're building the right thing. Unfortunately, the pace of modern product development is so fast that the minute a product spec is written, it’s no longer relevant.
I think the missing insight is that while the final outcome is no longer relevant, the process of reaching the outcome is critical! When I am trying to understand a feature, I find myself spending most my time in the version history of Google Docs (something that team has treated as a secondary feature) – learning how the feature team's collective understanding has evolved. I think Decisions in Fable is a step closer, but not far enough.
One thing I would love to see is product spec editing / collaboration focused around version history. The real "work" of building product specs is building shared context between PM, Eng, UX through evolution of the requirements. However unlike devs who can see the diff of a code file, PM rarely "show their work" – and it makes it hard for everyone to see how the final requirements were reached. I still haven't seen any PM tool with this paradigm in mind.
This is a great point. It's particularly useful to have that context into how the thinking evolved when you're looking back at a feature built months or years ago, to help you avoid doing something that was skipped in good reason OR make the same mistakes again.
We agree our decision feed is just step one to get there, we're also exploring other ways to show the evolution of work.
Relay is like Zapier for DevOps teams. We're excited to launch our integration with PagerDuty to streamline incident response. Our goal is to make it super simple to compose automation workflows for automatically remediating issues while you figure out the root cause so you can prevent it from happening in the future.
Relay is an event-driven DevOps platform. It listens to events from 3rd party services like AWS, Datadog, PagerDuty, Jira and more to trigger simpler, smarter workflows that automate tedious tasks. A lot of existing solutions either require a lot of upfront DIY work (AWS Lambda or running your own script) or they weren’t built for DevOps teams (Zapier, IFTTT).
Relay provides out-of-the-box workflows for common use cases like cloud cost optimization, security, incident response and more. If those don't work for you, you can write your own workflow using integrations with dozens of cloud provider services, open source tools and APIs that can be composed together in a YAML-based workflow (yes, I know, more YAML).
Some features we think are interesting:
- Visual execution graph shows exactly what's happening in your workflow run.
- Connections make it simple to authenticate to other services.
- Audit log shows who initiated every workflow run, whether manual or by an external service.
- Human in the loop approvals give you full confidence in your automation.
- Growing community of 30+ open source integrations with AWS, Azure, GCP, Datadog, PagerDuty, VictorOps, Jira, Terraform, Helm, and more.
Looks great! "Zapier for DevOps" would convey it a lot faster. It didn't click for me until I got to that part. I'm excited to try it out!
A couple things:
1) Please, please support some other config file other than just YAML. Even JSON would be an improvement, since you wouldn't have to change your config reader library. YAML has been a miserable nightmare to use in other tools like Open API Spec. I'm not alone in my YAML hate, either[1][2][3][4].
Implicit typing and semantic whitespace in a data file is insane. At least in Python, you're not unlikely to get an error if your whitespace is off. In a config file, you might just end up with dangerous/confusing behavior.
2) I'm surprised you used Relay, which is already used by Facebook. I don't think Facebook is going to care that much, but it's going to be really hard to Google this library.
> 1) Please, please support some other config file other than just YAML.
Although we don't directly advertise it, you can in fact write a workflow in JSON and there's an underlying JSON interchange format that is authoritative in our system. We expect that any other languages we support would "compile" to this JSON format. What other languages are interesting to you? We've looked at CUE[0], HCL, and of course Puppet itself.
I think the YAML hate is a bit exaggerated. It's not perfect but I would rather write out YAML than JSON or XML.
Besides it seems like this company (Relay) has gone to the effort of making a VScode language extension, which enables autocomplete and syntax checking in the YAML files. Which is cool.
FWIW we didn't make a separate extension, it uses the vscode-yaml extension from Red Hat, you just configure it to associate certain filetypes with our json-schema and custom tags. It is awesome for sure.
(When) Is a self-hosted version coming? Does Relay use Lyra in some way, or is it a brand new engine?
The usual DevOps automation web systems like Jenkins, GoCD, Rundeck are all disappointing in one way or a dozen. Java, to start with. I'm desperate to see a modern, full-featured, self-hosted alternative.
On-premises support is in progress. No release date yet. That said, would you need it to be fully self-hosted or would it be viable to have an on-premises agent?
Relay uses Tekton under the hood to run workflows and Knative to process triggers. What kinds of workflows are you thinking about running?
Fully self hosted is a requirement in my case. Letting an agent that's essentially externally controlled would be a hard sell in corporate environment.
In my case, I need very simple workflows that e.g. run Ansible playbooks, or do non-urgent monitoring, bookkeeping, and essentially trigger scripts. I usually need a single step - no serious need for a pipeline/workflow even. Cron job and manual triggering would be enough to cover the base usage (though git hook would be next on the list).
The more "convoluted" part that I'd want to see is a capability of jobs controlling themselves (e.g. job disabling itself or others on error), jobs as code, flexible notification system, and make it easy to deschedule/disable jobs in bulk, easy to extend with plugins.
Granted, Rundeck has most of what I need, but the implementation is Java, which also includes its SSH functionality.
What made you go for yaml rather than your own DSL? For a service that's as programmable as relay, it seems nice to have better support for branching control flow for example.
Hey there, I'm an engineer on Relay. Our PM is busy so thought I'd jump in here.
Great question on why we went with YAML instead of our own DSL. The main reason is, really, YAML has become a bit lingua franca for managing configuration of tools similar to Relay. We wanted to keep Relay simple and make it as familiar as possible. So YAML was our go-to choice.
We have some control flow primitives that you can configure but to do really complicated logic we figured it's best to push that in to the steps versus the configuration (there by keeping the configuration simple). Here's a link to our (very simple) conditional execution docs: https://relay.sh/docs/using-workflows/conditionals/
It varies. We have a primary PostgreSQL database for non-sensitive data including some workflow configuration. We store sensitive data in Vault and logs in Google Cloud Storage. A bit more info here: https://relay.sh/docs/how-it-works/#where-and-how-is-my-data...
I'm happy to answer any questions about our storage and security architecture too!
Senior PM at [Open Source Enterprise Software Company]
Degree in EE --> Internship as Program Manager at Microsoft --> Moved into enterprise products --> Moved to smaller company for larger scope.
Unlike development, it's quite difficult to create small assignments for product managers that is not trivial except at large companies. A key skill in PM is being able to see the complete picture (i.e. Market, Industry, Company, Organization, Team, Person and the interactions between all these different groups) in order to make the right trade-offs for a product.
The best advice I got was from a panel done by Scott Wiltamuth (then PM director of VS) who mentioned that PM is an apprentice discipline. The only way to learn is by sitting and watching someone else who is very good at it and learn from them.
reply