Also, have you considered using i3 instances for their superior price per throughput/IOP? Obviously, you can't rely on EBS snapshot based backup/restore workflows on those instances, but maybe the performance gain is compelling enough to make the exercise worthwhile?
HN user
jacobscott
Cal; MIT; Palantir; Infer Milkshakes; Bacon; Indie Video Games
$username+hn@gmail.com
Are Citus Cloud customers generally IOPS constrained rather than throughput constrained? You're also constrained by the EBS-optimized interconnect, right? http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimi...
Thanks! I look forward to reading about implementation details.
It does seem like documentation of Citus Cloud HA and disaster recovery behavior is a bit light, compared to e.g.
- http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concep...
- https://devcenter.heroku.com/articles/heroku-postgres-ha
"In addition to continuous protection which is explained above, high availability is available if your application requires less exposure to downtime. We provision stand-bys if you select high availability at provisioning time. This can be for your primary node, or for your distributed nodes." https://docs.citusdata.com/en/v6.1/cloud/features.html
Please let me know if I've missed any resources on this topic!
Does Citus (Cloud?) have features that offer better high availability and failover functionality than what RDS provides? Managed Patroni and packaged workflows for zero-downtime failover would be quite interesting, but I don't see anything like that mentioned on https://www.citusdata.com/product/cloud.
Thanks, this makes sense!
The software has to be distributed somehow, right? Probably over https? What makes curl more susceptible to MITM than apt-get/pip/gem/etc?
I don't particularly like curl | sh either, but without sudo, I'm not sure how much it /really/ differs, security wise, from other options.
Edit: real package managers have improved features compared to curl, as outlined in another branch of the comments.
What's the difference between downloading and executing a binary, installing a package (apt-get, pip, gem, etc), and curl | sh which makes the later so bad?
If the script source is on github and isn't run under sudo, is there a meaningful difference between curl | sh and apt-get install from a PPA, gem/pip install, etc?
Will General Purpose (SSD) be an option for RDS?
If we assume stability, in what circumstances would PIOPS or Magnetic volumes be preferable to General Purpose?
For example, workloads that use an average of < ~.4 IOP per GB per second, might save money using Magnetic.
The previous generation had a small instance (m1.small). There is no comparable offering in the current generation (at least, not yet). The smallest m3 instance is the m3.medium. You can still provision an m1.small, though, right? You just miss out on the hardware upgrade.
GCE, Digital Ocean, etc may be a better fit than AWS for these kinds of instances.
From Jeff Barr's blog post (http://aws.amazon.com/blogs/aws/new-ssd-backed-elastic-block...):
* A bucket is associated with each General Purpose (SSD) volume, and can hold up to 5.4 million tokens.
* Tokens accumulate at a rate of 3 per configured GB per second, up to the capacity of the bucket
I take this to mean that a 1TB GP SSD gets 3K tokens/sec = consistent 3K PIOPS. Can you explain where you disagree?
Previously a 1TB, 4K PIOPS volume was $525/mo. With a 35% discount on PIOPS this now runs $385/mo, but you can also get 1TB, 3K PIOPS General Purpose volume for $100/mo. Pretty nice price drop!
Generally, since 1 GB of GP SSD costs as much as 1 PIOP, in most cases you should just purchase a max(DESIRED_VOLSIZE, DESIRED_PIOPS/3)GB GP SSD volume rather than a PIOPS volume. I think.
I agree with the gist of the post, but there are some ways in which you can tip the scales in your favor:
- Get an offer where you get your options up front and the company reserves the right to repurchase them.
- Exercise your options immediately and file an 83b election. There will be no difference between fair market value and strike price, so your exercise-time tax liability should be zero. Obviously, this is easier if #options*strike_price is low.
- Look for a low strike price. If the seed round was convertible debt, the strike price may still be low.
- If you're trying to "go big or go home", look for a big gap between strike price and the price of preferred shares in the most recent round.
- Work at a company that is a qualified small business at the time you (fully, see above) exercise your initial grant, and hold your stock for five years. This can make any capital gains almost entirely tax free (see e.g. http://www.morganlewis.com/pubs/Tax_LF_CongressExtendsSmallB...)
I am _not_ a tax/finance professional, so remember to take these with a grain of salt!
Have you used any other cloud monitoring/metric/etc providers? If so, how do they compare to DataDog?
Yang's notes are awesome! I considered their strength a positive signal when he recruited me to Infer, a startup which he left MIT ABD to cofound (https://www.infer.com/about.html).
We're hiring, so if you're impressed by these notes, check out our careers page: https://www.infer.com/careers.html or email me directly jh<lastname>@infer.com
It seems like there's vague consensus on first engineer equity. Are there any common rule-of-thumbs for Nth engineer (or Nth employee) equity?
Sadly, no. I almost missed the SHDH that we hosted a few weeks ago.
Palantir Tech is hiring for just about every position in the company (we're growing fast). The most YC-relevant positions are probably software engineers -- most of what we do is in Java (with a bit of Groovy glue). Most jobs are at our Palo Alto, CA hq.
See: http://www.palantirtech.com/careers
http://www.palantirtech.com/careers/positions
http://www.palantirtech.com/careers/interviewing
Also feel free to contact my directly -- jhscott/at/palantirtech[.com].
My favorite perk is probably 4v4 Halo3 after dinner on the two HD projectors in the game room.
I work there, in software development. I think I work hard, but certainly not death march hard, or any harder than someone working at another random startup might. Not fourty hours a week, but certainly not eighty, either.
If you think you can add 1mm to the value of your startup by working 12 hours a day 7 days a week for a year, then your time is "worth" $230/hour.
Also, considering what someone with a similar background could earn working full time for an established company (especially factoring in benefits), $50/hr is fairly conservative in terms of opportunity cost.
also, from the same poster, to the actual source (slate). I flagged this one.
Twitter is still nascent compared to Facebook traffic-wise, and I bet that the vast majority of twitter users are also facebook users. So, if Facebook gives you the same functionality AND user experience, why maintain your twitter account?
So Facebook makes it easier to post public news feed items, and then writes a twitter-like UI on top of that data. There are obviously subtle usability issues here, but technically it seems straightforward...
I would be more worried about the "it" that is facebook providing a better experience for their core usecases.
From what I can tell, given the new Facebook UI, all Facebook needs to do to implement twitter is:
* Streamline directed relationships (fan versus friend) for "follow" functionality
* Streamline status privacy settings (so that changing your status can be equivalent to a tweet)
* Write lite.facebook.com that looks just like twitter/jaiku/etc
In addition, it seems to me that Facebook has the following advantages over twitter:
* Funding: 500mm versus 50mm
* Scale Facebook has many more users and engineers
* Platform/Apps Facebook has a rich platform, twitter doesn't
Thoughts?
It seems like I asked the question in the wrong context. Sorry about that. Given that scale is hard, how about monitoring, or management?
I want to make it very clear that I'm not a business guy.
Think of it in the context of building a database-backed enterprise app that customers run in house. You don't want to ship a DBA to every customer...
If it helps, I asked a more concrete version of this question focusing on PostgreSQL on stackoverflow: http://stackoverflow.com/questions/556325/postgresql-managem...
If one vertically oriented monitor is good, are two better?
A well known quote (in the right circles):
"Real men reduce from 3SAT" -- Christos Papadimitriou [http://www.cs.berkeley.edu/~christos/]