Veteran IT executive, Jeff Reed, offered some key insight today in an article on how the cloud helps application developers and operations teams.  To summarize in one word: collaboration.

With a background as the lead developer for the original Outlook Web Access product, Chief Software Architect for T-Mobile, and CTO at multiple companies, Jeff’s perspective highlights why two historically separated teams come together “in the cloud.” 

Background – A Unique, 3rd Party View

Though Jeff’s company historically provides services as a VAR, Jeff spends his days speaking with customers about Java applications. While discussions between his company and his customer are traditionally about infrastructure and data centers, most of his time is spent collaborating with IT teams to identify solutions based on the VMware vFabric stack – architectures made up of Spring frameworks, application servers, web servers, middleware, monitoring, in-memory, distributed databases, and more.  The operations teams he works with are typically focused on monitoring applications, keeping them running, ensuring security is in place, patching, identifying anomalies, working with performance issues, procuring hardware, etc.  The managers of these operations teams have a different focus, a different goal than application development teams.  Due to the different goals, a rift between teams exists in many IT shops today.  Jeff has seen this as a front-line worker, manager, consultant, and executive.

Yet, while Jeff’s company helps with operations, Jeff focuses on applications.  And, he sees IT team dynamics change right before his eyes.  Whether the devops approach is an elephant in the room or a target strategy, the cloud concept pulls applications and operations on to the same page, with same goal, and as the same team. And, Jeff gets excited about this for two reasons:

1. Both infrastructure and development teams take responsibility for efficiency and the cost of operations.
2. Big/fast data is almost impossible without this collaboration.

Here is (a somewhat dramatic :) summary of the two reasons:

Encouraging Responsibility

Virtualized, automated infrastructure creates elasticity, and elasticity creates the biggest benefit of cloud computing.  Do you need to quickly move from 20 JVMs today to 200 tomorrow?  Without a cloud infrastructure, this could take weeks.  With a cloud infrastructure, it could take minutes. This elastic capability is why the term “cloud” has become so overused by so many companies.  While it may become annoying to hear “cloud this and cloud that,” the cloud model unleashes a boatload of value and makes IT faster, more responsive, and better at keeping SLAs while reducing costs and downtime headaches.  While IT teams may reach a point of never wanting to hear the term again, IT teams are now including the related requirements and the business drivers into their plans.  You just can’t design an app or open a PO anymore with an overestimate on hardware…and you certainly don’t want to wait on environment set-up or upgrades if you don’t have to.

Making Big Data Possible

The traditional RDBMS model cannot scale. Period.  Because of this, people speak of a death knell for the traditional RDBMS. Interestingly, fault tolerance, disaster recovery, and high availability die too.  The resurrection taking shape includes in-memory, distributed data stores and other purpose-built data management systems.  These solutions have redundancy and availability built in and enable real-time analytics, cached sessions, and more.  So, what happens when the shift in capabilities literally changes someone’s job description?  The teams creating, consuming, and managing the data must also change.  Apps and Ops work together because the sheer scale of data and processing tear down a long-time wall.

To read Jeff’s specific viewpoint and more detail on this shift in IT team dynamics, read the full article.

It is unfortunate that TheServerSide, which advertises a "Research Panel" chose to summarize the article with the statement, "The traditional RDBMS model cannot scale. Period.". Its not that I object to the statement, but it is an outright avoidance of whether this is scientifically correct.  Ever hear of a little known RDBMS being merged with GPGPU optimizations?   Never mind. The statement stands on its own. No references, no "we the community of ...". Well the author may have been successful in industry, but I think I'll reserve judgement on the work of Coad, until someone demostrates its death ... scientifically.  These kinds of statement can prove quite useful in styming innovation; after all don't all CTO's stick together. Microsoft Kool-Aid blathering .... been there, skipped the drink.

Is this what TSS has come to? A place for VMWare and Dynatrace to post advertisements every couple of days?

"my intentions were pure to help whoever might find the article useful" - that is not true. unfortunately. NOBODY can find this article useful.

your only intention was just to publish some stuff somewhere and then use it as a REFERENCE in your CV, blog,web site, book etc. you are not only one who publishes a USELESS stuff. But SO USELESS I have not seen yeet. One should name it a TECHNICAL SPAM.

May be other sites like Slide Share ;-)  tolerate such SPAM. It's their problem. But on THIS site some minimal quality is supposed.

To come to the piece you might want to remove any references to the theserverside.com from your personal web site, blog, including statements that this site is your partner, remove TSS logos, etc. Don't mention this site anywhere, and not so many of your friends, colleagues, employers, customers will know, that you can write such unprofessional, such rediculous stuff, SUCH SPAM.

who cares of Codd?

this Stacey Schneider understands marketing, not IT, not cloud, not databases, especially not relational databases.

this Stacey Schneider has a contract to put this SPAM to as many site as possible. period.

dear Stacey, you could put your SPAM to a cloud an scale it 200 times. it's easy, a matter of minutes. ask Jeff for assistance.