Most Read This Week
Real-World Cloud Computing
Bringing Shadow IT into the Light By @bcferrycoder | @CloudExpo #Cloud
There are good reasons why the practice (malpractice?) of Shadow IT is so common
By: John Wetherill
Jan. 13, 2015 02:00 PM
Going Rogue with PaaS: Bringing Shadow IT into the Light
In a recent blog I suggested that it's okay to install PaaS on a couple of PCs, and run them "under the desk" for cloud development. This immediately provoked a comment from a reader who said "You're not endorsing Shadow IT are you?"
Well in fact I am. By the end of this blog you will too.
What Is Shadow IT?
In a nutshell, Shadow IT is practicing IT without IT's permission. I'll focus on Shadow IT as practiced by developers here. A common example is bypassing the internal resource request process and spinning up VMs on AWS for application development. Or using a DBaaS like MongoHQ or Google Cloud Datastore for instant access to a fast, redundant, reliable, always-available datastore. Other examples include using DropBox to store corporate files, using Evernote to store notes, github to store source code, collaboration software too like yammer, and LastPass for password management.
Not all rogue IT happens in the cloud. For example, a developer using IntelliJ IDEA instead of the corporate-mandated Eclipse for Java can be considered rogue. Or the league of users who have surreptitiously installed Firefox or Google Chrome to avoid the anguish of IE9.
My favorite rogue activity is the practice of configuring a PC with a bunch of memory then putting it under a desk and making it available to the whole team for spinning up VMs. I've seen this behavior at multiple companies where the sanctioned process to spin up a VM is just too arduous.
Why Is Shadow IT Rampant?
It comes down to the huge barriers to getting any work done. In many environments, if a team needs a cluster of VMs, they must submit multiple service tickets and then wait, days, or even weeks before all the pieces come together and the new VM is available. It's actually often worse than this. I frequently talk to developers who tell me it can take months to get a VM provisioned on their network.
And it's not just about acquiring resources. Often, archaic and restrictive network rules are in place, where all traffic has to go through an ornery and overly-restrictive proxy server, and networks are partitioned in such a way that moving bits from one place to another is probably easier done using smoke signals than trying to navigate the internal network.
Another reason for rogue activity among developers is due to restrictions on software and behaviors. Internal policy often banishes all software that hasn't yet been vetted by the internal compliance team, which doesn't have the bandwidth or motivation to validate all the cool technologies out there, many of which might significantly benefit your development effort. The end result is that a developer's request for a resource is declined, often after many days of the ticket languishing in the system.
Another significant factor in rogue IT's popularity is that it's just so darned simple, especially compared with the internal, non-rogue way of doing things. The promises of the cloud are truly being delivered: self-service, on-demand, elastically scalable resources can be obtained in minutes with nothing more than a credit card. Facing the choice of waiting five minutes vs. three months to get a VM, it's a no-brainer to go the "rogue route."
This all boils down to disempowering the software team. Requiring someone to ask for resources, then making them wait for a response, and ultimately denying the request is demoralizing, and establishes a false and dangerous hierarchy between the dev team and IT. Nothing good comes out of this division, only discontent, angst, resentment, attrition. Not to mention long and costly delays.
Empower vs. Hobble
Surely there's a better way.
Rogue IT Under the Desk
Are These Valid?
First, let's discount the extra power required to run a couple of PCs under a desk. Compared to the average cost of a booth at a trade-show, I'll bet the cost of powering a few PCs is a round-off error of a round-off error.
Address-space on the network is similarly negligible. Sure, we're running out of public IPv4 addresses, but that doesn't apply on a corporate LAN where you can have all the addresses you need.
The remaining issues can be resolved with PaaS and some simple practices.
"Under-the-Desk" PaaS to the Rescue
The PaaS running under the desk is, for all purposes, exactly the same as the PaaS running in the data center or in the cloud so there is no unsanctioned software. The configuration is identical and moving applications from under-the-desk to the data center to the cloud is trivial.
The under-the-desk PaaS would have nothing extra on it except application code and configuration code, both of which should be stored in the SCM. Backups are no longer an issue, and the PaaS system would be a commodity, ephemeral, and from the viewpoint of the developer, precisely the same as the PaaS in the data center, or out in the cloud. So moving software from the PC PaaS to the cloud PaaS, once it's ready for prime-time, is trivial.
The only issue not addressed here is charge-back. But if charging internal users for IT is more important than innovation, retention, and software delivery, then we're done here. Please put down this blog and step away from the cloud.
BYOD on PaaS: Bring Your Own Data Center
And PaaS makes it possible. It could be argued that almost all IT innovation today is happening in the shadows of IT. Best to embrace it, with PaaS as the perfect enabler to make that innovation go even faster. Given the simplicity of getting started with a Cloud Foundry PaaS, it's trivially easy to prove out PaaS in a shadow IT framework and then move it into a more structured use once its value is evident. As it surely will be.
Download the free Stackato Micro Cloud and sign up for the 20GB license today and see how easy it is to try out your own "under-the-desk" PaaS.
The post Going Rogue with PaaS: Bringing Shadow IT into the Light appeared first on ActiveState.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads