10 ms·

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particul

This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will have an experience of post 2030. Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Almost all the objections in the article can be rephrased as “serverless is not mature enough yet”, and that’s accurate, but I suspect there’s also a bias against giving up control to the cloud companies, and some wishful thinking as a result. The future of software development is going to be defined by cloud providers. They’re going to define the language ecosystem, the canonical architectures for apps etc... it’s just early days and cloud is really very primitive. Just clicking around Azure or GC or AWS illustrates how piecemeal everything is. But they have a lot to do, and just keeping pace with growth is probably hard enough. I’m not sure I’m super happy with this outcome, but I’m pretty certain the trend line is unmissable.

nathias 6y ago
How about someone else is controlling your infrastructure and your project completely depends on their good will. We need self-hosted serverless...
- davedx 6y ago
  Self hosted serverless has also been around for years. Lookup openshift, openwhisk, etc. TFA is clickbait
  - nathias 6y ago
    I mean as the main paradigm of hosting, now its beyond niche and everyone is happy to go to google, amazon and microsoft. What does TFA mean?
noncoml 6y ago
> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.
- reilly3000 6y ago
  Most actual FaaS code is quite portable; the configuration is what can’t move easily. And things like OpenFaaS and kNative make self-hosted runtimes completely flexible- it’s just a short-lived container.
- jfoster 6y ago
  At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.
  - technimad 6y ago
    That standard could be something like CloudABI [1] which already exists, but is too limited (no networking) to replace generic serverless workloads. [1] https://lwn.net/Articles/674770/ https://lwn.net/Articles/674770/
  - toyg 6y ago
    The point of serverless for vendors is lock-in. Everything else about it is an annoyance, from their side (having to manage lifecycle, controlling load in shared engines, measuring resource usage...). But it locks people in and can be slapped with basically-arbitrary prices. The incentives to set standards are exactly zero, because once all providers support them and easy portability is achieved, it becomes a race to the bottom on price. Unless vendors can come up with some extra value-added service on top and choose to commoditize away the serverless layer, there won’t be any standard.
  - rzwitserloot 6y ago
    > Is there anything stopping an organisation from defining some standard types of serverless environments? Yes. Basic economics. There is nothing _technical_ stopping 'an organisation' from making a federated twitter or facebook. But there are (evidently) insurmountable non-technical reasons: It hasn't happened / there have been attempts which have all effectively failed (in the sense that they have made no significant dent in these services' user numbers). Why would e.g. Amazon (AWS) attempt to form a consortium or otherwise work together or follow a standard, relegating their offerings to the ultimate in elasticity? Economically speaking, selling grain is a bad business: If someone else sells it for 1ct less per kilo then the vast majority of your customers will go buy from someone else, there's no product differentiation. Serverless lockin (such as GAE or AWS Lambda) is the opposite. No matter how expensive you make the service, your users will stay for quite a while. But make a universal standard and you fly in one fell swoop to the other end of the spectrum. If I have a serverless deployment and the warts of serverless are fixed (which would, presumably, involve the ability to go to my source repo, run a single command, give it some credentials, and my service is now live after some compilation and uploading occurs) - then if someone else offers it 1ct cheaper tomorrow I'll probably just switch for the month. Why not? This cycle can be broken; but you're going to have to paint me a picture on how this happens. Government intervention? A social movement amongst CEOs (After the war, there was a lot of this going around)? A social movement amongst users so aggressive they demand it? Possible, but that would require that we all NOT go to serverless until the services offering it come up with a workable standard and make commitments to it.
Juliate 6y ago
It's massively inefficient, but it's also still massively safe in comparison, regarding soveignerity. Like, today, given the political uncertainty in the USA, any large company would be nuts to bet on hosting their critical services on US-dependant infrastructure without having a huge plan B already in the works.
- ehnto 6y ago
  Is there a serverless provider with a "self hosted node" option that could be used as a fallback? That pretty much defeats the purpose of serverless, but at least you could hang on while figuring out how to transition to a new solution if the provider fails. That has always been my sticking point. With AWS in particular. I don't trust AWS to exist forever, and it's definitely not without it own ongoing maintenance issues. Locking my entire business into their ecosystem seems risky at best. Something I see really often in startups is huge dependencies in the form of SaaS. It should be no secret to those in tech that many of these businesses will not be around in 3 years. Even the likelihood of their service staying the same for 3 years is pretty low. I have been bitten by enough deprecated services, APIs and Incredible Journeys that I am wary.
