OpenSearch: AWS fork of Elasticsearch and Kibana

From my perspective, Amazon has made most of its profit price gouging consumers on bandwidth after vendor locking them into their ecosystem, where they bootstrap new services by wrapping open source software with some provisioning scripts, management dashboards and cookie-cutter API / console templates. Indeed, most of this is templated -- AFAIU, for example, each AWS service autogenerates its Boto bindings and parts of its console frontend via code generators. Amazon has really mastered the factory process of churning out new services, and when they find a popular one, they can invest more resources into developing it than the original team ever could.

And therein lies the rub. If Amazon is improving the software in a way that the original team couldn't, it's hard to say that the community isn't benefiting. I think what strikes me the wrong way is that Amazon is not doing it for any altruistic reason. In fact, Amazon contributes very little to open source in general, considering how much they take from it. Compare them to Facebook (React, etc) or Google (tons of dev tools) or Microsoft (VSC, TypeScript). What does Amazon have? Firecracker, kind of? And now a fork of ES because that's the only way they could continue making money off it without violating the license a small startup put in place to stop them?

Well, good for Amazon, I suppose, but I find myself instinctively disliking them for this. I'm not sure what the solution is. Hopefully technologies like Kubernetes and Terraform will encourage big customers to become at least cloud-agnostic, if not cloud-independent. At the very least it would be great if Amazon / Google / Microsoft stopped gouging bandwidth at such absurd margins. Or not. Maybe it will be their downfall as startups differentiate along those lines. That would be ironic, coming from the originators of "your margin is my opportunity."

Personally I'm doing my part by not building anything with vendor lock-in. It's great to be able to deploy to any cloud, if you value either robustness or flexibility.

I think that changes some of the more floaty ethical concerns. This is not a David vs Goliath situation. This is Goliath vs Super-Goliath.

At this point, I'm much less interested in the drama of which mega-corp is screwing over the other. I'm more interested in: how does it affect me? When the titans are done trampling over the rest of us, which side benefits me the most?

Its too early to tell, but it seems like it'll be Amazon. The product is more open. They have a demonstrated history of great support. Yeah, they gouge us on networking and everything else, but at least they're the devil we know, and buying into the OpenSearch ecosystem has a greater probability of being the more open solution into the next decade.

He must have possibility to earn $100k in process to do that. Well unless you really pissed him off.

If you earn $25k a year and he spends $50k in one year to take your cake. Well unless he really is your competitor that can make use of your defeat he still needs 2 years to get even. Then it probably is not easy money because there is always a risk he will not win. Maybe he can find better ways to earn more money than squashing some $25k guys.

There is no way on earth that I would look at my "value" and compare it with a £50K "value" to decide on my legal "battle-worthiness." It is quite likely that we both have similar (to the same power of 10) insurance for whatever it is we are duking it out over. Anyway this is all a bit circumspect.

Against a company with billions to play with? I'll just keep my head down and crack on and hope not to be noticed 8)

I do personally feel like that the asymmetry is smaller between elastic and AWS than the say an indie dev and a company with $1M revenue for various reasons.

This doesn't mean that there still isn't a meaningful asymmetry between elastic and AWS.

If OpenSearch is truely open then in theory you can find another provider. But for ElasticSearch you’re stuck with them.

I am a bit at a loss about that statement, you can run Elasticsearch on your on infrastructure

> If OpenSearch is truely open then in theory you can find another provider

Those are the key words. With an open source solution someone else can offer a turn-key solution that benefits from economies of scale.

So the idea is you can move from AWS to Azure if you wanted to with open source services underneath.

1. Amazon wants to make private changes to the management layer for their cloud offering and not share those.

2. ES doesn't want that, so the 7.11+ license restricts it.

3. Amazon doesn't want to have to explain to their customers why their ES offering is stuck on v7.10, so they're changing the name of it.

4. Elastic was really hoping this wouldn't happen, but they overestimated the value of their brand and Amazon called their bluff.

So yeah, nominally OpenSearch is unrestricted, but realistically few other entities are in a position to make or benefit from the private modifications Amazon will be making. For us normal people, ES and OS are equivalent today, so it's more about how they're going to diverge over time in terms of fixes, features, whatever.

> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge...

> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

AKA someone must be able to create aws.example.com if aws uses SSPL code. Not exactly the 'freedom to run it anywhere'.

https://www.mongodb.com/licensing/server-side-public-license....

If this interpretation holds, I feel like it could be a pretty big problem for companies like GitLab, who not only have deep integration with ElasticSearch, but offer it as a premium-tier feature:

https://docs.gitlab.com/ee/integration/elasticsearch.html

Maybe this really is just a cash grab from the Elastic side, like, "it's too easy to self-host rather than paying for our SaaS offering, so now you need to pay us for many common self-hosting use cases also."

SSPL doesn't come up under free or open source licenses partly for this reason, actually.

This probably qualifies it as a service, but since it looks like gitlab doesn't install it or redistribute it Elastic isn't going to come after them (if they don't use SSPL code then SSPL doesn't apply). Plus, GitLab is effectively open-source, so they might meet the qualification for using SSPL anyways. Of course, I am not your/a lawyer.

According to Elastic, "it depends" - if you can just search by entering a term in the searchbox, you're probably fine; If you allow users to use Elastic's query language, you're very likely in violation. If you let your customers define Kibana dashboards, you're definitely in violation.

It's worth noting that you can do a custom deal with Elastic, as long as you pay whatever they ask & accept their terms (or renegotiate them, which is a fairly painful process) - so maybe GitLab did just that.

> The freedom to run the program as you wish, for any purpose (freedom 0).

And though we're talking about open source instead of free software, without Freedom 0, the software still might as well be proprietary.

Edit: It also violates Rules 1, 5, 6 & 9 of the OSD. So no, let's not call it "open source"

https://opensource.org/osd

If you can't use the software because you're a cloud provider, that's rules 1, 5 and 6 easy.

If using it forces you to relicense all of your code under the SSPL that's rule 9.

It is well known at this point that the SSPL withdrew their request for recognition to the OSI because they do not meet the rules of the OSD.

I may be mistaken but I thought cloud-providers can use it and offer it for others to use as well, they just can't charge for that. But I may be wrong.

Literally, "as you wish". Stipulations is "as we wish".

And you can read it from the OSI themselves: "The SSPL is Not an Open Source License" https://opensource.org/node/1099

If SSPL isn't open source, neither is the GPL.

The AGPL on the other hand, was a huge mistake, IMO.

While you may disagree, you aren't going to convince me to take your word over theirs, especially when I have come to the same conclusions they did on my own.

Just like some projects are best under LGPL instead of GPL, AGPL has its place in the toolkit of free software licensing.

I think it probably could not. And if lucene were licensed GPL, it would not be possible for ElasticSearch to use this new SSPL license, it would be have to be GPL too.

At this point, they are directly violating that core principle as well as the uncontroversial OSI directive 6 which copyleftists like myself don't really have a problem with... So I'm not sure what the issue here would be other than you dislike the larger companies' involvement in OSS? I think myself and others would appreciate clarification.

Just like the guy that is $1M worth is not going to blow all of his money just to squash some guy. He probably has more powerful friends and maybe some connections but I don't see dumping $0.5m on lawyers just because he can take piece of cake from the other guy that will make him $10k a year.

Imagine head of the department storming into Jeff Bezos office telling that he needs 20% of all Amazon worth to squash Elastic, that would be funny. Quick calc with 20% I assume would be $20B which would be only x2 of Elastic, so I don't see something like that happening.

Nobody needs to feel sorry for anyone.

