Apprenda & The PaaS Runtime Model: Show Me the Money

By Atos Apprenda Support

For anyone that’s seen Jerry Maguire, the “Show me the money” scene is arguably one of the best (or at least most repeated!) movie scenes in the past 20 years. Rod (the customer) tells Jerry that he needs one simple thing from Jerry, “Show me the money”! We’re at that phase in PaaS where customers need a “Show me the money” moment. Customers are saying quite simply, “show me the money” with respect to PaaS and we Jerrys (the PaaS providers) need to deliver. The goal of this post is to walk you through an actual “show me the money” moment and help quantify what PaaS runtimes, specifically Apprenda, can deliver that other PaaS models simply can’t. In our nerd world of IT, the “money” customers are asking for is the huge value around building next generation apps and running them on a layer that decouples apps from infrastructure details. Lately, I’ve spent quite a bit of time focusing on drawing a distinction between PaaS models that focuses heavily on helping developers deploy and manage applications (pushing bits around to different servers) from those that act as a runtime that enhance the guest applications they host with new capabilities (essentially injecting new architecture DNA into standard web and SOA applications). Many “demos” of PaaS systems grab a publicly available application and quickly deploy it to show their value. There is value there for sure but we should expect more from a PaaS and the story shouldn’t start at deployment, it should end at deployment (as this one will).

Understanding Where PaaS Runtimes Fit in

What makes a runtime architecture for PaaS interesting is thatPaaS runtimes instrument themselves into their guest application’s execution model, introducing new, enhanced behavior to those guest applications. This instrumentation can happen at the highest level of granularity such as at the HTTP conversation level, and, as is the case in Apprenda, can go down to threading behavior in the .NET CLR and even how CPU is managed across cores. Clearly, a runtime is much heavier R&D lift, hence the focus on single languages with depth rather than shallow value across many languages, but boy, when the customer asks “show me the money”, what a difference. In this post, I decided to take everyone through a deep dive of what a PaaS runtime can do that you can’t do with the non-runtime PaaS flavors. I’ll actually walk you through an application deployment on Apprenda and how to quantify the value. Although nuanced, the goal isn’t to dig on other PaaS offerings, but instead, to show what PaaS runtimes can do and how to quantify their value. At the same time, it’s important to realize that no other PaaS can replicate the sort of value I’m going to discuss.

To set the stage, let’s settle on a very basic framework for what a PaaS runtime should do:

  1. Abstract underlying infrastructure resources into a shared pool, decoupling the application and developer from those infrastructure details
  2. Providing a backdrop for all application management tasks, ranging from application deployment to application updating
  3. Provide APIs and a runtime execution engine that helps developers trivially build one of the four cloud application archetypes.

In this post, I plan to show all 3 framework components in action, with emphasis on bullet 3. In subsequent posts I will zoom in on bullets 1 and 2 to show a greater level of detail.


An Experiment to Evidence the Value of PaaS Runtimes

My co-founder and VP of Client Services, Matt Ammerman, ran a little experiment with our Apprenda PaaS – he took an already built multi-tenant .NET application, and moved it to Apprenda to see how much easier (if at all) it would have been to build on Apprenda. The purpose of this is that we strongly believe that a PaaS runtime must equip developers to be able to write cloud application architectures with little to no heavy lifting, much like the JVM or CLR equip developers to write managed memory applications with features like automated exception handling with no heavy lifting.

For his experiment, Matt decided to use a well-known sample application created by Microsoft known as “Fabrikam Shipping” as his target. You can check it out here (source code link at the bottom of the Fabrikam page or grab it from MS’ website here). Fabrikam Shipping is an application targeting Windows Azure that embodies a proper, multi-tenant web service architecture. It’s really great work and highlights certain key aspects of Azure (which is one of the more impressive PaaS offerings out there). The Fabrikam application architecture aims to provide a reusable architecture pattern for multi-tenant services and is composed of 20 Visual Studio projects that define:

  1. The core application logic and presentation model
  2. Multi-tenancy (Isolation models including fully isolated and fully shared)
  3. Tenant provisioning services and UIs
  4. Metering & billing
  5. Identity management & federated identity services
  6. Azure services management

