klaruz

Cloudwatch does what you're referring to as well. It's more of a basic server monitoring system that happens to integrate with the load balancer.

You get a set of basic VM level metrics, and you can feed it custom metrics from your app, or log files. All of which can be configured to alarm. I don't think it's possible to run advanced statistics on the metrics for alarming (eg, standard deviation from 30 minute exceeds N), but it may be. Usually it's just an event count, like more than N 500 errors over X time.

I do agree you need to think deeper than basic health checks though, 'broken server' is always a hard boolean to nail down.

I think the problem is clustering is still very much a duct-tape situation in postgresql with no real clear consensus on how to build out a cluster.

Postgres-XL looks great for scale out, but you need 4 independent types of servers. Even with all those moving parts, it doesn't provide availability. If you want fail-over, you need pacemaker for the data nodes with traditional sync replication, and something like VRRP for your balancer, and something else to failover the coordinator. Several of these pieces can be tricky to set up in a cloud provider.

BDR looks nice, but it looks like there could be lots of gotchas for consistency in there. Maybe it is a magic bullet though... I don't know much about it yet.

Contrast with something like rethinkdb, mysql-galera, cassandra, etc, you start up enough nodes for quorum, tell them about each other, and you're pretty much done. The clients can handle the balancing, or you can use a pooler/balancer.

In my perfect world, I'd install postgresql-awesome-cluster-edition on 3 nodes, add the 3 IPs (or turn on multicast discovery, if my env can support it), and away we go for read scalability and availability. I do this today for mysql-galera, and other than the fact it's mysql, it's awesome. For writes, if you add 4 or more nodes, there should be some sort of shard system like XL has.

That said, postgresql is still clearly the best SQL and even noSQL single node server out there, it's a really great piece of software.

So you think recompiling OpenSSL from scratch, in doing so, deviating from the upstream vendor's supported binaries, and the dependency problems with updates it will cause, just to support a mostly smoke and mirrors standard is a good idea? I'd don't really think that's a best practice in commercial or government IT.

I am in 100% agreement with you, FIPS is bonkers.

I'm your counterpart at another agency. I'm glad to see other agencies are not doing FIPS on their websites (Which would be RHEL with mod_nss only). I'm a bit confused though, last I looked FedRAMP still required it. Have the mandates been changed?

I think it comes from their AppFog acquisition.

So in other words, become a FB/Twitter/Play/App store and put yourself at the top of the pyramid. Now you get to be the company changing the API and banning users, but we still haven't actually solved the problem for the users of web services.

I just posted a similar comment above. It seems like the time is right for an open source advanced chat server. Maybe there already is one, I just don't know of it yet.

Are any of these available for companies that can't ship all their internal conversations and files to the cloud? Are XMPP/IRC and overpriced 'enterprise' suites still the go to for private chat?

Yes, and google will throttle you if you make too many requests.

Very nice, I can stop updating my fork of the other rpm spec that's on github.

Any info on how it sets up networking? I see -b none in the startup... Is there some other tool that does it on EL6?

Do you know where devel talks for this rpm are happening? I did not see any mention of it in the EPEL list archives.