PaaS Means Really Following Enterprise SOA Best Practices
Since the early 1990s, the telecommunications industry and its associated ecosystem of software vendors have attempted over and over again to successfully embrace first object oriented software, then various Enterprise Frameworks, a slew of Service Buses, and finally Service Oriented Architectures as a basis to build out their mission critical LOB applications; what we often refer to as the BSS and OSS.
No matter how noble the intent to adhere to the framework or to follow the enterprise architecture best practices of the day, the pressures of delivering needed systems on-time while constantly having to react to an unmitigated stream of change requests and scope creep invariable led to the project teams cheating when it came to adhering to the architecture. They had to get that system in so that new service could launch and be billed. Before you knew it, the system was implemented with point-to-point interfaces over a “service bus” in a totally inflexible, non-agile manner. The standards and best practices were just not shortening the critical paths and no product manager could afford to front 100% of the cost of a framework based approach when it could make their product appear unprofitable.
A funny thing happens when service providers start to implement service mash-ups across two or more clouds. Enterprise SOA best practices and standards matter. One cannot ignore them. If you do cheat, as we are so prone to do, then no one outside of your organization will be able to actually consume your cloud services and generate revenue in an effective manner. Your cloud becomes a nice science project but, without the required ROI, how long can it survive?
Windows Azure is about Platform as a Service. PaaS implicitly means an Enterprise SOA set of design patterns. These design patterns permeate through the service logic, integration / application fabric, and data layers. Collectively PaaS represents a completely different and much more efficient economic model for software design, service creation, and lifecycle management. ITIL v3 comes into play here.
For now, the telcos and some enterprises are continuing to cheat. IaaS allows one to perpetuate, for a while, the poor but expedient practices of the past. One can off-load the problem applications. One can take those J2EE containerized applications and virtualize them on VMs deployed on an IaaS “cloud”. This is exactly what many of Telcos and their large enterprise and government customers are doing today. However, while it may deliver some incremental cost benefit, this approach fundamentally does not solve the problem of agility or ongoing costs. It is not efficient.
PaaS does solve this problem. The economics of cloud-to-cloud SaaS mashups naturally enforces an adherence to Enterprise SOA best practices and design patterns. All that matters is the frictionless interactions that become possible between services running on top of the PaaS layer. The virtualization technology becomes an abstracted capability provided by the underlying PaaS infrastructure but customers will not want to have to actually manage those VMs in the future anymore that they want to manage their own data centers today.
The core benefit of Windows Azure then is not that it is PaaS nor that it has anything to do with .NET per se. The real benefit lies in the economic efficiency that it creates via its natural tendency to drive adherence to a practical Enterprise SOA approach that fosters cloud-to-cloud service mashups, end-to-end service manageability, and a vibrant developer community.
This is the basis for the business cases that will emerge that will in turn propel many of today’s legacy mission critical LOB applications towards an Enterprise SOA driven PaaS model hosted in hybrid clouds.