Today’s PaaS Offerings: Pragmatic or Unrealistic?

Jul 12, 2010 by

Although my focus in life right now is CEO of Apprenda, I come from a software development and architecture background (I needed to put my Math/Comp Sci. degree to good use at some point in my life). Anyone who has written software in any “old” (in this case, the double quotes are for sarcasm) platform technology like Java or .NET can assure you the writing software goes far beyond writing code and then running it. There are three major inflection points in the life of a piece of software:

  1. The first time it is run
  2. The first time it is tested under duress
  3. Use in the real world

When people envision others writing code, they envision dozens of programmers writing text, deploying code, and using it. If it only were so simple. This make-believe scenario assumes that the only tool a developer uses is some sort of text editor/development environment. This is far from reality. Writing software typically requires the use of a number of advanced tools and techniques: debuggers (with the ability to work with real, running code), performance profiling tools, memory profiling tools, tuning tools for database queries, abilities to change the underlying runtime mechanics of your platform – you get the point. The reason for all of this is that code does not run as we expect it to, and this becomes painfully apparent at the three inflection points I described.

Interestingly, the general complexity of business software has been increasing. That is, business apps try to tackle more complex problems as each company tries to outdo their competitors by offering the market more value. This means that code also becomes more complex, tooling becomes more important, and visibility into an application becomes key.

Why then, did PaaS offerings (think Force.com style abstract PaaS offerings, particularly in the Apex only days) start off with such a “lowest common denominator” platform? Since business apps are becoming increasingly complex, and PaaS offerings presented a layer much less sophisticated than traditional platforms like .NET, how pragmatic are they for ISVs? As a tool for extending a CRM system, Force.com is clearly great stuff. It offers a simple way to provide new value to an existing system. But as a platform for serious ISVs who need to build complex offerings  - that’s a stretch. The complexity required of a serious development platform just isn’t there, and most software companies should recognize that. There are so many questions that are currently unanswered that make modern PaaS offerings unrealistic for many, many scenarios. Interestingly, these questions are unanswered for at least one (if not all) of the lifecycle inflection points I defined earlier:

  1. How can I debug a live Force.com (as in real, “attach to the code and see what’s going on” debugging)?
  2. My customers are complaining about speed, how can I performance profile and tune the application?
  3. How can I optimize around certain types of resource consumption?
  4. I can I use new architecture techniques if the PaaS is too limiting (think Apex before asynchronous calls – a concept that has existed in mature platforms for quite some time)
  5. My application is not working as expected in production, and my developers need access to system specifics and the running code to assess what’s going on, how do I get to the live runtime?

I could go on for a long time.  Fundamentally, PaaS offerings seem far too trivial with VERY immature tooling. Yeah, yeah – you’ll here the “In PaaS X, you’ll never have to worry about Y.” The fact of the matter is, code rarely meets expectation at those inflection points, and developers need to dig deep to make magic happen. PaaS offerings really trivialize this. It reminds me of the days when WYSIWYG editors were going to “revolutionize” how websites were made (think Frontpage, Homesite, etc.) and that web design would be democratized, and no one would have to touch HTML, JavaScript etc. We all know how that turned out. The concept of “everything can be written for you, no need to “hand tweak” has never worked at scale, and typically has failed miserably. The best web properties are still written “low level” (relative to web technologies), and complex tools and libraries for JavaScript, Flash, and Silverlight are flourishing.

“Old” runtimes can do a far better job than PaaS when coupled with purpose-built middleware for SaaS and cloud infrastructure like EC2. Developers can capture complex requirements and systems with the right languages and have all the real world tools needed to properly build, test, and evolve software.

Do you feel that PaaS offerings nailed it, or do you agree that they missed the mark and currently cannot support high levels of complexity and real software development life cycles? Is PaaS currently a reflection of WYSIWYG web editors and we’ll instead see a cloud stack evolve that doesn’t try to “solve everything” in one silo?

read more

Related Posts

Tags

Share This

Has SaaS & Cloud forced the server operating system into irrelevance?

Jul 6, 2010 by

I had the pleasure of reading a Structure 2010 follow up article written by Stephen Lawson titled “VMware’s Maritz: OSes are having their jobs stolen.” In it, Lawson outlines VMWare’s CEO Paul Maritz’ position that modern applications are relying on frameworks farther up on the stack for abstract services that used to be provided by the operating system, and that those frameworks insulate the application from even knowing what the operating system is.

This “commoditization” of the server OS is expected to some degree and is a case of “what’s old is new again.” Looking back through history, we’ve seen software development take on an evolutionary path of abstraction. Starting from assembly (x86 is my personal reference point) through higher order abstractions like C++ through byte code targeting virtual machines (as in the JVM and .NET CLR), we’ve always looked to move away from various OS level complexities in an effort to boost productivity, increase maintainability, and reduce coupling risk. However, these benefits were only considered OK so long as it didn’t jeopardize the programmers’ ability to express complex solutions to complex problems because of functional crippling that might arise from being too abstract. Typically, two things have held true:

  1. New paradigms in solution expressiveness have driven the introduction of new languages that embody those paradigms. For example, once “modeling” became en vogue, object oriented programming made sense. Now, we’re seeing a resurgence of functional languages or hybrids.
  2. Transitions in delivery paradigm have typically acted as catalysts to the creation of new frameworks (passive libraries) and runtime technologies (active application layers) to support the new delivery paradigm.

What we’re seeing today in that Cloud is that scale of technology coupled with the introduction of new application architectures and delivery needs that operating systems were not built for. OS’ are general purpose beasts with explicit and valuable capabilities and coordinating a fundamental execution platform. They are not specialized enough to really understand the upstack pressures being exerted on software developers. Clearly, they could be modified to do so, but were never meant to constantly evolve in that fashion. Instead, they are participating as a critical component at the bottom part of a stack.

When we look at SaaS and some of the architecture dimensions specific to SaaS such as multi-tenancy, the need to be able to achieve web-scale, and have operating tools in place to manage the application, we start to see that new modern frameworks, and in many cases, new types of middleware, are needed. This is the whole motivation behind why I helped co-found Apprenda and we set out to create SaaSGrid. In the early days, my co-founders and I frequently had conversations about how today’s applications need not know about OS specifics in order to function properly, which lead to some of the early architecture decisions of having SaaSGrid act as a mechanism that would leverage the decoupling of app components from their underlying network and OS dependencies to help facilitate scale-out (many details, of course, which go beyond the scope of this post.) As SaaSGrid matured, it took on a number of architectural dimensions on a guest application’s behalf, such as providing baseline single instance, multi-tenancy at all tiers or scaling out by offering partitioning services that can help reorganize application component distribution across a network of servers without reconfiguring or rewriting parts of the application. In effect, SaaSGrid started to manifest a number of “OS-like” capabilities, which go far beyond the frameworks that Maritz describes. It seems inevitable that upstack pressures will also hoist value-add solutions away from the core machine/VM OS, but we should all remember that a stack isn’t a stack if the bottom-most piece is missing or instable.The traditional server OS has simply transformed from necessary and sufficient to necessary but not sufficient.

Do you agree that the server OS is becoming commoditized with respect to cloud offerings, or is this an over-dramatization of what’s happening? If you feel the OS is fading into the backdrop, is there an opportunity for the OS to “modernize,” and if so, how?

read more

Related Posts

Tags

Share This