ethanwillis 6y ago
This on the assumption that there isn't a balkanization of the serverless frameworks between providers. History doesn't bear this. In 2020 we still need tools like BrowserStack even after decades now of web developers complaining about the fragmented ecosystem. Instead of maintaining software compatible with the right operating system, you're maintaining software compatible with the right flavor of serverless by Cloud Provider. Now we're back to square one on at least one front. On the control aspect, the bias against giving up control is not an unwarranted one. Maintaining control of critical infrastructure is extremely important. And in fact outsourcing your critical infrastructure is an existential one, and not just in an academic sense. When you give up control you give up the ability to prevent your infrastructure being hostile, but incompetent. In these cases it reduces the quality of your product for your customers. I won't even go into the anti-competitive tactics Amazon themselves get into that make them not a good choice for your infrastructure. Instead I'll draw upon a recent experience that illustrates why outsourcing infrastructure, even at a higher level, is a bad idea. My girlfriend recently was taking her NLN exam remotely. They weren't allowed to use calculators of their own, they had to use a virtual calculator provided by the company administering the test. Like most of these companies they are doing remote proctoring of the exams. During her exam this virtual calculator flat out wasn't available. The proctor told her to simply click through the exam and that once she submitted it she'd be able to call into customer service to get the exam re-scheduled due to the technical difficulties. Well, that wasn't the case. After doing some deep digging for her, here is what I found. The testmaker NLN contracted out the test administration to a third party, Questionmark. Questionmark in turn contracted out yet another 3rd party, Examity to handle the proctoring. Examity proctors don't have access to Questionmark's systems. Questionmark doesn't have access to NLN's systems, etc. So how did we get this resolved? I had to track down the CEO of Questionmark, the CEO of Examity, and the head of testing for NLN. I had to reach out through LinkedIn inmail to get this on their radar. And then it was handled(quickly and efficiently I might add!). However, frontline support for each of these companies could do nothing. They just had to offload blame onto the support staff of each other. Another aspect of this is that each handoff between 3rd parties creates a communication barrier. In this case the communication barrier seems to have kept Questionmark from configuring this specific test correctly. I wouldn't blame any of these companies for this specific failure mode because it's just the nature of what happens when you offload your work to 3rd parties. When you say, "Oh it's great we don't have to worry about X because Y can do it." The implication is that you lose all of the power of a vertically integrated company by essentially spinning off tons of subsidiaries and creating a communication overhead both before and when problems DO arise. What is the future of software development going to look like when it reaches consumers and you have to say "Sorry, we can't fix that issue because Cloud Provider has to get back to me, and then in the background Cloud Provider has to say sorry we can't get back to you because we have to wait for our spunoff hardware division to get back to us?" Maybe this type of business is fine for fun apps, but it's not fine for a lot of businesses. Even SLAs and disclaiming responsibility in your own contracts won't save your reputation. All it does is protect you financially!
brainless 6y ago
> Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Except that it is not. The security and constant maintenance is needed but it is worth in many cases. And large companies can not really off load all ownership of data and applications. The interest in servers actually went in reverse direction due to the cloud effect. I would say having own server or application hosting capacity is very similar to why you produce your own solar power and store it in batteries - it is simple? No. But the technology is improving and thus it makes it easier for people to adopt this paradigm. When I see what is happening with WebAssembly/WASI in particular, I see a great future for self-hosting again. Software written in any programming language (as long as it targets WASM) is a lot easier to host than existing models. Also there is interoperability of software coming from different languages at the WebAssemply level as I understand.
- zelly 6y ago
  > Software written in any programming language (as long as it targets WASM) is a lot easier to host than existing models. For the past 20 years you have been able to target x86 gnu/linux and have it running without modification on a readily available server, either your own hardware or rented/public cloud. How does switching from one binary format to another (x86 to WASM) change anything (except maybe slowing down your code)? As I understand it, the main draw of WASM is running non-JS code in a web browser.
  - tarruda 6y ago
    > As I understand it, the main draw of WASM is running non-JS code in a web browser. Simplified deployment + automatic sandboxing? AFAIK with x86 you can't just write a client app and have it automatically run on any computer that visits your website.
    - cblconfederate 6y ago
      Are people reinventing java as if it never existed?
kiney 6y ago
your "serverless" framework becomes your operatings system. Just a bad one.
na85 6y ago
>The future of software development is going to be defined by cloud providers. They’re going to define the language ecosystem, the canonical architectures for apps etc... That's... quite depressing to consider, actually. I long for a return to the internet of yore when Native apps were still king and not everything was as-a-service.
- toyg 6y ago
  I agree. But you can still do native apps today, if you’re willing to jump through all the hoops that OS vendors set in your path and maybe renounce a couple of platforms (like chromebooks). Unfortunately, now that basically OS vendors are also effectively cloud providers, their incentives are set to increase those hoops (“for secuyriteh”), nudging more people towards “easier” cloud deployments.
raxxorrax 6y ago
In my experience, maybe it just isn't there yet, serverless has much more points of failure than a conventional infrastructure. I am sure there a lot of software that really needs the scale the cloud can provide. Funny thing is that we tend to use it for tiny apps, some IOT voice interfaces or BTB tools that we don't want in our corporate network. I doubt cloud providers can dictate environments, other providers would quickly fill the gap to meet developer preferences. I also think that more developers care about lock in these days.
zshrdlu 6y ago
On the other hand, perhaps endeavors akin to NixOS and Guix will make maintaining your own operating system trivial.
CaptArmchair 6y ago
> When put like that, it’s amazing that we didn’t come up with this idea earlier. It's called time-sharing and it existed in the 1960's. [1] [1] https://en.wikipedia.org/wiki/Time-sharing https://en.wikipedia.org/wiki/Time-sharing The difference between time-sharing and serverless is that the former solved the issue of expensive personal computing, until cheap personal computers took over that market. The latter solves perceived expensive computing on the "server" side. But what does it serverless solve exactly? It doesn't solve a technical problem, rather addresses concerns on the business side. Serverless solves a cost problem. First, computing needs aren't linear, they fluctuate. And so, there's a problem of under- and over-utilization vs availability of resources. Serverless approaches computing power like tapwater: you're essentially paying for the CPU time you end up using. Second, elasticity. Instead of having staff struggle - losing time - with the fine intricacies of autobalancers, sharding and what not; you outsource that entirely to a cloud provider. Just like a tap, if you need more power, you just turn the tap open a bit more. Finally, serverless services abstract any and all low level concepts away. Developers just throw functions in an abstraction. The actual processing is entirely black box. No need to worry about the inner details of the box. Sounds like a good deal, right? > Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Well... no. Outsourcing all of that to a third party cloud computing vendor doesn't dismiss you from your responsibility. All it does is shift accountability to the cloud provider who agreed to take you on as their customer. Securing your factory still very much includes deploying a secure digital solution to manage your machinery and process lines. Plenty of industries wouldn't even remotely consider outsourcing critical parts of their operations, and this would include digital infrastructure. And this is regardless of the maturity of serverless technology. Risk management is a vast field in that regard. Then there's legal compliance. There are plenty of industry specific regulations that simply don't even allow data to be processed by third party cloud services unless stringent conditions are adhered to. Medicine, banking and insurance come to mind. Finally, when it comes to business critical processes, businesses aren't interested in upgrading to the latest technology for the sake of it being cutting edge. They want a solution that solves their problem and keeps solving that problem for many years to come. Without having to re-invest year after year in upgrades, migrations and changes because API's and services keep shifting. Does that mean that there isn't a market for serverless computing? Of course there is. Serverless computing is a JIT solution. It's an excellent solution for businesses in a particular stage of their growth. And it closes the gap for plenty of fields where there really is a good match. I just feel that "maintaining your own server is completely nuts" is a bit overconfident here;
deleted 6y ago
[deleted]
zelly 6y ago
It's not nuts to run servers. If an application is operating at any scale such that there is a nonstop stream of requests, then it will be cheaper, faster, and more energy-efficient to run a hot server. This follows from thermodynamics. No matter how good the cloud vendor's serverless is, it's always going to be less efficient than a server, unless it doesn't do any setup and teardown (i.e. no longer serverless). It is nuts to run one server. Then you're wasting money with a server/VM. That's what serverless is ideal for: stuff no one uses. That's a real niche. Who's going to use that? Not profitable companies. Often I think for most cases where you reach for serverless, you should reconsider the choice of a client-server architecture. An AWS Lambda isn't a server anymore; it's not "listening" to anything. Why can't the "client" do whatever the Lambda/RPC is doing? Maybe what you want is just a convenient way to upload code and have it "just work" without thinking about system administration. The types of problems where you don't care about the OS is once again a niche. You probably don't even need new software for these kinds of things. You can just use SaaS products like Wordpress, Shopify, etc. Serverless won't be profitable because the people who need it don't make money.
- molf 6y ago
  > Serverless won't be profitable because the people who need it don't make money. You seem to implying only applications with huge numbers of users can be profitable. This statement ignores a tremendous amount of (typically B2B) applications that provide enormous value for their users but don't see a lot of traffic. I have worked on applications that are at the core of profitable businesses yet they can go days, in some cases weeks without any usage. Serverless architecture will be a real benefit there once it matures.
  - robertlagrant 6y ago
    I don't think that's necessarily true. Google Cloud functions give you 2 million invocations free a month - that's almost 1 per second. You can keep adding another 2 million for $0.40 at a time. It's not terrible.
