Cloud PaaS tools: this is how developers use them.

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.


Mapping The Developer Universe: Cloud PaaS & IaaS platforms and tools

The Map of the Developer Universe charts developer usage of and satisfaction with leading platforms and tools. This is not just an assessment of software products. It is the real developer experience based on hard data from 30,000+ developers surveyed annually. Check out how developers’ perception of products place them on the market map and improve your product positioning against competition.

The Map addresses the following questions:

  • Which solutions in each sector are developers most satisfied with?
  • Which solutions in each sector  are the most and which the least popular among developers?
  • Which are the upcoming solutions in each sector challenging the leading ones?
  • At a high-level, what are the key reasons behind the shown mapping of solutions?

cloud paas-iaas-platform-tool-satisfaction-infographic-visionmobile

Chatbots: From hype to “figuring it out”

Chatbots and conversational UI are among the most hyped technologies of 2016. Chatbots are computer programs that can maintain automated text conversations with users through use of artificial intelligence and natural language processing.

Early excitement about chatbots has given way to the realization that many challenges remain in both technology and understanding of what users are looking for when chatting with computers. In the words of Fred Wilson, a prominent venture capitalist who invested in Kik, a popular messaging platform:

“New user behaviors take time to develop and sometimes require a breakthrough app to get things started. That’s where we are with chatbots. The hype phase is over and we are now into the figuring it out phase. That’s usually when interesting stuff starts to happen.”

According to Comscore, smartphone apps now account for half the time Americans spend online. At the same time, the mobile app market has become saturated. It is extremely difficult and expensive right now to succeed with a consumer focused mobile app. The mobile app gold rush is over for all but large deep-pocket publishers. Mobile app developers are looking for the next big thing. 

While many challenges remain, chatbots promise to create a new channel for reaching mobile users alongside mobile apps. That’s why there is no shortage of entrepreneurs and developers taking their shots at “figuring it out” with chatbots.

All popular messaging services, including Facebook Messenger, WhatsApp, Skype, Telegram, Slack and Kik, are opening their platforms to innovation by 3rd party developers. In July 2016 Microsoft announced that 30,000 developers have signed up for the Microsoft Bot Framework. In the same month Facebook reported that developers created 11,000 bots for its Facebook Messenger platform. In August 2016 Kik, a smaller messaging app popular with teens in North America, reported that more than 20,000 bots have been built for Kik, and Kik users have exchanged almost 2 billion messages with chatbots since the company has opened its app to developers. The chatbot group on Facebook has close to 13,000 members, and a new chatbot is being announced almost every day.

The outcomes of the “figuring it out” phase in chatbots will be decided by developers. This is why we included questions about chatbot development in our 11th Developer Economics survey. 8,464 developers answered questions about chatbots and we published full results in the Chatbot Developer Landscape 2016 report.

The data shows that the efforts of Facebook, Microsoft and Slack to promote chatbot development achieved early results. An absolute majority of developers worldwide are aware of the opportunities in chatbots. At the same time, the chatbot ecosystem is still in its early stages and lots of work remains to attract masses of developers to the chatbot idea. Less than quarter of developers who are aware of chatbots are convinced of the chatbot appeal.

It’s notable that Apple and Google, the undisputed leaders of the mobile app world, fell far behind Facebook, Microsoft, and even smaller messaging apps in seizing the chatbot opportunity. Facebook is the undisputed global leader in developer mindshare with over 40% of developers interested in developing for the Facebook Messenger platform.

If you’d like to know more about what developers think about chatbots, take a look at our Chatbot Developer Landscape 2016 report, which answers the following questions:

  • What does the chatbot landscape look like?
  • How popular is the idea of chatbots with developers?
  • How mature is the chatbot developer ecosystem?
  • Which developers are more attracted to the chatbot promise?
  • Which messaging platforms are popular with chatbot developers?