Amazon Web Services (AWS) and Amazon Machine Images (AMI)

[I D Shukhov]

It's really amazing what software frameworks you can apparently get up an running in short order on Amazon's Elastic Compute Cloud.

I decided to start looking at some enterprise frameworks: strictly as a hobby -- I just want to see what's going on with SOA and web services since I hear it mentioned constantly at work but am let nowhere near it.

I go here: http://developer.amazonwebservices.com/connect/kbcategory.jspa?categoryID=205 and I find an incredible list of AMIs, apparently all usable under Oracle's OTN (Oracle Technology Network) license, which says I can install the software for learning purposes:

LICENSE RIGHTS
We grant you a nonexclusive, nontransferable limited license to use the programs only for the purpose of developing, testing, prototyping and demonstrating your application, and not for any other purpose. If you use the application you develop under this license for any internal data processing or for any commercial or production purposes, or you want to use the programs for any purpose other than as permitted under this agreement, you must obtain a production release version of the program

For example, I can learn about Oracle's SOA Suite (whatever that is)

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=4052&categoryID=205

Or Weblogic:

http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2017&categoryID=205

I'm not sure what the pricing for ECC is, but as for my time, it sure beats building one of these systems from scratch.  You get Linux, the Oracle database and whatever applications Oracle layers onto it all bundled together.   

Now all I have to do is come up with an idea for something to build.  I'm thinking about some free tool that you anonymously use -- maybe a public domain psychological inventory, like the Myers Briggs inventory that will give you some immediately useful feedback about yourself.  That particular one has (probably) already been done. 

The next thing I do is exactly what "John Masterson" keeps harping on -- integration of components.  I'm not going anywhere near programming if I can help it.

[John Masterson]

ID,

Yes, detailed, lower-level coding has disappeared from business IT departments.  Probably has been gone for 10 years or more, I bet. Do you agree?

You still find it at software companies. You find it on custom embedded or middleware projects like G0ddard does. You find it in the defense industry and medical device makers, but I bet there, too, it's more and more snapping together "larger chunks".

After all, we can't keep reinventing the wheel and rewriting the "basics" over, and over, and over.

But this means 1) higher productivity, 2) Less highly-skilled programmers needed, = 3) Lower wages and worse working conditions with less "professional respect".

[The Original Henry]

The business side sees it exactly like John's post above. From the programmer's side it's not quite that simple. Most of the time the holes on all those blocks don't line up with the specs, so we end up having to do some insane hacking to make it sort of work like it's supposed to. When the project is big enough or the holes are far enough out of line then the question becomes - "wouldn't it be simpler and easier to just design these blocks myself based on the specs they are supposed to be meeting?"

Sort of like trying to rebuild an old car where original parts can't be bought. Is it easier to buy parts that are sort of similar and then engineer around the differences or would it be better to have the parts you need custom-fabricated to precise tolerances?

[Richardk]

... it's more and more snapping together "larger chunks".

As stated, assuming that you can find what you need and integrate it into your system.

Reminds me of a client that wanted an invoice  printing system replaced. They wanted to dump their dot-matrix printers, upgrade to something newer and change the format. Their expectation was this should take me 4 hours but they will allow up to 8 hours.

"Just find something on the Internet that looks good." was their reply. When I asked for a database schema or at least 'where is the data?' they got that deer in the headlights look. Sad thing is they had an IT dept that was enabling their users to be so clueless and demanding. Also my FTE 'helper' took days to reply to requests.

The big picture was they were moving towards these pre-fabricated chunks but they still needed a lot of setting up or tweaking.

This just shows me that the sales and marketing are very good which leads to high expectations but the delivery falls short.

[I D Shukhov]

JM wrote:

You still find it at software companies. You find it on custom embedded or middleware projects like G0ddard does. You find it in the defense industry and medical device makers, but I bet there, too, it's more and more snapping together "larger chunks".

Exactly right.  I work for a defense industry contractor and they, and the government customer, try to squeeze every last bit of usefulness out of legacy systems.  This year I did a considerable amount of work on a project that is based around CORBA and Motif (Builder Xcessory) of all things.  All very solid code, probably better than most of the stuff being developed these days, yet the technologies are no longer cool.  It was definitely a framework and dozens of servers and GUIs worked very well together as a system. But it wasn't a commercial framework and thus useless as far as me becoming marketable.  It's a totally outdated skill set.

(Note:  not so amusingly, they grafted a Weblogic/Oracle supervisor sort of thing onto this (formerly) well crafted system.  All sorts of difficult to solve bugs are now degrading the system.  Sometimes they're traced back to Oracle and the interface with it, sometimes to something in Weblogic.  The Weblogic/Oracle people do not share knowledge very well and little that is useful is documented.  Sometimes lab operations just halt until somebody who knows about the Weblogic stuff can be found.)

But this means 1) higher productivity, 2) Less highly-skilled programmers needed, = 3) Lower wages and worse working conditions with less "professional respect".

The thing to do is to learn about these frameworks and call yourself an architect instead of a programmer.   The Original Henry's point is well taken, however.  I think you need to be both a programmer and an architect.  In the kind of company I'm looking for people will be called programmer-architects or architect-programmers.

[Peter Gibbons]

I think there will always be work that needs to be done with algorithmic languages.

I have had a lot of work during the last 10 years redoing failed projects where the client bought off the shelf software, magic conversion tool or expected just snapping together a few pieces of OSS will do the job.

Every project that a company thinks could be done only by configuration using XML is doomed to failure.

[The Gorn]

Every project that a company thinks could be done only by configuration using XML is doomed to failure.

The main problem here is managing the client's broken expectations. It's pretty difficult to lead the end-userish out of blind faith in vendor data sheets, PDFs and marketing hype (mostly the latter.)

They expected to spend $X,XXX to achieve their result and instead you are telling them they need to spend $XX,XXX.