- throw7889 6y ago
  We use serverless in a project and our monthly revenue is $6K. It is not true to assert that only people with no revenue are using serverless.
xorcist 6y ago
> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part of this stack. A vanilla Linux VM is a platform to build on. Just like AWS or anything else. It is the environment in which my software runs. Thus far, something like Debian has been more stable and much less of a moving target than any proprietary platform has been, cloud or non-cloud. Should a client wish to minimize maintenance costs of the software over the coming decade, it is most cost effective to not depend on specialized, proprietary, platform components. That may change in the future, but right now there is no indication that is the case.
- numlock86 6y ago
  That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it go. On the other hand, if you actually need to tinker with your OS, roll your own. But what you described is the prime example of serverless target audience.
  - jeroenhd 6y ago
    One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises. There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".
jbirer 6y ago
What are you going to do when the container solution / node.js instance / insert x component here crashes? Wait for support to do something about it when you can fix it instantly? Or when you want to deploy a gRPC / crypto daemon to communicate with your back-end? As an experienced back-end developer and linux user I would pull my hair out if I was completely helpless in fixing an issue or implementing some side thing that requires shell access. I don't want to wait for some guy in Philippines who will be online 12 hours later to come try to fix it.
gnarcoregrizz 6y ago
Sometimes I wonder if this is propaganda by cloud/serverless providers to get everyone to jump on it and get locked in. The serverless black box kind of sucks, apart from “auto scaling” stuff. Crap performance too.
- narrator 6y ago
  Auto-scaling is usually a myth anyway. You have to understand your system deeply and where all the bottlenecks are to really scale. If you have a part that's a big black box, that's going to get in the way of that.
OJFord 6y ago
> Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run. Instead, developers can build applications that are compatible with particular serverless frameworks.
sippingjippers 6y ago
It's not clear to me how much experience with serverless architectures the author of the parent comment has, but speaking as someone with plenty, the operational costs of serverless are at least equal to managing stateful infrastructure, with much less control when things go wrong. Lambda was a major step up in long term predictability compared to for example App Engine, where there have been plenty of instances of overnight unannounced changes, or changes announced with incredibly short notice period, requiring developer time rather than ops time to bring an application back to service. On the ops side even with a platform like Lambda, training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right. "The app is down" -> escalate to the developers every single time. Compare that to "the app is down", "this app has basically no ops documentation", "try rebooting the instances", "ah wonderful, it came back" I'm pro-cloud in many ways and even pro-serverless for certain problems, but let's not close our eyes and pretend dumping everything into these services is anything like a universal win.
- darkwater 6y ago
  This. 100 times this. Also, in several places most of the services downtimes are due to, you know what? Application bugs, not infrastructure outages. Sure, they happen as well and being on a good cloud provider mitigate a lot of them (but not all of them!) but if you increase the application design complexity you will increase also those downtimes. Yeah sure, there are tens of really good engineering departments where everything is properly CI?CD, automated, they can scale to thousand of services without skipping a beat... but that's not the reality for thousands of other smaller/less talented shops. So, "moving to serverless" will not just automagically fix all of your problems. Also - and I'm an infra guy so I'm probably biased - I don't really get all this developer anxiety to outsource infra needs. Yeah if you are 2 devs working on your startup it makes sense, but when you scale up the team/company, even with serverless, you WILL need to dedicate time to infra/operations and do not dedicate it to strictly-business-related code. Having somebody dedicated to this is good for both.
