From the earliest days of enterprise software development, developers have been presented with the challenge of writing code on laptops and desktops that provided nowhere near enough power to run the OSes, middleware, and application servers that would eventually host their applications. At first blush, people think this was done because of licensing costs, but cost is a red herring. Even if app server vendors gave their tech away for free, a local development environment would still be problematic.
Typically, production application servers and middleware carry hefty requirements. Often they need significant CPU and memory to provide all the services an application needs. Add in the requirements of a custom app itself and you have seriously substantial resource requirements.
Vendors traditionally provide development runtimes allowing developers to develop disconnected from production expectations. IBM has WebSphere Application Server for Developers and Microsoft offers IIS Express (and formerly Cassini) as a local runtime in place of the beefier IIS.
Platform as a Service (PaaS) isn’t immune to this issue, and may even exacerbate it. Most PaaS architectures are distributed by nature. Most PaaSes have physical components (usually loosely coupled microservices) responsible for running the PaaS itself. These components define the subsystems that make up the PaaS. Examples include caching components, schedulers, health monitors, cataloging, inventory services, etc.
In a production environment, these subsystems would be distributed across some number of OS instances, helping spread risk, resource needs, and scale and availability concerns across multiple virtual and/or physical resources. This makes sense, but consider PaaS in a practical development lifecycle. What if I’m on a plane or at a beach and I don’t have access to my organization’s central PaaS environment? What if I want to rapidly test and debug? Clearly, my laptop can’t run a distributed PaaS architecture as intended. Now what? I need to run a copy of my PaaS locally.
Collapsing the distributed architecture to the single machine case is a must-have requirement for a PaaS. A developer can install the PaaS as a micro-cloud on their development image, allowing for disconnected development and local debugging and testing.
There is one catch. The localized PaaS has to be as representative as possible of the production PaaS, but cannot offer the actual capabilities of the production environment it has issues holding it back. Let’s think of the basic feature/value stack a developer’s guest application either inherits from the PaaS or explicitly taps into via APIs:
The result is clear: a developer has to modify his or her expectations when it comes to local development. For example, scalability and availability in a one-node PaaS will either be severely crippled or non-existent. Testing for these features locally is silly because they’ll fail by default. Other services such as storage and NoSQL instances that IT might be providing to developers in the extended developer services catalog—add-ons in Apprenda lingo—might not be available locally, meaning that your application’s run-time bind requests might fail. If they are available, the performance, feature fidelity, or accessibility might be quite different from what the production PaaS instance offers.
Ultimately, this means that not only do developers need to be using a PaaS that can run locally, but also, developers need to understand the ramifications of local development. We’ve invested a ton of energy at Apprenda ensuring that our Enterprise PaaS can install in highly varied infrastructure environments, including in a single-node development environment so that we can equip developers to succeed.
Want an easy litmus test as you’re evaluating a PaaS? Ask a PaaS vendor what it would take to bake a development copy of their PaaS into your existing corporate development environment golden VM image. If the PaaS can’t be run on your development environment and produce a reasonable subset of the production experience, you’re likely to find the actual experience lacking.