Yesterday, I wrote about the trends pushing developers toward PaaS solutions and away from IaaS. The simple analogy is that IaaS is the “assembly language” of the cloud world, while PaaS represents a higher level language. With IaaS, developers have complete freedom to build and configure anything they want, from the operating system on up, but in return they have the responsibility to do all that work. In contrast, PaaS systems make a lot of choices for developers ahead of time, but then offer a pre-configured, high-level starting point that is “good enough” for a large class of applications.
Now, most of the time, when people talk about PaaS, they think of the public providers. Yesterday, I mentioned Microsoft Azure, Google App Engine, Salesforce.com with Force.com and Heroku, and VMware Cloud Foundry as examples.
There are a number of drawbacks to public PaaS, however. Some of them are outlined by Bernard Golden, in an article for CIO.com, Cloud Computing: What You Need to Know About PaaS. Bernard’s article highlights the fact that each of the various public PaaS solutions has a unique API with its associated learning curve. Once you commit to adopting one public PaaS offering, you’re going to be locked in quite thoroughly. Moving your application from one provider to another will require lots of rewriting. If we go back to our programming language analogy, once you commit to Java, moving your application to Ruby would require a rewrite.
This lock-in can result in problems if the PaaS provider changes the rules of the game, particularly with pricing. In spite of lots of warning, Google managed to ruffle feathers with a recent price-increase for App Engine. Also, think about the disruption to your application if your provider went bankrupt. While you could probably recover, it would take some time to move your application around.
JP Morgenthal, in Thar Be Danger in That PaaS, points out that public PaaS might carry greater trouble-shooting risks than either IaaS or SaaS. In short, with IaaS, the developer owns everything from the operating system on up. If the virtual machine is running, the IaaS provider is doing his job and any problems in application logic can be blamed on the application code, all of which is owned by the developer. In the case of SaaS, the service provider owns the whole application and can debug problems better because everything is under the provider’s control. With PaaS, there is a shared responsibility between the provider and the application developer. Subtle interactions between the PaaS middleware and the application code can create problems that are difficult to debug. This can result in finger-pointing and application downtime.
To expand on JP’s post, remember back to the old days, when clouds were just those puffy white things in the sky. Way back when, Microsoft Windows used to suffer from “DLL hell,” where different applications would require different versions of the same shared library in order to run properly. Installing a new application might actually break an old one if the new application updated a shared library to a newer version that conflicted with the older application. The solution was to keep multiple copies of a DLL around. This is one reason why a modern Windows system has several different versions of the .Net libraries installed simultaneously, for instance. In short, as much as programmers try to provide backward compatibility, it’s a difficult problem.
Public PaaS services are going to suffer the same problem (“PaaS hell?”). As careful as we are, we’re still going to find that a version update to the PaaS service will break an application. Since most public PaaS environments are built to be multi-tenant, this poses a big problem. What happens when the PaaS provider upgrades the service? Does it happen at midnight on a given day, with all applications forcefully moved to the new environment? You wake up in the morning and hope your application is compatible with the new environment and is still running? Or does the provider offer to migrate each application on your timeline? If things break in the new environment and you want to keep your application in the old environment, how long are they willing to keep the old environment running? Are you forcefully migrated at some point?
In order to bypass many of these concerns, enterprises are increasingly looking to “private enterprise PaaS” systems. In the case of private PaaS, the enterprise builds a custom PaaS environment and maintains it itself. This is often performed by the so-called “platform engineering group.” An enterprise PaaS system may be as simple or complex as desired.
At the simple end, ServiceMesh customers have created standardized .Net and Java development environments that run on a single virtual machine. For example, a Java environment might package Apache, Tomcat, JBoss, and MySQL together on a RHEL base. A .Net environment might package IIS, .Net, and SQL Server on a Windows Server base. These single-VM environments are used for basic applications without heavy performance or scalability requirements. The advantage in this case is the standardization of the components, tools, and configuration. These environments are so low-level that our customers have taken to calling them “IPaaS” offerings, for infrastructure and platform as a service, the expectation being that users can still work at the operating system level and add more components or tweak them, if desired.
At the other end of the spectrum, there are ServiceMesh customers who have created sophisticated multi-VM PaaS systems based on full IBM WebSphere, Oracle WebLogic, or open-source foundations. These systems are deployed as giant, connected, auto-scaling topologies on top of IaaS. They can run in private clouds or in public clouds (there are some licensing restrictions with public clouds, but that’s a topic for another post). Using ServiceMesh’s Agility Platform, developers or testers can have one-click access to a private environment with 100% fidelity to the production environment because it’s the exact same topology.
Whether small or large, a private enterprise PaaS offering provides a number of advantages:
- You get to choose the components and API that are right for you. If you have previous experience with a given environment, you can leverage that skill set and development expertise moving forward. The important point here is only that you standardize on something and then reuse it at much as possible to give you development and operational leverage.
- You can run these environments in any IaaS cloud you want, whether internal, external, or a combination (e.g., partitioned or cloud-bursting). You could create a transitory development and test environment in a cheap external cloud and then migrate the code into a more expensive internal production cloud environment when development is complete. Since you’re just using IaaS, if you locate things in an external provider and pricing changes, you can pull up stakes and migrate to another IaaS provider that offers something better — no rewrite required because you own the environment.
- You control the runtime environment and all upgrades. You won’t be forced to move to a new version of the system on the provider’s timescale. If a given application doesn’t want to run in a new version of the environment, you can keep the old version running as long as you want.
- You can run as many copies as you want (licensing obviously applies). This allows you to easily create full development or debugging environments on demand. Because you didn’t create each copy from scratch, installing all the components each time, the copy has 100% fidelity to the production copy. This reduces risk of drift between the various environments and helps ensure a quick transition from development to production.
- There is no need for multi-tenancy if you don’t want it. While there may be some licensing cost benefit in putting multiple applications into the same PaaS instance, there is no arbitrary requirement that this be done. This allows each application to be operated in isolation, if desired.
- When things break, you have access to the whole environment. You can apply all your existing debugging skills to the problem. There is no finger pointing because you control it all (though you may still have to resolve finger-pointing between internal groups who own pieces, but you’re already used to that, no?).
Now, obviously, with all these upsides there are some downsides, too. The biggest downside with enterprise PaaS is that you’ll have to build and maintain your own environment. That’s work that you have to do. In the case of public PaaS, Microsoft or Google or Salesforce.com do that work for you, but in return you’re beholden to them. In truth, however, most enterprises, particularly large enterprises, are doing some amount of this engineering work today. There is typically a platform engineering or developer tools engineering group that is trying to standardize on various middleware components (sometimes without much success). Developing a private enterprise PaaS environment requires only that these same folks focus on the development and operational aspects of it.
So, get ready for private enterprise PaaS. More and more people are choosing to go this route for the control and portability it offers.
You must be logged in to post a comment.