[dmitriid]

The tower of Babel that "serverless" requires to do the simplest tasks (like running tests) should scare anyone. And yet... "We deploy to cloud and then shim calls via websocket to dev machine which then shims something else while requiring individual accounts with full prod access" is magical

[8n4vidtmkvmk]

does the word magical scare anyone else or just me? anytime someone describes their feature as magical it just means black box, undebuggable. nice while it works and then god awful when it doesn't

[moritonal]

I used to describe most processes in Azure as "magical", and meant that word as dangerous. It worked like magic, which meant you had no idea how it worked. App Service Slot swapping was a good example of this, when several MS engineers couldn't explain how it worked.

Note how their docs don't give any technicals as to _how_ this tech works[1].

1. https://docs.microsoft.com/en-us/azure/azure-functions/funct...

[giaour]

> Note how their docs don't give any technicals as to _how_ this tech works[1].

From the linked page:

> Update routing: If all instances on the source slot are warmed up successfully, the two slots complete the swap by switching routing rules. After this step, the target slot (for example, the production slot) has the app that's previously warmed up in the source slot.

[moritonal]

To me those aren't technicals. Let's assume that by "routing rules" they implicitly mean IP Routing Rules. So what's swapped, the DNS name of the machines, the machine IP's are swapped or an insert into the ARP table? Does this mean that a live web-socket connection will swap to the new machine, or stay attached to the old one until flushed...

Hey, if you can make sense of it, sure, enjoy. I just know that we had a lot of issues when I used it last and would often beat our head against Kudo to try tracert to other devices to find the machine black-holing requests because the information wasn't shown in the Azure UI.

[giaour]

I've only used this feature with HTTP requests going to a function app, but my understanding was that there is a reverse proxy involved. I have an app with two slots, and both slot domains (<app name>.azurewebsites.net and <app name>-staging.azurewebsites.net) report the same external IP address. You can set up routing rules where a percentage of incoming traffic is forwarded to a specific slot, which would be hard (impossible?) to manage via DNS or ARP tables.

[tomatowurst]

I don't understand what this means, can somebody break it down?

[3np]

It's a Rube Goldberg machine wrapped behind simplified interfaces. As soon as things follow the happy path and the top-level interfaces cover your needs, it feels great. Once abstraction layers unavoidable leak, or you need to do something that was not catered for, you're venturing going down a deep labyrinth.

The OP is actually relatively simple and clean, though, compared to some other things I've seen.

[tomatowurst]

yeah that was my worry but seems like it is based on CDK so perhaps you would end up hacking that layer but then I don't know really know and I would be gambling and I really don't like it.

I'm just amazed by how small problems are blown out of proportion to sell you an elaborate contraception....like a Rube Goldberg machine which is what this feels like.

what is wrong with just using SAM or aws chalice like we've always done? even looking at Laravel vapor (problems with cloudwatch logs)....all of it seems like a rube goldberg machine of sorts and this is why aws chalice has been my go to tool simply because A) it is written by AWS team B) it just spits out cloudformation, SAM, cdk C) stages like you are used to

"magical" here means sacrificing simplicity and overloading the developer with MORE rube goldberg machine on TOP of the stress from having to do "program in AWS" imho.

[3np]

If you don't see the purpose of something adding complexity or abstraction layers, you most likely don't need it and shouldn't adopt it (yet). With the hopefully obvious caveat of some things relating to security, like firewalls and scoping capabilities. Start simple and look for solutions only once certain things become painpoints.

[zaphirplane]

There was an post a few days ago about https://en.m.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

Which boils down to if you don’t understand why then don’t replace it

[tomatowurst]

very very good principle. i have favorited. in case next time i feel like im drinking the koolaid.

also applies to the whole blockchain space.

[3np]

And as always - just because it is not the right choice for you right now does not mean it is "bad".

On the flip side, consider a small team spending hours every week doing fully manual deployments instead of automating at least parts of that.

Different people and orgs have different needs, and those can change over time. Learning to strike that balance and timing right is a hallmark of a great engineer IMO.

> also applies to the whole blockchain space.

It applies to everything. Blockchain can serve a purpose w.r.t. the security I alluded to above. Security in general is a tricky one as once you realize it's a problem, it may be too late to reconsider.