If you’re considering the cloud for custom application development, you’re probably licking your chops over its promise of rapid time to value, smooth scalability and the prospect of delegating the management of the underlying I&O mess to a cloud service provider. Cloud-native applications promise to unleash the productivity of the next generation of developers. Not so fast.
Value That’s Impossible to Ignore
Cloud service providers deliver an embarrassment of riches to the overburdened application architect or developer. From storage and compute primitives (via IaaS) to turn-key application runtimes with full release management integration hooks (via PaaS), this stuff is hot! As a guy who used to write code for a living, I definitely appreciate the idea of eliminating any of my “infrastructure plumbing headaches” so that I can sling business logic. Its good times. That said, it doesn’t come for free.
I’m From the Cloud and I’m Here to Help
Every time you push something onto the cloud, somewhere in the world, an angel gets its wings. Well, maybe not an angel, but certainly a Cloud Evangelist of one ilk or another. There exists a cadre of well-heeled individuals with one mission in mind: convince you to deploy your application to the cloud, any (but preferably a specific) cloud, rather than put it into the “traditional” data center. And for the most part, these well-meaning individuals have a point, in that delegating the plumbing is a smart call. But they don’t tell you about the dark side.
Cloud Service Providers Will Have Their Pound of Flesh
When you think about creating a cloud-native application, the primary rationale is to reduce your responsibility for plumbing, as we’ve said several times by now. In exchange, you pay the provider for its good service and both of you win.
Once you’ve agreed to this deal, in order to grow you as a customer, all your provider has to do is expand the definition of plumbing that the two of you agree on. In fact, this is exactly what moving up the stack is all about; convince you that more of what you thought of as critical infrastructure is dumb plumbing in order to capture higher revenues and especially, margins. Presto, larger addressable market.
When you see companies like Amazon adding aPaaS services like Lambda, Microsoft and Salesforce expanding into mBaaS, or IBM launch the aPaaS Bluemix – this is exactly what is going on. They say they’re providing greater value to customers – and they are – but they’re really doing it by defining plumbing up. And they’re doing it to extract more cash from you. But there’s a problem.
When the High Ground Becomes a Commodity
I mentioned a few companies above but it is a little unfair of me to leave out the rest of the IT industry. We already know that there is a price war going on for the bottom of the cloud stack (IaaS). It should be no surprise that everyone is scrambling for higher ground (PaaS) as quickly as possible in an effort to capture high-margin business before the “top of the stack” becomes a commodity. But a commodity it will become. We’ve already seen the concept of a “polyglot platform” cease to be a differentiator – long ago are the days when Heroku could boast of being the only public-cloud aPaaS committed to many languages. The emergence of open-source frameworks like CloudFoundry, OpenShift, Stratos, and others alongside the rise of container technologies like Docker is closing the window on aPaaS differentiation much more rapidly than I’d anticipated.
The Only Way to Win is Not to Play
If you’re running a software company, and you’re accustomed to the traditional fantastic operating margins of a wonderfully scalable business model, the rapid commoditization of the infrastructure and middleware cloud services businesses makes you feel like a sad panda indeed. The writing is on the wall: public cloud will eventually dominate the market for IT services, and while the game’s not over yet, watching a discount retailer run away with the starting gun is.. did I mention sad panda?
While Microsoft and others are trying to compete more-or-less directly against Amazon in the IaaS market, the smart move is to attack where the competition is not (yet) fully prepared: in PaaS. Win lots of customers before the market for PaaS is fully commoditized (e.g. before Amazon fully gets there), and find a way to hang onto them. It is in that retention effort where the danger to customers comes in. Because cloud service providers will try to retain you by adding features and functional capabilities that are valuable and reduce the effort you must expend to build and run cloud-native applications.
Hey Kid, Here, Have Some Candy
Every cloud-native application needs scalability, both in the application code and in its backing services. If you’re building your applications with best practices, you’re using microservices and backing them up with modern caching, persistence, and messaging services that support functional and reactive programming. Cloud service providers have noticed, and as a result they’re offering you more and more services that you can just plug your applications into so that smooth scalability is easier to achieve.
The way they do this is through proprietary APIs and SDKs that wrap them. You drop the SDK into your project and start working with the backing service right away, without having to run it yourself. This is a great boon to developer productivity and it allows you to focus more of your attention on the business logic while the provider takes on more plumbing. In exchange you pay a premium of a few cents for the extra convenience and compute cycles. What a great deal!
You Can Check Out Anytime You Like, But You Can Never Leave
There’s a scary downside. Without realizing it, you may be locking yourself in to the provider’s platform in a way that makes it very hard for you to escape later on. We’ve already established that there is a hot price war in IaaS, and I think I’ve made a fair case that the PaaS market is headed toward commoditization and a subsequent price war of its own. Cloud service providers want to build a proverbial moat around their businesses to avoid hemorrhaging customers later on. Proprietary services are that moat, and once you cross it, providers hope that it will simply be too hard for you to escape its friendly confines.
Protect Yourself with Contextual Independence
To be sure, it’s not all bad on the provider side of the moat. In fact, as long as you make an explicit choice to be over there, I have no problem at all with your decision. But far too often these things happen without a conscious effort, or by degree over time. For this reason I think it is important for every cloud application architect to carefully consider what we’ve decided to call “contextual independence”:
- Well-defined interfaces
- Few external dependencies
- All external dependencies are easily satisfied
For a full deep-dive into how these concepts can be applied to your cloud-native application architecture decisions, I invite Gartner for Technical Professionals clients to read my latest paper entitled “A Guidance Framework for Architecting Portable Cloud Applications“. If you want to better understand this concept right now:
Generalizations are dangerous but good ones contain some truth, and the above image is no exception. SaaS provides essentially zero contextual independence. PaaS provides some, and IaaS often provides a lot (if you’re careful). If you want your application code, data, and service functionality to be portable you have to take contextual independence into account. If you fail to do so, you may find yourself locked into not a castle, but a prison.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.