goatinaboat 6y ago
Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. TANSTAAFL. Let’s say serverless becomes commoditised the same way as electricity. What are the margins in that business? What are AWS etc margins now? There are very strong reasons to believe that serverless will offer convenience at a premium price, forever.
JulianMorrison 6y ago
The midway point between "maintain your own servers" and "wholly in the cloud" is "configuration as code", using chef and terraform, or similar tools. You don't patch your OS, or your apps, you define their versions and configuration in code and it gets built for you. And typically snapshotted at that point and made into a restartable instance image that can be simply thrown away if it's misbehaving, and rerun from the known good image.
bborud 6y ago
Well, when will it be mature and what will it take to get there? My first experience with serverless architecture was back in 2007 or so when trying to port Google News to App Engine. That was a thoroughly painful experience, and things haven't exactly gotten much easier since. If you go back in time a decade, Google's strategy for selling compute capacity was App Engine. Amazon went the EC2 route. Reality suggests AWS made the better choice. I can understand the superficial notion that having idling virtual machines is inefficient (because it is). But this reminds me a bit of tricks we did to increase disk throughput in systems with lots of SCSI disks back in the day. Our observation was that if we could keep the operation queues on every controller full as much of the time as possible, we'd get performance gains when controllers were given some leeway to re-order operations, resulting in slightly better throughput. Overall you got higher throughput, and thus higher efficiency, but from the perspective of each process in the system, the response was sluggish and unpredictable. Meaning that if you were to try to do any online transactions, it would perform very poorly. For a solution to be desirable it has to be matched with a problem that needs solving. As the article points out, there are some scenarios where serverless architectures might be a good design paradigm. But extrapolating this to the assumption that this paradigm is a universal solution requires not only a leap of faith, but it also requires us to ignore observed reality. So you owe me some homework. Tell me what needs to happen for serverless architectures to reach "maturity".
nemetroid 6y ago
Those are the same arguments as the ones put forth in the article under "the promise of serverless computing". It remains to be seen if they can be realized without the downsides.
nicbou 6y ago
I don't do any server admin. My code runs in docker on pretty much any server I can get my hands on. Some of my code runs on a ThinkPad stashed behind my desk, on DigitalOcean, on my Macbook. I could deploy to a Raspberry Pi and it would run just the same. It takes 10 minutes to deploy an exact copy to a new environment. None of that requires OS maintenance. My house plants require far more maintenance than my software. I sometimes forget where some things run because I haven't touched them in years. Serverless code runs on the cloud you built it for. I don't want that. I don't want to invest years of my life becoming an Amazon developer, writing Amazon code for Amazon servers. That's without delving into the extra work serverless requires. There isn't a dollar amount tied to my import statements. I don't need software to help me graph and make sense of my infrastructure. I can run my code on my computer and debug it, even offline.
- Just1689 6y ago
  You probably know this but from what I read above it might be worth mentioning. Your hosts are still packed with a bunch libraries and services (sshd for example) that should probably be updated with regularity. I echo a lot of what you say here regarding run anywhere and not marrying some giant vendor.
  - beagle3 6y ago
    Agreed. On hosts I manage professionally, I update/upgrade weekly after reading the notes - it takes a few minutes, I know I'm up to date and if there is anything I should be wary of. On a personal debian server, I have an update/dist-upgrade -y nightly on a cron job, and I reboot if I read on HN/slashdot/reddit/lwn about an important kernel fix; Never had an issue, and I suspect it's about as secure and trouble free as whatever is underlying lambda -- with the exception that every 3-4 years I have to do an OS upgrade.
- oblio 6y ago
  What if your ThinkPad is unplugged? What if its HDD dies? Why aren't you updating the OS? Did you patch the firmware for Spectre/Meltdown? Etc, etc
fragmede 6y ago
Serverless is already here, it's just unevenly distributed. Instead it's called (managed) Kubernetes and yeah, you need a devops team and there's still a bunch of overhead but like you say - the writing's on the wall.
toss1 6y ago
>> Like running your own power plant to serve your factory With newer power technologies becoming more affordable and effective, solar, wind, & storage are increasingly being used to power factories and other businesses. It's all about control of your product and operations. If it is economically feasible, it's always better to control your own stack all the way down. Does serverleds actually deliver better control over your development, portability, reliability, security, etc. for your application & situation, or not? This sounds a bit like the "When will they turn off the last mainframe?" arguments a while back - I wouldn't expect servers to disappear either...
bearjaws 6y ago
Anyone moving to Hitrust or SOC2 loves serverless for that exact reason. When asked how I maintain my infrastructure, I point to RDS, API gateway, and Lambda. This leaves my security mostly free to focus on application level security.
thinkharderdev 6y ago
I've never really understood this argument for serverless. Everything you do in AWS is through an API. I've never quite understood how replacing one set of API calls to provision an EC2 (or ECS cluster) is so much more complicated than another set of API calls to create a severless stack. If anything, my experience has been the complete opposite. Provisioning a serverless stack is much more complicated and opaque.
ForHackernews 6y ago
> The future of software development is going to be defined by cloud providers That's probably true of web development, but "software development" writ large is much more than just cloud providers and webapps. "Software" encompasses everything from embedded microcontrollers to big iron mainframes that drive (yes, even today, even in 2030) much of the world's energy, transportation, financial and governmental infrastructure.
- randomsearch 6y ago
  I think you've made a fair point, which I did have in mind but didn't write down - that there is a dichotomy between embedded and cloud systems, and the definition of software development will be to a lesser extent defined by the embedded side. Apple, for example, will have clout. But long-term I think the cloud providers will assimilate so much power that the embedded side will follow its diktats. Big iron mainframes have longevity, but will absolutely die out close to complete extinction - I've worked on those systems, I understand their strengths and the legacy issues, and there's no way that cloud isn't going to gobble up that market, it's just going to take a long time (as you say, beyond 2030).
thaeli 6y ago
We had that utterly compelling framework in the early 2000s. Write generic code, upload to any provider you want, watch it run - that's exactly how shared-hosting PHP worked in ye olden days and to this day no one has made a developer experience as nice and It Just Works as that.

