by Eric Knipp | January 28, 2015 | 1 Comment
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.
Category: Applications Cloud Cloud Application Platforms Tags:
by Eric Knipp | May 1, 2014 | 2 Comments
The Gartner Application Architecture, Development, and Integration season is upon us! Every year, Gartner Events runs a series of events geared toward the application delivery leader. The biggest is in Vegas, but there are satellite events in Sydney and London. Owing to the presence of Technical Insights content geared toward demonstrating the GTP (formerly Burton) service to potential clients, I’ll be speaking at the latter on May 19-20 with colleagues Gary Olliffe and Gonzalo Ruiz. AADI London is sure to be a great event, featuring presentations on application development in the cloud and on mobile devices.. as well as the back-end services that implies. This conference is all about how application delivery leaders should adapt themselves and their organizations to the art of delivering the digital business, and it will surely be filled with great insights and fun times.
This year I have the pleasure of taking the stage with Gonzalo for a presentation on Migrating Applications to the Cloud and with Gary for a presentation on API strategy, both topics near and dear to my research the last several years. I’ve also got a round table on crowd sourcing application development – bring your war stories and peer questions! If you’re still boning up on the topic, my recent research document is sure to help.
More than two dozen Gartner analysts will be there, presenting on the latest in enterprise-ready (and enterprise-disruptive) application delivery practices and technologies. On top of that, we have a ream of fantastic exhibitors, including both enterprise mainstays like Oracle and Tibo, and cutting-edge enterprise newcomers like 3scale, ZeroTurnaround, and CloudBees. Got questions about how your application delivery strategy fits with the capabilities these guys are bringing to market? Ask them to tell you how they can help – then come talk to a Gartner analyst in a one-on-one session to learn objective pros and cons about the story you’ve been told. When you’re done, network with peers as you cut loose during our fun evening events. There’s really nothing like a Gartner conference – it is the best of objective IT advice, world-class tech vendors, and the brain trust that makes it all hang together – you!
Category: Applications Crowdsourcing Tags:
by Eric Knipp | April 4, 2014 | 6 Comments
Crowdsourcing has become well known because of high-flying concepts like the X Prize and the Netflix Prize. And everybody has heard of Amazon Mechanical Turk. Less well known are coding puzzle sites like Project Euler and HackerRank. Then there are the hidden gems for Application Development organizations – the crowdsourcing AD vendors like [topcoder] and uTest. That Crowdsourcing has appeared in many kinds of work, including application design, architecture, testing, and development, isn’t that surprising. Cutting edge “rocket science” stuff (which the X Prize literally rewards) always seems to make its way into the everyday eventually. What IS surprising is just how much impact Crowdsourcing AD can have on the enterprise today.
In my paper “Use Crowdsourcing as a Force Multiplier in Application Development” (link available to Gartner for Technical Professionals subscribers), I explore how Crowdsourcing maps to three key areas in the SDLC – design, test, and coding. I talk about good practices in applying Crowdsourcing to your own projects, and finally about the rise of the Crowd Curator – a new kind of role that blends the technical aspects of application architecture with sophisticated soft skills in community and project management. There’s no doubt in my mind that Crowdsourcing AD is going to be huge for the enterprise – and those who figure out how to harness it early will enjoy a substantial advantage over their competitors.
Category: Applications Crowdsourcing Tags:
by Eric Knipp | April 2, 2014 | 5 Comments
At the BUILD conference Microsoft announced that Windows is free for all mobile devices with screens smaller than nine inches. That means for phones and some tablets, Windows is basically free.. as in beer. Awesome!
Let’s back up for a minute and really think about this. The last few years, Microsoft has gone from a joke in the mobile world to having a respectable OS that a lot of people like. The uptake hasn’t been great, but that was before the price was free (and before universal Windows apps were announced at BUILD today). Microsoft is offering you a little free candy so that they can hook you on the hard stuff later. The hard stuff is Microsoft Azure and a ticket into the emerging Microsoft cloud services ecosystem, encompassing cloud services, media services, data services, and partner apps and services.
Unlike a PC, a mobile device is of limited utility without a robust back-end. Microsoft is banking on that fact. Sure, they can give you the mobile OS for free.. but what they’re giving you is basically useless. Only the most trivial apps can function without a set of data, processing, integration, etc. services powering them. Microsoft hopes that by giving away the OS, they’ll grow bigger market share (they will) and that this will in turn give them a chance to push app developers into the waiting maw of Azure (it probably will).
About the only thing that can get in the way of success here is a price war that’s recently gone hot.
Category: Uncategorized Tags:
by Eric Knipp | August 2, 2013 | 5 Comments
I had a great week at Gartner Catalyst where I spent time with many clients and got to catch up with friends old and new. Gartner analysts speaking at our conferences not only present on-stage, we spend a large amount of our time in one-on-one sessions with attendees. During these one-on-ones, we try to help our clients answer their most important questions and solve their most challenging problems. As you can imagine, at a conference with 1500+ attendees, there are a lot of different questions to go around. My most popular client question came down to, “How do we select and implement API management capabilities?”
While working with attendees to answer this question, I noticed a concerning trend. Attendees interested in talking to me about criteria to use in selecting an API management product often could not articulate an API strategy; even worse, few had spent much time considering the importance of API design. I definitely felt the focus was more on buying a solution, rather than understanding the fundamentals of API strategy, design, delivery, and management.
Rolling Without a Strategy Will Cost You Money
Why are you building your API? A lot of people tell me they need the API because of a particular mobile project (or at least, that’s how they’re funding the development of the API). When I ask about the long-term plans for the API, I get a lot of blank stares. That’s a problem.
Your API might really just be for that one mobile app. But I doubt it. The real value of an API lies in its ability to provide access to many new channels that were previously very difficult to reach – mobile, social, third-party developers creating new apps, and so on. On top of that, your API might be relevant in a partner integration scenario, or even for running your own non-mobile Web applications. If you make design decisions in a vacuum – based on the presumption that the API is just for the mobile app you’re currently working on – you will paint yourself into a corner.
Maybe it is worth being painted into that corner because of the learning you’ll get by executing quickly. That’s a position I can understand and respect. But it isn’t one that I endorse taking by accident; it will cost you money down the road. So, start by having an API strategy that takes explicit positions on what the API is and is not intended to do and how the API strategy aligns with your business strategy. My colleague Gordon Van Huizen has written a great document on the topic.
API Design is Important
I’ve written about it extensively, but just to make it clear, one more time: API design doesn’t require you buy any new technology. You should begin your API design before, or at worst, in parallel with your exploration and purchase of an API management solution.
Without an explicit process for API design, the temptation to turn it into a supply-side exercise is great. The odds of building the wrong thing become much higher. Without an understanding of what a good API looks like for your audience(s), you’ll also have a harder time prioritizing capabilities available in the API management product space. Loosely translated, this means that in the absence of understanding, you’ll substitute money and pay for a bigger, heavier, and more expensive API management platform than you really need. Skipping API design is bad on a lot of fronts.
The first step in doing an API well is to create a well thought-out strategy. The second step is to do a great job with design. Please don’t skip these steps.
Category: Uncategorized Tags:
by Eric Knipp | July 28, 2013 | 2 Comments
A little levity before we start off Gartner Catalyst. A b-school friend of mine pointed out that as we go through life in the US, there’s a bit of a love/hate relationship with getting “carded” for alcohol purchase. I realized immediately that this relationship bears a striking resemblance to something we know well at Gartner..
While I won’t be giving a presentation on this topic, I still hope to see you at Gartner Catalyst.
Category: Uncategorized Tags:
by Eric Knipp | July 26, 2013 | Comments Off
I’ll be in San Diego next week at the annual Gartner Catalyst conference. “Convergence” is the theme this year. Specifically, the convergence of mobile, social, and information – all backed by cloud – to bring about new opportunities and challenges for enterprises and IT professionals alike. My team is presenting a “virtual track” of application architecture and development goodness. Our presentations explore:
- How to develop applications for delivery to mobile devices and the desktop
- How to select the optimal development frameworks
- How to improve your development methodology in the face of a volatile technology climate
- New approaches to software architecture
- How to leverage the cloud in your custom-built applications
I hope you’ll join us. If you can’t, I’ll be tweeting as often as I’m able.
I’m still hiring one more analyst for our Egham office. If you’ve got well-informed opinions on software development, great presentation and writing skills, a passion for telling people what you believe about IT, and you live in the UK, please take a look at the job description. Feel free to drop me a line if you want to ask a few questions about the role.. and if you’re just positive you want to be a member of our team, go ahead and apply!
Category: Uncategorized Tags:
by Eric Knipp | May 20, 2013 | 2 Comments
Large enterprises are very interested in the PaaS value proposition, but much less interested in making strategic commitments to public PaaS. This is generally true of public cloud overall. Only in the SaaS area do we see substantially less durdling by our enterprise clients. My working theory is that this is mostly because popular SaaS options are a cut above their packaged counterparts in capability, usability, and spending flexibility; plus, the business won’t take no for an answer. The differentiation available in some SaaS is too alluring to ignore.
The same has so far not proved consistently true for public cloud IaaS and PaaS. To be sure, these areas are growing; recent financial analyst AWS revenue estimates are impressive indeed. Step back a minute and let the reality sink in that the market for cloud services is at least as large as the existing market for enterprise IT (hardware, software, and hosting) itself – then, the AWS number doesn’t look nearly as big. There’s still a lot more cash burned in traditional data centers than there will be in public cloud IaaS and PaaS for some time. We can argue until we’re blue in the face about whether that’s a good thing or not, but it is what it is…
And, what IT is, at least with respect to PaaS, is a growing enterprise desire for Private PaaS. Mock it at your peril – just like private cloud, the ship has sailed and will be pulling into a harbor within an enterprise data center near you. The value proposition for Private PaaS seems compelling – an increasing number of stories suggest that Private PaaS can get you both reduced operational burden and higher developer productivity. As anybody who reads my blog knows, I think that developer productivity is a big deal.
Private PaaS is coming, but how do you adopt it if you’re the “classic” enterprise IT organization with a diverse portfolio of home-grown applications and integrations, running on what I will for the purposes of this discussion call “classic” middleware? Do you wait around until 2015 (or later) for Java EE 8 to bring you the cloudy features you’re looking for, now that we know for sure that Java EE 7 won’t have any? Or, do you just wait for your preferred IT megavendor to get around to offering you a for-real, multitenant, cloud-native, Private PaaS that goes beyond simply slapping a pre-built middleware stack onto a virtual machine?
If for your enterprise, technology is just a necessary evil, a cost of doing business, then the answer is probably yes: wait until the early movers have wrung all the new value from the PaaS model and pick it up when prices are cheap and the systems commoditized. My guess is nobody reading this blog feels that way about IT.
If for your enterprise, technology is expected to expand the business, to serve as a differentiator in your market, to deliver what MBA types like to call competitive advantage – then Private PaaS can no longer be ignored.
Category: Cloud Cloud Application Platforms Private PaaS Tags:
by Eric Knipp | May 17, 2013 | Comments Off
I am heading back to Germany after a few fun days in London at the Gartner AADI conference. We had a good show, with a high level of attendee enthusiasm and interaction. I had good 1-on-1s and a very engaged (if small) set of workshops on .NET in the cloud, private PaaS, and cloud application architecture. I have a few quick takes on my experience.
Professional Effectiveness is a Big Issue
At lunch today I presented to a set of interested attendees on Gartner for Technical Professionals (GTP) – our value proposition, resources available to clients, and so on. In a nutshell: as GTP analysts our mission is to accelerate time to competency for the solution architects using our material. When you get a new project, we provide objective advice and how-to guides that will shorten your effort’s time-to-value.
Among our technical coverage areas (which include application platforms, data centers, cloud computing, mobility, social software, and so on) we also include one focused on “soft skills” which we call Professional Effectiveness. The idea here is to help the propellerheads communicate more effectively, manage up better, manage their careers more competently and just generally function at a higher level than their purely technical skills might suggest. The attendees to our GTP lunch focused laser-like on this topic, sharing with us numerous challenges around staff development. This is a great way to leverage GTP research and I was glad to see it. As a broader trend, I think it bodes well for the next generation of techies to have engaged managers who care deeply about professional development. And, it’s neat to see how our PE agenda is helping to shape at least a small number of the next generation of IT Leaders.
.NET Shops are Interested in a Hybrid Cloud Future
My workshop on “Choosing .NET Platforms for Cloud Computing” was my best session of the conference. Workshops are a great forum, providing an extended time (90 minutes) for analyst expository on a topic, incorporating several exercises and group discussion. The intimate environment of a large boardroom makes for a crackling atmosphere when the audience is truly engaged, as the attendees of my session were. We worked through the framework I developed for my soon-to-be-published paper on assessing .NET alternatives.
Capacity utilization rose to the top as the most important consideration among session attendees, followed closely by reduced time-to-market. Further, all reported very strong interest in hybrid cloud deployment models that preserve the enterprise’s option to choose runtime location at a later date. Basically, .NET shops represented in my session are looking to get elastic, cloud-native solutions out the door as fast as possible but without compromising portability by mitigating vendor lock-in as much as possible (or as much as is possible once you’ve already locked yourself to Microsoft by virtue of the choice of .NET). These were interesting findings for me, and I didn’t see as much desire for lift-and-shift style cloud adoption as I expected.
API Management is Really Popular
As usual, 1-on-1 topics were diverse and interesting, but the most often asked question had to do with Web APIs. API management came up frequently but it was good to hear more clients asking about API design issues, which I think are so much more important than which API product suite you end up buying (or consuming as a cloud service). API management has been a hot space lately and there was no shortage of vendor representation at the event, but attendees were also very interested. I saw a great appetite for my API design paper – which I hope will prevent some GTP clients from making major design mistakes.
Did you attend Gartner AADI? What were your most important take-aways?
Category: Uncategorized Tags:
by Eric Knipp | April 30, 2013 | Comments Off
According to Forbes, the “API market is on fire“. My conversations with Gartner clients on this topic would seem to confirm the article’s top line. In the first quarter, only application PaaS crowded out APIs as the most popular topic for my client dialogues (and that’s counting the fact that for the month of March, I picked up all of a departing analyst’s PaaS client calls). I have covered APIs at Gartner since mid-2009 and have seen a steady growth in client interest. If you’re an API aficionado, that’s great news.
Now, for the not-so-great news. A great many API initiatives from non-technology companies suffer from poor, or entirely absent, design. Beside the usual REST-vs.-SOAP impedance mismatch that experienced object-oriented developers have to work out, there is a darker, more sinister force causing problems with enterprise-created APIs: laziness.
We want to get our APIs out the door as fast as we can so that we can start leveraging them, monetizing them, seeding the market with them, powering our mobile apps with them, and so on. In our haste to get the API to market, we can easily be tempted to take a short cut – simply expose our existing domain models (which include our databases, web services, SOA repositories, and so on) to the world with a thin veneer of REST generated by some development tool. Presto! API. Not so fast.
The practice of “domain model dumping” is sure to be a scourge of poorly-designed APIs in the coming years, especially if the recent acquisitions have lit a fire under the hindparts of previously oblivious CIOs and CTOs. As the API landscape becomes increasingly crowded, developers will discover that they have several (or even many) functionally identical APIs to choose from – so don’t give them a reason to avoid yours. Gartner’s approach to API design focuses on several key factors, in an approach we call Consumer-Driven API Design.
A Consumer-Driven approach decouples API design from the underlying data model it exposes to its intended audience. It forces the design team through a repeatable and transparent methodology that produces demonstrably better outcomes than an ad-hoc and hackneyed approach. And the best part: you don’t even need a fancy-pants API management product to do it. If you’re interested in getting better at API design, as a Gartner for Technical Professionals client you can have a gander at my document on the topic, and follow it up with a conversation with me.
Finally, I am still looking to hire a couple of great analysts in the UK. Click here if you’re interested!
Category: Web APIs Tags: API