soamv

Isn't Cloud Run's cold start latency even worse?

I did watch it. Their extrapolations were wrong. You can't just multiply positivity rate found in a biased sample by the whole population. That's not a meaningful extrapolation. Then using that extrapolation to say the death rate is low is just building up the error even more.

And then, comparing that to the flu and saying this isn't much worse, we're now well into the "this video is a potentially a public health hazard" territory.

The spec pdf looks a lot like the DP-3T protocol. The DP-3T docs have more explanation and a good discussion of privacy aspects.

https://github.com/DP-3T/documents

paper: https://github.com/DP-3T/documents/blob/master/DP3T%20White%...

data protection aspects: https://github.com/DP-3T/documents/blob/master/DP3T%20-%20Da...

Here's an overview comparing that approach to some others (such as Singapore's tracetogether): https://github.com/vteague/contactTracing

Having maintained an open source project for a while I relate to a lot of the problems brought up here.

It's really really hard to create a contribution system that works well when there is a large set of users, a large set of contributors, _and_ a tricky design space. It's tempting to become authoritarian, especially when the design space is complex and you've thought about it longer than anyone else. Inclusion is a shit ton of work, and a lot of it feels non-technical and boring to most people.

It's tempting to throw away compatibility and ask users to just deal with it. No project is perfect at this, but infrastructure stuff has a much higher bar for this than most other projects. That makes everything else that much harder.

Most tech culture undervalues management a lot, especially in open source. But open source should be valuing it more, because the problems are so much harder than in a small co-located one-company team -- communication is lower bandwidth and higher stakes, there's no way to manage other people's schedules, there's differing goals and incentives, and on and on.

Uh, that's a pretty bad HN edit on the headline -- only one bank is "melting down". The headline should be "India's Yes Bank meltdown..."

This is super nice. Love the clear explanation and the app design.

I'd use it, except there seems to be a total lack of context. If I add this button to my (web based) single-page app, I want to know what exactly the user was doing when they clicked it.

Giving the user just a text box and hoping that they'll include all context unprompted is a bit too optimistic IMHO. Maybe your JS thing could accept a context argument, and you can show that context in some way along with the complaint.

The article does say that there was a discussion about "exiting the business"; that's sufficiently terrible to be news, even without anyone explicitly talking about shutting it down.

Ah that answers it, thanks for posting that.

Looks neat, why not try to upstream it to the Go standard library if it's fully compatible?

No, this isn't about how much you can burst -- the maximum concurrency is still the same.

Lambda has always been the most expensive compute you can buy on AWS -- you could think of that as the premium for being the most "elastic". So this feature is about giving away some of that elasticity for (a) performance predictability and (b) a bit of total cost savings. Note that you can still happily "burst" into exactly as much concurrency as you could before, you'll just have cold starts.

People used to write cron jobs to keep their functions warm, which besides being ugly didn't even work well -- you could at best keep one instance warm with infrequent pinging, i.e. a provisioned concurrency of 1. So this feature addresses that use case in a much more systematic way.

There's some precedent for features like this -- provisioned IOPS and reserved instances come to mind. In both those cases you tradeoff elasticity and get some predictability in return (performance in one case, cost in another).

Fair enough -- then I'd recommend contacting the few most active users through DM/private messaging etc.

There really is no substitute for talking 1-1 to potential customers.

Good luck :)

Do you have some sort of user community? A slack or discord or whatever? Just ask your users. The ones who say yes will also be a good set of beta testers.

The product page is https://aws.amazon.com/savingsplans/, but it's 404 for now.

I believe both of you :) Human color perception is weird like that.

They're not even using the same pink! So this isn't just a usual "trademarks just work this way" thing, it's also a question of how much of the colorspace a trademark can own.

The techcrunch article is a bit more informative -- https://techcrunch.com/2019/11/04/lemonade-gets-a-nastygram-...

I'll throw in yet another recommendation for the Dell XPS 13". I'm using the 9380. It's light, thin, and has an excellent keyboard, and good battery life. The higher resolution screen option is beautiful, but it does drive the price up.

It's a carefully worded answer. No plans != doesn't want to. And also, I'd read "no plans" as "no plans that we're gonna tell you about right this minute".

It's a short talk with no transcript, but it's relevant and interesting if you were following all the open source licensing stuff from Redis, Elastic, and others.

It would be nice if you could tell at a glance how many of these are forks, versus just installing unmodified upstream Kubernetes.

Thanks. Here's the github link for fission: https://github.com/fission/fission

Platform9 Systems (http://platform9.com) | Software Engineers, Developer Advocates, Program Managers, et al | Sunnyvale CA | ONSITE, VISA

Platform9 makes cloud-hosted management systems for open source software (such as Kubernetes and Openstack) on customer infrastructure.

We're also making Fission, a serverless framework for Kubernetes: http://fission.io.

We're hiring across several positions: Software Engineering in various teams including Kubernetes, Openstack, and Fission; Software Engineers in Devops; Developer Advocates; and Technical Program Managers.

Find more at: https://platform9.com/careers

Oops, sorry, the option is supposed to be --url, not --route. I'll submit a fix for the blog.

$ fission function create --name hello --env python --code hello.py --url /hello

I think you're on an older version of the CLI, can you try updating it? https://github.com/fission/fission#install-the-client-cli

1. One time operations like that are run at module init time. Here's a trivial example: https://github.com/fission/fission/blob/master/examples/pyth...

2. We don't support Java yet, but we'd like to. The JVM would already be running by the time there's a request, so there won't be a JVM startup in the request path.

3. Dev workflows: Lots to do on that front. A big part of our roadmap is improving the dev workflow, better versioning support, CI/CD.

For running locally, yes, the best way is to run a local Kubernetes instance on your machine. minikube makes it very easy to do that, see the instructions in the README: https://github.com/fission/fission#setup-kubernetes

Kubernetes gets you pretty far along the path of not messing with servers (especially if you use GKE). And we think there's other advantages to Functions-as-a-Service on Kubernetes -- it simplifies the dev workflow, improves server utilization, interoperates well with other services on K8s, etc.

Yes -- Go and other compiled languages are on the roadmap.

So we've started by focusing on improving the whole workflow, which is why we're operating at the source level. But we have occasionally heard the use case for working at the image level, and it has pros and cons, so we're thinking about it. I'd like to learn more about what you're trying to do -- did you consider just using Kubernetes Deployments and Services? Or are you saying you'd like to combine the on-demand start with working at the image level? Is this basically a resource optimization use case?

Agree on the importance of API gateway.

Feature-wise, fission router is very simple right now. It's a service based on gorilla/mux. We had to write our own router because of cold-starts -- basically, the router needs to be able to talk to the pool manager and to get an instance when one doesn't exist, while holding on to the incoming request. (I'm not sure how much of this is possible to write as an nginx plugin.)

I don't have perf numbers just yet, but the router is stateless and you can just run more replicas when you reach its limit. It caches results from the rest of fission components, and most requests are on this fast path.

(We're also thinking about adding some existing feature-ful API proxy in front of the router, to get stuff like authentication, rate limiting, etc.)

Hi there, it would be awesome to have Zappa support Fission, happy to talk more about it!

We're working on a detailed comparison with Openwhisk, but basically -- we bet on Kubernetes as a good foundation to build this on, and it seems to be going well so far. It's true that we're at an earlier project maturity stage than Openwhisk is. In particular, we're actively working on integrating event sources and adding support for more languages.