9 ms·

AWS S3 is a testament to just how successful a service can be if it is SIMPLE and RELIABLE. I recall using it in its very first incarnation in the 00's. From an

AWS S3 is a testament to just how successful a service can be if it is SIMPLE and RELIABLE. I recall using it in its very first incarnation in the 00's. From an API surface perspective there was barely anything to it, but it nailed being easy to use, easy to pay for, and as reliable as the sun.

mywittyname 7y ago
Do one thing, but do it very well.
- dnautics 7y ago
  It's also at it's heart distributed state management, and that is generally speaking very hard to do for anyone to do correctly.
  - Thaxll 7y ago
    You don't distribute state mgmt in S3 alone since there is no lock mechanism.
    - nine_k 7y ago
      If there is but one direction of distribution, e.g. when you deploy config changes, and never replace objects, this suffices.
    - dnautics 7y ago
      Eventual consistency is a valid distributed strategy.
- david-cako 7y ago
  Unix philosophy for services encourages the user to model their problem rather than their architecture. Edge computing is a brewing shitstorm at companies which are not trending in this direction.
  - mpfundstein 7y ago
    Care to elaborate? Like every sentence you wrote?:-)
mtberatwork 7y ago
I agree that S3 is fantastic, but not sure I would consider it simple considering how much sensitive data is left wide open in publicly accessible buckets all the time. Clearly, applying correct permissions seems to be quite a challenge for even experienced folks. The S3 console doesn't really make life any easier either and terminology can be confusing. Also, applying IAM/CORS policies, object headers, etc isn't exactly simple for the layperson.
- deleted 7y ago
  [deleted]
- scarface74 7y ago
  You have to jump through hoops to make buckets public and even then you get a clear label saying “public”.
  - alpha_squared 7y ago
    The "public" label was somewhat recent (I think that happened in the last 18 months), but I think many of the biggest S3 leaks predate that labeling.
- madeofpalk 7y ago
  The S3 console now makes it quite apparent, in my opinion when things are left public. Public is no longer the default, and theres big scary warnings whenever you make something public.
  - deleted 7y ago
    [deleted]
- saber6 7y ago
  > I agree that S3 is fantastic, but not sure I would consider it simple considering how much sensitive data is left wide open in publicly accessible buckets all the time. You're conflating two things: A) simple, reliable service B) dumbass operators. Yes, I said it: If you leave a public bucket exposed in S3 unintentionally, you're a dumbass. You're also most likely not appropriately skilled (security fundamentals) for the responsibilities you have been charged with (information security). Neither of these are the fault of AWS or S3. S3 is a tool, like a pick axe. If you ram it through your foot, it is not the pick axe's fault.
closeparen 7y ago
I'm constantly reminded of Rich Hickey's point about good platforms providing few but powerful verbs. Put another way, if you look at your service's API and it's complicated, you probably don't have the abstraction right.
lenkite 7y ago
Implementing a S3 client from scratch is no longer simple. V4 signature and payload signing is a pain and you have to read the doc a dozen times before you can successfully implement it.
- dexen 7y ago
  >V4 signature and payload signing is pain Don't be overly discouraged :-) I have a reliable (if a bit ugly) implementation in under 3kb of sparse PHP OOP code. Yes it took a few hours to iron out the last kinks, and one extra refactor to free up a mistakenly bound variable. It might have helped that it was the first version I implemented, thus no need to match impedance of older interface. On the plus side, the signing is designed as self-contained, and neither implementation nor API calls spill to too many parts of request handling. >you have to read the doc a dozen times before you can successfully implement it Very much so - it does require a small 'eureka' moment. It's hard to put your finger on what exactly makes it hard to get right the first time around. At the very least it is written from a somewhat peculiar viewpoint. Fortunately the primitives used are common enough to be available in typical standard libraries.

mywittyname 7y ago

Do one thing, but do it very well.

dnautics 7y ago
It's also at it's heart distributed state management, and that is generally speaking very hard to do for anyone to do correctly.
- Thaxll 7y ago
  You don't distribute state mgmt in S3 alone since there is no lock mechanism.
  - nine_k 7y ago
    If there is but one direction of distribution, e.g. when you deploy config changes, and never replace objects, this suffices.
  - dnautics 7y ago
    Eventual consistency is a valid distributed strategy.
david-cako 7y ago
Unix philosophy for services encourages the user to model their problem rather than their architecture. Edge computing is a brewing shitstorm at companies which are not trending in this direction.
- mpfundstein 7y ago
  Care to elaborate? Like every sentence you wrote?:-)

mtberatwork 7y ago

I agree that S3 is fantastic, but not sure I would consider it simple considering how much sensitive data is left wide open in publicly accessible buckets all the time. Clearly, applying correct permissions seems to be quite a challenge for even experienced folks. The S3 console doesn't really make life any easier either and terminology can be confusing. Also, applying IAM/CORS policies, object headers, etc isn't exactly simple for the layperson.

deleted 7y ago
[deleted]
scarface74 7y ago
You have to jump through hoops to make buckets public and even then you get a clear label saying “public”.
- alpha_squared 7y ago
  The "public" label was somewhat recent (I think that happened in the last 18 months), but I think many of the biggest S3 leaks predate that labeling.
madeofpalk 7y ago
The S3 console now makes it quite apparent, in my opinion when things are left public. Public is no longer the default, and theres big scary warnings whenever you make something public.
- deleted 7y ago
  [deleted]
saber6 7y ago
> I agree that S3 is fantastic, but not sure I would consider it simple considering how much sensitive data is left wide open in publicly accessible buckets all the time. You're conflating two things: A) simple, reliable service B) dumbass operators. Yes, I said it: If you leave a public bucket exposed in S3 unintentionally, you're a dumbass. You're also most likely not appropriately skilled (security fundamentals) for the responsibilities you have been charged with (information security). Neither of these are the fault of AWS or S3. S3 is a tool, like a pick axe. If you ram it through your foot, it is not the pick axe's fault.

closeparen 7y ago

I'm constantly reminded of Rich Hickey's point about good platforms providing few but powerful verbs. Put another way, if you look at your service's API and it's complicated, you probably don't have the abstraction right.

lenkite 7y ago

Implementing a S3 client from scratch is no longer simple. V4 signature and payload signing is a pain and you have to read the doc a dozen times before you can successfully implement it.

dexen 7y ago
>V4 signature and payload signing is pain Don't be overly discouraged :-) I have a reliable (if a bit ugly) implementation in under 3kb of sparse PHP OOP code. Yes it took a few hours to iron out the last kinks, and one extra refactor to free up a mistakenly bound variable. It might have helped that it was the first version I implemented, thus no need to match impedance of older interface. On the plus side, the signing is designed as self-contained, and neither implementation nor API calls spill to too many parts of request handling. >you have to read the doc a dozen times before you can successfully implement it Very much so - it does require a small 'eureka' moment. It's hard to put your finger on what exactly makes it hard to get right the first time around. At the very least it is written from a somewhat peculiar viewpoint. Fortunately the primitives used are common enough to be available in typical standard libraries.