nathias 6y ago

How about someone else is controlling your infrastructure and your project completely depends on their good will. We need self-hosted serverless...

davedx 6y ago
Self hosted serverless has also been around for years. Lookup openshift, openwhisk, etc. TFA is clickbait
- nathias 6y ago
  I mean as the main paradigm of hosting, now its beyond niche and everyone is happy to go to google, amazon and microsoft. What does TFA mean?

noncoml 6y ago

> developers can produce generic code There is nothing generic about the code that runs on serverless services. It’s the ultimate lock in.

reilly3000 6y ago
Most actual FaaS code is quite portable; the configuration is what can’t move easily. And things like OpenFaaS and kNative make self-hosted runtimes completely flexible- it’s just a short-lived container.
jfoster 6y ago
At the moment. Is there anything stopping an organisation from defining some standard types of serverless environments? Is there anything stopping someone from turning that standard into implementations to help cloud providers offer it, or even be a fallback option that could be deployed on any generic cloud infrastructure? I think those are the way forward from here.
- technimad 6y ago
  That standard could be something like CloudABI [1] which already exists, but is too limited (no networking) to replace generic serverless workloads. [1] https://lwn.net/Articles/674770/ https://lwn.net/Articles/674770/
- toyg 6y ago
  The point of serverless for vendors is lock-in. Everything else about it is an annoyance, from their side (having to manage lifecycle, controlling load in shared engines, measuring resource usage...). But it locks people in and can be slapped with basically-arbitrary prices. The incentives to set standards are exactly zero, because once all providers support them and easy portability is achieved, it becomes a race to the bottom on price. Unless vendors can come up with some extra value-added service on top and choose to commoditize away the serverless layer, there won’t be any standard.
- rzwitserloot 6y ago
  > Is there anything stopping an organisation from defining some standard types of serverless environments? Yes. Basic economics. There is nothing _technical_ stopping 'an organisation' from making a federated twitter or facebook. But there are (evidently) insurmountable non-technical reasons: It hasn't happened / there have been attempts which have all effectively failed (in the sense that they have made no significant dent in these services' user numbers). Why would e.g. Amazon (AWS) attempt to form a consortium or otherwise work together or follow a standard, relegating their offerings to the ultimate in elasticity? Economically speaking, selling grain is a bad business: If someone else sells it for 1ct less per kilo then the vast majority of your customers will go buy from someone else, there's no product differentiation. Serverless lockin (such as GAE or AWS Lambda) is the opposite. No matter how expensive you make the service, your users will stay for quite a while. But make a universal standard and you fly in one fell swoop to the other end of the spectrum. If I have a serverless deployment and the warts of serverless are fixed (which would, presumably, involve the ability to go to my source repo, run a single command, give it some credentials, and my service is now live after some compilation and uploading occurs) - then if someone else offers it 1ct cheaper tomorrow I'll probably just switch for the month. Why not? This cycle can be broken; but you're going to have to paint me a picture on how this happens. Government intervention? A social movement amongst CEOs (After the war, there was a lot of this going around)? A social movement amongst users so aggressive they demand it? Possible, but that would require that we all NOT go to serverless until the services offering it come up with a workable standard and make commitments to it.

Juliate 6y ago

It's massively inefficient, but it's also still massively safe in comparison, regarding soveignerity. Like, today, given the political uncertainty in the USA, any large company would be nuts to bet on hosting their critical services on US-dependant infrastructure without having a huge plan B already in the works.

ehnto 6y ago
Is there a serverless provider with a "self hosted node" option that could be used as a fallback? That pretty much defeats the purpose of serverless, but at least you could hang on while figuring out how to transition to a new solution if the provider fails. That has always been my sticking point. With AWS in particular. I don't trust AWS to exist forever, and it's definitely not without it own ongoing maintenance issues. Locking my entire business into their ecosystem seems risky at best. Something I see really often in startups is huge dependencies in the form of SaaS. It should be no secret to those in tech that many of these businesses will not be around in 3 years. Even the likelihood of their service staying the same for 3 years is pretty low. I have been bitten by enough deprecated services, APIs and Incredible Journeys that I am wary.

ethanwillis 6y ago

This on the assumption that there isn't a balkanization of the serverless frameworks between providers. History doesn't bear this. In 2020 we still need tools like BrowserStack even after decades now of web developers complaining about the fragmented ecosystem. Instead of maintaining software compatible with the right operating system, you're maintaining software compatible with the right flavor of serverless by Cloud Provider. Now we're back to square one on at least one front. On the control aspect, the bias against giving up control is not an unwarranted one. Maintaining control of critical infrastructure is extremely important. And in fact outsourcing your critical infrastructure is an existential one, and not just in an academic sense. When you give up control you give up the ability to prevent your infrastructure being hostile, but incompetent. In these cases it reduces the quality of your product for your customers. I won't even go into the anti-competitive tactics Amazon themselves get into that make them not a good choice for your infrastructure. Instead I'll draw upon a recent experience that illustrates why outsourcing infrastructure, even at a higher level, is a bad idea. My girlfriend recently was taking her NLN exam remotely. They weren't allowed to use calculators of their own, they had to use a virtual calculator provided by the company administering the test. Like most of these companies they are doing remote proctoring of the exams. During her exam this virtual calculator flat out wasn't available. The proctor told her to simply click through the exam and that once she submitted it she'd be able to call into customer service to get the exam re-scheduled due to the technical difficulties. Well, that wasn't the case. After doing some deep digging for her, here is what I found. The testmaker NLN contracted out the test administration to a third party, Questionmark. Questionmark in turn contracted out yet another 3rd party, Examity to handle the proctoring. Examity proctors don't have access to Questionmark's systems. Questionmark doesn't have access to NLN's systems, etc. So how did we get this resolved? I had to track down the CEO of Questionmark, the CEO of Examity, and the head of testing for NLN. I had to reach out through LinkedIn inmail to get this on their radar. And then it was handled(quickly and efficiently I might add!). However, frontline support for each of these companies could do nothing. They just had to offload blame onto the support staff of each other. Another aspect of this is that each handoff between 3rd parties creates a communication barrier. In this case the communication barrier seems to have kept Questionmark from configuring this specific test correctly. I wouldn't blame any of these companies for this specific failure mode because it's just the nature of what happens when you offload your work to 3rd parties. When you say, "Oh it's great we don't have to worry about X because Y can do it." The implication is that you lose all of the power of a vertically integrated company by essentially spinning off tons of subsidiaries and creating a communication overhead both before and when problems DO arise. What is the future of software development going to look like when it reaches consumers and you have to say "Sorry, we can't fix that issue because Cloud Provider has to get back to me, and then in the background Cloud Provider has to say sorry we can't get back to you because we have to wait for our spunoff hardware division to get back to us?" Maybe this type of business is fine for fun apps, but it's not fine for a lot of businesses. Even SLAs and disclaiming responsibility in your own contracts won't save your reputation. All it does is protect you financially!

