Perception that they are THE cloud player to use with great reliability and enterprise focus, so people support their protocols and develop their products for AWS and end up with a bit of lock-in. Mid to large enterprise continue to get on the cloud train hype and spend tens, to hundreds of thousands a month on AWS/S3 instance costs and cannot figure out how or why the bill is so expensive. Then they spend internal costs and personal resource time trying to figure out how they spent so much money on AWS. This happens where I work on both the test/dev and also production hosting.
If DO or Linode were an option to consider, we might be able to save so much money but our own customers use and believe in AWS so we develop and test on AWS. It's a bit of a vicious cycle.
Have you seen these remote temperature monitors from sensorpush? They seem to do a decent job and there is an internet gateway device to manage them if you want.
Nope...the argument is more like the shoe manufacture should just include the shoelaces. Shoelaces support the functional operation of the shoe...a purse does not support the operation of shoes. Most people would expect their shoes to come with shoelaces, not a purse.
Thank you for sharing this; I hope more people can see this.
Apple gets the credit for this notch when it was the Essential phone that implemented the idea first. At least in the Essential phone their notch was so minimal to just get the camera to fit that it was not very intrusive. Even though I'm not a fan of a notch, this worked fine.
My podcasts are all downloaded with multiple episodes for each podcast and so is a large collection of my Spotify music. I get what you're saying but it isn't that big of an issue with a reasonably modern mobile device and a little customization of the app to do the downloads for you.
I've had very few buffering issues with Spotify via LTE over the years when compared the constant dropouts from my SiriusXM in my various cars that have had this service. SiriusXM audio quality is also terribly compressed and tinny in addition to the constant drop outs. I've never had a good experience with their product.
Spotify can also download large quantities of music and playlists...so with minimal planing you will have no buffering issues.
The article leaves me with more than a few doubts with this strategy of storing power. One issue that concerns me is the amount of energy that will need to be spent in manufacturing all the concrete and steel drums as well as the amount of pollution this will generate. There will also be the pollution in transporting the drums onto the battery locations. I get that this isn't a unique problem and other forms of "green" power generation also suffer from this such as wind turbines or even photovoltaic panels. Once the drums are onsite there is likely minimal maintenance needed so once the cost of producing is done, there should be a way to figure out how many years or months it would take to offset that.
Thanks for the link. That looks interesting; I'll have to give that a try. When I started reading the link my first thought was Pex from Twitter. I don't know how comparable XAR is to Pex but it's worth a look to compare the two.
I've recently been exploring AWS Lambda in a stack which contained API Gateway + Python Flask under Lambda for a task I was working on. I deployed it using Zappa and its purpose was to be a simple REST frontend for transferring files to S3.
After experimenting with uploads from Lambda to S3 I was noticing that the time to upload a tiny 4MB file changed dramatically when I reconfigured the Lambda function's memory size. At 500MB it took 16 seconds to upload the file which is pretty slow. Once I got past roughly 1500MB of memory, the performance no longer improved and the best I could get was about 8 seconds for the same payload.
None of my tests were controlled or rigorous in any way so take them with a grain of salt...they were just surprising to me that the speed changed dramatically with memory size allocation. I'm new to Lambda so I wasn't ware that memory size is tied to other resource performance. I'm curious if this goes beyond CPU and also changes network bandwidth/performance? The Lambda I deployed did not write data to the temp location that is provided, it streamed directly to S3.
I've since moved on from this implementation and now my Lambda function performs a much simpler task of generating pre-signed S3 URLs. I have noticed something else about Lambda that bothers me a little. If my function remains idle for some period of time and then I invoke it, the amount of time it takes to execute is around 800ms-1000ms. If I perform numerous calls right after, I get billed the minimum of 100ms because the execution time is under that. The part that bothers me is I'm being charged a one-time cost that's about 8x-10x the normal amount because my function has gone idle and cold. I'll have to continue reading to see if this is expected. It's not a huge amount in terms of cost but surprising that I'm paying for AWS to wake up from whatever state it is in.