
IAM Is The Real Cloud Lock-In - forrestbrazeal
https://forrestbrazeal.com/2019/02/18/cloud-irregular-iam-is-the-real-cloud-lock-in/
======
013a
The only people worried about vendor lock-in are people who have practically
nothing of value to be locked-in. "Lambda is horrible for lock-in, once you're
hitting billions of invocations a month you're going to wish you could cost
optimize by shopping around with other providers! I've got my personal website
hosted there, it gets a dozen hits a month, sure glad I'm inside the free
tier."

I've heard CTOs/CIOs of large companies express concern over it, but at the
end of the day they'll sign that $100M contract with Amazon or Azure. It
doesn't actually matter. Its a _concern_ , but its not going to stop the sale
or development.

Today, if you're not locked in, you're leaving business value on the table. I
hope that changes in the future, and maybe Kube will be the standard platform
we've needed to push it forward (for example, I wish I could tell kube "give
me a queue with FIFO and exactly once delivery", it knows what cloud provider
you're on, if you're on AWS it provisions an SQS queue, if you're on GCloud it
errors because they don't have one of those yet, and in either case I
communicate with it from the app using a standard Kube API, not the aws-sdk).

But for now, lean in. Don't fight the lock-in; every minute you spend fighting
it is a minute that you should be spending fighting your competition.

~~~
cosmodisk
Vendor lock-in isn't something anyone, especially at C-level should be
ignoring. Yes, there are things to be gained and money to be made,but one
should always have some sort of alternative,just in case. I happen to be in a
business,which 100% relies on one vendor,which keeps hiking up prices every
year way above inflation.

~~~
fnord123
There are loads of orgs trying to get off Oracle as we speak.

~~~
jessaustin
Lots of people were already trying ten years ago, and had wanted to try it
twenty years ago!

~~~
dvtrn
Is "migrating from Oracle" the Enterprise equivalent of nuclear fusion? We're
always 20 years away from production nuclear fusion, Enterprises are always a
few quarters away from migrating out of Oracle %list_your_appliance_here%?

------
xrd
It's a back and forth. You get excited about building lambda functions and are
surprised at how easy they are, and how much autonomy you have as a developer.
Then, you try to deploy them, and realize you have to file 14 tickets to get
the correct IAM settings setup for your production function. No one knows all
the permissions you need, and the only way to understand is to try one, see if
it works, and what other services you need access to. And, it'll kill all
sense of autonomy you had a few hours prior.

~~~
snypox
I wish people would speak about this problem more. I can’t tell you how many
times I need reiterate certain things with our DevOps team to get the proper
permissions because I can’t seem to get it right the first time.

~~~
scarface74
So you didn’t test it in a dev account first?

~~~
xrd
If the dev account role has different permissions, it doesn't matter. Of
course (s)he tested it first in a dev account. The point is the context around
roles matters much more than the code that runs inside it, a critical flaw of
AWS. Fairly, this problem is definitely not just limited to AWS but I find
their implementation particularly poor.

~~~
scarface74
That’s still the issue.

You should have a custom role for each set of lambdas that make up a service.
Your role and your lambdas should be in the same CF template that can be
deployed together. Security best practices is for the role to have the least
amount of privileges the lambda needs. Not just one generic “lambda role”.

Whoever is responsible for production deployment could audit the role’s
permissions and the definitions would be in source control.

------
kodablah
> I'm referring, of course, to AWS IAM, which absolutely is the worst form of
> cloud lock-in that currently exists, at least relative to the zero people
> who seem to be talking about it.

I assume people don't talk about it because it's not trivially solvable. While
we can have many abstractions out there, abstracting IAM across providers is
very difficult because while you could get roles and users/members/policies
abstracted, you couldn't get resources and permissions abstracted. They are
too bespoke. The best you could hope for is a common API, but you'll still be
provider-specific in everything you pass.

------
PaulHoule
Alternately, IAM brings AWS customers a lot of value.

Do you think the average enterprise could develop a unified system for access
control to cloud resources that would have a prayer of being secure? Would the
average enterprise be able to develop such a system (secure or not) that
wouldn't bring work to halt?

~~~
sl1ck731
The author says as much. The title is clickbait, but the article basically
says you're locked into AWS no matter what, and arguing over stuff like Lambda
lock-in is pointless considering the other avenues AWS already has you on
(like IAM).

------
bradknowles
I'm not worried about AWS IAM. I'd love for my problem to be that small.

I'd like to get off Azure SSO.

------
based2
like MS/Azure Active Directory.

~~~
idbehold
Did you even read the article?

~~~
nothrabannosir
Please don't ask that. It's in the HN guidelines:

 _> Please don't insinuate that someone hasn't read an article. "Did you even
read the article? It mentions that" can be shortened to "The article mentions
that."_

–
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
plorkyeran
That comparison isn't something the article mentions; it _is_ the article.

------
mentat
Might be nice if the author understood the difference between the CEO and CTO
before he went off insulting their positioning.