brainless 6y ago

> Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Except that it is not. The security and constant maintenance is needed but it is worth in many cases. And large companies can not really off load all ownership of data and applications. The interest in servers actually went in reverse direction due to the cloud effect. I would say having own server or application hosting capacity is very similar to why you produce your own solar power and store it in batteries - it is simple? No. But the technology is improving and thus it makes it easier for people to adopt this paradigm. When I see what is happening with WebAssembly/WASI in particular, I see a great future for self-hosting again. Software written in any programming language (as long as it targets WASM) is a lot easier to host than existing models. Also there is interoperability of software coming from different languages at the WebAssemply level as I understand.

zelly 6y ago
> Software written in any programming language (as long as it targets WASM) is a lot easier to host than existing models. For the past 20 years you have been able to target x86 gnu/linux and have it running without modification on a readily available server, either your own hardware or rented/public cloud. How does switching from one binary format to another (x86 to WASM) change anything (except maybe slowing down your code)? As I understand it, the main draw of WASM is running non-JS code in a web browser.
- tarruda 6y ago
  > As I understand it, the main draw of WASM is running non-JS code in a web browser. Simplified deployment + automatic sandboxing? AFAIK with x86 you can't just write a client app and have it automatically run on any computer that visits your website.
  - cblconfederate 6y ago
    Are people reinventing java as if it never existed?

kiney 6y ago

your "serverless" framework becomes your operatings system. Just a bad one.

na85 6y ago

>The future of software development is going to be defined by cloud providers. They’re going to define the language ecosystem, the canonical architectures for apps etc... That's... quite depressing to consider, actually. I long for a return to the internet of yore when Native apps were still king and not everything was as-a-service.

toyg 6y ago
I agree. But you can still do native apps today, if you’re willing to jump through all the hoops that OS vendors set in your path and maybe renounce a couple of platforms (like chromebooks). Unfortunately, now that basically OS vendors are also effectively cloud providers, their incentives are set to increase those hoops (“for secuyriteh”), nudging more people towards “easier” cloud deployments.

raxxorrax 6y ago

In my experience, maybe it just isn't there yet, serverless has much more points of failure than a conventional infrastructure. I am sure there a lot of software that really needs the scale the cloud can provide. Funny thing is that we tend to use it for tiny apps, some IOT voice interfaces or BTB tools that we don't want in our corporate network. I doubt cloud providers can dictate environments, other providers would quickly fill the gap to meet developer preferences. I also think that more developers care about lock in these days.

zshrdlu 6y ago

On the other hand, perhaps endeavors akin to NixOS and Guix will make maintaining your own operating system trivial.

CaptArmchair 6y ago

> When put like that, it’s amazing that we didn’t come up with this idea earlier. It's called time-sharing and it existed in the 1960's. [1] [1] https://en.wikipedia.org/wiki/Time-sharing https://en.wikipedia.org/wiki/Time-sharing The difference between time-sharing and serverless is that the former solved the issue of expensive personal computing, until cheap personal computers took over that market. The latter solves perceived expensive computing on the "server" side. But what does it serverless solve exactly? It doesn't solve a technical problem, rather addresses concerns on the business side. Serverless solves a cost problem. First, computing needs aren't linear, they fluctuate. And so, there's a problem of under- and over-utilization vs availability of resources. Serverless approaches computing power like tapwater: you're essentially paying for the CPU time you end up using. Second, elasticity. Instead of having staff struggle - losing time - with the fine intricacies of autobalancers, sharding and what not; you outsource that entirely to a cloud provider. Just like a tap, if you need more power, you just turn the tap open a bit more. Finally, serverless services abstract any and all low level concepts away. Developers just throw functions in an abstraction. The actual processing is entirely black box. No need to worry about the inner details of the box. Sounds like a good deal, right? > Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Well... no. Outsourcing all of that to a third party cloud computing vendor doesn't dismiss you from your responsibility. All it does is shift accountability to the cloud provider who agreed to take you on as their customer. Securing your factory still very much includes deploying a secure digital solution to manage your machinery and process lines. Plenty of industries wouldn't even remotely consider outsourcing critical parts of their operations, and this would include digital infrastructure. And this is regardless of the maturity of serverless technology. Risk management is a vast field in that regard. Then there's legal compliance. There are plenty of industry specific regulations that simply don't even allow data to be processed by third party cloud services unless stringent conditions are adhered to. Medicine, banking and insurance come to mind. Finally, when it comes to business critical processes, businesses aren't interested in upgrading to the latest technology for the sake of it being cutting edge. They want a solution that solves their problem and keeps solving that problem for many years to come. Without having to re-invest year after year in upgrades, migrations and changes because API's and services keep shifting. Does that mean that there isn't a market for serverless computing? Of course there is. Serverless computing is a JIT solution. It's an excellent solution for businesses in a particular stage of their growth. And it closes the gap for plenty of fields where there really is a good match. I just feel that "maintaining your own server is completely nuts" is a bit overconfident here;

