No mention of App Engine, Elastic Beanstalk, IBM Bluemix, Microsoft Azure, Cloud Foundry, Parse, Firebase. The only company I recognize from that list is Heroku.
If you do not even talk about market leaders in a space, you're almost guaranteed to form an inaccurate opinion.
That said, if the point he is trying to make that newcomers aren't there or aren't innovating, that's wrong too. PaaS is not moving at the slow rate that traditional hosting went through. So the term Gartner defines goes out of date before they publish their reports. There has been plenty innovation by Parse, Firebase, Compose, Mongo in 2015. IBM Bluemix came to the scene with great modularity and Watson as a service. Google brought in a bunch of new stuff too. Docker didn't kill PaaS, that's like saying LAN wires killed servers. It just pushed the level of abstraction in PaaS a bit higher. Being able to throw code and being able to run it without thinking of hardware is a very 2014 problem for most people. The sex is in what's coming next. PaaS has evolved.
Furthermore, the measure of PaaS is not whether PaaS companies are profitable, but whether the companies built on PaaS systems are profitable. Infrastructure should be a tough business. As a startup developer, I want them pouring every extra cent into either expanding my services or making my existing services cheaper.
Lambda is something new. It's akin to BaaS (backend-as-a-service, like Parse or Firebase), but operates fairly differently from them, and doesn't have the mobile focus. Not sure if I'd lump it under BaaS or if it's an entirely new category (EaaS, execution-as-a-service?).
The interface to the outside world is different, the granularity of abstraction is different, and the pricing model is different. All those make it suitable for different applications, which indicates it's a new market and not going after the same customers as a PaaS.
AppEngine still treats your whole codebase as an "app" - all your handlers share configuration, they share a data store, and you interact with them over straight HTTP or XMPP. You're billed per instance-hour, which implies instances (virtual machines), and the control panel is setup to scale the number of instances devoted to your app.
Lambda is just a collection of functions, and you setup those functions to be triggered on various events. Those events could include HTTP requests to an API gateway, but they also include S3 or DynamoDB writes, Cloudwatch monitoring, SNS, and a wide variety of other apps. You're billed only for computing time; having an Amazon Lambda function uploaded that's doing nothing costs you nothing.
I get the sense that Amazon Lambda : database triggers :: Google AppEngine : webapps. The former is utility code that glues together events in multiple storage systems; the latter is designed to serve a single application and interface with all of its data needs.
You can pair Lambda up with AWS API Gateway and get something pretty close to App Engine. What sets Lambda apart is that it is event activated, similar to stored procedures in a database. But instead of updates or inserts to tables, Lambda can be triggered by events in other AWS services (S3 object created, API gateway method requested, etc).
We run applications for dozens of clients across several different language stacks on Heroku. Our entire (rapidly expanding) business depends on it. If we had to maintain those instances ourselves, it would require a full time dev ops employee, if not multiple. We've side-stepped the requirement for any dedicated devops staff by relying on Heroku's automation for this. So I really do not see how PaaS is even remotely close to dead. Those companies probably don't release glitzy PR bragging about their success (like most VC-funded companies trying to generate hype) because they don't need to - the money just keeps rolling in. If I start seeing PaaS companies vanishing inexplicably then I'll start to wonder.
I 100% agree. I was launching apps on linode and running into open file limit issues because of the amount of traffic the application was receiving. One server could handle the load find if it wasn't for that (as far as I knew at the time) but I tried launching it on Heroku and saw immediately there were no issues handling the traffic we were sending to it. It may not be the fastest or cheapest, but it was turning into the majority of my time spent on figuring out how to configure a server that could handle the traffic rather than me focusing on actual development.
The added monthly cost is a fraction of the cost it would take me to actively manage the servers.
People thought that the price changes a few months ago would be the death of Heroku but in reality we are saving money compared to what we were playing previously.
You should be able to change the file handle limit without much effort? I'm not saying you made the wrong choice, if you don't have some pretty deep sysadmin skills, you should probably be outsourcing your hosting, but that seems like a weird justification.
All that really matters is Heroku is cheaper than people. When it no longer is, you start thinking about hiring.
There's no reason why you can't have Heroku to connect to a RDS instance or a DB you manage yourself. It's not has easy as using the Heroku way, but not very difficult either.
I'm curious, would this adds considerable amount of latency to the DB queries? I'm guessing connecting to RDS from an EC2 instance would have less latency compared to connecting to RDS from a Heroku or DigitalOcean instance, but how much is the difference and is it significant enough?
... and then six months later your server runs out of disk space and collapses because you hadn't configured proper graphs, and you spend several hours frantically trying to fix it. And then two months later your RAID controller fails and you realise that your backups stopped working when disk space ran out you never fixed them again. And then when you rebuild the server you realise you documented/automated 95% of the setup of the original machine, but that last 5% has you totally screwed because a package you were depending on has been deprecated by your Linux distribution and you need to figure out how to build it from scratch.
Running a server in a production environment across multiple years is hard. One of the hardest part is when everyone forgets about it because it's fully automated... and then it breaks.
Your servers are virtualised with redundant hardware (if they're not IaaS in the first place). There's no "rebuilding" of the server. Have you ever actually managed a production environment in the last 10 years? We're not even talking about a lot of money here.
A raid controller dying should either a) not bring down production or b) not be your problem anyway.
> I very much doubt it. This just comes across as you vastly over-estimating how hard it is to run a server.
What about security updates? Log alerts? Rollbacks? Monitoring? Support for multiple servers? Load balancers? Automated deployments from Git? Atomic web code updates? Ability to destroy and recreate the server from scratch? Setting up a similar staging site with the same versions of everything? None of this is trivial to automate reliably yourself.
I'm not saying it hard to get it working, but it's hard to make it work reliably and scale well. Comparing Heroku to e.g. manually setting up a Digital Ocean instance that you rsync the code across to is missing out on a huge number of details.
I do all of them along with coding and managing project members. But i use Rackspace cloud which has most of them built in. One you have the basic configuration set up rest if easy. You can use ansible to automate it or same images.
What are you paying for that though? My point was people compared cheap VPSs to more expensive managed services and don't take into account the automation they're missing out on.
1GB server comes to £73 which includes $50 service support.
We do use a dedicated server for DB. Recently moved our ap servers from dedicated to cloud.
I could have used Digital Ocean as well they have similar setting. I can now easily use the ansible scripts to setup on any other server.
It's not about difficulty, it's about time and money.
I _can_ manage a server. But for $25/month to just forget about it? I'll take that tradeoff any time. (And have, back when I had production machines myself. And will, if I have time for that side project again sometime soon...)
And for stuff that needs more than one dyno, well, if we assume $100k/year for an ops person, that still gives you sixteen of Heroku's beefiest instances for the same price? I still think it makes sense.
Exactly--it's about what your time is worth to you and what you would prefer to spend it on. These services make it possible to just be a software developer and not have to either hire or be a sysadmin. But if you can't afford PaaS or enjoy being your own sysadmin, that option is still open to you.
Why to assume that any kind of server setup would need a dedicated Ops guy? It is reasonable to assume that once a server is provisoned, all you need is to have familiarity with tools and how things work to resolve issues.
I know I might be oversimplifying but the decision is not always simple as "we save one hire". Seeing many articles on the web, PaaS bills rake up more quickly than anyone expects.
Yes, but then you have to actually do the work to resolve the issues. Again, it's not about skill, it's about time and money. What you're paying for is just not having to think about it.
I think it depends on how hard your software pushes the hardware. If complex configuration / maintenance is needed then the likelihood of a human-error bringing the system down is much higher.
Service disruptions can have costs much higher then a dev-ops salary (or several) so if a PAAS solution can cause you to avoid that..
I think beyond it simply being difficult to compete with AWS and Microsoft, the more specific reason is that those providers (plus the smaller ones that are probably also thriving) all support pretty much any language / configuration you can throw it them, so the barrier of entry is too high. For a new PaaS start-up to compete you'd need automate the provisioning and deployment of dozens of different languages out of the gate, or support at least one of these stacks much, much better than any of the existing PaaS too, such that it makes it the obvious choice for that language. WPEngine would be an example of a PaaS that specializes in a single stack better than any of the multi-stack players. Heroku too started off as a PaaS specialist for Ruby on Rails, and now has expanded to supporting many languages and configurations. If you specialize you have a shot at besting AWS or Azure - if your goal is to support all of the existing stacks plus new ones, then forget it.
Or are they leveraging their resources to provide a capable service at a lower cost? Two huge players (and other competition) seems like a healthy space, unless they're colluding.
Not actually arguing that this is what's happening, but they could collude to keep prices low so that the resulting small profit margin doesn't provide any room for newcomers.
Straight out of the Standard Oil playbook actually.
The argument against Standard Oil was that it kept prices low until their competitors went out of business or were cheap to acquire, and then raised prices as a monopolist.
Simply keeping prices low to keep the competition away is just competitive markets working - there's no benefit to consumers in the entrance of new suppliers if they will offer the same product at the same or higher price.
I've priced this out and I don't think that AWS prices are "low". I think it would be easy to set up a PaaS and undercut AWS. The challenge to doing that, though, is the need to build software, the cost of marketing it so people are aware of it, etc.
I'm glad someone else said it. I work on Azure, so I thought maybe I was just in a bubble, but the various "Death to PaaS" articles not mentioning Azure or AWS seemed odd. Azure App Service is just one of the PaaS services we have, and we're quite healthy. :)
Something like beanstalk is a great example because it's basically a canned configuration for other AWS services meaning you can graduate to fully custom virtual infrastructure with far less hassle. That's tough for other services to compete with.
In my experience you pay a ton more for the same amount of resources when it's PaaS so it makes sense that providers are going to push that over just configuring your own blank VMs.
I think with Azure the costs for basic compute services are about the same, you can run the same code on Iaas (Virtual Machines) or Paas (Cloud Services, App Services) and the costs are the same for equivalent performance.
For more complex products it's probably different, but the value of that is also higher. Just clicking Azure Search and simply start using it is a lot simpler then setting up your own Elastic Search cluster and having to manage it.
Anyone who thinks that Dokku is remotely comparable to the offering that Heroku provides almost certainly also forgot to setup something like fail2ban or database backups. Yes, it definitely does help ease the pain, but IMO is not in the same category as actual PaaS solutions.
There is just so much more to maintaining server infrastructure that most people don't see, and that's where services like Heroku shine. Even managing self-hosted PaaS software is hard and not a complete replacement for just paying another company to handle it for you.
Note: I am one of the Dokku maintainers, and my full-time job is Operations Engineer (one of several) at a startup.
I disagree, I think PaaS is in its infancy and will grow not die. One PaaS not mentioned in the article, Microsoft Azure, is growing fast and provides a vast range of services.
We run an enterprise grade SaaS product on PaaS, and I personally have several apps running on PaaS. These solutions would have taken much longer to get to market without PaaS and be much more complex to manage and maintain.
Starting a government-focused startup, their FedRAMP certification is invaluable. No way we could go through that process (multiple years, tens-hundreds of thousands of dollars) and make an affordable product.
Author did make a good point about devs being problem solvers who want to do it themselves. A great sign of a truly senior engineer is focus on the outcomes and offloading the non-business-critical things.
(This isn't to say DevOps isn't important, but unless your business relies on innovative ops as a core piece of what it offers, don't spend time on that.)
We use Azure's PaaS features known as Cloud Services and App Services (a.k.a. Azure websites/web apps). They make deploying and scaling your app as easy as it could ever be. The App Service plans also allow you to combine multiple apps together on a group of servers which enables you to save a lot of money if you have a lot of small applications.
Now of course I could use a bunch of automation and do this all myself with VMs... but why? Just use Azure, AWS Elastic Beanstalk, etc.
I think it's safe to invoke Betteridge's Law here.
Anyone working in this space can tell you that's still the age-old discussion: Wether it was mainframes vs. microcomputers, containers vs. VM's, microservices vs. monolithic applications. Sometimes a particular architecture was preferred, sometimes the other. And none have gone away for good, and none have taken up the market completely. Essentially, the answer depends on your requirements (And the world just isn't binary).
The only thing that's for sure is that distributed systems are here to stay – but how you call the various abstraction layers forming them up really doesn't matter. All that really changes (currently) is the size of the market, or the shares therein.
Some of you might remember that we did the 'cloud' before it was called as such, and while the terms I/P/SaaS weren't known under this moniker, it was already in use.
It's even older than mainframe vs microcomputers. It'd centralization vs distribution, and its the fundamental question to human life, which is necessarily social and therefore needs organization.
Interestingly, the answer is always "both", just in different ways. AWS could be used as an example argue that technology and society is becoming more centralized, and that it is becoming more distributed. It's all about what your focus is.
I think the Docker based self-hosted PAASs (Deis, Flynn etc) is squeezing the smaller PAAS offering at the low end, and Elastic Beanstalk/Azure/Google CloudDB is killing it at the high end.
Why would you use <insert random small PAAS company> when you can deploy your own on AWS and then use their managed DB service?
I think PaaS demand is going to die down in the near future. The simple reason is that before, it used to be quite annoying to get a server set up, replicate it and scale it, but now with all the awesome automation tools coming out, I doubt that is going to be a problem anymore.
Nonetheless, I doubt PaaSes will disappear, they will still remain useful for hobby projects as you can see with this quote:
The free usage got less attractive,
paid hobbyist usage got more attractive.
I find it notable that the hobby-pricing-level is
competitive with DigitalOcean.
> I think PaaS demand is going to die down in the near future. The simple reason is that before, it used to be quite annoying to get a server set up, replicate it and scale it, but now with all the awesome automation tools coming out, I doubt that is going to be a problem anymore.
No matter what the tools are, I think people realized that the simplicity PaaS tried to offer doesn't exist (regarding availability, scaling etc). Even Heroku isn't able to accomplish it, and they're what I would've considered the leader in the space.
> it used to be quite annoying to get a server set up, replicate it and scale it, but now with all the awesome automation tools coming out, I doubt that is going to be a problem anymore.
Curious, what kind of tools are you thinking of? Because the ones I'd be thinking of as coming out right now kinda fall into the category of PaaS, just that you can self-host them if you want.
And by the time you really "need to scale", you'll typically have plenty of resources to figure it out. It seems to me the pull is inexorable to bare metal or a close equivalent.
thx, your comment sums up the article quite good > Problem already solved, PaaS probably not needed. Is in return DigitalOcean only for hobby projects?
> PaaS is a black-box; it's proprietary; it's a beautiful island; it's not as versatile as a home-grown solution. Developers love the freedom of root access, they want to able install any open-source software they like. While PaaS is offering well defined and thoughtful solutions.
Wow, there's a lot of fancy talk to avoid the phrase "vendor lock-in" here.
I am a paying Heroku customer and I used to use AppEngine a fair mount. I would argue that both of these PaaS are doing well. I don't think the article even mentioned AppEngine.
I cannot imagine how many startups would have failed to successfully launch (as they had) if it wasn't for the ease-of-use of hosting their platform, such as Heroku. I know that early on I wouldn't have had the patience/confidence to roll my own stack on a node, let alone trust its integrity.
1. PaaS is such a good idea that everyone is building their own. Even though the field has matured -- Cloud Foundry and OpenShift are already available and supported by major vendors.
2. The author cherrypicked a selection of failed small vendors as the marker of the trend. By this logic every single technological advance of the past 100 years is dead.
Meanwhile, Pivotal Cloud Foundry has the fastest-growing sales of any opensource product in history.
What I agree with:
PaaSes don't get love from techies because we like to tinker. We always assume we can do better. We often can, and for special cases PaaSes may not be suitable.
But large organisations with heterogenous teams and apps, PaaSes are godsend.
Disclaimer: I work for Pivotal, which donates the majority of engineering effort to Cloud Foundry.
As much as driver service on demand exists for people who don't want to own a car or learn how to drive it and do not want to walk, use a bike and don't care about parking space.
As long as investors are over investing. It is living on perfusion.
I mean PaaS as a business?
PaaS/IaaS is overly ridiculously expensive for competent team. It is usable for companies who do not care about the OPEX... the costs of resources ... the costs of not hiring competent dev/sysadmins.
We are in recession, the source of investments is gonna run dry, so I guess it is time to see PaaS users' slowly bankrupt while the cheap competitors will survive.
Business is a harsh world for those who do not care about costs and prices.
Article author here. Thanks for all the feedback. Many of you missed the big players like Azure, AWS (Lambda & Elastic Beanstalk), Google App Engine … Well, that's true.
Due to my perspective I am mostly interested in the "bootstrapability" of the business model here: What are our companions are doing?
> I am mostly interested in the "bootstrapability" of the business model here
By that definition I can see how you think it's dead. I'm afraid the opportunity for that went away several years ago, by now all the early innovators were bought by big vendors.
It seems like an awfully capital-intensive and global business to me.
I'm a user of Heroku, and I went in with the idea that the add ins (DBs, notification, logging, etc.) offerings would be super easy to use and compelling to stay in the eco system. They are super easy to use, but I learned that so are their competitors, and they don't integrate into Heroku in a compelling way. I ended up with a DBaaS that was miles more expensive than the AWS competitor that I will switch to when I get a chance. The base Heroku service, while not super cheap is one of the few pieces of my puzzle that may not change. AWS EB is probably better than the Heroku dynos, but not so much that it's on my short list of things to do.
In terms of market cap, how do Elastic Beanstalk, App Engine, and Azure compare with Heroku? Can we really make a claim on the PaaS landscape without talking about some of the biggest players?
I'd be very curious to know how the 4 mentioned services are doing.
It's getting easier to assemble scalable we application out of IaaS offerings. OTOH, writing against, say, Google App Engine is not as simple as writing for Django or Flask. It's, however, educational.
If you do not even talk about market leaders in a space, you're almost guaranteed to form an inaccurate opinion.
That said, if the point he is trying to make that newcomers aren't there or aren't innovating, that's wrong too. PaaS is not moving at the slow rate that traditional hosting went through. So the term Gartner defines goes out of date before they publish their reports. There has been plenty innovation by Parse, Firebase, Compose, Mongo in 2015. IBM Bluemix came to the scene with great modularity and Watson as a service. Google brought in a bunch of new stuff too. Docker didn't kill PaaS, that's like saying LAN wires killed servers. It just pushed the level of abstraction in PaaS a bit higher. Being able to throw code and being able to run it without thinking of hardware is a very 2014 problem for most people. The sex is in what's coming next. PaaS has evolved.