Internally at Amazon, Pipelines (which inspired this service) was a lifesaver. Apollo (which is the inspiration for CodeDeploy) was also helpful, but should probably just be replaced by Docker or OSv at this point.
But if they ever release a tool that is inspired by the Brazil build system, pack up and run for the hills. When it takes a team of devs over two years to get Python to build and run on your servers, you know your frankenstein build system is broken. It could be replaced by shell scripts and still be orders of magnitude better. Nobody deserves the horror of working with that barf sandwich.
hah. I believe you either don't understand Brazil (the build system) or you had to deal with inexperienced people that don't get it. IMHO the internal Amazon tooling is THE reason Amazon is able to build things so fast and to iterate so quickly.
If you are on a team that does nothing but Java on a MAWS or corp platform, brazil was built for you and I wouldn't be surprised that you like it. But...if you deviate slightly, you run the chance of not getting what you need. If you stray away from the JVM or Ruby, chances are you will never get anything at all, let alone what you need.
ruby, java, perl :S , python, roll-your-own
have done it all. :) yes, the learning curve can be pretty steep, but one thing that always helps is that the probability that there is somebody out there that did it already is very high. you just need to be curios and invest into learning it and looking at what others are doing.
Yep. Definitely!
One caveat, in short, is: Everything involved in the build must be placed under the nix store (/nix/store). Which, for some software, can cause issues: They might have a hardcoded runtime path that references /usr/lib.
Nix provides tools to resolve these assumptions, but they can still be a sticking point at times.
There is also, more or less, a unsafePerformIO that can be used. Which is discouraged. Still, for private builds the cost can be acceptable.
Assuming I understand the question correctly: Yes.
Nix uses a pure evaluation model so it enjoys the property: An artifact in the nix store is uniquely identified by the closure used to build the artifact. For any artifacts A, B if and only if the closure used to build the artifact are equal then the artifact file path will be equal.
This creates opportunities for sharing between builds that can be hard to achieve in other systems. One form of sharing "referencing a derivation in multiple apps" works as expected, just like other systems: Each app will reference the same artifact.
(a derivation is the closure to be evaluated to build an artifact in the nix store. Well, attribute set of closures.)
Suppose a derivation is assigned to the variable "commonData" and two derivations "appX" and "appY" reference this closure. "commonData" will be built once and both app derivations will receive a path to the same file in the nix store.
The other form of sharing comes from the equality comparison being based on the closure and not the name used to reference the closure.
Ehh.. I'm butchering the explanation... I think there is a succinct PL term that covers this.
Suppose we have a derivation:
let x = mkDerviation { name = "foo"; builder = aBuilder; src = /share/src/foo; }
which is referenced by another derivation
let y = mkDerviation { name = "bar"; builder = aBuilder; src = /share/src/bar; inherit x; }
"y" will force the evaluation of the "x" derivation's closure. The source directories, since they are not in the nix store, will be copied to the nix store first. (By an implicit conversion between local files and nix store paths)
So far so good, but what happens if there is another derivation like so?
let z = mkDerviation { name = "zab"; builder = aBuilder; src = /share/src/zab; somethingLikeX = mkDerviation { name = "foo"; builder = aBuilder; src = /share/src/foo; }; }
"somethingLikeX"'s equation is equal to "x" but not the same reference.
What will happen if z is evaluated after y? (assuming aBuilder is the same)
First, the derivation "somethingLikeX" will be evaluated. Ah ha! That closure is equal to the closure for "x" above! Which has already been evaluated. So that evaluation result will be shared. Even though "z" does not directly reference "x".
This can result in more sharing than the developer explicitly requested: Equal closures are shared.
I thought that was because they MVP everything? Still waiting on a NAT service and a slew of ELB features that are "coming" so.. I'm not aware that they iterate particularly quickly across the board. Tags are still "kinda" supported to differing degrees or not at all across services.
This is interesting for lone developers, but I'm not sure about the pricing:
You’ll pay $1 per active pipeline per month (the first one is available to you at no charge as part of the AWS Free Tier). An active pipeline has at least one code change move through it during the course of a month.
Does this mean that every time you run a session you pay 1 EUR no matter how many stages the session has (pull, compile/build, test (multiple tests) and deploy?
From my reading, it appears to hook up to a Jenkins server, potentially that you control, so it can do anything Jenkins can, which includes building windows artifacts.
As far as I can tell this is more about orchestrating builds, to actually build your game you'd need to run jenkins on an EC2 instance and connect it to CodePipeline.
AWS sells an API. Serious users don't use the web console. Need to tend your cluster of 1000+ EC2 servers? The Web console will fail for that. The console fronts the API, just like the CLI tool.
AWS just builds the basic UI's to make it possible for people to do simple things. If you get deep into the weeds, you'll need to use the API directly, i.e. for installing an SSL cert on your CloudFront distribution, or launching a 2K node computing cluster.
If you don't like the UI, make your own and sell it to people. That has become a viable business model for various startups, or launch your own hosting company on top of EC2 like Heroku.
Why? I'm amazed people expect a light and airy, responsive, material designed enterprise control panel that is redesigned yearly. These are backend tools. The UI works and was (1) not meant to be sexy and (2) not meant to push sales.
AWS is in a race to the bottom, cutting prices all the time. Hiring 50 UX devs to rewrite their web interfaces doesn't comport with Jeff's lean vision.
The initial impression of a new AWS console is pretty overwhelming. I've stuck with DigitalOcean and CloudFlare over Amazon alternatives partly because every time I sign into AWS all I can think is "Heck. Which of these product names and acronyms matches the thing I came here to do?"
I will fully admit that when I started using AWS, it took me a while to learn Amazon's "language." Unfortunately Amazon does a bad job of distinguishing between their core offerings (e.g. S3, EC2, Route53, etc) and their very niche ones (e.g. EMR, Kinesis, SWF, etc), so new users are left scrambling to figure out what they need to know.
I understand their desire to create unique "products" that people can use in a conversation (e.g. "Have you considered Route53 for your DNS?"), but ultimately mixing common and niche things together and giving everything confusing names is likely doing Amazon more harm than good.
That all being said, Amazon are slowly improving. See this page[0]. They now have a list of their products and how they fit into different categories. But the console can still be a jumbled mess of different acronyms and made up words.
This is why I REALLY like the MS/Azure way of doing things.
"I need to host a web app" "Okay there's Azure Web Apps for that"
"I need to store lots of files" "There's Azure Storage/Blob Storage for that"
"I need a SQL Database" "There's Azure SQL for that"
"I need a VM" "There's Azure Virtual Machines for that"
"I need a Data Lake" "There's Azure Data Lake for that"
"I need a Data Lake" "There's Azure Data Lake for that"
"I need a Data Warehouse" "There's Azure Data Warehouse for that"
"I need a Cache" "There's Azure Redis Cache for that"
I could go on, but you get the picture. Cute names are not the way to go when you're offering dozens of services which may overlap with eachother somewhat. I can just scroll down a list of things MS offers on Azure and be able to easily pick out the things I need to use by their names alone.
"A massive, easily accessible data repository built on (relatively) inexpensive computer hardware for storing "big data". Unlike data marts, which are optimized for data analysis by storing only some attributes and dropping data below the level aggregation, a data lake is designed to retain all attributes, especially so when you do not yet know what the scope of data or its use will be."
The intended use is to be able to use things like Hadoop or other tabular text processing systems to glean information from enormous amounts of data, then once valuable insights are found, use the Data Lake source to process it into a form suitable for a data mart, or preferably, a data warehouse.
Do you really find the AWS console usable? I was shocked the first time I logged into that thing, I said to myself, "what the hell is that?". AWS is certainly one of the most complicated app available online, and i'm sure it is maintained by a lot of different teams but a serious designer didn't do the UX/UI. It feels SO clunky.
> Not that it matters, but I think they use GWT.
the problem is I think it's much more difficult to iterate with this kind of abstractions.
Netflix has long had bits of horrid UX. They just finally replaced the agggggggonizingly slow scroll left/right as you're browsing through the suggested content carousels.
An internal tool like Asgard doesn't have the same need a customer-facing tool like the AWS Console does to be user-friendly, either.
This used to be the case - new features usually launched API-only and console came later - but I think Amazon has woken up to the fact that many customers want to play with it easily before they go automating everything using the API.
Pretty app - Ehh, I could add this new feature but it would make my menu go off screen, maybe I will skip it and work on making the profile icon sparkle.
Function ugly app - Ehhh I could research better fonts, but sans serif will work - let's go code some new featues.
I agree it doesn't look great, but I assure you they have A/B tested the shit out of every page they have ever rendered. Aesthetics aside, I am sure there is a justifible reason they do everything in their UIs.
The major tech cos bundle their big announcements on their annual conference day. Amazon, Apple, Google, Microsoft all do this, and all have had multiple stories on HN's front page at the same time. As long as the announcements are significant and HN-worthy and they do it rarely, it seems ok. A story doesn't become spam just because it's coeval with others.
If one or two of the stories are noticeably weaker than the others, or especially if they've appeared on HN before, we'd appreciate users pointing that out, since we can penalize those.
I agree. A single post would just end up unmanageable and dominated by whoever had the top comment. (I always yearn for a 'by date' sort for HN comments as often the top comment hijacks the discussion on a tangent and it's annoying to find people discussing the primary topic)
> I always yearn for a 'by date' sort for HN comments
We can't make a big flat list and sort those by date without losing the threadedness of the comments and thus their context. But we could sort siblings by date at each level of the tree, including the top level. Is that what you mean?
Sometimes this would be a good thing. Top-level (and in general 'higher up the tree' comments completely dominate. It's rare for the direction of a HN thread to shift much after a reasonable number of comments as everything gets buried quite far down.
I'd really like a 'what changed since i was last here' button. Quite often I come back to a long thread I was especially interested in and I'm completely unable to find out if anything of value has been added.
> But we could sort siblings by date at each level of the tree
More options = better. The intended audience of HN can cope with a few more things to click. Treat us like power-users.
HN has always treated users like power users. That's part of its design. But there are other considerations, such as its minimalism and the fact that there is a single shared view of the content.
If you look at the profiles of the submitters, at least one admits to being an Amazon employee.
Yes, lots of us are interested in AWS (I am too), but that doesn't mean each separate announcement should be its own post. And I don't think the nearly uniform submissions we see would have happened organically.
Note that you are also getting voted down. Lot's of Amazon employees to hit down votes on people who say anything against them. This text may be grey. :)
But if they ever release a tool that is inspired by the Brazil build system, pack up and run for the hills. When it takes a team of devs over two years to get Python to build and run on your servers, you know your frankenstein build system is broken. It could be replaced by shell scripts and still be orders of magnitude better. Nobody deserves the horror of working with that barf sandwich.