PaaS - The Ultimate Survival Contest for IT
Even with all the confusion around Cloud Computing, there are a few things that are fairly well accepted by everyone involved in the IT industry:
- Developers have led the early waves of Cloud Computing and they will continue to lead the next phases, especially as more open-source options are made available to them.
- Corporate IT organizations are typically slow to change, as they are focused on stability and 3-7yr budget/depreciation cycles.
These two dynamics are creating a challenging environment within the IT industry. As more "in house" developers leverage public cloud resources, typically due to the pace of IT (operational) responsiveness, this is creating a "shadow IT" environment outside the corporate IT walls. On the flip-side, corporate IT is growing more concerned about external Cloud Computing resources  because of well-publicized outages and concerns about security and compliance.
The latest wrinkle in all this development is the emergence of several PaaS projects and platforms which will give developers the option of running their applications in public or private environments. They also come with the promise of application portability between public and private environments. Whether or not this happens is still TBD and will probably take several years to work out the kinks (and levels of trust from developers). But it introduces an interesting crossroads for corporate IT organizations, which has experts predicting a variety of potential outcomes.
For the most part, developers don't care about costs, they care about working code. They have been bypassing IT organizations to "speed up their time to code". The ultimate measurements for developers is if code works and when code ships. The IT organization can negatively impact this due to lack of speed or complexity of deployment environments (eg. network, security, authentication, etc.).
Some people argue that that the future of IT is all about costs and commoditization. Unfortunately too many of these arguments only take into consideration "acquisition costs" (VM, GB/Storage) and "basic operations" (power, cooling, SW licenses), but don't consider broader context costs like security, compliance, switching-costs, re-training, downtime, etc. They also rarely consider that for most organizations, IT costs make up less than 10% of overall expenses, with many industries being less than 5-6%. [NOTE: Pure technology companies are the outliers to those numbers].
For the past few years, IT organizations were spending most of their time focused on keeping the existing services functional. Keeping the lights on. But now they have an opportunity to potentially break the cycle of "shadow IT" by developing the skills and architectures to support these PaaS environments in-house. To give their developers an alternative option that combines the speed of availability with the potential to comply with corporate security and regulation requirements. Will it be delivered at the same price-point as a public service? Probably not, since the utilization levels in-house will be cyclical and not normalized by multiple tenants/customers. But will they potentially be able to deliver the "pace of availability"? The answer may ultimately determine the survivability of IT in the long run.
Will developers trust the IT organizations? Not initially, as there are years of animosity and uncertainty built up between those groups. But the one thing IT has going for it is that developers hate sitting in meetings, or just about anything that takes them away from creating and deploying code. If IT can create an in-house PaaS environment that will reduce (or eliminate) the myriad of security/compliance/costs meetings the developers will be subject to if they expand the shadow IT environments, there is a chance that IT will appear to add-value to those groups.
So if you're an IT organization hearing the buzz about these new PaaS offerings, now my be the perfect time to not only reconnect with your developers, but also start looking at how to establish those environments in-house.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)