Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
Bringing Shadow IT into the Light By @bcferrycoder | @CloudExpo #Cloud
There are good reasons why the practice (malpractice?) of Shadow IT is so common

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?
Shadow IT, aka Rogue IT, has a bad rep. And it probably should. It can compromise security, increase IT costs, result in dangerous leakage of data and IP, and get people fired. It also generates friction and thus expands the already too wide rift between developers and 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?
There are good reasons why the practice (malpractice?) of Shadow IT is so common.

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."

Prohibition Is Not the Answer
A natural reaction to the proliferation of rogue IT is to erect more barriers. Indeed, that is exactly what happens. Developers are prohibited from having root or admin access on their systems. Networks are getting more locked down. Software choices are being further restricted. Processes get heavier and more arduous.

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
Network restrictions, lack of trust, authoritarian proxy servers, software restrictions, tedious and time-consuming processes: it's a wonder anything gets done, at the office. Home is a different story, and I know way too many developers who endure the corporate restrictive agony during the day, then go home to their fast open networks and unlimited access to software where they're enabled to get productive. Then they show up the next day blurry-eyed, tolerating meetings, making it through until days-end when they can go home and, again, actually get real work done.

Surely there's a better way.

Rogue IT Under the Desk
Let's circle back to to the practice of putting a couple of PCs under a desk and sharing it. This is generally considered rogue. That is to say, it's not encouraged by IT. Why would this be? There are several reasons:

  • The PC takes up address space on the network, it consumes power, it's likely configured in a non-standard way, and is probably not being backed up.
  • If the person who built it were to vanish, it would take time and effort to figure out how it was configured.
  • Software installed on the PC might be unsanctioned or prohibited by IT.
  • Then, after the development/experimentation period is over, the process to move whatever was built on it to IT-supported servers is complex and unclear.
  • Finally, there's no way to charge-back for resources used.

Are These Valid?
Some of these are valid reasons, some are not.

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
With PaaS installed on an under-the-desk PC, there's less risk if the person building it leaves. PaaS is (or should be) trivial to install, so even if an existing cluster of under-the-desk PCs were to melt down and the original team responsible for it were to leave, it should take under an hour to rebuild it all again. (It's also worth noting that the under-the-desk solution will probably result in the person staying longer in the first place, as they experience less frustration than having to deal with a cumbersome ticketing system. Keeping your developers happy is a good way to reduce project turnover and results in greater productivity.)

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
An under-the-desk PaaS, compared with a legacy cumbersome ticketing system, brings power and flexibility to the development team. It brings a new meaning to the term BYOD, which typically involves bringing a personal tablet or phone into the office for corporate use. Now with Private PaaS, your device can be your 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.

About John Wetherill
Originally from Canada, John has spent much of his career designing and building software at a handful of startups, at Sun Microsystems, NeXT Inc., and more recently in the smart grid and energy space. His biggest passion is for developer tools, or more generally any tool, language, process, or system that improves developer productivity and quality of life. Without question, Stackato is one such tool and the reason why he is here. No stranger to technology evangelism, John spent several years in the late 1990's on Sun's Technology Evangelism Team spreading the Java Gospel across the globe and focusing on the prolific number of Java technologies. Now John is now returning to his roots, as a technology evangelist working for a Canadian company, albeit remotely from Santa Cruz.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Latest Cloud Developer Stories
In a recent survey, Sumo Logic surveyed 1,500 customers who employ cloud services such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). According to the survey, a quarter of the respondents have already deployed Docker containers and nearly as many ...
DevOps promotes continuous improvement through a culture of collaboration. But in real terms, how do you: Integrate activities across diverse teams and services? Make objective decisions with system-wide visibility? Use feedback loops to enable learning and improvement? With tec...
"I focus on what we are calling CAST Highlight, which is our SaaS application portfolio analysis tool. It is an extremely lightweight tool that can integrate with pretty much any build process right now," explained Andrew Siegmund, Application Migration Specialist for CAST, in th...
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is ...
The past few years have brought a sea change in the way applications are architected, developed, and consumed—increasing both the complexity of testing and the business impact of software failures. How can software testing professionals keep pace with modern application delivery,...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
ADS BY GOOGLE