AWS is just offering customers what they want and there are many other companies doing the same thing (IBM's Compose, Aiven, Instaclustr, etc). How is this against OSS? This is the OSS industry operating as intended.

Allowing one of various foundations to take control of an open source project, can be beneficial for the community as its licensing is unlikely to change in the future. However it does present challenges for any future commercialization.

A good example of this is Confluent, which was founded by the creators of Kafka. LinkedIn, where Kafka was originally developed, transferred control of Kafka to the ASF. As the original developers, the Confluent team still has a lot of influence and contributes a lot of code to Kafka, but they do not wield absolute control. While this has presented some challenges to build a Kafka-centric business, and even led to them creating their own Kafka fork ("Confluent Server") they have still been successful. The community also has long-term confidence in the Kafka's license.

But it's moot, since Apache Lucene is part of the Apache Software Foundation and has much stronger promises about its licensing and governance. Which is not a small reason why Lucene is the de facto standard for search technology.

If Lucene had adopted SSPL they would have been forced to fork. But basically nothing really interesting happens at the Lucene level for ES anymore. (Sure, there's always a lot to speed up, optimize, etc. But anyone who buys ES needs the fancy stuff, security/audit/management, not a few percent more RAM efficiency.)

Some of the biggest changes within ES come from Lucene, like _massive_ reduction in memory footprint, enabling ES to use cases not even possible before.

OSS doesn't have anything to do with business models. Anyone can create open-source software and many do. The whole point is that it's free to create, see and modify. Some companies choose business models which include open-source software, and that comes with advantages (increased popularity and growth) and disadvantages (free usage, forks of codebase).

The reality though is that tech has changed and customers don't want to buy software, they want services now. ES has been slow to offer this, and they still offer it poorly, which is why AWS and other companies have filled in the gap. This is how business competition works.

Please answer these questions: Do you have a problem with the other companies (which are smaller than Elastic) that offer managed elasticsearch? Do you have a problem with multiple companies offering hosted Wordpress? Do you have a problem with any company that sells software or services that use open-source components?

Forks are a celebrated part of OSS and we only have more choice as customers now. The industry is better than ever. You keep ignoring these facts so at this point it's clear that you just have a personal bias against Amazon rather than a cohesive argument regarding OSS.

As I said, it's a tactic to change the subject. Instead of focusing on actions with bad faith, change the subject by saying they have a lot of money so Amazon is allowed to be competitive and fork the code.

> AWS is just offering customers what they want.

No. it's not AWS improving some services. It's about a multi-billion dollar company launching a campaign against OSS. They did it with MongoDB and it continues. Some see these actions as justifiable. Because OSS should be MIT and maintainers should live with donations. Others, however, disagree. It can be OSS and profitable (without Amazon actions).

I get that this is inconvenient for Elastic, but it’s good for users.

> The Apache License is a permissive free software license written by the Apache Software Foundation(ASF).[6] It allows users to use the software for any purpose, to distribute it, to modify it, and to distribute modified versions of the software under the terms of the license, without concern for royalties

[0] - https://en.m.wikipedia.org/wiki/Apache_License

Of course it is. Why wouldn't this be allowed?

> "fork the code"

That's the entire premise of OSS. Would it make a difference if they did it years ago? If not then what's the problem?

Again, the value AWS adds is in operational services because that's what customers want. Are you taking issue with all the other companies offering managed elasticsearch too?

I know this is a popular narrative, but as someone who works on AWS, I think you would be shocked by how small the individual dev teams are that build and maintain the services that everyone uses.

I'm not going to downplay the network effects involved. Of course AWS has a tremendous advantage in being able to standardize the customer billing, IAM, and EC2 Usage.

And there are economies of scale.

But individual AWS service teams are: * incredibly lean and focused * still have to make a profit on their own terms based on the infrastructure they build and the fees they charge customers * laser customer obsessed to solve people's (developer's) direct needs.

I understand the community's concern about AWS investment and approach to OSS. But I can assure you (though you have no reason to believe me) that the goal is never to embrace, extend, then extinguish. It's all in the service of going where the customers are, and solving problems that they tell us they have. The profits are a byproduct. The "working backwards" process is no joke. We spend a lot of time figuring out what is the right thing for customers to build, start building it, and THEN we think about how do we make money from it.

> and THEN we think about how do we make money from it

Do you really need to think? Looking at the on-demand pricing in US East, a m5.4xlarge.elasticsearch instance costs $1.133 an hour, while a m5.4xlarge instance costs $0.768 an hour. That's 47.53% of extra money. And like you said, it only requires a small team to build and maintain the service.

It is no coincidence that all cloud providers are trying to ramp up their hosted services for open source software, even GCP, who historically only focused on their own proprietary stack. There's a lot of money to be made.

If that were true, people wouldn't pay for it...

As we can see elsewhere in the comments, your biggest competitor appears to be the various kubernetes operators. With kubernetes as the common stack across multiple cloud providers as well as on-prem datacenters, the 10,000 customers can now contribute to the same operator project, to possibly get somewhere close to, or even exceed, what AWS can do with a small team of engineers.

Perhaps anticipating this trend, GKE now has an "autopilot" mode, such that a 30% profit margin is already included in the node pricing. That's one hell of a moneymaker.

curious if others have noticed this as well (capabilities without clear owners)? what does this depend on? time? company size? both?

As an outsider, I would guess huge swaths of developers with a massive hierarchy. Buildings full of folks working on AWS services. I have no idea and extremely curious.

at least 12 people. Of course they are in turn supported by many different teams, which also consist of who knows how many people.

Then, as the scale increases, and the number of features increase, so do the number of teams.

Lambda and CloudWatch are both a couple hundred people which wouldn't be surprising once you consider all the things that they do.

But I would venture a good half of all AWS services are built and run by one team of 10-12.

This sounds a little unfair, even if I agree with the argument that they’re free to fork OSS software and do whatever the fuck they want.

1. No fixed deadline, with a few exceptions of course, for platform-related projects.

2. Promotion/salary negotiation was not tied directly to release of external features.

3. A single engineer could be responsible for more than one service for the entire company, with 24x7 oncall.

With Netflix establishing such incentives, engineers naturally focus on getting infrastructure right, to the point that oncall 24x7 is a non-issue.

So, yeah, culture matters, big time.

Edit: another incentive was that a service was measured by its adoption. The more people praised it, the more successful the service would be. Requiring meetings to get buy-in for a new service was considered a sign of potential failure. As a result, every single team focused on making the value proposition of their services obvious. Path of least resistance was a given instead of a debated topic.

With that in mind, their behavior here makes a lot more sense, and comparing it with companies who have dramatically different products, like Facebook and Google, takes a lot of effort to understand the differences and what impact they have.

The AWS "value add" is only value add in the context of being locked into AWS in the first place.

Looking at what "as a service" providers of open source software do though, that is taking it a step further, since they wrap the software in a layer that _smoothes_ out changes for the user. Going back to the rental company that would equate to the car manufacturer deciding the indicator needs to be on the right side of the steering wheel now and the rental company installing an adaptor so that it remains on the left for you, to keep the look and feel for the user the same.

Not a perfect comparison, but they never are :)

