[HN Gopher] No more magic, please! (2023)
___________________________________________________________________
No more magic, please! (2023)
Author : indigodaddy
Score : 26 points
Date : 2024-01-28 21:49 UTC (1 hours ago)
(HTM) web link (nickgeorge.net)
(TXT) w3m dump (nickgeorge.net)
| JackFr wrote:
| > Why is there such a strong preference for "one step app
| deployment", no infrastructure knowledge required?
|
| > The obvious answer is because it is easier.
|
| No. The answer is that it's more robust in the face of operator
| error, it's repeatable and it's auditable.
| timeagain wrote:
| A lot of these tools are created in an atmosphere of corporate
| redundancy. Sure your test framework, regional deplyments, A/B
| testing, CI, code coverage, storage infra, network infra,
| security settings, and app configurations are held in a
| 20000-line yaml-within-yaml-within-yaml disaster.
|
| On the other hand, at least they aren't hand-coded by Steve
| (who left the company last week)
| dehrmann wrote:
| A higher bus factor is nice, but there's almost certainly
| more thought and wisdom in a popular CI/CD setup than Steve's
| scripts.
| alsiola wrote:
| Came here with that exact quote in my clipboard. I have a
| medical background prior to software, and one of the key
| learnings there is that wherever there is scope for a human to
| make a mistake, that mistake will (eventually) be made. It's
| therefore crucial that wherever possible the capability of
| making that mistake is eliminated. I see automated deployment
| as falling into a similar category of utility.
| o11c wrote:
| What I find is missing from this discussion: the major advantage
| of config-based deployment is that it's relatively stateless and
| easily reproducible. Their pain point tends to be when state
| leaks in.
|
| A lot of traditional approaches are gratuitously stateful, and
| there's a lot of room for tooling improvement there even if you
| want to avoid YAML.
| randall wrote:
| cdk is so good for aws... i haven't used terriform but I'd bet
| it's just as good.
|
| Stateless infrastructure is amazing. Checking my infra into
| code is awesome.
| eptcyka wrote:
| Could you elaborate on the state here?
| duped wrote:
| I think when you see products that hide complexity and you're
| forced to "learn" them and this frustrates you, there are three
| responses
|
| - Accept this is how we make our money and that being paid to be
| the $INFRA person (replace with your infra tool or cloud provider
| of choice) is not necessarily a bad thing unless you can't
| translate that into whatever the next $INFRA is
|
| - Go build the next $INFRA and sell it to all the people like you
| that didn't like the old $INFRA (or lose everything, obviously
| this is risky)
|
| - Complain
|
| I don't think the third option is really a good strategy in life.
| A lot of the frustrating things in industry exist for good
| reasons (that more often than not, turned out to be
| bad/inconvenient a lot later) and life is too short to get upset
| at things when you're being paid to understand them.
|
| But obviously a config file is just a program and you need to
| know how to debug it when something goes wrong, and it's not
| helpful when "what does this config do" is hard to see because
| the thing it configures is intentionally obfuscated.
| 0xcde4c3db wrote:
| > I don't think the third option is really a good strategy in
| life. A lot of the frustrating things in industry exist for
| good reasons (that more often than not, turned out to be
| bad/inconvenient a lot later) and life is too short to get
| upset at things when you're being paid to understand them.
|
| On the other hand, a lot of frustrating things that could be
| fixed with a modicum of effort are neglected on the basis that
| "nobody's complained". Sure, pick your battles, but don't be so
| compliant that you leave easy wins on the table.
| wouldbecouldbe wrote:
| I love running a VPS and just controlling everything.
|
| Always feel helpless when app engines cloud, managed db, managed
| kubernetes upgrades or something else fails. Slow builds, builds
| getting stuck, upgrade issues, overcomplicated new concepts,
| cloud outages, slow support.
|
| One exception to them all is Vercel, it's just amazing. Haven't
| had any issues, fast deploys, works instantly. What a joy.
| jakelazaroff wrote:
| _> The further I get into studying deployments /DevOps methods
| the more surprised I am that the balance has shifted rather
| strongly towards configuring tools from third party
| infrastructure vendors and away from what most would call
| software engineering._
|
| This is kind of an arbitrary line to draw. You can learn the ins
| and outs of Nginx, but that's also "configuring a tool" rather
| than "software engineering".
|
| Of course, the advantage of something like Nginx is that it works
| on any Linux box, so you're not locked into your third-party
| infrastructure vendor. But most front end frameworks are
| compatible with many "one step app deployment" vendors, as long
| as you're careful to avoid any proprietary features.
| _heimdall wrote:
| In my experience we as an industry just can't stop ourselves from
| moving deck chairs on the Titanic.
|
| We swing from monoliths to microservices and back. From server
| rendering to client apps and now some bastardization of both via
| RPC calls.
|
| I've seen this happen most often due to moving too quickly
| upfront and not putting in the time to really plan for later. We
| ship fast above all else but end up with a pile of tech debt and
| a team that's built skills around those very same tools and
| patterns that are causing problems at scale. Shifting later is
| extremely tricky (and interesting if you know what you're doing),
| but you often have a team that is ill suited for the next
| architecture and paying customers potentially with SLAs that make
| migrations difficult and risky.
| kira0x1 wrote:
| enjoyed the read and agree on how intellectually boring it can be
| to do the same magic config copy paste every time. i love still
| going in and doing it my self, its just so much more enjoyable.
| albeit i can only afford to do this on my own projects.
___________________________________________________________________
(page generated 2024-01-28 23:02 UTC)