I'm a huge cloudflare fan. Massive advocate for them but when I do see this talk of them as a new kind of cloud platform I cringe a little. Are we going to under go the same lock-in like experience we've had over the years by using very bespoke closed sourced systems like workers and durable objects. It's one thing to buy into something that does have wide portability like a postgres but much harder to buy into the platforms that aren't open source.
> when I do see this talk of them as a new kind of cloud platform I cringe a little. Are we going to under go the same lock-in like experience we've had over the years
I don’t understand your argument. A relatively small but innovative company is working to provide competition against the big 3 cloud providers … and you cringe?
Even if their service turns out to be more or less a S3 replicate with better pricing (for some applications involving a fixed amount of data that needs to be widely distributed) it’s a win for consumers and innovation
I mean competition overall is a great thing. Personally I wouldn't bemoan disruption of Google et al by Cloudflare.
That said, I remember when I was rooting for Google against Microsoft and Amazom against Walmart. Before my time people rooted for Microsoft against IBM.
Sometimes we want things to become a little more timeless like Linux or HTML where it is democratized and much freer and slower to chamge.
On the one hand, I hear what you're saying. You root for the underdog long enough and they end up becoming the dominant player with the power to match. But this feels like a pretty apples-to-oranges comparison to me.
Cloudflare has to buy, operate, and maintain huge amounts of servers with lots of hard drives, plus all the fiber/copper connecting them across the planet. Linux and HTML are software. They're only "decentralized" in the sense that they don't physically exist anywhere the way that a cloud provider absolutely must.
Cloudflare is still software. We consume these services by writing code after all.
Another example would be postgres. I can rent postgres, including whatever hardware is used to power it, from AWS, GCP or Azure. Or anybody really, like DigitalOcean or Heroku.
My 'postgres' code will run on every vendors service. The same applies to containers.
That is how I understood the comment 'Linux and HTML', something that is standard and universal, that affords portability and let's vendors compete on quality rather than relying on vendor lockin.
Yes, CloudFlare has software, and I think that only further highlights the difference between a complex cloud provider and a piece of software. What good is CloudFlare's software without the vast global network to back it up? Pick a problem, though, and there's probably an open source solution though: CockroachDB for global HA dbs, there's a bunch of containerized drop-in S3 API replacements, etc. But something tying them all together requires a lot of ops work that you don't get through software alone.
Is there something that is fundamental to the cloud that promotes vendor lock-in? I can understand it from operating systems and retailers.
But is there some fundamental obstacle that prevents most cloud services to be delivered by commodity RFC-compliant vendors? Or maybe some glue software layer, that, once you purchase a license, can abstract away the actual provider and make it simply a price decision?
I understand the providers will fight tooth and nail against commoditization, but once the initial wave of innovation and savage competition has passed, do they have a fundamental tool to prevent it?
> But two years from now CloudFlare could be doing the exact same stuff Amazon is doing now, and customers are locked in again, because no source code.
I hear this argument often but it always rings hollow.
A friend had a first gen iPod – when he wanted to switch, he discovered that the music he bought on iTunes couldn't be moved anywhere else because of DRM. That's lock in.
But this morning I was looking at the source code of an app built against the Serverless framework[1] and what I'm seeing is a bog standard WSGI application that uses a library to transform the inbound AWS "proprietary bits" into WSGI[2]. I'm not worried about lock-in there because all API Gateway + Lambda do is "translate an HTTP request into a JSON object and toss it to an app"[3] – what source code am I missing? The underlying Lambda/APIGW code? OK, but do I need it to run it myself? Not really.
Many – most? – AWS products tend towards this analysis. S3 is so locked in that, what, we now have multiple very high quality alternatives that are API compatible?
The real risk of cloud vendor lock in, from where I sit, comes from egregious pricing models that make it cheap to get data in & expensive to push data out. But I'm not sure Cloudflare has the juice to make this play work: egress pricing is essentially free money for AWS, so they've got lots of room to cut costs there – from what I've heard from people who negotiate real bills with AWS, they're very happy to give you discounts there.
This comment doesn't make any sense. I don't see how Cloudflare publishing the source code to their own hosted s3 service would help prevent lockin when an open source alternative to s3 is out there with hdfs. While s3 is a proprietary system, Any programs you write to operate against s3 can also easily be migrated to other object stores (Azure ADLS, Google Object store) with relative ease.
The thing that keeps people locked into s3 are egress/bandwidth cost. Until Cloudflare came along, no hosted object store (Google,Azure, including self hosted HDFS onprem or in the cloud) had economical bandwidth/egress costs.
This is actually one of those instances where I'm not sure how open sourcing a product would make it freer. Don't cloud providers make their dime by what-they-have, i.e. your data, instead of what-they-do (i.e., the source code)? As far as I understand, it's the prices of ingress vs egress that act as the mortar in these particular gardens.
Like if Facebook went full open-source... how does that help, if they retain sole custodianship of my data?
Which means that the REAL question isn't whether they open-source the code (not saying it wouldn't be nice... but it may come with lots of dependencies about their environment that wouldn't be easily replicable elsewhere) but whether their API is open.
And in the case of R2, they mimicked the API for S3. Which is as close to "following a standard" as I think it's possible to get.
Let's be realistic: capitalist organizations should not ever care about source code more than they care about getting money from customers. When you can share code, you do (because "open source" has been a marketing ploy for years now), but when it conflicts with making money, you don't. If they need to lock-in customers to make cash, they will, and if they find themselves a monopoly, they definitely will.
> I don’t understand your argument. A relatively small but innovative company is working to provide competition against the big 3 cloud providers … and you cringe?
Cloudflare is by no means a small hosting provider. By some accounts, cloudflare is world's leading CDN provider by a long margin, far ahead of AWS in this market, and it currently piles up about half a billion dollars in revenue.
Meanwhile, AWS holds 41% of the entire marketspace, with $14.8 billion USD in revenues per quarter. Extrapolating that a bit, $60 billion USD in revenues... $500 million is peanuts compared to this [1].
What Cloudflare is trying to do is remarkable considering what they are up against.
> What Cloudflare is trying to do is remarkable considering what they are up against.
I repeat, Cloudflare is already the world's leading CDN provider, ahead of AWS by a long margin. This is not a David vs Golias story. At most it's a CDN Golias vs a all-in Golias.
It's disingenuous to compare Cloudflare and it's CDN offering to AWS at face value based on gross revenue. AWS offers everything from build pipelines to satellite ground stations, and even provides backup services comprised of a big truck with armed guards.
Cloudflare is impressive and very successful, but it's by no means a small upstart, specially when it serves a market where it eclipse all competitors, including AWS.
In any case, it kind of is a David vs. Goliath. Cloudflare currently employs ~1800 people and has revenues of under a billion dollars. They don't qualify as a large enterprise by anyone's definition. They aren't a 2-man shop but they are very much a David in the broader market. Amazon is an absolute monstrosity in comparison.
I think OP is correct, I'm not sure a judge would say that the "market" here is the entire set of cloud offerings. If the market is CDN, Cloudflare is the current market leader.
I think this is generally how things are seen. For example, in the Apple vs Epic lawsuit, the judge said the market was "mobile gaming", and that in that space Apple was not a monopoly.
Amazon total revenue adds up, but in each of the cloud categories they operate in, are they the leader?
Cloudflare Workers competes with both Lambda and Lambda@Edge. Workers is a general-purpose compute platform that happens to run on the edge; it is not a platform intended to be specific to things that need to run on the edge.
It's probably better said as, "CF Workers competes with Lambda's synchronous use-cases".
Based on what I understand, there are still a few things missing to compete with Lambda's asynchronous use-cases. e.g. Step Functions, 15 min time limits, non-cron events (i.e. events for every CF product), batching events into the same execution, etc. While some of these are technically "not part of Lambda", to compete with Lambda CF needs the ecosystem as well.
Disclosure: 1. I'm an AMZN investor, therefore calling out that the ecosystem is worth keeping in mind. 2. I'm a NET investor, therefore calling out that I'm looking forward to seeing the ecosystem develop :)
I'd say that CloudFront Functions was a closer functional fit (and likely created in response to Cloudflare Workers). Lambda@Edge, despite the name, doesn't actually run at edge locations, but CloudFront Functions does.
Source? Assuming you're talking about 18% of traffic and not percentage of websites, how do you define what counts as traffic in that case? Transfer between AS's? Does internal traffic within AS's count? Does traffic between entities within the same AS count (e.g traffic from one AWS customer to another, or traffic from a Netflix OCA to an ISP?) I'm skeptical of any entities ability to fully measure the throughput of the internet even remotely accurately. The closest estimate you'll likely get is if you're a transit provider able to measure data transfer, and even then you'll be lucky to extrapolate within the correct order of magnitude from that for total global inter-AS traffic.
Why would you think that a company's market cap (not only the relevant portion of the business, but the entire company) is a reasonable marker for how big of a player they are inside of this part of the industry?
Heck, market caps at this point are almost entirely untethered from reality. {cf. Tesla}
Market cap is a reasonable proxy measure for how much money those companies can bring to bear to win the market (especially if losses[1]), should those companies decide that competing is a number one priority. Two examples from Microsoft: XBox (worked) and Windows Phone (failed).
Revenues or profits in the cloud market for each company are mostly a measure of how much they are winning. How much they are spending is a measure of how much they are trying to compete, and the amount they can spend is also dependent on profits in other areas of their respective business.
> Heck, market caps at this point are almost entirely untethered from reality
Most stocks have some basis in reality, and relative value still matters even if you think the whole market is in Lala land. The stocks mentioned are not diamondhand stocks. Variation in valuation is not hitting two orders of magnitude, which is what we have here.
A better measure might be some gross profitability figure for each company that measures how much each company can pump into competing (expenses), but that is hard to calculate, especially for Amazon.
Market cap. has little meaning nowadays especially in tech. It's just a pumped-up number. You could talk about revenue but that's a different discussion.
How does an additional S3 replica with better pricing help the market/innovation except adding one more competitor? And if that's all they end up offering (as per your statement) their cost is to high.
> It's one thing to buy into something that does have wide portability like a postgres but much harder to buy into the platforms that aren't open source.
I tend to feel the same as you - preferring portable solutions that I can host anywhere. However, the reality that we're all building CI/CD pipelines as much as we are actual software nowadays, and moving those from one cloud provider to another is no small feat. Even if you're using some infrastructure-as-code tool to manage all of your resources (e.g. terraform), you can't really `SET TARGET=GCP` and re-run the script (so to speak).
I guess the lesson is: spend as much time picking your infrastructure provider as you do your core technical stack. They're not easy to replace! :-)
Great point about CI/CD pipelines being hard to move between cloud providers. I wish someone will do for CI/CD what Docker/k8s did for cloud deployment and provide a non-proprietary structure that can be easily transferred.
But, depending on your use case, you could also try to describe your build process is some combination of make files and dockerfiles and then just call that from whatever CI you are using.
First time I discovered earthly I found it looked cool, but then I encountered the issue that it needed privileged docker which is not really practical in our setup, as this would require launching one VM per build job (we are using gitlab CI)
Is it still an issue? If yes, any plan to lift this limitation?
I don't see that as an issue right now. They are closed source. But the workers and key/value apis are (so far) either close to native, or very simple in nature. Porting away would be fairly straightforward. It may be a space to watch as more features roll out.
They're smart about this. It's infrastructure lock-in but not at the API/application level, as they are trying to stay as close to "just JavaScript with browser API semantics" as possible. Deno is a project that does this too. If you know service workers and web workers you know Cloudflare Workers. If you know JS OO you know Durable Objects (to a degree).
Think about it, the huge influx of web developers that have been growing up on just using JS. Look at their docs too. It's all very accessible, modern, low friction stuff all while they are selling us their infrastructure. And they communicate in a technical, programmer friendly way as opposed to the business/marketing jargon that we are used to by some of the others.
I think when you say it like this it makes a lot of sense. I'm not a JS dev, that's not my world, but I do understand building primitives for a given audience so if that's their target market makes sense. I just think as they try to battle AWS and explore wider demographics they're going to need to accept some of what that requires. CloudFlare isn't a slick brand like many of the startups around today in JS land. They're playing a different game as a public company so feels like wider adoption is going to require something more.
But saying that, I love when companies push the boundaries and CloudFlare are doing that. Conforming to the norms is just becoming another boring IBM like machine.
What do you mean by "Cloudflare isn't a slick Brand"?
I feel like they're the only cloud company that's been doing any real innovation for the last 5-10 years, and in a very approachable and affordable way.
I am confused. What would you like about CF that needs to be open sourced? Is it the front end? The datacenter operations software? Their algorithms? How would that solve the problem of portability? If there is anything to cringe, it is emotional appeal to OSS without thinking it through. Cloudflare is a massive service provider, not a database engine. OSS has a huge significance in basic building blocks of software - things like openssl lib.
Cloudflare needs to innovate more in order to properly be in a position to do long-term battle with Google and AWS.
Their overhead cost is a concern. As a free service provider to many sites that use them for encryption, they're possibly primarily benefiting (CDN-Wise) from Google's encryption assertions made in Chrome.
A few well-publicized system outages for CloudFlare right now would devastate their entire business model... It's happened.
In order to be independently competitive truly, Cloud Flare would need to probably quickly develop a new mobile phone OS, web browser, and scale their cloud hosting to market prominence very quickly in order to be able to preserve their current market share over the long term, which is a very very steep mountain to climb right now.
It's a very steep mountain to climb, because Google already has the aforementioned things in place, and AWS is firmly embedded with customers that don't want to face huge costs in refactoring apps.
CloudFlare needs to battle Google on many fronts to gain a proper foothold. If I was in leadership, I'd recommend a partnership with a struggling mobile phone company like RIM or Nokia, and possibly with Mozilla on the browser front. Reassuring users about and being committed to upholding personal privacy would be another solid move, and then getting rid of the "utility metered" approach to charging for cloud hosting and introducing simple monthly and annual rates with easier services would likely be ideal moves to ensuring proper growth and market share into the future.
This is the chess game that wins from my perspective... As companies like AWS and Azure develop more and more micro-service and licensing-locked cloud platform apps, it becomes harder and much more costly for those same customers to migrate anywhere else like CloudFlare. This is also why competing with giants is a dangerous game. CloudFlare would need to put a lot on the line to compete.
The smartest hosting customers often stay liquid in terms of which platform they can leverage and migrate to through chess in development, but the process of getting locked into one host platform is now a very real threat. Overall success has always been a chess game to me. Informed and carefully planned strategy, and conservation of resources, always works best.
The SEO impact is negligible at best unless you have it set up to specifically block crawlers (or you just forget about crawlers when configuring rules).
Maybe at some point there were crawlers that assigned spam reputation on a per-IP basis, but so much of the internet these days goes through Cloudflare and other CDNs with shared IP ranges that it would be insane to keep this practice up.
Maybe 2-3 years ago. Pretty sure it was IP based. CF drops you on a shared IP, its hit and miss of you end up on an IP next to a bunch of dodgy sites or not, do a reverse IP lookup to find out what else is running on your IP.
> It would be insane to keep this practice up.
What's the alternative?
Oh yea, did CF ever fix the domain hijacking issue for deleted sites?
Your experience is a bit unusual. We saw measurable improvement from edge caching. Argo routing gave us about 200ms back on TTFB where we thought it was worthwhile. We could of course set up our own edge caching with another provider (we also use Cloudfront a lot), but that doesn’t make Cloudflare bad for providing the same service. Similarly, Cloudflare isn’t bad if they provide a fast DNS alternative to Google’s fast DNS—and the mix of features isn’t identical.
I you don't leverage performance related features of a CDN (mostly cache), it's more a security layer. It won't improve performance until you get your hands dirty or ask a professional to tune it for you (and maybe you did).
A global DNS resolver may decrease performance, for instance it can give poor results on DNS based load balancers.
Interested to know how you assess SEO impact and your findings.
So the interesting thing, back then I think we were willing because of the nascent state of cloud services. We hadn't fully bought into any of this because most were still just buying hardware or renting servers and building their own software. S3 and EC2 were pretty pivotal in the move to this lock-in from a pure infrastructure perspective. Luckily s3 equivalent apis exist on every cloud provider now, its a staple cloud service but I think in 2021 as more things appear, they should be open source first. The open source companies start with that, I think cloud companies should actually open source the tech too.
Honestly you touch one one of the reasons I love Heroku so much. I've never seen a service that manages to do so much of the heavy lifting for me, but at the same time be 0 lock-in. I've helped move 2 apps off Heroku once they hit a point where they needed a bit more operational flexibility and there was zero work to disentangle them from Heroku operationally. Try that with AWS, GCE, or anything else.