The way they operate their cloud service leaves a lot to be desired and encourages maximum spend if you end up wanting to use it for anything demanding in production.

At my current client we started with their cloud and in a few months deployed our own in Kubernetes using the official operator.

It's a lot cheaper and gives us fewer headaches this way.

They must think their customers are cash machines.

It's always great (really, it was quite easy to get started and usually works) until it's not (a couple times have had indexes break, or had to reindex to a fresh cluster to fix balancing problems).

I'm sure LOTS of people use aws elasticsearch for big, user-facing stuff, but I often feel you'd be better off managing it yourself if it were truly critical.

However, we found that running our own cluster on EC2 with Cloudformation was relatively painless.

Also my saying that is extremely colored by experiences with pre-ES6 versions, where AWS's offering didn't have many of the configuration knobs available that you really _need_ to operate a decent cluster.

https://www.elastic.co/about/press/elastic-acquires-elastics...

Also virtual beers to you -- I really like Websolr!

I truly believe the negative voices are coming to the fore in this thread or they are paid Amazon folks (or they have a vested interest in AWS succeeding here).

Or people who have some form of vested interest in AWS succeeding (whether directly financial or indirectly benefiting from AWS being a monopoly) are influencing the discussion.

I was mostly thinking that in previous threads on this same subject these voices were not quite so loud.

These other opinions and negative voices you reference come from actual customers who pay Elastic large sums of money, and they feel they don't get good value and service for that money they're forking over.

Pretty sure this is the definition of SAAS and IAAS

Referring to my other example, in more detail: Elastic Cloud suggests operating your cluster across 3 datacenters for redundancy. This is a good idea. Then Elastic does maintenance in all three datacenters that your infrastructure is in at once and takes your clusters hard down. This is fucking stupid. Elastic's suggested solution to the problem: Operate a _duplicate_ cluster in 3 datacenters in a different region/provider. No guarantees that they won't do the same there either so it's not actually a solution.

I don’t think this is a fact. Amazon seems to contribute pretty significantly according to the pages [0,1] they put out that describes their contributions. Not to mention their membership in OSS foundations like Linux Foundation. [2]

You have the caveat about in relation to benefit they gain, but that’s pretty hard to measure. And I think isn’t really a good measure.

I’d like to learn more about why you make such an absolute claim and maybe you have some better measure.

I remember back in the 90s when big orgs (Microsoft, IBM) didn’t contribute to open source and can’t even think of any big orgs today that don’t contribute to open source. Even Oracle has big open source projects.

[0] https://amzn.github.io/ [1] https://aws.amazon.com/opensource/ [2] https://www.linuxfoundation.org/en/join/members/

To the sibling comment that asked about Firecracker -- I think Firecracker is awesome, and I did mention that in my original complaint. They even created it themselves! Well, a team of amazing engineers in Romania did. I have no personal insight into the matter, but it seems like they operate relatively independently from the AWS profit machine. Good for them too, it's incredible software. But I'm sure if they were to tell the story of how they got buy-in at Amazon to open source it, the same themes would come up -- how does Amazon benefit from this? In the case of Firecracker, the more people test it / harden it / run Doom on it, the more value Amazon can provide on its serverless platform. So again, unlikely to be purely altruistic intentions... but that's not to say there's anything wrong with that. I just find it all a bit distasteful in aggregate.

When I think of MS I think of C#, TypeScript, VSCode, .NET

When I think of Facebook I think of React, Flux, Jest, PyTorch, GraphQL, Haxl

When I think of Apple I think of Swift, WebKit

When I think of Amazon...I can't really think of anything

Apple made significant contributions to LLVM and Clang

Hell IBM has more open source contributions (many through the Apache foundation and standards committees) than Amazon, which is saying something.

This is an interesting one in the context of this discussion. It likely does not exist as we know it without Amazon's Dynamo paper.

(This information may be slightly out of date at this point)

But I think it's important to note that these companies don't contribute to open source out of any moral obligation, do they?

I think they do it to tie more developers and development around their eco-systems and products.

