Sinclair Schuller

Subscribe to Sinclair Schuller: eMailAlertsEmail Alerts
Get Sinclair Schuller: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, Infrastructure On Demand, SaaS Journal, Cloud Application Management, Cloud Development Tools


Five Mistakes to Avoid When Developing Cloud Apps

Understanding the differences between traditional and cloud application architectures

The cloud has created tremendous value in the IT industry, ranging from the on-demand availability of enterprise-class infrastructure via Infrastructure as a Service (IaaS) and the simplified deploy and manage semantics of Platform as a Service (PaaS), to business applications delivered via the Software as a Service (SaaS) model.

If approached incorrectly, however, the cloud is a double-edged sword. More specifically, writing applications for the cloud requires much more sophistication than writing traditional application architectures. Certain decisions that made sense in a pre-cloud era no longer make sense in the modern cloud world. In addition, the cloud has introduced some unique programming problems of its own that, if not understood, could lead to long-term negative consequences.

The cloud is not something that is public only in nature; enterprises are adopting true, private cloud semantics where compute power, storage and applications can be consumed with ease by end users internal to the enterprise. This means that potential blunders exist both inside and outside the walls of enterprise IT.

Whether architecting applications for a private or public cloud, having a robust framework to make decisions is critical to success and the best decision frameworks help you avoid common mistakes. Learning how to avoid these five cloud blunders will provide a strong foundation to anyone tasked with building or managing cloud applications.

  1. Using traditional application architectures: Traditional application architectures are not well suited for the cloud, public or private. Surely one can use the cloud, public or private, to host traditional applications and inherit deployment and management value. But if you're writing an application for a public or private cloud, a very different approach is needed. Cloud computing offers amazing elastic capacity. Having capacity available and the writing of an application that knows what to do with it, however, are very different things. Pre-cloud application architectures are typically built for fixed-server arrangements with rigid configuration: my database is over here, my application server over there, and some web services over here. This sort of approach is hardly capable of leveraging a dynamic infrastructure environment for scale-out, let alone intelligently handling high availability or providing for failure isolation. Furthermore, cloud computing platforms are shared in nature (as is most everything virtualized).Sometimes, they can misbehave, thereby reducing reliability. Traditional software development practices with more rigid expectations tend to fail under these circumstances rather than planning for failure and working around it for continued operation.
  2. Ignoring how cost is impacted by architecture decisions: When developing non-cloud applications, it was usually the case that writing code that was inefficient or didn't perform well, or choosing architectural patterns that were not cost-conscious, meant that your customers would have to spend more time and money operating the software you created. When building cloud offerings, the tables are turned. You are not only responsible for developing the applications, but you are also responsible for operating that application for your customers. Any inefficiency will increase your operating costs, drastically impacting your success profile. Interestingly, the cloud stack evolved from the top down. A number of companies built SaaS businesses worth hundreds of millions - if not billions - of dollars, and did so well before the advent of most cloud stack technologies. They evidenced that by making wise cost-savings motivated architectural decisions such as single instance, multi-tenancy, and shared nothing architectures. Using failure tolerant patterns, a company could push more revenue dollars to the bottom line or boost quality while keeping enterprise IT application delivery costs to a minimum. The cloud, public or private, is not inherently cheaper than traditional datacenters, but its flexibility and per-unit pricing approach does make it easy to fall into the trap of throwing money at a problem rather than using innovation to drive costs down.
  3. Relying on human rather than automated workflows: Building an application and business model that leverages the cloud allows you to tap into an enormous amount of flexibility. What good is that flexibility if your application relies on human workflows that made sense only in a non-virtualized, non-cloud world? Fundamental operating workflows like provisioning new customers, business units, or partners to your application, changing price-points and modifying entitlements, dealing with billing and collections or chargebacks in enterprise IT, and rolling out application upgrades and bug fixes need to be push button and automated. Furthermore, having a service-oriented architecture where known critical workflows are discredited is of high importance for true interoperability. By leveraging cloud but sticking to manually driven operating work flows, you are setting yourself up for terrible inefficiency, thereby leaving a majority of the cloud's value on the table and leaving yourself disadvantaged.
  4. Ignoring operational lock-in risk: A number of cloud platforms, particular some PaaS offerings, tout an all-in-one holistic stack. If you use their APIs and specific infrastructure patterns, you'll be able to extract some interesting value, but pay attention to lock-in risk. In many cases, your code will only run on that particular platform and nowhere else. This might seem like a fair trade, but it's important to understand the implications: making an R&D decision of what runtime and stack to use is a very different one than committing to a day-in-and-day-out operating and hosting environment, whose reliability, security, and performance can change over time. Try to choose public or private cloud technologies that are broadly adopted (even if proprietary), or better yet, cloud platforms that draw the line at providing infrastructure value and allow you to make operating-independent architecture and programming decisions. In the latter case, identifying purpose-built cloud middleware that can be layered on top of cloud infrastructure can give you the best of both worlds and some without the associated risk.
  5. Not leveraging purpose-built middleware and tooling: Building cloud applications the right way is a difficult, costly, and time-consuming adventure. A majority of the challenges are orthogonal to your primary competency and development focus, and tackling those challenges head on is not worth it. SaaS and cloud pioneers had to build things from scratch. One of the largest time-sinks and risk points in software development is re-inventing the wheel. The software industry has reached an inflection point where everything from virtualization abstractions to true single-instance, multi-tenancy and codified, inheritable operating workflows are available in application server, middleware, or framework form factors. Not leveraging middleware and tooling that already solves a majority of the cloud architecture challenges is one of the top mistakes. In fact, by doing research and deciding to use middleware packages that already solve most cloud architecture challenges, you will already be ahead of the curve with respect to the other four mistakes identified above.

Whether you are building applications for a public cloud to be sold to other businesses, or building private cloud custom enterprise IT applications for consumption by your internal end users, business units, branch locations, or enterprise customers, it is extremely important to understand the differences between traditional and cloud application architectures. By understanding these differences, you will be able to avoid common mistakes and fast-track your journey to cloud success.

•   •   •

If you're interested in understanding more about this topic, visit, download whitepapers from, or the article Programming for Cloud Computing: What's Different? at,0

More Stories By Sinclair Schuller

Sinclair Schuller is the CEO and co-founder of Apprenda, creators of SaaSGrid, the software delivery fabric for public and private SaaS architectures. He focuses on the strategic direction and vision of the company, particularly as it pertains to helping independent software vendors (ISVs) and enterprise IT achieve superior software delivery through Apprenda technology. Schuller frequently speaks at cloud-related events and conferences, and focuses on promoting cloud related education to the IT community.

Prior to Apprenda, Schuller held software architecture and lead engineer roles on a number of SaaS and non-SaaS projects. Schuller received a dual B.S. in Mathematics and Computer Science from Rensselaer Polytechnic Institute.

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.