Platform as a Service: Empowering Developers, Unleashing Productivity

Introduction

When people hear “Cloud Computing,” most will think of Amazon Web Services, Rackspace, “renting servers and storage by the hour” -- all of which are typically grouped under the Infrastructure as a Service (IaaS) banner. Yet, while IaaS has played a unique role in defining what the cloud is today, it is a low-level layer that hardly makes sense for developers: they should not even have to worry about setting up operating systems, replicating storage, or automating business continuity when IaaS servers go offline for maintenance. IaaS realistically provides a way to consume IT’s fundamental “Lego blocks” in a cloud fashion (i.e., pay as you go, self-service, elastic, etc.), but does not provide the right abstraction for developers.

On the other hand, developers care immensely about use cases, like creating and deploying an application, instantiating a new database, building and testing their code, performing code analysis, making sure their application will be scalable, verifying their Web application works in a variety of browsers…and the list goes on. Those are much more interesting activities to a developer! This is exactly what a Platform-as-a-Service (PaaS) aims to provide: a developer-centric, cloud environment.
In this article, we will first explain some of the issues developers face today and then see how life compares in PaaS-land. We will discuss how PaaS can make developers more productive, creative, empowered and responsible for their ultimate objective: creating value for the business by focusing 100% of their time on developing business-critical applications.

Being a Developer Today

Developers are not a homogenous crowd – they do not all use the same tools and methodologies. Thus, differences arise due to company size, geography, industry vertical, culture and other variables. However, there are general trends and behaviors that can be observed in almost every company:

• Development teams are closely dependent on IT Operations. The tools that developers need to do their job (i.e. servers, storage, development tools, etc.) and the activities stemming from those resources (setup, upgrade, maintenance) have to go through IT Operations first. Consequently, since the two teams do not always share the same priorities, there is a strained interaction that frequently equates to friction, delay and frustration for all parties. Developers are tired of waiting months for new servers, while IT Operations personnel are weary of having to always support the latest new, shiny frameworks discovered by developers.
• To be really useful, development tools (continuous integration, source code repositories, binary artifact repositories, bug trackers, load testing, IDEs, etc.) typically require integration. This can be very time consuming and is rarely managed by IT.
• Not all development tools are set up and maintained by IT. Often times, IT feels that this daunting task is outside of their scope, and they will allow developers to set up what they need on “unmanaged servers” (i.e., under the developers’ desks). A prime example is a continuous integration environment, which is frequently set up and maintained by a member of the development team on ghost machines.
• Developers are not able to take full advantage of many beneficial tools that are available because the time required to set up, configure, integrate, and maintain them would further infringe on their already limited development time.

As such, most developer teams spend a non-negligible amount of their time in friction-related tasks, such as integrating and maintaining development tools that quite frankly nobody else wants to be accountable for. All of this is performed at the expense of pure-development activities, hence at the expense of the business.

Platform as a Service (PaaS) – the Friction Killer

Overall, the objective of PaaS is to solve most of the issues above by providing another level of abstraction, one that makes more sense to developers than the traditional IT model does. PaaS “industrializes” industry best practices and applies them in an efficient manner, thanks to best-in-class, highly optimized software stacks that are, ultimately, transparently mapped to the infrastructure layer.

However, not all PaaS offerings are equal, so it’s important to understand some of the main differences:

• PaaS scope:

  Some PaaS solutions solely focus on the deployment stage, helping developers push applications to production and scale them. Other PaaS solutions have a wider scope, helping developers along the entire application lifecycle from development, to testing, pre-production and finally, into production. It is up to the user to define the scope of the problems that need to be solved. (Since the focus of this article is on development in the cloud, we will not consider PaaS offerings that only focus on running applications.)
  
  Also, a number of PaaS solutions provide easy access to an ecosystem of third party providers that extend the core features of the PaaS with added-value services, nicely integrated with the PaaS solution’s core platform. There is an obvious analogy that can be made with yesterday’s ISV ecosystems in the operating system and middleware era.

• Service or software?
  

  While the “S” in PaaS means “Service”, a number of PaaS offerings would be better called “PaaSaaS” or “Platform as a Service as a Software.” While such platforms are indeed still consumed “as a service” by developers, such PaaS vendors distribute a traditionally packaged software that needs to be set up, configured and maintained by the company’s internal IT team. The difference between the two is significant, as maintaining a complete PaaS environment can be an arduous task that requires sophisticated IT skills: using such a platform is trivial, maintaining it is not. If a company cannot afford such an investment, they’re better off relying on a PaaS that is truly offered as a service by a third-party provider that will not only service your company, but also thousands of other companies, hence having a real critical mass – and the necessary expertise -- for managing such a complex environment.
  
  This externalized service component is often marginalized in discussions about the cloud: this is unfortunate, as ongoing maintenance is probably one of the most important value vectors of the cloud revolution. For example, if you are going to take on self-servicing your PaaS, you will be completely responsible for the operating system, application servers, virtual machine setup, maintenance, security patching, monitoring, backup and making sure you have the time to handle major version upgrades properly. With a full-service PaaS, you won’t even see those activities; they’ll be performed for you, in the background, in a continuous fashion.