Maybe Amazon should get smart and start doing something similar. Or maybe they don't need that. But in any case I don't hold it morally against them that they don't. I think a bigger issue is it seems they pay and have been paying very little or no taxes.

https://www.cnbc.com/2020/02/04/amazon-had-to-pay-federal-in...

It is also due to Android Studio performance issues that Kotlin compiler improvements came to be, and also the compiler plugins for stuff like kapt and Jetpack Composer.

Android Java might be stagnant, not kept up to date with standard Java, yet it still rules in Studio tooling performance.

Microsoft's core business is developer tooling. In the 90's and early 2000's that could be closed-source and proprietary. By the 2010s it was clear that the only way to operate with the kind of tools they have is to be open source, so they pivoted. But their goal is still business.

Google built Kubernetes as a platform play to compete with AWS and Azure - brilliantly - by feeding engineer fears about "lock-in", giving them a set of tools that they could justify feeling "free", and then when the engineers invariably said "this is too complicated to build, maintain, and operate" they turned around and sold a GCP managed kubernetes solution! After all, who better to operate Kubernetes than the team that built it, amirite?

Android is the same play just competing with closed-source iOS instead of AWS.

Facebook built GraphQL for developers on THEIR Platform.

Apple built Swift for developers on THEIR platform.

Examples like this are just as cynical and capitalistic profit-driven as AWS "open sourcing" an SDK for interacting with AWS.

Amazon and AWS is a massive multinational corporation with development teams around the world. Including Romania, where we had a dev center for a very long time: http://romania.amazon.com/#/

There is no such thing as the AWS profit machine. All dev teams around the world operate with similar levels of autonomy and responsibility. It's just that some of them are working on super internal systems, some on super external, and some open source. Some make a ton of money, and some don't make any, but are beneficial to the overall developer experience/ecosystem, and so make sense.

I personally am against modern day corporate America, but I can't blame them for this. The software is given away free/libre/gratis to be forked by whomever.

Perhaps to combat this, one should choose a non "Open Source(TM)" license, but a source availbe license. E.g https://mariadb.com/bsl11/ (not my personal favorite, just an example).

Also, I definitely agree with/do the same:

> Personally I'm doing my part by not building anything with vendor lock-in. It's great to be able to deploy to any cloud, if you value either robustness or flexibility.

Could Elastic's business model survive if lucene adopted the SSPL license that Elastic has, saying it's the "spirit" of open source?

That is an interesting question.

MySQL for example took a proprietary API (the mSQL API) and implemented an open software for it. Then Oracle bought MySQL. MariaDB started and it quickly dropped full compatibility. Options for the developers/users. Great.

AWS/GCP/Azure on the other hand distorts the market. Just as Google/Apple/MS fund Chrome/Safari/Edge development from other sources, thereby distorting the market, forcing browsers to be free as in beer. (Which arguably hurts the market.)

You are suggesting this is not correct?

Elastic (and other vendors) complaining about this instead of using it for their own success is a problem of their own making. At least a few companies are finally learning.

We already know Amazon isn't interested in doing that (either at all, or at whatever price ES wanted, we don't know that).

They had no legal requirement to when ES was open source. So ES changed the licensing to no longer be open source.

So, Amazon could... a) decide to give ES a cut after all, b) decide to stop hosting ES, or c) fork the last open source version.

I don't think anyone is surprised they chose c? Presumably ES isn't either? Maybe ES thinks this will be good for them/bad for Amazon anyway, because they are hoping potential customers will abandon the Amazon fork and stay on the original ES fork?

Not sure why they'd be confident in that exactly. Maybe they know what they're doing.

As users/customers, we would rather have a choice of hosted vendors/platforms, and that it remain un-forked (so we can use/write software compatible with either vendor/platform). Competition is good for us as users/customers, that's in fact one of the reasons we choose open source, so no one vendor can set the hosting price all on their own without competition. We want to be able to choose among competitors for hosting, based on price, customer service, performance, uptime, whatever.

But ES didn't want that, they didn't want hosting competition to exist -- at least not without permission and agreed upon cut for them -- because, I guess, hosting was how they planned to make money as a company to fund development as well as profits for investors etc. So they changed their license to no longer allow it. So of the possible outcomes remaining... this one seems as good as any for the user/customer, I guess?

So, when you say "I'm doing my part by not building anything with vendor lock-in" -- I'm not sure which course you are suggesting. In fact, between ElasticSearch and new OpenSearch fork.. it's OpenSearch that is the one without vendor lock-in, right? OpenSearch is Apache licensed, and can be hosted by any vendor and still forked by anyone . It's ElasticSearch that has a license limiting what vendors can host it (without permission of ES), it's the one with vendor lock-in, right? So not building anything with vendor lock-in means... ?

