Is PaaS dead?
blog.fortrabbit.com
blog.fortrabbit.com
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.
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.
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.
All that really matters is Heroku is cheaper than people. When it no longer is, you start thinking about hiring.
I very much doubt it. This just comes across as you vastly over-estimating how hard it is to run a server.
Most of the time it's painful, you take a day or two to write a build script, then everyone forgets about it because it's fully automated.
I run my SAAS on bare metal infrastructure. I don't anticipate my software to suddenly go viral, but have a steady growth.
If I had to use Heroku, I wouldn't be able to run my projects for profit because of the number of resources I'd need.
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 _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.
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.
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.
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.
Even more so in the case of Redis.
Why is it getting harder for randos to succeed in PaaS? Because they're competing with Amazon and Microsoft, and that's hard.
Straight out of the Standard Oil playbook actually.
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.
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.
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.
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.
because have more time than money.
"Nodejitsu has joined GoDaddy We are excited to join GoDaddy to help spearhead their largest Node.js product: Website Builder."
That has got to be the saddest acquisition I've ever heard.
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.
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.
Why would you use <insert random small PAAS company> when you can deploy your own on AWS and then use their managed DB service?
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.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.
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.
Wow, there's a lot of fancy talk to avoid the phrase "vendor lock-in" here.
I imagine there are enough others like me that will keep these companies around awhile.
The problems are:
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.
Technically that stuff works yes.
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.
I can foresee the growth of do-it-yourself PaaS, built on Docker, Kubernetes, etc.
Cloud Foundry is an installable opensource PaaS. You can use a hosted version or set up your own on AWS, Azure, OpenStack and I forget what else.
> I can foresee the growth of do-it-yourself PaaS, built on Docker, Kubernetes, etc.
RedHat are packaging these for OpenShift Origin.
Disclaimer: I work for Pivotal, which is the major donor of engineering effort to Cloud Foundry.
Due to my perspective I am mostly interested in the "bootstrapability" of the business model here: What are our companions are doing?
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'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.