We’re going to start at the results first. As a PaaS runtime, Apprenda already provides a bunch of these capabilities in an *inherited* way, meaning that by running the Core Application only on the Apprenda platform, Apprenda can instrument this sort of architecture into Fabrikam, achieving the intended outcome, and add even more functionality like scale-out, database sharding, query scoping, monitoring, entitlements management, etc. . Essentially, Matt removed all code from Fabrikam that wasn’t part of bullet 1 above. This means he removed all auxiliary services in 2-6, as well as any code in 1 that was in support of 2-6 (such as code in 1 related to multi-tenancy). Matt ran Visual Studio’s built-in code metrics tool before he ported Fabrikam to Apprenda, and after. Here are the results:

Platform VS Projects Lines of Code Maintainability Index
Azure 20 projects 9,529 lines 78.5
Apprenda 2 projects 1,506 lines 86

Doing the math, that’s an 84% reduction in the total lines of code, without sacrificing quality or functionality. Yes, “lines of code” are not a good measure of productivity in the general case, but when you back 84% of the code out of a project and have more capability, there is something meaningful communicated in the metric. As a weighted function, that 84% represents tricky topics like multi-tenancy and identity federation, so it’s a much more difficult 84% than the remaining 16%.  In this case, this isn’t a knock against Azure – Azure is amazingly powerful tech in many different ways, but it does quantify Apprenda’s value quite clearly. If you run this trimmed down version of Fabrikam on any other PaaS, you just end up with the basic behavior represented in the code – no additional capabilities. This means that in other PaaS’, you’re still responsible for lots of the cloud architecture heavy lifting. Don’t believe me? Give it a try (link to source is below – just comment out the two lines of Apprenda specific code in the project) To understand how we threw out 84% of the code, let’s dig in to the Fabrikam Visual Studio solution. Here is a screenshot of the Visual Studio Solution structure with some highlighting (I explain the highlighting below):

On the right-side of the screenshot, you’ll notice that I’ve tagged the project with what part of the architecture the given project represents. Projects highlighted in red represented functionality unneeded on Apprenda, so they were deleted. The two remaining core projects representing the Core Application could be deployed to Apprenda as-is. However, the 2 projects were modified by adding 2 lines of  code which were not necessary for the app to run but needed to personalize the UI the way the original Fabrikam did. The reason we could do this is that the expectation for a cloud architecture outcome is shifted away from the developers who built Fabrikam, and to the underlying Apprenda PaaS runtime.

As a runtime, Apprenda instruments itself at cutpoints inbetween tiers, managing call flow and context, and also hosts application components themselves either in traditional Microsoft containers like IIS but enhanced with in-memory components that help the application execute, or by hosting them in custom Apprenda based containers, such as our P2P service container system. This instrumentation allows Apprenda to create a functional outcome that is different than was intended by the developers of the original application, but can take configuration items from those developers to help dictate what the ultimate outcome is (like being able to instruct Apprenda on isolation patterns, etc.). The end result is an app that does much more than what the code of the app would lead you to believe.

Deploying the Application

