Amazon's 21-step Hello World example
-
AWS Java documentation is now much better
Update: Eron Hennessey from Amazon has responded below with a new updated Java SDK that’s much easier to grok. The title of this article has since been changed accordingly. The problem…
Jesus Christ, that's insane.
Wait a minute. At no point in that massive and confusing HelloWorld tutorial was there ever any actual code that pushes or pulls items off the workflow queue. The tutorial got so far up its ass that it actually forgot to teach us anything about the AWS SWF service.
-
All of Amazon's developer documentation is fucked.
-
Like the author of that blog posting, I've found the C# examples are fine. My conclusion was closer to, "Java developers love design patterns and abstraction so fucking much, they're literally incapable of writing straightforward code."
-
Damn that's bad. Given I would expect something like that to be reviewed from a technical perspective, that means there are multiple people at Amazon who see no problem with that as a Hello World tutorial!
-
Holy shit that's bad. Even if you skip all the Eclipse bullshit and just use IntelliJ. Which, despite what the author says, seems to have no Problem with AspectJ:
Hey, the plugin is even bundled by default. No need to install anything.
-
Can someone provide like a two sentence explanation what's the point behind this AWS thing?
I'm vaguely aware of workflows in .NET (WWF). It's some kind of programming interface for managers. I guess? And this is Amazon's version of it, so that you can send these workflows to their cloud? Maybe?
Both the .NET and Java examples are very confusing in why you would need these workflows to convert images or print a string to the screen.
-
In Amazon SWF, tasks represent invocations of logical steps in applications. Tasks are processed by workers which are programs that interact with Amazon SWF to get tasks, process them, and return their results. A worker implements an application processing step. You can build workers in different programming languages and even reuse existing components to quickly create the worker.
I think it's simply a way to distribute tasks to workers, as well as keeping track of the state of everything so the processes can be resumed if they are interrupted.
-
Sounds like a distributed actor system. Or microservices with an orchestrator.
Sigh. So many distributed scalable solutions, so few people who actually need this.
-
I always get this feeling when reading about things like message queuing middleware or enterprise service buses. Like, is that problem really hard enough to warrant having hundreds of expensive competing products to solve it?
Then again I don't think I understand anything at all about enterprise software. It's definitely one of my pending subjects.
-
Correct me if I'm wrong, but that sounds a lot like Azure's Logic Apps and/or WebJobs
-
Microsoft Azure, Amazon AWS, Google Cloud SDK, they're all just different flavors of the same ice cream. Everyone likes ice cream. EVERYONE. They scream, you scream, we all scream for ice cream!
-
Then again I don't think I understand anything at all about enterprise software. It's definitely one of my pending subjects.
This way lies insanity...
-
-
Like, is that problem really hard enough to warrant having hundreds of expensive competing products to solve it?
Don't worry! The solutions add so much cost to the handling of a single message that it feels immediately justified to use an expensive solution…
-
I think it's simply a way to distribute tasks to workers, as well as keeping track of the state of everything so the processes can be resumed if they are interrupted.
What I don't really understand is they already had that, it was called SQS, Simple Queue Service. What's different about this?
But whatever. This falls under, "if you use it, you're putting too many eggs in your cloud provider's basket", IMO. "Oh man, another price hike, we need to move off AWS." "Can't, our whole app is written using their proprietary message passing crap, we'd have to spend 6 months rewriting it."
-
I would expect something like that to be reviewed from a technical perspective
You wouid, and you'd be wrong. In my experience, this kind of documentation doesn't get any attention from anyone who knows they're doing till some important customer raises enough hell about it being useless. A lot of the time this never happens, customers either work around the stupidity or go elsewhere, and the documentation continues festering in this state.
Nobody pays attention to technical writers until a shitstorm happens... assuming this was even written by a writer and not by a random junior dev.
-
Fun fact: The pages for said tutorial have buttons at the bottom to tell them whether it helped you or not.
Maybe we should all go there and click "No"
-
If they don't like ice cream, I doubt I'll ever want to meet them.
-
If they don't like ice cream, I doubt I'll ever want to meet them.
Tastes vary more than you think. And no, I don't know why she doesn't like ice cream. She'll eat some occasionally, when it's the very expensive real-vanilla stuff, but that's only if the weather is very hot and there's no real alternative.
-
It's apples and oranges. The java code sends your implementation of the interface up to amazon, and gives you an implementation of the same interface on your local machine that you can call methods on, and have those method calls be executed by your actual code running up on the cloud. This means that you won't be locked in to aws, because all it takes to turn your aws code into local code is to remove the proxy factory call with a constructor call to the actual impl.
Complaining that they didn't get into the nuts and bolts of how the library is implemented seems kind of silly. Why would you want to learn the vendor-specific, laborious, manual process that you would need to follow every time you want to run something, when you could follow the setup guide one time and never need to think about it again.
it's like they were expecting to do write a lot more code to get it working, so when it's just some annotations to tell aws which classes are to be run remotely, some configuration with all the secret keys and what not, and a call to the object that sets it all up, then after that you just use the object that was created as if amazon wasn't even there, that seems too easy and so they have to go out of their way to do it the hard way.
I get that if you're not used to the whole code-weaving, proxy-object way of life, that it looks like sleight-of-hand; that whole “when are you going to show me where the code is?” deal is totally something I can identify with, but once you get used to it, it is pretty great just being able to focus on what your code does, and let the framework deal with the logistics. And I don't see how it's amazon's responsibility to teach users that. If anything, their problem was walking users through setting up aspectj themselves, rather than just listing it as a pre-requisite.
For example:
GreeterMain creates an AmazonSimpleWorkflowClient object by using the same code as GreeterWorker. It then creates aGreeterWorkflowClientExternal object, which acts as a proxy for the workflow in much the same way that the activities client created inGreeterWorkflowClientImpl acts as a proxy for the activity methods. Rather than create a workflow client object by using new, you must:
1.Create an external client factory object and pass the AmazonSimpleWorkflowClient object and Amazon SWF domain name to the constructor. The client factory object is created by the framework’s annotation processor, which creates the object name by simply appending “ClientExternalFactoryImpl” to the workflow interface name.
2.Create an external client object by calling the factory object’s getClient method, which creates the object name by appending “ClientExternal” to the workflow interface name. You can optionally pass getClient a string which Amazon SWF will use to identify this instance of the workflow. Otherwise, Amazon SWF represents a workflow instance by using a generated GUID.The client returned from the factory will only create workflows that are named with the string passed into the getClient method, (the client returned from the factory already has state in Amazon SWF). To run a workflow with a different id, you need to go back to the factory and create a new client with the different id specified.
Are you fucking serious?
Sure it looks like a lot of words, but all it really means is that this
GreeterWorkflow greeter = new GreeterWorkflowImpl(); greeter.greet();Got turned into this
GreeterWorkflowClientExternalFactory factory = new GreeterWorkflowClientExternalFactoryImpl(service, domain); GreeterWorkflowClientExternal greeter = factory.getClient("someID"); greeter.greet();Which is exactly what the intro paragraph to the whole tutorial said was going to happen, so I'm not sure what else you could say to make it any clearer.
-
What'll eventually happen (and might've already happened for all I know) is that all that factory stuff will get packed into a variant of a framework like Spring so that this:
GreeterWorkflow greeter = new GreeterWorkflowImpl(); greeter.greet();gets turned into this (IoC/DI version):
@Autowired GreeterWorkflow greeter; // In a suitable context, e.g., an instance field // The binding to the "someID" will be in some config elsewhere greeter.greet();There'd be a lot of magic going on, but the magic would be in the framework and not explicitly in your code. That's the thing about modern Java; it's only complicated if you're looking under the covers. (Alas, that includes when you're trying to understand stack traces, but you can't have everything and abstractions are always leaky somewhere…)
-
Enterprise software is easy: make a product you can configure into a "solution," make landing pages that BA's will find when they're speccing a plan, sell a solution (ideally with consultants implementing instead of the BA in house).
AspectJ | IntelliJ IDEA
AWS | SWF | FAQs
