A slightly plaintiff and frustrated tweet from grumpystorage aka @ianhf inspired this blog as did replies from various of the storage twitteratti.
Ian cries the lonely cry of the infrastructure architect
'Application
architects – please know & understand your infrastructure
requirements. Infrastructure isn't magic or telepathic!'
And of course, IaaS and PaaS are then held up as potential solutions to the problem. I've got bad news; they're not! Cloud Architectures are neither magic or telepathic, they still rely on application developers and architects understanding their infrastructure requirements.
Now we, in the infrastructure world can help them by educating in the questions that they both need to ask and also need to answer. Questions like, what availability does your application require? What is it's throughput? Have you designed an application which scales either horizontally or vertically? Infrastructure Architects have always had to work in a consultative manner and drag the requirements from the Application teams.
All providers of infrastructure need to understand the importance of this; nothing will destroy the credibility of Cloud Architectures quicker than the inappropriate and unplanned deployment of applications into the Cloud.
I think there is a temptation that we represent the Cloud as Magic Smoke where things happen but just look at the backlash when Gmail goes down? Fortunately for Google; people have become so reliant on Gmail, beyond a bit of moaning, few people will really change but a Corporate taking their first steps into the Cloud who loses a key application or a key application under performs may well be more unforgiving.
Push button deployment without the consultative input of the Infrastructure Architects guiding could end up in a world of pain and it won't be the application at fault, it will be the Infrastructure.
Understand the sentiment, but there’s another way to frame the problem.
We, as infrastructure experts, need to think in terms of infrastructure that does what it’s supposed to, regardless of what the application guys throw at us.
I, for one, believe that infrastructure can be made to be “telepathic and magic”. Perhaps sooner that most people think.
— Chuck
I had a few thoughts about pain points, consider this
a “perhaps.”
Perhaps corporations that have consolidated data
centers over the years have many remote offices with
dedicated circuits back to the datacenter. Cloud
might mean that remote offices have to get fatter
circuits out to the internet so the public cloud
isn’t a multi-hop. Maybe increased circuit costs
across the board.
Cloud friendly apps like Exchange are already in the
cloud with outsourcing. The challenge will be tier-
1 bandwidth and latency sensitive apps. Sure,
AppSpeed will pinpoint the VM bottlenecks *after* the
move to the cloud.
The larger corps with the true Enterprise architects
will get it right spending on services. The folks
that will get burned will be the ones that don’t
invest the services and introduce major performance
and management issues in the move to the cloud.
Lastly (re-hashing the same point), I’ll bet a
number of business units with too much autonomy (the
big money making divisions that do as they please
and treat IT as a nuisance) will be the first to do
the cloud thing (new and sexy). Some will make a
mess of it as they won’t do the spend to do it right.
Martin, you won’t see my type these words often, but in this particular case I completely agree with @Chuck’s comment above! 🙂
@Rob – if you re-wrote the last 2 paragraphs of your comment more in the present tense than future tense, you’d have an accurate representation of what’s already happening today, especially your last paragraph.
Val & Chuck; could I build an infrastructure which always performs no matter what the application developers throw at it? Actually I probably could but I would possibly end up spending alot more money than I need.
Yes I can take some educated guesses about what the application mix may look like and I might be able to even guess what the average RPO, RTOs are.
For a more efficient delivery of IT; both Application Architects and Infrastructure Architects need to talk and communicate. Traditional infrastructure functionality may well better delivered at an application layer; so why invest in infrastructure which delivers the functionality?