No single capitalist wants competitive markets. They want monopoly, for themselves. It is only when they don't have the monopoly or an easy way to get it that they cry for competitive markets. And that is good of course.

I'm the first to say that AWS is too expensive, and I vote with my wallet (and the company I work for by proxy). But I'll never claim that there's any gouging involved.

So for AWS the term is arguably correctly applied.

But I'd be more worried about the market if AWS was artificially undercutting pricing because it would kill the incentive to create competitors or innovation in the space.

What outsized leverage have AWS had for a decade? There are multiple competitors at different levels, AWS are just better in terms of coverage/redundancy and amount of services.

Can you elicit the argument by which this is correctly applied?

But, I guess the argument could be similar to the case against Apple for its iOS App Store: there are lots of competitors, but the lock-in arguably creates a market definition of Apple customers. AWS customers are largely locked-in and at the mercy of AWS prices.

That's the argument. I'm not sure I buy it, but it's one perspective.

Elasticsearch was first released over a decade ago. ElasticSearch, now just Elastic, the company was founded over 9 years ago and now is public. Are they still a "small startup"? If so when does a company graduate from that status?

The beauty of OSS is that motives don't matter. If Amazon contributes and it's not detrimental in someway to the code, then it's a plus for anyone else who wants to use it.

All this being said, progressive corporate taxes seem more enticing year after year.

Really this is the secret sauce of the cloud. Create new abstraction layers where you can charge for logical separation on a physical basis. First VMs, then containers, then serverless... Would be cool if somebody did it with bandwidth (looking at you, Cloudflare). Why can't I buy an elastically sized pipe? Why do I need to pay for the stuff I put through it instead of reserving a size for the time I'll need it?

[0] https://twitter.com/eastdakota/status/1371252709836263425

It's like going to a restaurant and complaining about the price of steaks because beef should cost a lot less. There's a ton of other things involved, and yes, they probably have a decent margin, but not as much as you initially imply.

So they should be able to reach the lowest amortized cost for bandwidth with all of those costs included.

They price bandwidth so high because they can and they are still growing.

so, when should we expect this gloriously efficient competitive market to kick in to action?

my guess is that the AWS ecosystem, despite "price gouging", is simply the best and will be because this is really hard, non-glorious engineering, where solid reliability actually matters. anyone who wants to can go ahead and co-lo, so, whatever. people who want cloud will pay, and those who can't or won't, will not.

It's easyish to compete on bandwidth costs, but Amazon has a lot of other features many people want; it's harder to replicate all of those, especially the part about having a long history of operating such services and not making a lot of changes to make things more expensive or otherwise more difficult. Having to pay a much higher than market price for an easily replaced good in order to get a good that's less easily replaced is textbook anti-competive bundling.

If your bandwidth usage is high enough, maybe it makes sense to send it all through AWS direct connect, and pay for transit yourself; although even then, the AWS direct pricing seems a bit high.

And it's easy to replicate the water part (after all VPS providers are dime a dozen), the hard part is the food.

The point is that if you charge absurd prices for what has basically no marginal cost your pricing model is broken and 1) you are excluding customers that are particularly sensitive to this price or 2) you are liable to undercharge other customers that primarily use other services for which you are not charging what it costs you to provide.

For AWS, given the generally inflated prices, it's probably a lot more of 1) than 2).

There are plenty of other platforms as well, like Digitalocean, that have much lower bandwidth pricing.

Nobody else can give you bandwidth out of Amazon data centers. Amazon's advantage is having a ton of services that work together, and they take advantage of it to price gouge on bandwidth.

If you're buying a standalone CDN service you can get massively better rates.

If a colo provides you a 1 Gbps connection if you use less, you don't get a refund. And most of the time you don't get 24/7 saturation, or you get charged on some 95th percentile billing, and their networks are almost always oversubscribed anyways.

AWS is trying to disincentivize using it as a dumb pipe. They want you to use it smartly and if you just want to push static data there are much more cost effective ways to do it, such as CDNs, which are more cost effective for both you AND AWS.

Comparing AWS bandwidth costs and Colo and even other clouds like Oracle isn't fair because different things are associated with that cost.

A couple of comparisons:

Oracle Cloud give you 10TB of bandwidth for free, with overage charged at around €7.5/TB.

You can rent a VPS from the likes of Hetzner, and they will throw in 2-20TB of bandwidth for free, with overage charged at something like €1/TB - AWS charge an eye-watering €125 for each TB!

I think the reason the big 3 (AWS, Azure, GCP) still charge such huge amounts is that they profit so greatly from it, and there is more than enough business to go round.

Or that their networking does vastly more and is of better quality? Hetzner can't provide you with everything around a VPC that AWS do. Just a tiny example - peering VPCs across regions, which is free.

