Thinking Out Cloud

Application Lifecycle in the Cloud

Cloud computing is having a profound effect on the software application lifecycle.

Almost every phase of creating and rolling out software applications is now addressed by a growing number of cloud services: from prototyping, to development, testing & QA, continuous integration  -- and all the way down to staging, deployment and post-production (monitoring and management). All of this can now be done in the cloud.

The vision is compelling. Imagine a world in which programmers can access their development environment from any computer without having to set up anything, collaborate with teams spread around the world, easily push the code to testing and QA, and then to production, where the apps will be automatically monitored and managed.

Although admittedly realizing this vision in full is several years away, we are already seeing many of the components emerging and gaining traction.

Here are some examples:

Development

Almost every area of the development phase is now supported by cloud services. Software-as-a-Service code repositories, version control and bug tracking services such as GitHub, Beanstalk (Subversion-as-a-service) and others are now commonly used in organizations large and small.

IDEs are another story. Until recently, IDEs were last bastion of local development work, but that seems to be changing (at least there are some early indications of it). A couple of example are the Mozilla Lab's Bespin project and HerokuGarden (which although it is no longer supported by Heroku, has a following and is featured in books such as O'Reilly's Learning Rails).

Another trend in IDEs are hybrids, which introduce the notion of developing on the local machine but deploying to the cloud from within the development environment, such as the g-Eclipse project and Aptana Cloud Connect.

A new tool that was recently released and caught my attention is Mike - a service for adding and managing builds in Java for continuous integration.

Testing and QA

This is a particularly active area in the cloud, and for good reason: testing seems to be one of the earliest applications for cloud computing. Some interesting companies in this space include Sauce Labs' Sauce On-Demand, which provides functional web testing in the cloud and is based on the popular open source framework Selenium, and Skytap which provides a full-featured "QA Lab".

Mercury (now part of HP), the 800 lbs. gorilla in testing also has quite a few SaaS offerings, which are increasingly gaining traction. And IBM has launched a development and testing cloud service, which allows using various Rational products in its cloud on a pay-per-use basis.

As a "bursty" workload, and with the growing trends of continuous integration and agile development, it's not surprising that cloud testing is doing well. Developers can run massive tests on-demand and in parallel, saving significant time and shortening the development cycle.

Deployment

Then, of course, there is deployment to production. This is where PaaS players such as Google AppEngine, Force.com, Stax, Heroku, Engine Yard and others come in. All of them significantly reduce the deployment of the app by pre-building and pre-configuring a stack of application infrastructure (data tier, middleware and so on).

Production

In production, applications need to be monitored and managed. New Relic is an application performance management service running entirely in the cloud, and it can serve both applications that run in a cloud environment such as Engine Yard or AWS, as well as applications deployed in the data center. Originally, the company supported only Rails apps, but has now expanded its product to support Java as well.

RightScale is another cloud-based service that allows for a variety of management and monitoring capabilities (and in fact integrates New Relic into it).

The Future of App Development

Last week I received a call from a friend at one of the largest vendors in the technology industry. He told me they were trying to figure out the "future of application development" and asked to meet the team so they could "pick my brain". Whoa, big topic.

I spoke about a number of areas and the topic of this blog was one of them. Although this is merely a story about "tools", there is a bigger picture here. After all, in the eyes of many, the number one benefit of cloud computing is increased business agility. And a key part of business is application development.

If we take all this to its logical conclusion, we can envision a web-based environment (i.e., cloud) which developers go to and can -- with a click of a button -- streamline the entire development process on-demand, accessing the myriad of tools that today require installation and configuration on local hardware.

If you are a developer and use any of these tools, or would like to mention other tools, or have any other thoughts about the experience of development in the cloud, please leave a comment.

The Purpose-Driven Cloud: Part 3 - Domain-Specific Clouds

This is the third post in the series I described in The Purpose-Driven Cloud. the series is an attempt to categorize the various cloud platforms available today (and that may be available in the future). Each installment examines one of the dimensions that differentiates various cloud platforms. Previous posts discussed the Usability-Driven Cloud and Framework-Based Clouds. This post is about: -

Domain-Specific Clouds

Unlike general purpose clouds, such as IaaS clouds (for example, Amazon Web Services) and PaaS clouds (e.g., Google App Engine), domain-specific clouds are cloud platforms intended for developing apps (or components of apps) with a particular kind of functionality.

The example that epitomizes this concept is Twilio -- a cloud platform focused entirely on telephony and voice applications, as I described in detail in What's Really Exciting About Cloud Computing.

Other examples include testing clouds (SOASTA, SkyTap) and ITStructures' PoC, Demo and Training Cloud.

The rumor is that OpsCode is working on an IT automation domain-specific cloud using Chef, the domain-specific programming language the company is promoting.

Other domain-specific clouds are sure to follow, as well as industry-specific clouds, which will be the topic of the next post in this series.

The Purpose-Driven Cloud: Part 1 - Usability

As I explained in the previous post The Purpose-Driven Cloud: Introduction, this is the first in a series of blog posts on the different cloud platform offerings available today and how they focus on different dimensions to serve different purposes. This post discusses --

The Usability-Driven Cloud

Usability-driven clouds are a concept similar to the idea of programming language generations. Lower-level generations give the developer complete access to the computing infrastructure, but are extremely complex as the developer is required to build every aspect of the application from scratch. Higher-level generations are much easier and intuitive to use by humans, and come built-in with many common tasks and functions. But this usability comes with a price: the developer cannot access the underlying resources, or "plumbing", at a fine-grained level.

In programming languages, 1GL (1st generation language) would be machine language, 2GL is Assembler, 3GL are high-level languages such as C and Java, 4GL are mostly niche programming languages designed for specific business purposes (such as scientific analysis) and 5GL are visual programming tools (think "drag & drop"), which in their original vision were intended to allow non-programmers create software applications. For the most part, 4GL and 5GL never became mainstream (although the corpses of many attempts lay on the wayside of Silicon Valley roads).

We're seeing similar "usability generations" evolve in cloud computing. However, they come in two main flavors: deployment usability and programming usability.

Deployment Usability -- Platforms of higher deployment usability generations focus on easing and abstracting the process of deploying and configuring the application, not necessarily on writing the code for it. In modern development, this is as big an aspect of application development, if not bigger, than actual programming. See James Lindenbaum's Why Instant Deployment Matters for more on this topic on the Heroku blog.

At the moment, all of the IaaS players can be generally categorized as lower generation deployment platforms. This includes Amazon EC2, Rackspace, Terremark, GoGrid, etc.

PaaS offerings such as Heroku are a higher level generation deployment platform and eliminate the vast majority of infrastructure setup and configuration required to get an app running (hence James's use of the term "instant deployment").

I further discuss Heroku's role as an application platform in Ruby Developers: The Cloud Generation.

Programming Usability -- This dimension is similar to classic programming language generations. So while Heroku is high-level in terms of deployment, it is relatively low level (in modern day terminology) in terms of programming. You have to develop your apps in straight Ruby (which in classic terms would be a 3GL). This is the same generation programming language you would use on an AWS or Rackspace (on either of which you can use pretty much any 3GL language - e.g., Java and C++ - but more on that later).

But although 4GL and 5GL languages failed to become mainstream, we are seeing a revival of them in the cloud. A few examples of such platforms, which generally enable non-programmers to develop apps, include Intuit's Quickbase, WorkXpress (who in a conversation with me explicitly called themselves 5GL PaaS) and even Salesforce.com.

Note that I am not referring here to the Salesforce.com CRM SaaS application, which is a packaged app; nor am I referring to the company Salesforce.com Inc.'s PaaS offering Force.com (which is a high-level deployment platform but low-level programming platform). I am referring to the fact that a business user can quite easily create a custom app using Salesforce.com by creating new objects, fields, tabs, workflows, etc. without any programming skills.

Another thing to keep in mind is that high-level programming clouds will invariably be high-level deployment clouds, as they appeal to non-programmers.

Finally, it's important to emphasize that a higher generation platform in either usability dimension -- programming or deployment -- is not necessarily better or worse than a lower generation platform. It depends on what you are trying to achieve and the skills and resources available.

If the purpose is to develop a unique app that requires a high degree of optimization, a lower generation platform is better. If the task at hand involves building an app that uses typical services and functionality, and a general-purpose infrastructure will serve it well, then a high-generation platform is in order. It's a trade-off.

In the next installment in the series I'll be discussing The Framework-Specific Cloud.

Stay tuned.

The Purpose-Driven Cloud: Introduction

Nearly a year ago I posted Thoughts on Platform-as-a-Service, in which I reviewed the state of cloud platforms at the time. A lot has happened since then, and it's time to revisit the latest and greatest in PaaS and specialized cloud platforms.

I've been asked several times by companies I advise or just talk to, as well as by journalists, how should companies select a cloud provider? The answer is, as it almost always is, "it depends." Similarly to what we had already seen in programming languages and traditional application platforms (i.e., installed on-premise), different platforms have been designed to serve different purposes.

I am planning on publishing a series of posts with the general title of "The Purpose-Driven Cloud", which cover the different dimensions that differentiate cloud platforms and make them more suitable for different purposes.

The dimensions I am going to cover are:

• Usability-Driven Clouds [UPDATE: Post is live here]
• Framework-Based Clouds [UPDATE: Post is live here]
• Domain-Specific Clouds [UPDATE: Post is live here]
• Data-Driven Clouds
• Industry-Focused Clouds
• Geographically-Centric Clouds

Simultaneous to this intro, I am publishing the first in the series: The Usability-Driven Cloud.

What's Really Exciting About Cloud Computing

Last week I attended an event in New York organized by Tibco as part of their launch tour for their new cloud offering, Tibco Silver. It was a really fun panel to do with Mike Culver from Amazon Web Services, Mike DiPetrillo from VMWare, Ed Simmons from Deutsche Bank and Sreedhar Kajeepeta from CSC.

As the panel was about to wrap-up, Farrell McManus, moderator of the panel and the publisher of Waters Magazine, asked the panelists something to the effect of what makes us excited about the future of the cloud. My response was that most of our conversations on cloud computing now focus on how the cloud will enable us to do the same things but cheaper, faster and easier, what's really interesting to me is how the cloud will enable us to do things we couldn't before. And as an example I gave Twilio.

Twilio is a remarkably simple concept, but very difficult to implement in an elegant way, as the Twilio folks have done. It is a cloud platform that enables developers with basic web programming skills to develop complex voice applications.

Under the hood -- but completely transparent to the developer or the end user -- Twilio is hosted on Amazon EC2, uses a multi-tenant architecture and has implemented a fully functional telephony infrastructure based on the open source framework Asterisk.

But again, the developer is shielded from the complexity of the telephony infrastructure, something that used to require specialized engineering skills that involved things like ports, trunking and SIP servers. Instead, all the developer needs to do is call the Twilio service from his or her web app via a simple API that consists of five verbs: Play, Say, Gather, Record and Dial.

The other interesting aspect of Twilio is the pricing model. It is a simple pay-by-the-minute model, and a cheap one at that: 3 cents per minute, inbound or outbound. No upfront or monthly fees, no contracts.

Lastly, Twilio is highly scalable on demand. If a customer is now running some huge marketing campaign -- and some of Twilio's customers have done just that -- the system can scale without warning as needed.

These last two aspects of Twilio -- pay-per-use pricing and on-demand scalability -- are a direct consequence of the fact that the service itself runs on Amazon's cloud platform with a multi-tenant architecture.

The end result of all this is that the barriers to creating highly creative and sophisticated voice applications (or adding a "voice interface" to existing web apps) are extremely low. And it means that we won't just be able to create the same apps we did at a lower cost, but that a whole range of new applications will be developed. You can already see some of that happening on Twilio's blog.

In order to get people's imagination working on the types of apps they can create with Twilio, they have organized several developer contests, and you can check out the creative results on the above linked blog.

Their current contest is one of my favorites. It's aimed at Ruby developers who run an app on Heroku and use Twilio. If you read my post Ruby Developers: The Cloud Generation, you'll realize like me that this is some serious cloud-on-cloud action that really changes the game.

Check out this video Morten Bagai from Heroku that shows how easy it is to get a Ruby app running on Heroku and using Twilio:

How to create a Twilio app on Heroku from Morten Bagai on Vimeo.

Ruby Developers: The Cloud Generation

In Evans Data Corp.'s  first 2009 North American Development Trends Report, Joe McKendrick reports that Ruby usage has increased 40% during the past year. Darryl Taft of eWeek writes about the report:

According to Evans Data's biannual North American Development Survey, 14 percent of North American developers use Ruby some part of the time, up from 10 percent in 2008.

Moreover, the survey showed that 20 percent of developers expect to use Ruby in the coming year.

This trend is somewhat corroborated by the Framework Web Trends report from Built With.

To cloud computing there is a special significance in the increased adoption of Ruby, because Ruby developers are the cloud generation.

Back in early May I attended Oreilly Media's RailsConf 2009, the largest annual event for the Ruby-on-Rails community. It was an enlightening experience for me as for the past 10 years or so I had been deeply involved in the enterprise Java world.

For those of you unfamiliar with the story of Ruby, it is a dynamic programming language that has been around for more than 15 years but became "hot" circa 2006, particularly among the Web 2.0 crowd. It really took off when David Heinemeier Hansson developed the Rails web application framework as part of his work on 37Signal's Basecamp software-as-a-Service in 2005. It became especially famous by the fact that companies such as Twitter were using it and Ruby enjoyed an adoption explosion in 2006-07.

So essentially RoR is a programming language that is only now coming of age. And what struck me at Railsconf was that as a community they are taking cloud computing as a given. This is how you deploy apps. Period.

Before I explain further, an analogy I use for this is the telephone infrastructure in under-developed countries. Many countries in Africa and regions of China, for example, jumped straight to cell phone infrastructure. They simply skipped landlines for the most part.

In a similar fashion, the Ruby community is essentially skipping traditionally on-premise installed software. The dominant model for RoR application deployment is cloud, with platforms such as Slicehost (now part of Rackspace Cloud), Engine Yard and Heroku. Cloud services such as New Relic, FiveRuns and Scout provide the de facto standard monitoring and management frameworks, and cloud-based GitHub is the standard code version and developer collaboration tool for the RoR generation.

Moreover, training courses and educational books, such as Oreilly's Learning Rails , use cloud platform Heroku as their standard learning environment. Meaning that a new generation of developers, for whom Ruby is their first or early programming language, are growing up with cloud platforms as a natural part of life, just as my kids are growing up with Google Docs, Wikipedia and smartphones as a natural part of life. Imagine that.

What's also interesting about Ruby-land is that unlike Java, a programming language that made its big entrance a little over a decade ago, there are no dominant software vendors for Ruby infrastructure/framework/middleware/platform space. Instead -- and this is perhaps another area in which Ruby skipped a generation -- all of the application software components are pure open source plays, including Ruby and Rails themselves (and also including a long list of components such as Sinatra, Rack, Mongrel and Thin). 

And the same goes for the various Virtual Machine implementations of Ruby, such as MRI (the original), JRuby (a JVM-based implementation) and IronRuby (an implementation for the Microsoft .Net Framework).

If you had gone to a Java conference in 1997, the vendors dominating the show would have been WebLogic and NetDynamics (and Sun, of course) -- the three leading app servers. At the 1999 JavaOne show, they would have been the vendors that acquired them - BEA and Sun.

In the 2009 RailsConf, the two dominant vendors were Heroku and Engine Yard. Unlike some perceive these companies, they are not merely Rails hosting services -- they are the application platforms for Ruby, and they are on the cloud.

Heroku has demonstrated a particularly deep understanding of this role. They have "curated" a complete tightly integrated platform out of the various components and deliver an extremely easy to use platform that takes care of all things infrastructure (scalability, reliability, configuration, database connections, etc.) and lets the developers focus on their unique logic -- not the plumbing. They are, in essence, the WebLogic of the cloud generation.

Full disclosure: I am advising Heroku on strategy and marketing.

Hubs, Spokes and Islands in the Cloud

Many of the cloud start-ups I've been working and talking to during the past few months are facing some of the same go-to-market challenges. Larger companies are also facing these issues (see podcast with Intuit, for example). My intent is to write a series of posts discussing these issues and some of the considerations around them.

This first post in the series has to do with the cloud offering's role in its ecosystem. Before I jump into it, I acknowledge the fact that there is a very large body of work about this topic. Please see my footnote on this.

We can think about as the hub-spoke-island dilemma: cloud providers (IaaS, PaaS, SaaS) and cloud services need to make a strategic decision about their role within the ecosystem.

Some are the sun of their solar system (hub) and others play the role of the planets (spoke). But things can get a bit more complex than that and the decision on what role to play is not trivial.

The Hub

What characterizes a hub is that an entire ecosystem of products and services evolves around it. In addition, the hub typically "owns" the customer relationship. Some examples of cloud-related hubs are:

Amazon EC2 - A plethora of ancillary services and tools have been created to support Amazon's compute infrastructure-as-a-service. Examples of these satellite services include RightScale's EC2 management and deployment offerings and Hyperic's EC2 monitoring support. In addition, many vendors -- including IBM and Red Hat -- have made their software products available within the Amazon ecosystem, including pay-per-use hourly pricing (billed by Amazon) and packaged Amazon Machine Images (AMIs).

Another example is Salesforce.com/Force.com, with its AppExchange. AppExchange allows third-party providers to offer various applications that extend and enhance Salesforce.com's core CRM capabilities -- and many have.

Spokes

Spoke services are ones that complement and enhance a hub, but are not viewed as the central service in the eyes of the customer. In fact, spoke cloud services often have no value unless they are working in the context of a hub service.

There are many examples of spokes.The popular VerticalResponse email campaign service is a classic example. It has zero value without access to a customer database, and so it is most often used as an extension to a CRM application such as Salesforce.com. I have already mentioned RightScale and Hyperic, both of which make classic spokes. And there are many others, just check out Salesforce's AppExchange or Intuit's Marketplace.

Should Everyone Strive to be a Hub?

The answer is simply no. While the hub has the great advantage of owning the core relationship with the customer, one can only be a hub after having that customer base. And to attract many satellite services, it has to be large customer base, something that takes both time and money. Many spoke services don't have a large enough addressable market, or the wherewithal to make that investment worthwhile. Attaching yourself to an existing large customer base can be a very lucrative strategy.

Take for example TopTier, the company that made Shai Agassi rich and famous when it was acquired by SAP for $400 million in 2001. Agassi chose a "ride the elephant" strategy, developing a portal product for existing SAP application users. In a sense, become the spoke for a single large hub is a risky strategy. In fact, many companies have tried and failed in this strategy when they built apps for Microsoft Windows' hub or for other platforms. The risk is of course that the hub vendor itself will get into the business that the smaller company is in (instead of opting to acquire it as in the case of TopTier).

In the cloud, we saw this risk materialize for RightScale last year when Amazon announced it is releasing (or planning to release) several services that RightScale had provided as a value-add to Amazon, such as a web management console and auto-scaling.

Spoke to Many Hubs

Continuing with the RightScale story, the company realized they cannot be entirely dependent on Amazon as their sole hub, so they quickly introduced support for additional cloud providers, such as GoGrid and Flexiscale. In fact, many of the other spokes I have given here as an example, are in fact spokes to many hubs, like electrons shared by atoms in a covalent bond.

The "spoke to several hubs" approach has the advantage of both access to a much larger install base as well as significant reduction of the dependency on a single hub. It is almost an eventuality that any company with a spoke strategy will end up with.

Snowflake Patterns: Hub-Spoke-Hub-Spoke

Being a hub *and* a spoke is not mutually exclusive. CohesiveFT's Elastic Server is a good example for this. Elastic Server is a spoke to many cloud and virtualization platforms such as Amazon EC2, VMware and Parallels. But in turn it is also a hub for the many stack components that it supports - including many free open source and commercial software.

Don't Confuse Spokes with Customers

Not every service that is built on Amazon EC2, for example, is a spoke to it. Many services are simply customers of EC2 and so shouldn't be confused with being spokes, because as far as the customer is concerned it is not part of the hub's ecosystem.

A good example of this is Heroku, a Ruby platform-as-a-service. It is a cloud that allows Ruby developers to instantly deploy their applications. Users can easily fire up additional instances of the application to scale it. Heroku is built entirely on EC2 but that fact is transparent to the user. Heroku is taking advantage of the EC2 platform but does not play a role in its ecosystem. It does not benefit from EC2's install base, nor does it add value to direct EC2 users.

The Island of Doom

Perhaps the worse scenario is to be a completely independent island in the ecosystem. Neither a hub to many spokes, nor a spoke to one or many hubs. Very few companies other than Micorosoft, Google and a handful other mega-vendors can afford to quickly build both the product depth and breadth as well as the customer base to survive and thrive in this environment -- and even those large vendors are increasingly relying on the ecosystem.

The classic Silicon Valley island story is of course the early years of the Macintosh versus DOS/Windows. Apple famously insisted on tightly-coupling its hardware, OS and applications and all but shut out others from being able to develop to the platform. Microsoft, on the other hand (and this may sound strange to the younger folks reading this), took a more liberal approach and allowed others to develop apps to its DOS and later Windows operating systems. This allowed its operating system to have a much wider offering in terms of apps. Of course, eventually Microsoft crushed many of its own ecosystem partners by offering a competing application. Wordperfect anyone?

Building a Successful Hub

The key to becoming a successful hub -- besides having a great product/service and effective marketing -- is rapidly create an ecosystem around the service in question. This helps even small companies quickly offer a "whole product" because partners (spokes) develop complementary services the company cannot build itself fast enough.

Obviously, a hub with a large and growing customer base will attract many partners, but that's not enough. There are many ways to encourage additional spokes to support the hub, including:

• Open Platform/Open Source
• Open/Public APIs
• Offering a Software Development Kit (SDK) and other supporting tools that make developing for the platform easier
• Supporting standards which enable quickly integrating existing supporting products (such as Eucalyptus is doing with the Amazon API)
• Incentives and profit-sharing
• Helping partners monetize their solutions by providing marketing services and billing support
• Allowing easy self-service and support to partners

Note: as mentioned above, the topic discussed in this blog has been a core issue in the technology industry in general and specifically the software industry for decades. Much has been written and discussed about it, often with the terminology of platform versus application. Over the years experts have called it Value Networks (Clayton Christensen ), Value Constellation (Norman & Ramirez), Value Chain (Michael Porter">Michael Porter) and Whole Product (Geoffrey Moore ). This blog was a humble attempt to put this topic in the context of recent developments in cloud computing.

Cloud Computing Security Podcast

Security is consistently brought up as one of the main barriers to the adoption of cloud computing and one of the big challenges it presents. Issues such as security in virtualized environments, multi-tenant architectures and the cloud in general are often discussed with very little real-world understanding of the problems and the potential solutions.

So it's nice to discuss it with someone who actually knows what he's talking about, as James Urquhart and I do with Chris Hoff, the well-respected security expert and blogger, in Show #8 of our cloud computing podcast, Overcast.

Listen to it here.