Hey all, founder is here. I'd like to thank you for your votes here. Really appreciate!
Also, I just want to share our public roadmap: https://trello.com/b/7fEwaPRd/roadmap. Feel free to comment. It actually helps a lot for us to prioritize. Thanks!
Also, I just want to share our public roadmap: https://trello.com/b/7fEwaPRd/roadmap. Feel free to comment. It actually helps a lot for us to prioritize. Thanks!
As I explained in my other comment https://news.ycombinator.com/item?id=12892243 it really feels like Hyper.sh is hosted on Amazon, and there were references to that fact before, and you guys are trying to minimize that in your site now.
If you're on Amazon, that's OK. I don't think that minimizes how cool this technology is and how much easier it makes things. Amazon has an Elastic Container Service, but this is more nuanced than ECS is, and much more painless. But if the containers aren't on Amazon, a little more detail on how that works would be awesome, because right now it really feels like they're on Amazon. Which is fine, but when folks are making decisions (like putting their stuff on multiple platforms for reliability), it's important to know.
Edit: I signed up and looked around. It appears they're hosting on ZenLayer, a Chinese hosting company that has hosting in LA as one of their options. Not sure why they stick so closely with AWS on terminology though.
Makes sense from a user familiarity perspective -- AWS is what most cloud users are familiar with, and describing things in terms that are most likely to be understood is generally good practice.
I'd agree that it would make sense though if their site clarified who owns and runs the datacenter their running their service out of, if only for answering the question if they're hosting on top of AWS or not.
This also means you as Hyper.sh don't have to worry about servers, uptime, buying hardware, power, bandwidth peering, what a headache. Let AWS and Google worry about the commodity physical hardware.
damn, thank you. Anywhere I can see implementation details? Are you rolling your own system from the ground up, or using something like dkron (http://dkron.io/) behind the scenes?
http://docs.aws.amazon.com/lambda/latest/dg/with-scheduledev...
1) Create a Lambda function
2) Trigger it using CloudWatch Events. You can set up cron like rules and AWS will trigger them for you.
If this feature lands it sounds like it will give the ability to run any container arbitrarily and pay by the second - this would be huge for things like web scraping and other tasks that don't occur all the time yet still come with all the pain of server maintenance and uptime fees.
Imagine the scenario where you have a web scraper that runs once a week for 3 hours. Ideally you only want the machine to be on for those 3 hours, and to only pay for those hours of usage; but you also don't want the hassle of writing all the scripts that go with creating and deleting a cloud machine, mostly because those would also need to be hosted somewhere. For that kind of use case there is little out there as far as I'm aware.
Look for ways to divide-and-conquer your lambdas into smaller parts. If you need to run some logic for every record in some table, give N records to a single lambda (where N is some small number which doesn't make the lambda take anywhere close to 300s).
You can orchestrate this workflow with several different AWS tools which exist all over the spectrum of cost and ease-of-use.
Easiest is definitely just having the master lambda directly invoke the other lambdas with InvocationType:Event.
SNS is another easy option. Lambda(master)->SNS(per N records)->Lambda(splinter). Downside is that you'll probably completely blast out your global AWS concurrent function execution limit pretty quickly because you have no control over how quickly SNS will trigger your functions.
Kinesis is a more powerful option. SQS also has potential, but you can't directly trigger a Lambda from SQS. One pattern I've seen used is to have a CWEvents cron trigger a lambda every M seconds to read N records from SQS. Depending on how consistent your workload is, this might make sense because it gives you really fine-grained control over that ratio between "how quickly will my jobs be processed" and "am I approaching my AWS global account limits". But if your jobs are really disparate you'd be invoking lambdas all day to do a whole bunch of nothing 90% of the time.
We have the first version of hyper cron ready for internal demo and would love to get your feedback.
If you're interested in being involved, please email us on talk@hyper.sh and we'll show you what we have so far.
I did get the email about the beta this morning, and will definitely play around with it over the next week or so.
I'd like to learn and experiment, but without "running the meter" and without sending my bits off of my laptop, for the time being.
If I find Hyper appealing, I'll certainly be willing to pay to deploy/move projects to your service!
I'd like to run a local instance of the "hyper system," fully contained on my laptop, perhaps running atop virtualbox. If I find it appealing, with respect to the usage experience (i.e. deploying/composing containers), I'd be willing to run some apps on the real deal. I am, though, not willing to experiment with the "real deal" as a means of evaluating it.
If you think you might end up using it, why try and replicate it on your machine (any more than Docker already does) rather than just cross the deployment bridge sooner?
I'd like to worry even less about the container host and get comfortable with a system like Hyper, but it's important to me to get used to it running locally for dev prior to employing it "in the cloud" for prod.
You can do exactly the same with Hyper. Play with Docker locally and then move to Hyper.
The CLI commands are pretty much identical, docker compose works in the same way.
Of course it's not exactly indentic, neither is a vagrant image and an AMI.
Yes there are important differences between running a dev server on VirtualBox and a prod server on one of the above, but there is parity in the workflow. The same is true when thinking about docker-machine + docker, locally then remotely.
I understand that Hyper's cli is quite similar to docker's cli. But my preference is to not consider it seriously until I can bang against a version of the Hyper backend running locally. If that's not forthcoming, fine, Hyper's not for me. :-) If it is, then great! I can't wait to play with it, locally, on my personal computer/s.
It's like "I absolutely won't try DigitalOcean unless they let me create a VM locally first!" Doesn't make any sense.
I'd like to keep in touch. Could you drop a message to peng at hyper.sh? Thanks.
Maybe it helps to prioritize that topic if I tell you that your service not being hosted here is the only ting keeping us from moving our complete microservice ecosystem to your service ;-)