deleted 6y ago

[deleted]

zelly 6y ago

It's not nuts to run servers. If an application is operating at any scale such that there is a nonstop stream of requests, then it will be cheaper, faster, and more energy-efficient to run a hot server. This follows from thermodynamics. No matter how good the cloud vendor's serverless is, it's always going to be less efficient than a server, unless it doesn't do any setup and teardown (i.e. no longer serverless). It is nuts to run one server. Then you're wasting money with a server/VM. That's what serverless is ideal for: stuff no one uses. That's a real niche. Who's going to use that? Not profitable companies. Often I think for most cases where you reach for serverless, you should reconsider the choice of a client-server architecture. An AWS Lambda isn't a server anymore; it's not "listening" to anything. Why can't the "client" do whatever the Lambda/RPC is doing? Maybe what you want is just a convenient way to upload code and have it "just work" without thinking about system administration. The types of problems where you don't care about the OS is once again a niche. You probably don't even need new software for these kinds of things. You can just use SaaS products like Wordpress, Shopify, etc. Serverless won't be profitable because the people who need it don't make money.

molf 6y ago
> Serverless won't be profitable because the people who need it don't make money. You seem to implying only applications with huge numbers of users can be profitable. This statement ignores a tremendous amount of (typically B2B) applications that provide enormous value for their users but don't see a lot of traffic. I have worked on applications that are at the core of profitable businesses yet they can go days, in some cases weeks without any usage. Serverless architecture will be a real benefit there once it matures.
- robertlagrant 6y ago
  I don't think that's necessarily true. Google Cloud functions give you 2 million invocations free a month - that's almost 1 per second. You can keep adding another 2 million for $0.40 at a time. It's not terrible.
throw7889 6y ago
We use serverless in a project and our monthly revenue is $6K. It is not true to assert that only people with no revenue are using serverless.

xorcist 6y ago