Once Matt completed these changes, the next step was to package the new Fabrikam and deploy it to an Apprenda instance. Matt used our CLI, the Apprenda Cloud Shell (acs for short – please note, we haven’t released the acs yet, but will be making it available shortly), to do this. Matt could have used our Developer Portal, a web-based portal for app management, but chose not to. Essentially, Matt used two key acs commands:

  1. ConnectCloud to connect to an Apprenda instance that he already registered on his local dev environment (you can register Apprenda URLs and alias them for easy reference later. For example, you may register things like “My Laptop”, “Dev”, “Staging”, and “Production” clouds and then refer to them as such later.
  2. NewApplication to create a new application against the connected cloud. This command allows Matt to provide a path to his solution. Once the command is submitted to acs, a build is kicked off, the binaries are packaged on the fly, and are then pushed to the Apprenda cloud. There are a bunch of flags that can be supplied, like Stage, which tells Apprenda that this is either a “Sandbox” deployment or a “Published” deployment (Apprenda has rigid stage constructs to help govern versioning and version lifecycles)
  3. You’ll see Matt use other command like GetStatistics and DisconnectCloud. Don’t worry about these for now.

Watch the video to see all of this in action (it zooms in after a few seconds so you can see some of the detail).

The only thing not really shown here is that Matt had created a deployment-manifest.xml file that is bundled in the application archive that is packaged and pushed to the Apprenda cloud instance. This file contains configuration information consumed by Apprenda during the deployment of the application, including information like what application services to bind to, what isolation strategies to use at different tiers (like the presentation or persistence tiers of your application), etc. The image shows you a snapshot of a manifest.

If you think about what we’ve done, we’ve taken an application that, if written on Apprenda to begin with, would have contained 84% less code, be written as a standard web app, but would run as a full blown cloud application with all the bells and whistles. Additionally, we deployed the application in a single command. The only way to acheive this is via a PaaS runtime, and not via the typical PaaS architectures you see out in the wild. Doing runtime and expert depth in .NET is what makes this value possible.This is what you get with laser focus on being best of breed.

The amazing R&D staff at Apprenda made this happen because they built a model for PaaS that focuses on a runtime, application container model rather than simply focusing on application management tasks. This sort of stuff is what makes Apprenda insanely great. We’re quite certain (clearly, we can’t be 100% positive), that no other PaaS on earth can achieve this sort of outcome – an outcome that produces huge value for developers. And to think, we haven’t even touched things like caching, publish/subscribe events, etc.! Even more interesting is that this is just one app – our customers have hundreds and will build hundreds more in the future so the benefits get multiplied. With that said, using Apprenda for even just one mission critical application produces real tangible ROI immediately (just count the weeks of coding that you saved multiplied by the cost of highly specialized devs who can write this code for Fabrikam and then add the maintenance cost).

Over the coming weeks, I plan to refer back to this Fabrikam example and walk you through what it’s like to manage an application running on Apprenda, and also what it’s like to be the platform owner that operates an Apprenda instance on the behalf of all the development teams that use it. In the meantime, click one of the links below and download Apprenda Express and install a PaaS cloud on your laptop, download the original Fabrikam source code, download the modified one described in the post, or download an Apprenda Archive file with a packaged version of the ‘Apprenda-ready’ Fabrikam source code. Here are some links to those resources. (Be sure you have minimum requirements taken care of -Apprenda Express for the Apprenda version of Fabrikam if you want to compile, the Azure SDK for Fabrikam on Azure)

Download Apprenda Express Original Fabrikam Source
Apprenda Fabrikam Source Apprenda Fabrikam Package

I hope you walk away feeling the way I do – that anything less than a PaaS runtime is unacceptable and focus on bringing the best value to each stack in a depth first way is the only way to go. You should expect your PaaS to help you write, deploy and manage cloud applications faster and better. Don’t be tricked into thinking that PaaS is all about AppOps/DevOps/whateverOps – while there is tons of value in that, it is only a drop in the bucket in the context of a model that helps developers build world-class apps with modern architectures.


Atos Apprenda Support

View Comments
  1. PutulMarch 21, 2012

    Hi,I’m interested to see how PaaS tolnhecogy evolves. I like your comparison to WYSIWYG webpage tools. I suspect you might be right.I’ve been researching the options available to me, as a developer wanting to move as much of the logic and function onto online services as possible, and the services tend to fall into two groups:1) they want to do it all for you. They almost exclusively end up looking like Salesforce, with tabs and database metaphors all over the place;2) they have APIs to do common tasks and let you get on with writing code to bind them all together.I don’t really want to write code, but I can’t help feeling that the drag-n-drop approach is not really any simpler than writing some simple code to bind services together.If the development of PaaS is like the development of code editors, we’ll see lots of little tools released that help you not have to re-author the same thing for each project: I wonder what the PaaS version of jQuery or Ruby on Rails will be J.

  2. AmitMay 4, 2012

    Sinclair, as usual, you post a nugget of wisodm and describe good use cases. You make an excellent distinction between simply pushing bits (an operations activity) and injecting application behavior (an application run-time activity) shielding developers from run-time infrastructure details (i.e. location, topology, scale, coordination, lifecycle management). I appreciate you finding an easy to understand dividing line. I didn’t join WSO2 to see PaaS get hijacked and commoditized. My is starting to describe a and the current lack of .

  3. cobiacommMay 13, 2012

    I agree most PaaS platforms do not “Abstract underlying infrastructure resources into a shared pool, decoupling the application and developer from those infrastructure details”. The familiar machine shell and one tenant application per service node cluster model still dominates.

    Single tenant, dedicated container PaaS forces a one to many relationship between tenant application and application server nodes. In contrast, a multi-tenant, shared container PaaS offers a many to many relationship between tenant applications and application server nodes. Is there a “Show me the money” difference? You bet, up to 659% better investment performance when deploying in high tenant, multiple service scenarios. Read through the calculation and download the worksheet at

Comments are closed.