Platform as a Service (PaaS) tools are an important part of the modern developer’s arsenal. They provide a complete environment for building and delivering applications: taking care of both the underlying infrastructure (like hosting servers, compute and storage engines, and security) and the development tools, databases, frameworks needed to build mobile, web and enterprise apps.
In the 11th edition of the Developer Economics survey (for Q3 2016), cloud developers across the globe were asked which cloud platforms they use, and to rate the importance of features like ease and speed of development, security, flexibility, learning curve, and support/documentation. Based on these responses, Developer Economics calculated an overall satisfaction score per solution that truly reflects which cloud providers are delivering the services that developers care about, and which are focusing their efforts in the wrong place. This has now been compiled into the Cloud PaaS Developer Satisfaction Tracker.
The survey covered the major Public Cloud PaaS options:
- AWS Elastic BeanStalk
- Google App Engine
- Heroku
- IBM Cloud Platform
- MS Azure App Services
- Oracle Cloud Platform
- Red Hat OpenShift.
Which Developer Segments are Using PaaS?
Developer segments making use of PaaS tools include:
- Explorers experimenting with new ideas who want to quickly build proof of concept applications,
- Product Extenders looking at better managing their product range while reducing their overheads on infrastructure management, and
- Corporate Guns for Hire and Hunter developers who are using Cloud PaaS to work with enterprise clients and build commercial apps to enter new markets quickly.
How each developer segment uses PaaS, and their thoughts on the direction PaaS tools must take, varies according to their goals and objectives. We spoke with three developers: an explorer, a product extender and a gun-for-hire about how they use PaaS tools.
Developer Explorers using PaaS
By day, Jack Skinner works as API Evangelist with the MYOB software company where he supports over 4,000 developer partners to build integrated solutions. On weekends, he attends hackathon and maker events. So he often needs to quickly create proof of concept ideas from scratch and uses PaaS tools as a complete creation and pilot deployment environment. “When I look at PaaS vendors, I’m looking at the simplest possible solution to launching an app,” said Skinner. “This lets me focus on building the next greatest API demo or side project rather than focus on the underlying infrastructure management.”
Skinner said that there is still some difficulty in choosing which PaaS to use, as there is rarely a feature list that compares the different options side-by-side. “I have more experience working with Heroku,” he said. “I find the tutorials documentation really smooth and their social response has been really great: I have tweeted questions and gotten immediate replies, and that for me is definitely one of the deciding factors: Can I experiment and get feedback quickly?”
Skinner offered some advice to developers starting in Cloud PaaS environments. He recommended that developers follow the 12-factor app mindset for building apps. Eventually, if an app is successful, it will grow to a point where developers need to scale components of their app and might choose to take them off the PaaS and into their own infrastructure environment. By using the 12- factor process, apps will be built from the outset in a more composable form that lends itself to having some components taken out and moved around without destroying the data flow or services.
Skinner also suggests developers alter sample code to reduce vendor lock-in. “To a certain extent, with any level of tech, there is always some level of vendor buy-in: the language framework, the toolkits or the underlying services. But you can create environment-independent code. For example, in naming conventions around environmental variables, you could use app_n rather than heroku_n so that your dependencies are not hardcoded.”
To sum up, Skinner suggested:
“When building for PaaS, I’m generally looking to:
- Isolate dependencies so that there’s minimal vendor lock in
- Detect features rather than hard coded dependencies, and
- Automate, visualise and have pipelines for deployments.”
Skinner admitted that any developer on a growth trajectory will at some point need to accept that they may need to pick up their app and move it into a different PaaS environment, or into their own infrastructure. “To have the vision that you will be able to pick up your app and move it is a bit idealistic. There will always be work to do to change your infrastructure, your libraries, there is always some kind of overhead,” he confirmed.
Product Extenders using PaaS
Alex MacCaw, CEO of Clearbit, a software service that offers market intelligence based on contact emails and business domains, says that the PaaS market is quickly maturing so some of Jack Skinner’s limitations around using PaaS are already changing.
“Traditionally that has been the case that PaaS is best for proof of concept and experimentation,” confirmed MacCaw. “But there are some very interesting developments happening that will let you have a production-grade PaaS and host it yourself.”
One of Skinner’s concerns is that as an app grows beyond the initial prototype, and starts to gain users, PaaS has difficulties scaling up which is when devs need to take certain app components out of the PaaS environment and into their own infrastructure. MacCaw says that PaaS gives developers the freedom to focus on their app without worrying about the infrastructure and DevOps management, and as they grow, newer PaaS tools are becoming flexible enough to allow a deeper dive into the DevOps working of their apps. He pointed to the open source project Deis as the type of new generation Cloud PaaS that is most promising.
MacCaw says when looking for a PaaS, it is important to choose one that can work with the top three hosting environments: Google, Amazon and Microsoft. He encourages devs to consider PaaS not just for prototyping but for running their apps and websites in production: “You will ultimately need a sysadmin but hopefully this means you can put it off for longer and will need less in the long term,” he said.
Guns for Hire and Hunters Using PaaS
Saul Caganoff is Principal of Platform Engineering at Deloitte Consulting where he works with enterprise clients to implement technology platforms, including helping them make use of Cloud PaaS solutions.
“Many organizations are looking to become their own platforms. They recognise the benefits that a platform can give in terms of rapid iteration and innovation, plus reduced costs through shared infrastructure. But developing the platform requires significant up-front planning and design. We use a PaaS approach in delivering these capabilities since those technologies provide high levels of automation and take care of many of the challenges of distributed systems,” said Caganoff.
He clarified that for many corporate clients, they are looking for private PaaS solutions rather than the public offerings like Heroku and Google AppEngine, as enterprise often want to make use of the data in their legacy systems, which means running PaaS behind the firewall.
He does recognise the benefits of Cloud PaaS: “The great thing about using Heroku, for example, is you write just the code for your app and you get all the autoscaling and availability out of the box. The problem with public cloud PaaS is that they can be very isolated. For developers working in an enterprise innovation lab, you can do the app in Heroku but most people want to leverage off their existing assets. For example, in a bank you want to create apps that use banking transaction data and core banking services. They need to be able to get the velocity that comes with PaaS but leverage their existing assets. That requires either an on-premise PaaS, or some standard AWS-type infrastructure.”
Caganoff suggests that smaller developer teams, who may be looking to build for enterprise clients in future, look to use a PaaS that offers both public cloud and private on-premise editions (like RedHat’s OpenShift). This will let the developers become proficient on the public PaaS solution while also building their enterprise skill-set.
What PaaS Are Developers Choosing?
Given the diversity of reasons why developers are using PaaS, the best solution is rarely obvious. Overall, technical support, ease-of-use and availability of developer tools were often more important than price for developers choosing a PaaS solution, but the logic behind the decisions isn’t always so easily identified. For a comprehensive look at what developers care about, and where that is taking them, see our Cloud PaaS Developer Satisfaction Tracker.
What is the Developer Satisfaction Tracker?
The Developer Satisfaction Tracker is a research service exploring when and why developers choose competitor products over yours – and how to fix that. Our data proves you are the leader or helps you become one. We survey 30,000+ developers annually, including your competitors’ developers, to analyze and measure their experience across competitive products. This is not just an analyst assessment of software products, it’s the real developer experience. The Tracker helps SDK, API and platform vendors to better understand when and why developers choose competitor products or services over theirs – and how to fix that.Our research service tracks the developer experience across 10s of developer products, and measures 8 key quantitative and qualitative indicators of that experience.