> Maintaining your own server is completely nuts I've in this area professionally for some time now, and I've never "maintained" servers in any reasonable sense. There are kernel people who maintain the kernel and there are Debian devs who maintain the operating system. The server may be mine (but more often that not, it isn't) but only in very specific circumstances do I ever concern myself with maintaining any part of this stack. A vanilla Linux VM is a platform to build on. Just like AWS or anything else. It is the environment in which my software runs. Thus far, something like Debian has been more stable and much less of a moving target than any proprietary platform has been, cloud or non-cloud. Should a client wish to minimize maintenance costs of the software over the coming decade, it is most cost effective to not depend on specialized, proprietary, platform components. That may change in the future, but right now there is no indication that is the case.

numlock86 6y ago
That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it go. On the other hand, if you actually need to tinker with your OS, roll your own. But what you described is the prime example of serverless target audience.
- jeroenhd 6y ago
  One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises. There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".

jbirer 6y ago

What are you going to do when the container solution / node.js instance / insert x component here crashes? Wait for support to do something about it when you can fix it instantly? Or when you want to deploy a gRPC / crypto daemon to communicate with your back-end? As an experienced back-end developer and linux user I would pull my hair out if I was completely helpless in fixing an issue or implementing some side thing that requires shell access. I don't want to wait for some guy in Philippines who will be online 12 hours later to come try to fix it.

gnarcoregrizz 6y ago

Sometimes I wonder if this is propaganda by cloud/serverless providers to get everyone to jump on it and get locked in. The serverless black box kind of sucks, apart from “auto scaling” stuff. Crap performance too.

narrator 6y ago
Auto-scaling is usually a myth anyway. You have to understand your system deeply and where all the bottlenecks are to really scale. If you have a part that's a big black box, that's going to get in the way of that.

OJFord 6y ago

> Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run. Instead, developers can build applications that are compatible with particular serverless frameworks.

sippingjippers 6y ago

It's not clear to me how much experience with serverless architectures the author of the parent comment has, but speaking as someone with plenty, the operational costs of serverless are at least equal to managing stateful infrastructure, with much less control when things go wrong. Lambda was a major step up in long term predictability compared to for example App Engine, where there have been plenty of instances of overnight unannounced changes, or changes announced with incredibly short notice period, requiring developer time rather than ops time to bring an application back to service. On the ops side even with a platform like Lambda, training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right. "The app is down" -> escalate to the developers every single time. Compare that to "the app is down", "this app has basically no ops documentation", "try rebooting the instances", "ah wonderful, it came back" I'm pro-cloud in many ways and even pro-serverless for certain problems, but let's not close our eyes and pretend dumping everything into these services is anything like a universal win.

darkwater 6y ago
This. 100 times this. Also, in several places most of the services downtimes are due to, you know what? Application bugs, not infrastructure outages. Sure, they happen as well and being on a good cloud provider mitigate a lot of them (but not all of them!) but if you increase the application design complexity you will increase also those downtimes. Yeah sure, there are tens of really good engineering departments where everything is properly CI?CD, automated, they can scale to thousand of services without skipping a beat... but that's not the reality for thousands of other smaller/less talented shops. So, "moving to serverless" will not just automagically fix all of your problems. Also - and I'm an infra guy so I'm probably biased - I don't really get all this developer anxiety to outsource infra needs. Yeah if you are 2 devs working on your startup it makes sense, but when you scale up the team/company, even with serverless, you WILL need to dedicate time to infra/operations and do not dedicate it to strictly-business-related code. Having somebody dedicated to this is good for both.

goatinaboat 6y ago

Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. TANSTAAFL. Let’s say serverless becomes commoditised the same way as electricity. What are the margins in that business? What are AWS etc margins now? There are very strong reasons to believe that serverless will offer convenience at a premium price, forever.

JulianMorrison 6y ago

The midway point between "maintain your own servers" and "wholly in the cloud" is "configuration as code", using chef and terraform, or similar tools. You don't patch your OS, or your apps, you define their versions and configuration in code and it gets built for you. And typically snapshotted at that point and made into a restartable instance image that can be simply thrown away if it's misbehaving, and rerun from the known good image.

bborud 6y ago

Well, when will it be mature and what will it take to get there? My first experience with serverless architecture was back in 2007 or so when trying to port Google News to App Engine. That was a thoroughly painful experience, and things haven't exactly gotten much easier since. If you go back in time a decade, Google's strategy for selling compute capacity was App Engine. Amazon went the EC2 route. Reality suggests AWS made the better choice. I can understand the superficial notion that having idling virtual machines is inefficient (because it is). But this reminds me a bit of tricks we did to increase disk throughput in systems with lots of SCSI disks back in the day. Our observation was that if we could keep the operation queues on every controller full as much of the time as possible, we'd get performance gains when controllers were given some leeway to re-order operations, resulting in slightly better throughput. Overall you got higher throughput, and thus higher efficiency, but from the perspective of each process in the system, the response was sluggish and unpredictable. Meaning that if you were to try to do any online transactions, it would perform very poorly. For a solution to be desirable it has to be matched with a problem that needs solving. As the article points out, there are some scenarios where serverless architectures might be a good design paradigm. But extrapolating this to the assumption that this paradigm is a universal solution requires not only a leap of faith, but it also requires us to ignore observed reality. So you owe me some homework. Tell me what needs to happen for serverless architectures to reach "maturity".

nemetroid 6y ago

Those are the same arguments as the ones put forth in the article under "the promise of serverless computing". It remains to be seen if they can be realized without the downsides.

nicbou 6y ago

I don't do any server admin. My code runs in docker on pretty much any server I can get my hands on. Some of my code runs on a ThinkPad stashed behind my desk, on DigitalOcean, on my Macbook. I could deploy to a Raspberry Pi and it would run just the same. It takes 10 minutes to deploy an exact copy to a new environment. None of that requires OS maintenance. My house plants require far more maintenance than my software. I sometimes forget where some things run because I haven't touched them in years. Serverless code runs on the cloud you built it for. I don't want that. I don't want to invest years of my life becoming an Amazon developer, writing Amazon code for Amazon servers. That's without delving into the extra work serverless requires. There isn't a dollar amount tied to my import statements. I don't need software to help me graph and make sense of my infrastructure. I can run my code on my computer and debug it, even offline.

Just1689 6y ago
You probably know this but from what I read above it might be worth mentioning. Your hosts are still packed with a bunch libraries and services (sshd for example) that should probably be updated with regularity. I echo a lot of what you say here regarding run anywhere and not marrying some giant vendor.
- beagle3 6y ago
  Agreed. On hosts I manage professionally, I update/upgrade weekly after reading the notes - it takes a few minutes, I know I'm up to date and if there is anything I should be wary of. On a personal debian server, I have an update/dist-upgrade -y nightly on a cron job, and I reboot if I read on HN/slashdot/reddit/lwn about an important kernel fix; Never had an issue, and I suspect it's about as secure and trouble free as whatever is underlying lambda -- with the exception that every 3-4 years I have to do an OS upgrade.
oblio 6y ago
What if your ThinkPad is unplugged? What if its HDD dies? Why aren't you updating the OS? Did you patch the firmware for Spectre/Meltdown? Etc, etc

fragmede 6y ago

Serverless is already here, it's just unevenly distributed. Instead it's called (managed) Kubernetes and yeah, you need a devops team and there's still a bunch of overhead but like you say - the writing's on the wall.

toss1 6y ago

>> Like running your own power plant to serve your factory With newer power technologies becoming more affordable and effective, solar, wind, & storage are increasingly being used to power factories and other businesses. It's all about control of your product and operations. If it is economically feasible, it's always better to control your own stack all the way down. Does serverleds actually deliver better control over your development, portability, reliability, security, etc. for your application & situation, or not? This sounds a bit like the "When will they turn off the last mainframe?" arguments a while back - I wouldn't expect servers to disappear either...

bearjaws 6y ago

Anyone moving to Hitrust or SOC2 loves serverless for that exact reason. When asked how I maintain my infrastructure, I point to RDS, API gateway, and Lambda. This leaves my security mostly free to focus on application level security.

thinkharderdev 6y ago

I've never really understood this argument for serverless. Everything you do in AWS is through an API. I've never quite understood how replacing one set of API calls to provision an EC2 (or ECS cluster) is so much more complicated than another set of API calls to create a severless stack. If anything, my experience has been the complete opposite. Provisioning a serverless stack is much more complicated and opaque.

ForHackernews 6y ago

> The future of software development is going to be defined by cloud providers That's probably true of web development, but "software development" writ large is much more than just cloud providers and webapps. "Software" encompasses everything from embedded microcontrollers to big iron mainframes that drive (yes, even today, even in 2030) much of the world's energy, transportation, financial and governmental infrastructure.

randomsearch 6y ago
I think you've made a fair point, which I did have in mind but didn't write down - that there is a dichotomy between embedded and cloud systems, and the definition of software development will be to a lesser extent defined by the embedded side. Apple, for example, will have clout. But long-term I think the cloud providers will assimilate so much power that the embedded side will follow its diktats. Big iron mainframes have longevity, but will absolutely die out close to complete extinction - I've worked on those systems, I understand their strengths and the legacy issues, and there's no way that cloud isn't going to gobble up that market, it's just going to take a long time (as you say, beyond 2030).

thaeli 6y ago

We had that utterly compelling framework in the early 2000s. Write generic code, upload to any provider you want, watch it run - that's exactly how shared-hosting PHP worked in ye olden days and to this day no one has made a developer experience as nice and It Just Works as that.