Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atlas by Hashicorp

atlas.hashicorp.com

Post reply on HN
Print view View original

31–40 of 57 posts

Re: Atlas by Hashicorp

#31

Post by eikenberry »

alexatkeplar wrote: post #28

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant ( https://github.com/snowplow/dev-environment ) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too. The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Gola…

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy.

IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API. With something that moves as fast as AWS this is great.

Re: Atlas by Hashicorp

#32

Post by alexdean »

eikenberry wrote: post #31
alexatkeplar wrote: post #28

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant ( https://github.com/snowplow/dev-environment ) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too. The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Gola…

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API.…

I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases

But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormation using anything other than the Java client library is crazy IMO.

Re: Atlas by Hashicorp

#33

Post by [deleted] »

alexdean wrote: post #32
eikenberry wrote: post #31

Earlier quoted context omitted.

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API.…

I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormatio…

[deleted]

Re: Atlas by Hashicorp

#34

Post by Rapzid »

alexdean wrote: post #32
eikenberry wrote: post #31

Earlier quoted context omitted.

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API.…

I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormatio…

The .NET sdk is pretty fantastic as well.

But anyway, goamz is "Hashicorp's" AWS Go SDK in that Hashicorp forked it and refused to work with the larger community because it's "critical" to their business. This has, at least until super recently, stranded certain functionality into the different forks and severely fractured the AWS Go offerings. True story.

Ultimately, what the Go community probably needs most is Amazon to step up and support a Go SDK officially. The Java, Ruby, .Net, and even Python SDK's are very robust at this point. I can't speak to the others.

Re: Atlas by Hashicorp

#35

Post by jesseendahl »

porker wrote: post #30
tonglil wrote: post #5

Earlier quoted context omitted.

- Vagrant is a given, wonderful. - Packer is for syncing VirtualBox, AWS AMIs, and what not for quick and stable starting points, also wonderful. - Consul is great for monitoring and running a services oriented architecture, haven't pushed it to its full potential though. - Serf: n/a, haven't tried yet. - Terraform: n/a. We are still using Ansible as the provisioner. Overall, good ecosystem, would recommend.

> - Vagrant is a given, wonderful. It's really useful, but on my MBP I've found using it abysmally slow (VirtualBox backend, website code shared using NFS, DB and everything else stored in VirtualBox VM and not shared folders) - page load times taking upwards of 20s (sometimes even a minute) when running direct on my MBP would be under 0.3s. Never figured out the issue, in spite of extensive research and tweaking. Re…

Apparently syncing file changes between the VM and host via rsync leads to a lot better performance than using NFS. Worth a shot at least:

https://www.vagrantup.com/blog/feature-preview-vagrant-1-5-r... http://www.midwesternmac.com/blogs/jeff-geerling/nfs-rsync-a...

Re: Atlas by Hashicorp

#36

Post by kcorbitt »

porker wrote: post #30
tonglil wrote: post #5

Earlier quoted context omitted.

- Vagrant is a given, wonderful. - Packer is for syncing VirtualBox, AWS AMIs, and what not for quick and stable starting points, also wonderful. - Consul is great for monitoring and running a services oriented architecture, haven't pushed it to its full potential though. - Serf: n/a, haven't tried yet. - Terraform: n/a. We are still using Ansible as the provisioner. Overall, good ecosystem, would recommend.

> - Vagrant is a given, wonderful. It's really useful, but on my MBP I've found using it abysmally slow (VirtualBox backend, website code shared using NFS, DB and everything else stored in VirtualBox VM and not shared folders) - page load times taking upwards of 20s (sometimes even a minute) when running direct on my MBP would be under 0.3s. Never figured out the issue, in spite of extensive research and tweaking. Re…

I have the same Vagrant setup you do (nfs-shared app directory, everything else inside the vagrant box), and while I see overheads of 1.5-2x, I've never seen anything like the 60x overheads you're describing here. Something seems off in your configuration. Perhaps you're memory-limited and the vagrant box is thrashing your swap file every time you make a request?

Re: Atlas by Hashicorp

#37

Post by alexatkeplar »

Rapzid wrote: post #34
alexdean wrote: post #32

Earlier quoted context omitted.

I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormatio…

The .NET sdk is pretty fantastic as well. But anyway, goamz is "Hashicorp's" AWS Go SDK in that Hashicorp forked it and refused to work with the larger community because it's "critical" to their business. This has, at least until super recently, stranded certain functionality into the different forks and severely fractured the AWS Go offerings. True story. Ultimately, what the Go community probably needs most is Amaz…

Good to hear about the .NET library. I hadn't heard the story about goamz, that's unfortunate. I do know that there are SDKs which Amazon _only_ make available in Java and Python, e.g. the Kinesis Client Library (http://docs.aws.amazon.com/kinesis/latest/dev/kinesis-record...).

Re: Atlas by Hashicorp

#38

Post by tobz »

What is a node in terms of pricing?

Kinda/sorta feels like a stranglehold to have this remaining piece of the Hashicorp puzzle be free and then to start charging for it. :(

Re: Atlas by Hashicorp

#39

Post by wallflower »

eikenberry wrote: post #31
alexatkeplar wrote: post #28

Great to see the Hashicorp vision coming together across the individual tools! We are huge fans of Vagrant ( https://github.com/snowplow/dev-environment ) and Packer at Snowplow. Just starting to experiment with Serf and potentially Consul. The "Hashicorp way" of devops has really helped us too. The only real weakness I see in the stack is Terraform. The elephant in the room is CloudFormation, and being built in Gola…

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API.…

The sequence at AWS seems to be:

  1. Announce something in a blog post (sometimes get everyone really excited)
  2. Add access to that feature/setting in the AWS Web UI
  3. Add access to that in the official API
  4. Add access to that in aws-cli
  5. Add access to that in cloud formation stack creation
It seems sometimes weeks and months lag between steps (e.g. steps 2 to 3).

Re: Atlas by Hashicorp

#40

Post by vdm »

alexdean wrote: post #32
eikenberry wrote: post #31

Earlier quoted context omitted.

Goamz suffers from the same problem that all the libraries that try to hide the actual API do... that they can't keep up. Even boto has this problem as keeping up with the latest version isn't always easy. IMO the best of the AWS libs is github.com/bmizerany/aws4. It only wraps the auth, the API and results are up to you. This requires more work but means you never have to worry about the lib keeping up with the API.…

I'm not sure that's true of all the client libraries - I'm pretty sure that the Java library is used heavily internally within Amazon to leverage AWS services. Just look at the release history: https://github.com/aws/aws-sdk-java/releases But you're right, maintaining even a blessed third-party library like boto is a massive undertaking: 437 contributors, 431 open issues, 192 open PRs. Competing against CloudFormatio…

This Clojure library agrees with you, it reflects and post-processes the AWS Java library. https://github.com/mcohen01/amazonica
Post reply on HN