A bit of a rant about me and the world and ‘a porra toda’
This is actually an edited copy of a cp,,emt I’ve left on a ticket on Github for beanstalker, my Maven plugin for AWS Elastic Beanstalk care and feeding. While I wanted to tell the whole story, I culdn’t simply find the time. But today I kinda decided to share it a little bit.
It starts below…
First, some context: As you guys noticed, I’m a bit away from beanstalker. I admit I lost some motivation, but also it is interesting to draw some context.
The AWS Elastic Beanstalk API, afaik, only had a SINGLE change (cname swap I think) over the years, and yet it was in 2011 — the year it was launched.
I wrote beanstalker circa one month later after they announced support for Tomcat. First, focusing on basic API coverage (as they only had a Ruby client). Later, built in value and automation for users. All done on my spare time.
If you look at all the contributors — financial or technical — I’d say that only five people ever paid me to improve it. Another two of those contribute back to beanstalker on regular basis. I need to ensure at least that it works cleanly on the current zeitgeist, while at the same time trying to keep a sane release process (and thats why I never focused on overtesting it — Our tests are a mess because of the average runtime length — Taking Hours).
So what I do? I focus on the archetypes, since it allows me to provide a single codebase to not only allow me to quickly iterate and test, but also catch any showstoppers. 95% of the time, an issue here in Github could be simply solved by creating a version from the latest archetype, and comparing the parameters.
Actually, there’s an integration testing that just uses the archetypes to achieve that (all voluntary — have you noticed the challenges of writing OSS for paid services like the cloud?)
AWS Support?
Yes, I paid in order for the issue on the fast-deploy. In fact, I kept a case open for over three years, to only hear, after meeting people in Vegas (AWS re:Invent 2014) that “-oh, thats an undocumented feature. And deprecated”.
Oh nevermind. You meant AWS Supporting me?
My e-mails asking for assistance were ignored. Any official opinions from AWS personnel so far went from complete silence to even an “its not supported”. I know the AWS Trainers like it. AWS Architects try to convince you to go to Eclipse. Good riddance.
And here’s the follow up I’ve had from the only useful meeting I’ve had from an AWS PM (the two I’ve met in Person in Vegas didn’t return my e-mails):
… was never intended to be an external service. It was simply an implementation detail for EB to enable incremental deployments from the CLI and the Eclipse/Visual Studio toolkits. Given, the new CodeCommit service, it would be better for EB to use that service for incremental deployments.
Also, have you looked in to the new CodePipeline service? Seems like a combination of CodePipeline and CodeCommit will enable a fully integrated CI/CD pipeline for EB.
So thats AWS Vision for CI/CD. And the whole reason I started this was because I feel more at home on Windows but don’t care doing CLI on Linux, would you believe it?
Consider I’m just making this whole thing in full maintenance, yet that some users interactions I interpret as impacient. My official answer for now will be: “Oh, its not working? Don’t worry, use AWS Toolkit for Eclipse!”. Or call Thoughtworks. Or Atlassian. Both also offer the same functionality, yet paid and with support 24x7. But I came first and judging by the numbers, going strong.
Has any one ever donated documentation? It also helps. But, I’ve had once a very rude user complaining. And I sent him a personal note asking for him to fix. My answer was: “-I’m too busy”
Yeah.
Enough rant.
Back to AWS Elastic Beanstalk
What changed from January 2011 until now? Nothing — The API versoin is actually October 2010 and no single method was added. What changes to justify the need to maintain it? Well, only two things:
- the list of available solution stacks
- the RUNTIME PARAMETERS of their solution stacks
An environment is a life organism, and while their parameters are initially overwritten by you, you have few control once it is launched. So actually I forgot the reason why I did have that line. And it was easy. Take note:
If I allowed you guys to do this, I wouldn’t have any peace of mind. Any undocumented parameters would require a new release, and I’d need to maintain the blacklist of options (when we started back in 2011, there were only one or two stacks. Today, I just noticed there are close to one hundred. And I never told you could only do it in Java btw :)
“-Oh, make it optional as a parameter instead”
Have you guys noticed how hard is just to make sense of the AWS Documentation? Look at all the possible parameters.
And try to envision there’s over a thousand. Now go ask AWS to support it in Eclipse, will you?
And please send me a picture of yourself when you see their reply (if you manage to get one).
So, tell us about that Warning
Why? I uncommented that line that you guys mentioned (btw, any users complaining about “-Why it wasn’t released?”, I suggest to learn a magical mvn command called ‘mvn install’ ffs) to remember what happens.
[INFO] --- beanstalk-maven-plugin:1.4.1-SNAPSHOT:replace-environment (default-cli) @ post-to-sns ---
[INFO] Creating a new environment on post-to-sns-prod-0.elasticbeanstalk.com
[WARNING] FAILURE
org.apache.maven.plugin.MojoFailureException: Failed
at br.com.ingenieux.mojo.aws.AbstractAWSMojo.handleException(AbstractAWSMojo.java:394)
...
Caused by: com.amazonaws.AmazonServiceException: Configuration validation exception: Unknown or duplicate parameter: DockerRPM (Service: AWSElasticBeanstalk; Status Code: 400; Error Code: ConfigurationValidationException; Request ID: d51b311d-5838-11e5-b311-211dc5f90da2)
...
[ERROR] Failed to execute goal br.com.ingenieux:beanstalk-maven-plugin:1.4.1-SNAPSHOT:replace-environment (default-cli) on project post-to-sns: Failed: Configuration validation exception: Unknown or duplicate parameter: DockerRPM (Service:
AWSElasticBeanstalk; Status Code: 400; Error Code: ConfigurationValidationException; Request ID: d51b311d-5838-11e5-b311-211dc5f90da2) -> [Help 1]
[ERROR]Of course the DockerRPM parameters were wrong!
(never heard of it previously. And it seems even AWS never heard about it — it is not documented)
To put it simply, the parameters would get messed up and the secondary environment wouldn’t start because replace environment copies and filters parameters.
I’d need to re-release the builds with an updated list (btw, I haven’t touched this code for 9 months and the world didn’t crash. Likely, my mothers name was cursed by someone which wanted to deploy, couldn’t and didn’t want to look under the hood).
Or keep a wiki of the options to blacklist. And hope my users would be able to maintain and keep up with that.
Ok, so what would be a good alternative?
I need to strive between making the hard possible and the impossible doable. Replace Environment is a marvel and even if stack upgrades aren’t automate-able, I believe there’s lot of pain avoiding effort. For me, not having pain is just as good as having pleasure.
In the ideal world, it would be easy to spot by the namespace what is copiable and what is not. However, we live in the real world, when there’s no real AWS Support and Documentation, and I’m left alone in a Maze surrounded by Unfriendly persons :)
I’ll never comment that code again, as I just reminded it was pandoras’ box about to open.
So?
No.
