Manage identity centrally is probably referring to using an identity management system like Okta, Microsoft Identity, or hosting your own IdP and using strong hardware 2FA. You don't want people creating their own accounts manually for everything or shared accounts that everyone knows the password for (or is on a shared spreadsheet that the entire company has access to).
At this point most startups would just use Google; since they're almost certainly using Google as their email provider, and "company email" is a de facto root-of-trust even if you don't intend it to be, there isn't really a whole lot of thought that needs to go into it. It helps that they have the best 2FA stack of any mainstream cloud service.
> 1. Engineers shall be guided in all their relations by the highest standards of honesty and integrity.
> ...
> b. Engineers shall advise their clients or employers when they believe a project will not be successful.
There's nuance around how hard you should push back on bad requests and where ownership/accountability and decision-making responsibility ultimately lie but providing professional judgement/advise/opinions is definitely in bounds for engineers.
There's still differences. If you're running it in prod then the functionality has at least gone through code review and you have higher confidence what's running is what you think it is. If you run things from personal boxes there's always the risk of them not having the latest code, having made a local change and not checking it in, or the worst case of a bad actor doing whatever they want with the privileged role. But if code review isn't required or engineers have unrestricted SSH access to prod hosts then it's pretty much equivalent.
Commercial mowers do exist, for example Exmark[1] (some not launched yet) and Toro[2]. Based on the pricing I'd guess the breakeven vs gas is still >3yrs without tax credits.
And make sure your project plan includes milestones for explicitly aligning all stakeholders on definitions otherwise you'll have a big hot potato game the first time the outputs show something unfavorable.
For an example, my team owns a dozen services and they have hundreds of direct and transient dependencies. Of those, maybe a dozen or two to need work to support the new version but that's a dozen different teams that have to put the work on their roadmap and prioritize it. When the entitlement is 'devs want to use shiny feature X with hard to quantify productivity benefit' it's difficult to prioritize. When there's an efficiency benefit then things move fast because a 10% efficiency improvement means 10% lower server costs and that's easy math.
This is just the data serialization format, you have to build any other functionality yourself. We do have a pattern on a few of our APIs where there's a big fixed schema (i.e. it's just a struct and you can't do GraphQL things like following references and hydrating them into objects) and clients select the subset of attributes they want and we only return that. It's useful for reducing response sizes but the main benefit is we can pretty easily track which attributes are actually used over time. That helps us deprecate attributes with a lot less pain.
The SDKs use Smithy[1] which is tailored for defining+generating services and SDKs, Ion is more of a pure data serialization format. It's definitely niche but my org uses it in a few places and it has some nice properties that fit our case pretty well (rapidly evolving schema, most clients only care about a small subset of attributes, ability to apply multiple and different schemas based on regions or businesses).
It's the sort of thing where I'd advise exploring other options first and only using it if the whys[2] really resonate with you because it definitely comes with some overhead.
