This morning I was part of a panel at the GigaOM Structure:Europe 2012 conference in Amsterdam., titled: The Evolution of Private PaaS solutions. The abstract:
Enterprises are starting to take interest in running PaaS solutions virtually, as app developers want to focus on building apps rather than dealing with infrastructure issues. Enterprises that use PaaS solutions almost always go down the private route. In this session we focus on private PaaS offerings and look at the considerations and what will happen if one day enterprises want to use PaaS solutions in the public cloud.
The idea was to discuss private vs. public PaaS and, as it was a theme throughout the conference, the differences in adoption rates in the US vs. Europe.
You can view the full video coverage of the panel at the GigaOM website.
Here is an overview of some statements made during the panel to
highlight some of the discussions (in my own words, so could be biased,
but you can watch the video to make up your own mind đ ):
Public vs. Private PaaS
Enterprises want PaaS within their own environment, behind their firewall, i.e. Private PaaS.
Public PaaS is focused on the lowest common denominator, limited to certain framework, database, etc. Private PaaS adapts (can/should adapt) to everything used in the enterprise, any language, framework, database, etc.
In our customer base we roughly see a 50%-50% split between applications deployed on our Public PaaS vs applications deployed on our Private PaaS. It mainly depends on data, integrations, and policies.
Mobile is actually helping public PaaS adoption. It is a new subject, and within such a new space enterprise seem to be more open to new ideas.
PaaS and productivity
PaaS is a huge enabler for Cloud Computing. PaaS is “clicky-clicky”: development and deployment that took months brought down to minutes.
PaaS is more driven by productivity gains than the need to move to “the cloud”. The business wants a solution for a business problem. Fast. Keep evolving with the changing business. PaaS should cover the complete application lifecycle.
A PaaS covering the application lifecycle in this way requires a new way of thinking. Connected to agile, continuous integration, etc.
PaaS can help to transfer old way of working seamlessly to cloud. It is just a small step.
No, you need to change the way you work. Modularize applications, no application silos.
If you really want to speed-up. We should also stop programming, start doing MDD.
MDD is possible now… no programming involved perse (also read: Why aren’t we all doing Model-Driven Development yet?).
Enterprise are adopting it.
PaaS should add a layer of abstraction. It should add a software layer. Key is that it is just the first step. New language constructs will abstract even further.
PaaS and the application lifecycle
PaaS can bring harmony between operations and development.
The opportunity is even bigger: it can bring all stakeholders in the application delivery process together. Even end-users providing feedback, and business owners collaborating on requirements. The complete application lifecycle should be covered by PaaS. Not only covered, also speed-up.
Even end-users doing app development and deployment?
Back to private vs public. I believe in hybrid. Even if enterprises want to go with private PaaS, they often want to have development and test environments in the public cloud. Once they start using production data in acceptance or actual production they move the app within the premise of the company.
Real-time updates and modularity
OSGi has been mentioned a couple of times, what is it? A dynamic modularity system for Java. The only industry standard that enables modularity, currently in the Java space but will become available for different languages.
But… enterprises are not asking for OSGi or these kinds of standards.
No, they do not ask for OSGi specifically. But if an enterprise starts to user your PaaS you will encounter something like this: build first small app fast, in an agile way with a small team.
If they start to build a huge app, i.e. with a lot of functional components, people will start to think about modularisation. If you want to release a new feature you do not want to redeploy the complete app. But only the changed component, and if needed the dependencies of this component.
Customer ask indeed about real-time updates in PaaS.
Version/configuration management becomes important: what version of my software is running. And what versions of all the components?
Layers
PaaS is about virtualising away lower layers. However, PaaS can also bring back to the table an understanding (and management of) what an application actually needs with respect to the underlying infrastructure, e.g. data needs to go over the same switch, caching is sensitive for locality, etc.
There is no clear distinction between layers. IaaS and PaaS players are moving into each others space. Amazon started out as IaaS, but nowadays delivers a lot of higher level services that you could categorise as begin part of the platform layer. Microsoft Azure and Google are moving the other way around: from PaaS player to also delivering IaaS.
Is there room for language specific PaaS?
It depends: if you only have .Net it makes sense to have a .Net specific PaaS. However, most organisations are heterogenous. So you need to support multiple languages.
You see that because we are in a transition, people still use their current methodologies. As PaaS becomes stronger, full stack, there will become PaaSes that focus on one language. That will need a different way to build the application. Because you need advantages like auto-scaling, dealing with locality, etc.
If you really want to change, you need to disrupt. Do not cling to your existing methodologies and languages. I truly believe there is a big opportunity for PaaSes with focused languages.
Forrester defined space within PaaS: new productivity platform. Step to higher level languages. Different roles that build applications.
Platform should run components defined in all kinds of languages.
It depends on how you define PaaS. It is not just a deployment platform. It should also cover the other aspects of the application lifecycle like development and maybe even requirements/feedback management.
If you really want to disrupt the field and make it a lot easier and faster to build applications (that’s in the end what businesses are looking for), than you also need to change the way you develop applications not just the way you deploy it.
PaaS adoption in Europe vs. North America
Interesting thing last 2 years: not really a difference. Everywhere businesses are looking to improve their software delivery. There is no business innovation nowadays without software delivery involved. Businesses want improvement, productivity gains.
Then the question is will it be a private or public PaaS. We see the same thing in US and Europe: it depends on the kind of data and the kind of company. Banks will probably go for private. But a lot of other companies will go with public PaaS, especially for their customer facing portals.
It all depends on the usecase. Not on region.
PaaS often starts small.
That’s an opportunity. We take a week to create a working app for new customers and they have something tangible to show within their own organization.
No difference between Europe and US. Almost all private PaaS.
It seems like we are saying that if you are an enterprise of course you will have private PaaS. That’s not true. A lot of big companies are using public PaaS. Of course there are enterprises that go with private PaaS, but it is use case dependent. Not dependent on the size of organizations.
Why do we see so much private PaaS? Well, it could be that if you product supports private PaaS that it is a lot easier to sell that.
People feel comfortable with private PaaS, that’s what they are used too. If they get used to the idea of cloud and see advantages they will move.
