I mentioned in another comment but many countries have free data for WhatsApp plans which kind of entrenches their position. They might lose out eventually but it won't be overnight.
195 karma · joined March 15, 2013
Last I checked marriage is by no means an STI preventing form of contraception so I think you mean monogamous relationship. As many people are in happy monogamous relationships with no intent for marriage because of a variety of reasons.
It's not entirely clear to me how you would even go about enforcing such a law. Why would either participant report their "crime"? Isn't that effectively what Judeo-Christian beliefs have encouraged since their inception?
I think it really comes down to your threat model though and what tradeoffs you're willing to accept for anonymity (e.g. captchas, performance, etc).
I think the sweet spot for CloudFlare's offering is if you're in a country or service provider that takes liberties in overriding DNS responses.
Although 1.1.1.1 is accessible for me know so I suspect it was a propagation issue.
ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1Suppose that would admit not knowing something... certainly not something we should be encouraging!
I've observed discussions with people citing it becomes particularly pathological when DRY is employed by Enterprise Architects. From my experience I tend to agree with that statement. I think RFC's (SHOULD, MUST, NOT, etc) with a reference implementation are a much better approach. If you want to move quickly use the reference. If it doesn't fit your use-case for whatever reason, document why you're branching out and get on with it. Obviously this approach poses an issue where documentation diverges from reality but ideally writing it down first will help clarify the objectives. Ideally the ABI/API for anything that's shared wouldn't be changing that much so maintaining the document shouldn't be too erroneous. If it is it might be an indicator to encourage duplication.
Pieter Hintjens RFC's for ZeroMQ is a great example of what I mean;
The GraphQL spec is pretty good too;
http://facebook.github.io/graphql/October2016/
Yes all of these things take time to write up but if you're going to constrain someone by saying "use this and under no condition nothing else" then it should be well documented.
1. purchase for innovation.
2. market control.
I think the latter is what people squawk about the most. Employees of the acquired will always find it uncomfortable. Small companies often have limited process where larger companies generally need it to function. That being said I don't think larger companies cull/assess the impact/efficiency of their processes on a regular basis.
I definitely like the lower density of text that an absence of end-tags provides.
1. desired time to market.
2. operating cost.
3. people cost.
If you're dealing at that level of traffic you're not going to go broke unless you lack a decent business model. One of the companies I worked at was spending $100,000+ per month on AWS (more than they should've for the incoming traffic level but they survived for a number of years). A friend was working at another company that was spending $3,000,000+/month. The motivation for using DynamoDB/Datastore over say S3 is that you can do range queries, field sub-selection, offloading of systems administration, some elements of security, etc.
Most traffic patterns have windows and tend to be diurnal in nature. This depends on the number of timezones your service covers. Obvious exception being IoT type time-series. So you might experience peaks of 16k/s but that will be for perhaps a few windows in the day. I also wouldn't be treating DynamoDB as permanent "long-term" storage for granular data. I would be using a sliding window of whatever I consider to be a valuable retention period (e.g. sliding window of 30 days). If you don't you'd need to scale C* as well.
In order to run Cassandra and get streaming aggregation via Spark you need to run "2 regions". One as the primary online region for serving requests and a second region for stream processing using Spark. Minimum recommended memory requirement is 16GB for a C* node. For a C* + Spark node minimum is 32GB. The more the better for both. If you've selected your keys well C* will scale almost linearly with the addition of nodes. Using Netflix 1,000,000 writes/second as a model you could roughly state that dividing nodes (285) by 60 should yield an approximately similar throughput requirement to the articles. So about 5-6 t2.xlarge nodes could potentially work for the FE cluster, and whatever gives you adequate streaming performance for the streaming cluster, as a minimum 3-5 x t2.2xlarge. Let's say ~$2,000/month.
Another thing to consider is that the management and maintenance of a C* cluster doesn't come for free either. So figure you'll need a minimum of 2 sys-admins to administer the cluster. Depending on where you are that'll likely cost the company upwards of $400,000 per year or $33,000k/month once you combine base salary, pension contributions, taxes, etc. You could say 1 sysadmin but then you're going to burn out your sysadmins if 1 guy is always on-call.
So assuming a sliding window of 30 days that's $2,160/day for DynamoDB. With a C* cluster you're looking at a minimum of $1,100/day. More depending on how well it performs for what your system is doing. If you're not using a sliding window you'd also need to scale you're C* cluster as well. In order to configure the C* cluster in a way that provides back-ups, auto-recovery, etc you're probably looking at about 2w-2m depending on experience. Whereas DynamoDB time to market will be probably a 1-2w.
There's a big caveat to any NoSQL database and that's how you handle aggregates/roll-ups. With a standard database it's easy to write these queries. If you do it without thinking on a NoSQL system it'll cost you in performance and where billed per access, money. There's a few ways to address this;
- batch ala map-reduce.
- streaming ala Apache Beam, Spark, etc.
- in query counting (aka sharded counters).
- kubernetes - elastic beanstalk
I'm currently using the "custom" section with a plugin I developed to deploy to environments. In the default build it pushes the build to Elastic Beanstalk and then deploys to test. The custom builds merely promote the build for other environments.
Only suggestion I'd make is learn to use the Command-Line with your tools (where possible) and practise writing scripts to optimise your workflow. If you do that it'll make the transition to a NIX a little less foreign.
1. Start-ups love OSS. OSS loves NIX. 2. Mac's just work (mostly). 3. Cult of Apple.
1. OSS is generally free. Windows software, esp. on the server side, tends not to be. For a start-up it means you might need to invest some sweat but you can spend your cash elsewhere (typically on hires or feeding yourself). OS X being a NIX allows easier porting of OSS than Windows.
2. Apple tech has a reputation for "just working" and continuing to work. Windows is still perceived to need a spring cleaning to reinstall it every year or so to keep it purring. Apple being a closed ecosystem from end-to-end doesn't have to support as much random stuff as MS. It keeps the problem space narrow and presumably that results in higher reliability.
3. The cult of Apple. Apple has a brand that is perceived as creative, fun, enlightened, whatever. MS is viewed as big enterprise. , which is often the Goliath that start-ups are looking to slay.
--
Anecdotally one company I was an early "many hats" hire I standardised on Macs because it meant less effort for support and licensing was easier.
If someones Mac was acting up/it fell down the stairs we could swap the drive to another machine and not faff with driver setup. If someone left the company, we could easily transfer the licenses which isn't always as straight forward between Windows and OS X.
One drawback is that we had one developer who preferred Windows. He was probably less productive than he could've been as a result. I would generally advocate to allow developers to pick their hardware when they start and take it when they leave. Once the company was big enough for a full-time IT support staff we diversified but it's a tradeoff either way.
In support of my flippant remark I see three indicators that hold parallels to Betamax with detail to follow. I qualify that it is largely informed by my own anecdotal experience. Specifically by objections and responses that I've received/observed while myself and peers have proposed or implemented cloud adoption at various companies.
Indicators
1. market share. 2. proprietary tech stack. 3. technical superiority syndrome.
Detail
1. Currently AWS has a major lead, then Azure, then Google. The implication is that market share translates to mindshare, which in turn yields blog articles, OSS libraries/tools, etc. This becomes a virtuous cycle.
For .NET shops that marketshare will tend to favour Azure on the premise that MS knows best.
2. Some of Google's technology stack has a learning curve that is unique to Google. Take GAE as an example and compare to AWS's nearest equivalent Beanstalk (or Heroku). Beanstalk requires few if any changes to an existing application whereas GAE requires that you do it the App Engine way. It might provide a number of benefits, but it's invasive. Containers are shifting the requirement, however not everyone is in a position or has the desire to start with containers on day 1.
Further Google Cloud's project oriented approach while not a bad organisation mechanism detracts from learning. If you assume the premise that exploration is part of learning it forces the user to hold two items in their head: their objective and Google Clouds imposed objective.
AWS on the other hand generally provides defaults that allow you to launch resources almost immediately after sign-up. Google's approach is better for long-term support, maintenance and organisation but the user needs to have the maturity to understand that benefit.
3. It may be technically superior but that statement in of itself is divisive and can shudder some away. It is not enough to simply be technically superior and from my observation the statements tend to originate from X/Googlers.
A number of people will latch onto feature set (for beta, number of films available was a factor). The absence of features will often discount a choice out of the gate (even if those features are irrelevant) as an example:
- regional coverage: AWS - 15 regions/~38 zones Azure - 36 regions/zones Google - 6 regions/18 zones
- partially/fully managed services: AWS is continually growing these, at a level that seems to outpace competitors.
- Outwardly Google appears to tackle the "hard problems" with technically superior solutions (e.g. TensorFlow, BigQuery) but often appears to neglect the "boring" problems a number of companies want as well (e.g. Cloud VDI's, SnowBall, etc).
- Some areas seem to be ossified due to tight coupling (e.g. servlet 3.0 and python support in GAE).
Summary
There is no silver bullet solution. Every provider will have an outage at some point and this could be a big reason that GCE won't be knocked out of the game. I also think Google is working really hard to build community and mindshare. I don't have a crystal ball so only time will tell what happens but technical superiority has rarely been the sole reason that drives adoption.
As an example let's say you want to install MongoDB on a new Ubuntu machine, you have the following dependencies in approximate order;
* Add MongoDB Apt Repo to apt list. * Add MongoDB repository key. * apt-get update. * apt-get install mongodb. * Configure /etc/mongodb.conf to your liking. * Restart mongodb.
Depending on how you implement it CM will allow you to make the process cookie cutter.
Want a new test environment? Spin one up and run your CM against the servers. Want to try that hot new cloud provider? Ditto.
I think it's worth the investment unless you're just doing apps that have a very short shelf life (e.g. marketing apps that live for no longer than a few months).
Kind Regards, Nathan