Site Sponsors:
Public DNS to AWS VPC on EC2 
There has simply GOT to be a good anagram in the title for this post somewhere ... ;-)

New to WHO?

Sadly, the folks at Amazon & elsewhere do not know that Clouds were being enshrined on blackboards & plastic (flowchart) stencils well before the Internet was a keyword.

Indeed, if it was not for the fact that things like REST caused folks to spend billions of dollars fixing things that were never broken in the first place - if so many new-wheel / old-wheel fire-drill were not so expensive - such over-hyped fire-drills would be comical. (*)


For financial reasons alone, many feel the the unfortunate tendency both new folks to the industry & the media have to shout "eureka" when re-discovering the wheel is truly unnerving.

And so it goes with AWS and EC2 - Rather than working with a box of well ordered tools, one often feels that they are instead working with a young ESL kid who is trying to describe what is in a newly-opened box of freshly-caught frogs. While the overall experience is extremely flexible and ready to take on any computing challenge, anyone who knows what they are doing is in for a rather amusing - and probably a needlessly time consuming - journey.

What pat of the term DNS ... ?

For example: After mucking about with Amazon Web Service (AWS) for any length of time, you will undoubtedly want to link a PUBLIC URL to your Virtual Private Cloud (VPC.)

VPC Misnomer

First and foremost note that the official name for "VPC" is surely a misnomer!

Why? Because Multicomputer Clouds do not have single-entry command prompts.

In short, one must use SSH (etc) to get a command prompt on your VPC so as to manage Operating System (OS) commands - just as one would do on any PC OS.

Rather than being any type of as-named "private cloud" however, this VPC is - in reality - a Virtual Personal Computer (or "PC")! (VPC == Virtual Linux / Windows P.C)


Moreover, the free Amazon VPC one most often encounters is certainly in no way even a "Personal Server:" Most cell phones have more memory & data storage these days. (Indeed, how could any modern P.C. of any description have so little RAM + storage? My Raspberry Pi and Beagle Bone Black microcomputers have as much!)

So the pseudo-technical folks might call the AWS-PC a cloud-prince... but after we kiss it, it still smells like a somewhat underfed frog to the rest of us? (Not to mention the warts-for-today I'm 'talkin 'bout ;)

What type of "warts" you might ask? -Well, unlike a multi-host "Cloud" of any description - yet just like any PC - your VPC will have an IP address. Unlike a PC however, at the time of this writing the default IP Address and public Domain Name Service (DNS) endpoints will change every-time the VPC is re-started (Instance) on the EC2.

Moving Target?

The problem with the new-IP-on-reboot strategy is that the entire point to having a Domain-Name Service is to associate a static "name" with a far more changeable IP Address. Hence - and unlike what most 'geeks of any tenure are used to - using that default Amazon-generated DNS entry becomes just as pointless as hard-coding that ever-changing IP address into your application(s)!

So if one might be tempted to (1) assume that your VPC will never be restarted & simply (2) create another DNS A Record to (3) point to your default DNS VPC instance-name, note that if you ever (4) re-boot your VPC off of the EC2 that the A Record will simply (5) become a pointer to a tombstone.

What's a geek to do?

Elastic IP Address

Like most things AWS, there is a way around everything.

In this case, after a few hours I discovered that the terrarium includes the ability to create a STATIC IP address (Colloquially speaking, static is not very "elastic"? -But with a little thought & tolerance, the concept works for me. -Such is the pattern with all things AWS ;)

Once created, one can THEN associate that "elastic" address with a running Instance of your VPC on the EC2, as well as create an A Record that will also refer to that far more immutable name, as well.

So sure, dynamically instancing a bevy of VPC clones onto the EC2 so as to allow them to "expand and contract" on-demand is a very cool idea. -Just like a "dial group", the idea of having a single phone number round-robin ringing any given set of telephone hand sets was cool even back in the 1950's.

Yet every rational regionalist knows that a frog-in-a-cloud - by any other name - is still a frog?

Sharing is caring!


Yes, in 1970 mainframes were trying to do "in-cloud" computing, as well ;)

Rather than having any historical context, new kids seem to want to re-discover everything from the concept of "web service" (what do all those RFC's describe, anyway? HTTP? HTTPS? HTML Forms?) to "the Internet of things" (was a UAV, PDA, set-top box, poll-top electric transformer, IP:X10 network, or oil rig not a "Thing"?

Do these new, visionary, "things" not have computers in them, as well?? IP?

--So overlooking the jibes in the postscript herein we must simply ask ourselves: Did we miss something here... or did someone else?

[ view entry ] ( 1243 views )   |  permalink  |  related link
SOA Meltdown 
Hariharan asks: "Can SOA predict slowdown?"

Response: Most can predict a slowdown for large companies who use SOA. Indeed, using the modern definition of an XML based service, SOA itself is inheritantly fat, chatty, and slow. Using a more broad definition (i.e. octet-optimized services), when you hit that XML parsing wall you can chuck that XML SOA noob mess and architect-in something a lot more customized, efficient, and - alas, closed. In XML terms, it is defined as favoring CDATA over PCDATA.

Indeed, until some motion is detected in the realm of ESXML, the best you can hope for when your XML based SOA inevitably becomes sluggish is to either chuck more hardware at the problem, or begin to design for a more customized, secure, and - unfortunately arcane - set of packet-level efficiencies.

Still, big companies do indeed need XML based SOA to help bring some order to the stove-pipe, duct tape, bailing-wire, file and protocol integration mess that we often see today. But be aware that the trade off between pumping metadata along with each and every packet, as opposed to assuming some form of implicitly strongly-typed packets, will still be the trade off for a very, very, long time.

Caveat Architect.

[ view entry ] ( 2904 views )   |  permalink

<<First <Back | 1 | 2 |