Predecessors of PaaS - DRAFTv1
In a datacenter far far away, there was "pre-PaaS"...
The pessimists of Cloud and stalwarts of IT should be happy … for now. Gartner’s hype-o-meter put Cloud concepts in decline (or rather the “Trough of Disillusionment”. Optimistics will note that -- at least according to Gartner -- after a period of disillusionment, technology re-emerges in a stage of enlightenment, followed by stable adoption. So let’s do the timewarp again.
Way back in 2010, some smart architects on my team finished implementing an application management and orchestration platform that would rapidly change user expectations. That platform's sales slidedeck, dated 2008 [1], had neither the term “DevOps” nor “Paas” (or any of the *aaS Cloud terms) but “Cloud” is mentioned, although fewer than a dozen times. The product’s slidedeck wasn't filled with modern buzzwords but focused on 1) dynamically orchestrating virtual resources and 2) automating application deployments.
[1]
I joined that smart team of folks when our goal was to streamline and automate processes that made fast, incremental releases of a distributed, multi-tier trading desk system finally possible. Many of our peers from traditional teams, like Dev and Ops, didn't' really get why we sat inbetween them. It was simple: because the traders demanded changes to their financial products ASAP. The traditional technical teams could not deliver feature requests at a pace that satisfied the business needs, aka. the traders in our case. Users of the system would request a feature or fix through typical business analyst channels and WEEKS or even months for the development lifecycle to finally spit out their change to production. By 2010, our application deployments were mostly automated, and though the final delivery to Prod wasn't yet push button, we really had streamlined the process. We had DAILY AUTOMATED builds.
I had heard the term “DevOps” for the first time while working there and really didn't know what it meant, and our architects faced many cultural obstacles because we were the new kids in the cubes. Many of those cultural obstacles boil down to ongoing silos in organizations but the technology itself has now graduated to getting its own label: PaaS.
I had heard the term “DevOps” for the first time while working there and really didn't know what it meant, and our architects faced many cultural obstacles because we were the new kids in the cubes. Many of those cultural obstacles boil down to ongoing silos in organizations but the technology itself has now graduated to getting its own label: PaaS.
Ideas/References:
The reason rapid deployment became a necessity is because small to medium sized businesses want to reach the biggest market / "market capture". These 21st century, technology dependent customer’s no longer accept that any application’s functionality would be interrupted by a large maintenance window set during U.S. “off hours”, nor that productions and solutions would not geo-specific.
Skeptics of PaaS: early on in 2008 Reese blasted the de facto feature of auto-scaling that’s in most IaaS and PaaS solutions. http://broadcast.oreilly.com/2008/12/why-i-dont-like-cloud-auto-scaling.html
Velocity 2009: 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
Technical and sociological justification of continuous delivery with PaaS: McCabe's Cyclomatic complexity, and Conway's Law. Cyclomatic complexity - modular programming, use small components together; Conway’s Law:
“If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture"
No comments:
Post a Comment