• Private, public or hybrid cloud:

  Some PaaS offerings make you choose between operating on a public or private cloud, while others can support both. Depending on the requirements at hand, this might become an important selection criterion.  It’s important to note that private-only PaaS solutions are typically offered as traditional packaged software that you or your IT team will have to operate and maintain (see previous point).
  
  Hybrid PaaS can exist in two variations. The first one is very much a private PaaS, operated by your central IT, that offers a way to push some of your applications to one of the third-party, public IaaS providers; as such they can be defined as “hybrid-from-private.” The second variant (more rare), are public PaaS solutions (hence operated and supported by the PaaS provider, not your central IT) which offer you a way to download a software appliance that will run on your servers (running on-premise or anywhere else – such as on a virtual private cloud, a hosting provider, etc.). This appliance will be remotely managed and maintained by the PaaS provider (despite running on your hardware) and you will be able to use those resources transparently, much like any other public-cloud resource. This scenario can be defined as “hybrid-from-public”.
  
  One of the most logical reasons for running a workload on-premise (whatever the Hybrid-PaaS variation is), instead of on the public cloud, is related to being able to access legacy resources – such as databases, mainframes, ERPs, etc. – with low-latency connectivity, which a WAN connection would not provide.
  
  While security concerns are frequently raised as a way to justify on-premise deployments, this justification is too rarely grounded in reality. Such restrictions are mostly based on off-the-shelf (and aging) security policies rather than on an objective risk assessment. One typically tries to compare what the ideal security processes are (by the book) vs. what the cloud offers. However, it would actually be more appropriate to compare the level of security offered by cloud providers (PaaS or IaaS) vs. the actual security implemented within most IT organizations. In such a comparison, the cloud provider will likely come out on top, because the provider’s practices have been formed to address the stringent requirements of many organizations.

• IaaS-like or SaaS-like:

  Some PaaS solutions – that can be defined as IaaS-like – tend to offer more insight and control into the underlying infrastructure being used to operate the PaaS (operating system, JVM, application servers, drivers, etc.). Other PaaS solutions are more SaaS-like – these offerings tend to focus more on use cases that the developers will need, and fully abstract the underlying infrastructure required to implement those use cases.
  
  Initially, having more control over the underlying infrastructure can be perceived as a good thing, especially as applications are migrated from a traditional/on-premise environment to a PaaS. Yet, that flexibility can lead to complications and increased costs down the road since this customized infrastructure will likely have to be managed in the future by the organization itself (hence, the development team), as this will be outside of the normal scope that the PaaS provider offers.

We have seen that there are many flavors of PaaS available; don’t take the decision-making process lightly. Make sure to pick the PaaS flavor that best fits what you are looking for -- and to be conversant about the pros and cons for your organization, and for your specific needs.

Software Development in the Cloud Era

To further understand the benefits of PaaS, let’s go through a specific use case and see how a PaaS can be leveraged to provide tangible business value.
Andromed, Inc. is a mobile phone company that operates physical stores around the United States. Andromed would like to improve their customer experience by providing Andromed sales teams with tablets (of their own brand) so that sales can guide customers through the Andromed product portfolio, drill-down into detailed data-sheets, check the availability of various products in real-time and perform a sales transaction, including check-out, directly from the device. Welcome to the 21st century of high value-added retail! The General Manager in charge of operating those stores asks his central IT department for a quote for this project, both in terms of budget and timing.

A few weeks later, IT comes back with a detailed roadmap to implement such a project. Problem: central IT has a busy schedule and they won’t be able to deliver on the project for 12 months. Additionally, this timeframe is IT’s best case scenario. This is a big disappointment to the General Manager, as he was planning to roll out such functionality long before 12 months (or more) into the future. Also, while his division has a few software engineers working for him, they cannot take on such an endeavor without external help in bootstrapping the first version of the application.

In order to find a solution, the General Manager exposes his problem to some of Andromed’s existing service providers. One of them, BluePill, a mid-size service company, offers what seems like an innovative and promising solution:

• BluePill could start working on Andromed’s project ASAP;
• Furthermore, BluePill wouldn’t need support from Andromed’s central IT for hosting the development infrastructure (which would take a few weeks to provision, in the best case);
• BluePill would involve a few of Andromed’s retail engineers in the project. While the Andromed engineers wouldn’t contribute any code initially, they would be able to stay up-to-date on the project progress and acquire expertise in the codebase as early as possible, as their schedule permits;
• As the project progresses, all unit tests, pre-production system tests, as well as go-to-production testing and configuration won’t require involvement or resources from Andromed’s central IT (this is especially important, given central IT’s lack of availability).
• Once the software has been deployed and the project is complete, all resources linked to the project will be smoothly handed over to the Andromed retail development team: source code, binaries, test, production environment, etc.
• The project will not require Andromed to buy, host or set up any hardware: their costs for operating this solution will linearly ramp-up as they deploy the solution to new shops;

This solution appears to solve all of the Andromed’s General Manager’s problems: lack of availability from his own IT department, ability to outsource application development, and the ability to smoothly transition ownership of the development and production environment, over time. The decision is made to move forward.

The next day, BluePill creates a new account on a SaaS-like PaaS with a scope that covers both development and deployment. The PaaS is obviously a public PaaS, since the idea is to keep any kind of overhead (IT, financial, timing, etc.) very low and not rely on Andromed’s central IT at all.

Once the account has been created, BluePill adds five of their consultants to the project, as well as three software engineers from Andromed’s retail division that will initially participate in the project, passively. In just a few minutes, BluePill has been able to setup a complete collaborative/multi-company development environment. The environment initially provides services to store code, build and test it through a continuous integration service, hence making sure their code is always stable.





BluePill initially creates a few code repositories and starts implementing application code, as well as performing unit tests. To make sure their code remains robust, they configure their continuous integration server so that it runs a complete battery of tests each time new code is contributed to the central code repository.

As development progresses, the application has reached the level where it can be deployed and tested by the team. The team modifies their continuous integration server so that any new code contribution is not only built and tested, but also assembled and deployed to the PaaS; a test database is also deployed. This takes only a few clicks. Now the team is able to see, on an ongoing basis and in real time, the very latest status of the application running.

Now that the project has progressed well and its size has grown, the team decides to enable additional services on top of the PaaS; those are nicely integrated within the PaaS environment and require no work from the team. The team decides to activate: an issue tracker, a Selenium-based web-UI testing environment that permits them to test the UI on a variety of operating systems/browsers at the same time, and a sophisticated repository to store their binary artifacts.

A few months later, as the project nears completion, Andromed’s developers have started to participate in the development and testing of the software and are taking increased ownership of the deliverables.

Once the time has come to push their application to production, the team deploys a stable version of code to the PaaS and sets up proper scalability settings so the PaaS can automatically scale its computing resources up/out/down based on the usage of the application: none at night, and with recurring peaks during the day (especially during the lunch break and into the evening). The team also instantly enables a new service on the platform that provides extremely detailed performance reporting on their application and detects issues very quickly.

Fast forward. The launch has been a success and BluePill has finished its mission. Now is the time to fully transfer the project to Andromed’s retail development team. This is done very simply by removing all of BluePill’s consultants from the PaaS account that was dedicated to that project! The PaaS account now serves as an efficient “vehicle” to transmit all of the project assets to the customer: source code, binary artifacts, test/pre-production/production runtime environments, databases, history, etc. If Andromed were to ever need BluePill’s help again for the project, they would just need to add a few of BluePill’s consultants temporarily back onto the account.

In retrospect, Andromed’s retail division was able to overcome IT’s busy schedule by outsourcing their development environment, as well as production environment, with no requirement for any bandwidth from Andromed’s IT department. At the same time, Andromed maintained complete control over the resources and deliverables, and smoothly transitioned the project back to the Andromed team. Furthermore, if at some point central IT ever wanted to host this application themselves, they could do it very simply: either by leveraging the PaaS’ hybrid model (and deploying a PaaS virtual appliance on-premise) or by simply deploying the exact same application on a compliant Java application server.

Conclusion

2011 has seen the emergence of high productivity development environments that can help teams finally refocus their attention where it belongs — on developing applications and deploying them, seamlessly and easily. For those who are still cemented to their on-premise environments, general IT maintenance tasks will continue to seep into the developer’s role, taking valuable time away from high priority projects that provide very real and tangible ROI to the business.
Gone are the days when developers have to set up operating systems, replicate storage, automate business continuity and maintain infrastructure. Today, it’s time to CODE.

The cloud is the new platform — and PaaS is the way for developers to take advantage of it.