OpenSearch: AWS fork of Elasticsearch and Kibana

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by fastball on Monday April 12, 2021 @12:45PM (#26781660)

I think the claim that Amazon is winning through "vendor lock-in" is pretty silly. Honestly anyone who can't quickly migrate the stuff they're hosting on AWS onto one of the many other cloud platforms is pretty bad at DevOps. If you're using K8S/Docker/etc it should be trivial. But even if you're not, the vast majority of AWS offerings were either built to be API-compatible with other existing tools (e.g. postgres-compat Aurora RDS), are literally identical to other services you can self-host (e.g. ElasticSearch) or others have built services compatible with AWS services (e.g. DigitalOcean's "Spaces" aim to be API identical to AWS S3 – you can literally use Amazon's S3 client libs to interact with various S3-compat services from other clouds).

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).

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by real_joschi on Monday April 12, 2021 @12:56PM (#26781830)

If you're not using any of the AWS services, that might be true but then you're also leaving a lot of potential on the table.

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.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by busterarm on Monday April 12, 2021 @01:20PM (#26782201)

> 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.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by Dylan16807 on Monday April 12, 2021 @01:55PM (#26782700)

> all of these available within the same VPC (talking to each other without paying bandwidth costs).

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.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by busterarm on Monday April 12, 2021 @02:45PM (#26783397)

It's always worth measuring/understanding your application because likely it's not "half" but skews heavily one way or the other (in vs out).

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by dilyevsky on Monday April 12, 2021 @09:54PM (#26787370)

It’s not super hard to run your own s3 or peer with wasabi and pay flat transit rate (probably like 10x cheaper than your s3 egress)

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by ukd1 on Monday April 12, 2021 @01:00PM (#26781895)

I buy the main reason being the all-in-one solution; the comprehensiveness is attractive. However, I think you're underplaying the lock-in: migrating clouds is non-trivial - mostly due to stuff that's not running in k8s/docker/etc; stateful apps (Postgres, etc), and or just static data like s3. This takes time, and careful planning and sometimes downtime - and is mostly avoided due to it being hard.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by fastball on Monday April 12, 2021 @02:57PM (#26783564)

I specifically talked about state and storage.

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".

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by StreamBright on Monday April 12, 2021 @02:53PM (#26783511)

Do you know can I migrate my sophisticated security setup easily over? Including users, groups, roles, policies and instance policies.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by fastball on Monday April 12, 2021 @02:59PM (#26783588)

Everything on AWS is accessible via API, which means you can easily automate the migration process. So do that?

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.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by JamesSwift on Wednesday April 14, 2021 @09:43AM (#26806937)

It appears you are using one definition of lock in while others are using another. What your version of lock in seems to entail is deliberate actions by the hosting provider to force you to stay with their offering. When I (and others it seems) use it, it just means the natural friction that keeps you in the provider. It doesnt have to be a deliberate strategy to be lock in. That doesnt make it any less difficult/painful to migrate.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by JamesSwift on Monday April 12, 2021 @12:59PM (#26781877)

The lock in is real, but they are also the best cloud option and its not even close in my opinion.

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by fastball on Monday April 12, 2021 @02:58PM (#26783571)

What would you say they lock you into? What is AWS doing specifically that makes it harder to move between providers than if they were not doing that thing?

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by JamesSwift on Monday April 12, 2021 @03:39PM (#26784135)

1) A vast majority of users are relying on managed services to some degree.

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

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by fastball on Monday April 12, 2021 @04:15PM (#26784586)

What do you mean when you say managed services? Because to me managed services are definitely not vendor lock-in because you can self-host most of those services and just migrate your data over.

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?

[ Parent | on HN ]

Re:OpenSearch: AWS fork of Elasticsearch and Kibana by JamesSwift on Monday April 12, 2021 @04:44PM (#26784915)

I generally think of managed services as anything not run directly on EC2.

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

[ Parent | on HN ]