1. High bandwidth charges are an effective form of lock-in. Once your data is there, it's prohibitive to move it out again.

2. Bandwidth use is very poorly understood in many businesses, compared with simpler metrics like storage, memory, and CPU. AWS can run razor-thin margins on things that people easily compare to on-prem or VPS-style offerings, and then make the money back in areas like network traffic, fine-grained monitoring, and other items that as less obvious.

I reckon DO have seen the big providers getting away with it, and they want a piece. Why wouldn't they, when there is apparently so little pushback?

Can I ask, are you in a data center? US or Europe?

Some of the larger bandwidth transit resellers like FDC will do Cogent for $0.02/Mbps. They have a marketing site at epyc100gig.net (not an affiliate or employee; just a FDC customer).

https://he.net/cgi-bin/ip_transit_quote is where I'm seeing the $200 number.

I believe that kind of low-for-1G-commit pricing is for their fully owned FMT1/FMT2 US CA facility. You have a lot easier peering in EU (AMSIX, DECIX, etc) that will help compared to the US's love of commercial exchanges like Any2/Coresite/Equinix where peering costs practically more than transit.

Amazon on the other hand developed a free and open source auth plugin and anyone is able to deploy it no problem.

To provide something for free, public use

To get the world to help you maintain your software

A reason to not make open source software:

You want the exclusive right to offer that software as part of a paid service

This is not the first instance of a company not understanding the last point there, and it won't be the last.

IMO, FOSS licensing is completely broken. Its definitions (of what is free/open) are from a boomer's era that is no longer sustainable. At least I wouldn’t want any of my FOSS projects become “corporate strategy” of any particular proto-nation.

Firecracker. s2n.

Not much, I agree

"having subsumed the opensource version of ES, we are now relicensing, calling it our own, and would be really happy if the opensource community would lie to contribute, because actually we don't totally understand how this product works. Many thanks to all who help us"

The issue with AWS version are many fold, but the main one is that it forces extra usage of expensive EC2 units, for the following reasons:

1. Blue/Green updates -> Start a new cluster with new version, lock current cluster, copy over all the data (can take over a day), at the same time write to both clusters, when finished, lock both clusters while endpoints are swapped over, unlock new cluster, trash old cluster. During this process Customer pays for both. - Solution, done properly, fire up new node with new version, swap it in, wait for 'green', take out old... wait for 'green'.. rinse and repeat. Result.. system never goes down, endpoints remain the same, less cost to customer.

2.There are a minimum of the folloowing node types: - Master (small) x3 - Data (heavy on storage, medium on memory) - Hot Data (very heavy on memory as shards have to be held in memory) - Coordinating (query) nodes, heavy on memory, light on storage (cos there is no real storage) - Ingest (same as Query). - voting only.. tiny - AI/ML heavy on memory and storage.. cos they do real work In the AS world they have: - Masters - Data - Hot Data (cos they are really pricey) The Data nodes do all teh functionality of the data, ingest and query nodes. Th emain query always gores to a data node, while it passes to other data nodes to get the data out, then aggregates locally to it... so its incorrect usage of the system. A data node should only ever deal with its own data, and pass the results it finds back to a node away from the data.

As your system is squeezed.. you add data nodes... not coordinating/Query or Ingest nodes, which you probably need. But thats more money into the coffers.

3. Their userhasging function is also old (2011 vesrion of bcrypt) , and fails. Any static password produces different results everytime you use it.. at least on the current opendistro. So you are forced into either not using security, or using proper security, which can be cumbersome across the cluster (if rolling your own). however.. on the cloud version they have base level security working, so thats Ok.. they arent using their own 'open' software.

I could go on.. but its all flaky, and misunderstood at the core developer level. Toput on record, I have spoken twice to teh core development team to describe how updates should happen.. the last time 18 months ago (by 'spoken' I mean a face to face video call) .. so they know hoe it should be done.. but dont do it.

4. I have noticed that there are some functions/methods available on the setup in Amazon Linux, that dont exist on other Linux versions (centOs/Debian) that are security related. AWS Linux is 'lifted' from Redhat.. so another piece of software that they didnt write.. but obviously Redhat are happy with this. Maybe they got the licensing deal sorted .. who knows.

basically gores like this:

"Who would actually install, in production, what essentially is very close to pirated software?"

Roll your own.. its a bit of grunt work up front, then 50% the cost of the cloud version.

0. https://en.wikipedia.org/wiki/Halloween_documents

Is Starbucks too big and a bully? Sure, they force Mom and Pop shops to close by out-competing them, and that sucks. But bullying? I believe that's just Capitalism.

Or say you're 6'6 and weigh 230LBS and you join a football team full of people who are 5'9 and 175lbs. Are you a bully just because you're bigger?

ES basically handed them a platter with a goose laying golden eggs and a sign that read "Free Goose" and hoped they wouldn't try to make money off the eggs.

I'd say it's more like a mom-and-pop coffee shop giving free coffee to patrons hoping to make money on cookies, and Starbucks coming in, taking the free coffee, opening a nice stand right next to the shop and selling the coffee they got for free.

I'm having trouble justifying this ethically.

I don't see how it's unethical if you do something that someone said was perfectly fine to do. "Obvious chosen outcome" comes to my mind long before "unethical".

To expand across the world they franchisedit.Th eagreeement was, you take te hfranchise, if yoou hit x target in 4 years, we will pay you y amount (large) ...and take it over.

That worked well. DOnt see any reason why Starbucks, or anyone else could nottake that on board, then everyone is a winner.

Now, assuming Starbucks charged you for the coffee, and you then re-sold it, this should also be fine. Starbucks is charging you presumably a rate with which they can recoup their costs. But if they are selling it below cost, they are clearly putting themselves at risk. A lot of businesses take this kind of risk as a strategic part of their business, like with making the coffee free. But you have to do it in a way that a competitor can't turn around to their advantage, or you're screwing yourself.

Enter the concept of "not for resale". If a seller enters into a contract with a buyer, that contract can stipulate that the buyer can't resell the goods. Starbucks could theoretically require you to sign a contract saying you will not resell their coffee. That's pretty standard with licenses, even software licenses.

ES must have known that their license did not forbid reselling. Yet they based their business model on this resellable coffee that they were giving away in order to make money on cookies.

Is it Amazon's fault that ES chose a business model where they were selling coffee at a loss? Does Amazon have an ethical responsibility to keep ES's business afloat? Should we find any business unethical that tries to undercut the customer base of a rival, or take advantage of a rival's shaky business model?

I think you have to come up with a whole framework for ethical competition, because one rule at a time isn't gonna capture it. (But I also think Capitalism is inherently unethical)

It's not "lock-in", it's providing a great all-in-one solution. You can host everything you want to host on AWS, which has good stability, good latency, etc. People are locked in because the DX around using AWS for everything your platform needs is just better than other platforms / having different services on different cloud providers (at least for many people).

If you're "cloud-agnostic" and could migrate away from AWS in the blink of an eye then you're paying for an overpriced VM offering and should probably migrate to a cheaper hosting provider immediately.

No this is what everyone suggesting this does not get. The offerings are not equivalent.

There are a baseline of services that the cloud providers offer that can be made functionally-equivalent. It's not just EC2 but more like EC2,S3,Lambda,RDS,DynamoDB,ECS,EKS (plus some others and of course the other cloud's equivalents). The secret sauce is in the APIs and permisioning and all of these available within the same VPC (talking to each other without paying bandwidth costs).

"Cloud-agnostic" has _never_ meant "just VMs". Some of these services are majorly hard to duplicate on your own VMs as well. Feel free to implement "cheap VM hosting + S3" and burn cash on transit costs.

Cheaper hosting providers do not give you this by miles.

That's one of the real key issues, I think.

If bandwidth is 10x cheaper, then maybe you decide it's fine if only half your inter-server bandwidth is free.

You're conflating the difficulty of migrating a complex system to anywhere with "vendor lock-in". It would be harder to migrate an Aurora RDS Postgresql instance to an Aurora RDS MySQL instance than it would be to migrate from Aurora RDS (postgres) to a hosted postgres anywhere else.

That to me screams "not vendor lock-in".

Obviously the more complex a system is the harder it will be to migrate, but that has nothing to do with Amazon trying to "lock you in" and everything to do with it just being a complex system that there is no industry standard solution for.

2) Permissions as a whole are usually very ingrained into much of what orgs rely on.

With regards to permissions, I don't feel like it's possible to permission across an entire platform and not make it difficult to migrate over – do you know of any provider or platform that allows for cross-platform authentication with permissions?

I agree about permissions. I'm just illustrating where the lock in occurs.

Elastic should have a for-profit and a non-profit company taking donations that would actually control the open source code and hiring the core part of team working on it.

I mean, we know how badly Amazon is behaving here, but at least they should have a option where they could realistically invest.

Asking for a company to invest in a competitor that can grow and eat their lunch with the money being invested by them is not realistic. Even because the company investing the money would want to know if that money is actually being invested back in the open source software and not used by a competing company.

If, giving this choice, they didn't invest back in the foundation, it would be much more clear that they are doing it in bad faith.

I guess we can check their github repos to see if that's the case.

On top of that AWS has done a lot of contributions upstream, particularly around the linux kernel, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin..., (particularly the virtualisation stacks involved), some around OpenJDK at what looks like an increasing pace, and the like.

To be clear: not an AWS employee.