bthornbury

This is the most promising one I've seen.

You should be able to "docker build" the image on the remote host that way. Downside there is that you are transporting the entire build context rather than just the layers. IMO most cases will be less efficient.

But so does quick, slapped-together code from late last night.

Depending on the complexity and impact of either, you can progress in your career.

College won't teach you either, but it gives you an (otherwise very difficult to obtain/justify) opportunity to study full-time for four years on complex subjects and a foot in the door.

Usually you can easily push your local docker images by calling docker save, scp the tar file, then docker load on the remote host. The downside here is that you are pushing every layer of the entire image every time (maybe GBs).

An alternative is to set up your own private registry or use a public one like dockerhub. This can be undesirable or cumbersome for a number of reasons, especially for code you prefer to keep private.

So this tool essentially establishes a private registry on your host which is only bound to localhost (no outside access), establishes an ssh tunnel from your host to the remote to access that private registry, pushes only the layers which don't yet exist on the host, and then cleans up after itself (closing down the registry, ssh tunnel, etc...).

In my mind, I'm thinking this creates something like a chain of generators in python, but would love if someone could explain in JS terms.

Death rates increase every year due to naturally occurring mechanisms in the body. Consider those mechanisms as a function with the body as a parameter and the output as a more aged body (or rather a body with higher probability of failure).

If the body reaches a point where the death rate ceases to increase year per year, it would suggest that those same naturally occuring mechanisms, thought of as a function, approaches some asymptote.

Note this doesn't necessarily mean you stop aging (in appearance), just that your body's rate of failure no longer increases. This suggests that if the reasons for failure can be treated properly, perhaps the body can remain in that equilibrium state indefinitely.

This study provides some preliminary evidence that such an asymptote may exist in the body's natural mechanisms. Both controversial and exciting. Worth exploring further.

This is just BS. I quit about 2 years ago, and am turn down recruiters quite often, very employable.

Stop trying to scare people on the fence.

I think you're ignoring a lot of human things like that a lot developers are quite isolated and working 60+ hours a week. Their social group is quite likely just their co-workers. Especially for new devs who have relocated.

Also the more popular answers are coming up over the more relevant results.

Seems like changes that would be valuable for most instances of casual searching, but when it's an off-the-wall blog you've never heard of that has the answer you seek, it's a problem.

Not sure what changed, are other devs experiencing the same?

For example, if you make a photo editing app, you need to request access to the user's photo gallery at runtime of the app.

If they refuse, it's fully expected that your app will continue to work with reduced functionality. IIRC you will have trouble getting approved for the app store if your app breaks after permissions are refused.

I understand this is intended for AWS Lambda, but what is it doing that makes it more suited?

https://github.com/brthor/docker-layer2-icc

Serverless platforms increase convenience.

Throwing them away decreases convenience and increases developer time to learn and launch.

Many great inventions, like writing, automobiles, all increased convenience.

Throwing away inventions that increase convenience, decreases convenience.

Makes the OP's scenario much easier. Code upload and configuration all handled for you. You run code online the same way you call a local function.

Disclaimer: I am the founder/dev/designer of CoherenceApi.

Forget that they take more time to care for, and to learn how to ride, and how to feed properly.

I'm thinking we'll put something in place for free frictionless small evaluation after we think about fraud management a little bit.

Thanks for the feedback here everyone this is really invaluable!

For example, if you only had 2 compute hours, would it be enough for your evaluation?

The fact is in the early stage, this will help restrict fraud and bring in more engaged customers to ensure their expectations are met.

It's not something we plan to require forever.

This is the most common question! Other FaaS solutions require your code or your workflow to be structured in some way to fit in with their system, not to mention requiring you to use their tools.

Coherence integrates with the programming language to make it a lot simpler on the developer. Just pass a func and it's getting run. Structure your code however you like and use your favorite tools!

EDIT: One example, it's going to be a lot easier to run your web crawlers on Coherence.

EDIT 2: Yes I worked on .NET Core and am a python enthusiast for over 9 years. This is why they are the first supported languages.

- scaling the function

This is where we've invested most of our effort. We're envisioning a load test demo soon.

- monitoring the function (billing, errors, throughput, latency)

This is something which we will need to invest more in. Great feedback here. We don't have much in the way of monitoring yet, but everything is there and we just need to expose it to the users.

- moving data between two functions, storing data

Traditional solutions like Redis and Postgres seem like a good solution here. You can't host them on Coherence yet, but it's something that we're working on.

- signaling a function, upgrading a function, downgrading a function

Versioning is particularly interesting here. A lot of time we've thought of these functions as ephemeral.

Send me an email (bryan at coherenceapi . com) I'm really interested to talk more about the use cases you're envisioning.

It's really just the running time of your program (you control this) plus a less than a second of setup / tear down time. If your job is set to consume 1GB that's it, you've consumed that many GB-seconds. If it's a 128MB job, then you've only consumed 1/8th of that many GB-seconds.

Let me know if this example is getting it across, it's a simplified version of the pricing of other serverless platforms.