Going Rogue with PaaS: Bringing Shadow IT into the Light
Going Rogue with PaaS: Bringing Shadow IT into the Light
Join the DZone community and get the full member experience.Join For Free
See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.
[This article was written by John Wetherill.]
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 developement. 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 amongst developers is due to restrictions on software and behaviours. 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.
Published at DZone with permission of John Wetherill , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.