The M in MVC (Minimum Viable Cloud) implies that there are additional capabilities in a mature cloud implementation beyond those outlined in our previous post, which introduced MVC. Recall those sine qua non MVC requirements: Clouds are APIs Clouds are SOAs Clouds Hide Implementation Clouds are Fully Automated Clouds are Utilities Clouds have Global Fault Tolerance Clouds are Opex Additional capabilities that constitute fully developed cloud ("C") exist in areas like service offerings - having more of them, such as object storage or noSQL databases. But, metaprogramming capabilities that allow you to compose and orchestrate systems across resources are the centerpiece of C. Let's get specific. C>M Clouds promote stateless, distributed compute Cloud-native...
Every time a new, hot technology appears on the scene, many companies with old, boring technologies slap a sticker on the front of their product, proclaiming it to be a torchbearer for the new tech. It's something of a parlor trick. Certainly this has been the case with cloud technologies. As a result, there's a need to differentiate things that actually deliver the promised benefits of cloud from things that are just cloudwashed. After a decade of building service-oriented architectures and cloud products for AWS and others, I've had time to reflect on how to distinguish the real from the marketed. Others have taken a crack at this, but explanations that begin with the developer's perspective - the developer who builds and uses new systems on cloud infrastructure - are not especially...
Several years ago, NIST produced documents (SP 800 145 & 146) that made admirable and compelling efforts to categorize cloud service offerings with the tripartite taxonomy already in use: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). NIST sought to tighten loose definitions. This was about as good a categorization as was possible at the time. While comprehensive, the perspective set forth in the documents zeroed in on "consumer-provider interaction dynamics." It represented an important perspective, albeit not a preclusive one. The terms have proved useful for understanding the array of cloud services available in the market, at least in a general, commerce-oriented sense. AWS is an IaaS, Heroku is a PaaS, and Salesforce is a SaaS.
I've noticed recently that I'm getting quite a bit of grey in my beard. While there are many downsides to being an aging geek (I can't pull all-nighter coding sessions any more without hell to pay for several days), one of the benefits is gaining some perspective on how innovations play out over time. I started building software in the late '80s on my beloved Amiga, began programming OO in Objective-C on NeXTStep in 1990, and built my first web application in 1993. Along the way, I've seen all manner of approaches to standardization of new technologies. Some ultimately yield successful standards, some do not. Innovation Lifecycle When a new technology that has broad relevance arrives, it tends to develop along a lifecycle that is more or less similar to that of other innovations...
Cloud infrastructure services have allowed our field to gradually abstract computation tasks from long-standing physical restraints. As cloud infrastructure adoption increased, we realized the power and efficiencies of quick deployments and elastic scaling, giving birth to the DevOps movement. We've been steadily directing more of our attention and resources to what matters most: the applications that differentiate our organizations and create value. We can do this because we spend fewer scarce resources managing and maintaining bare metal infrastructure. As we've moved toward a "paper-cup," ephemeral computing model, these "virtual" components are becoming skeuomorphs; that is, they are features of computing instances that resemble facets of the physical computers they've replaced,...
.png?width=36&height=36&name=linkedin%20(1).png){kind=small}
.png?width=36&height=36&name=twitter%20(1).png){kind=small}
