The Serverless Revolution Will Make Us All Developers(nextplatform.com)
nextplatform.com
The Serverless Revolution Will Make Us All Developers
https://www.nextplatform.com/2017/09/25/serverless-revolution-will-make-us-developers/
73 comments
> please chop off my hands and pull out my eyeballs if cloud computing becomes yet another workflow engine
I'll second that.
Moreover, I'm not sure who the author of this article imagines will fix all of these busted building blocks when some ill formatted or out of bounds data starts arriving from one of these IoT devices, not to mention non-standards compliant data.
I'll second that.
Moreover, I'm not sure who the author of this article imagines will fix all of these busted building blocks when some ill formatted or out of bounds data starts arriving from one of these IoT devices, not to mention non-standards compliant data.
Yay! Another revolution! I was starting to miss the IoT revolution, and chatboat revolution, and...
But, seriously. I read this the other day:
https://www.theatlantic.com/technology/archive/2017/09/savin...
There's a discussion on HN somewhere. TLDR; we're building complexity into software that developers can't keep in their heads any more, which is leading to more and more errors.
It crossed my mind today when I was fiddling with some AWS stuff. Keeping a mental-map of all of these services, security groups, VPC topology, IAM configs, etc. is also growing more difficult.
And now, this. Haven't done Lambda work, but the paradigm would seem to contribute to mental noise. On one hand, it seems liberating to move away from bound-servers, but who maintains the configs and mental-model for all of the "unbound" processes that can "materialize", do work, then quiesce again? How about the dependency map between Lambdas? Overall, seems they'd kind of become "phantoms" over time vs. servers.
>Permissions are a nightmare. You have to give both users trying to run lambdas and the lambdas' service accounts some crazy permissions sometimes in order to get anything to work
And once you've done this, it has to be recorded and mentally mapped.
On a related note, I find much of AWS to be this way. For all of its success, it is not the clearest to navigate, especially on the interoperability front. It's not always obvious what you need to do to connect things the first time around on any given service(s), and it requires more trial and error than I'd like. When it doesn't work, it generally just doesn't work. Is it a security group? VPC setting? Firewall? IAM role? Something I don't know that I don't know? Do I even need this or that component?
Always seemed that there's a lot of documentation on the parts, but that there's something missing on the whole/overall cohesiveness.
But, seriously. I read this the other day:
https://www.theatlantic.com/technology/archive/2017/09/savin...
There's a discussion on HN somewhere. TLDR; we're building complexity into software that developers can't keep in their heads any more, which is leading to more and more errors.
It crossed my mind today when I was fiddling with some AWS stuff. Keeping a mental-map of all of these services, security groups, VPC topology, IAM configs, etc. is also growing more difficult.
And now, this. Haven't done Lambda work, but the paradigm would seem to contribute to mental noise. On one hand, it seems liberating to move away from bound-servers, but who maintains the configs and mental-model for all of the "unbound" processes that can "materialize", do work, then quiesce again? How about the dependency map between Lambdas? Overall, seems they'd kind of become "phantoms" over time vs. servers.
>Permissions are a nightmare. You have to give both users trying to run lambdas and the lambdas' service accounts some crazy permissions sometimes in order to get anything to work
And once you've done this, it has to be recorded and mentally mapped.
On a related note, I find much of AWS to be this way. For all of its success, it is not the clearest to navigate, especially on the interoperability front. It's not always obvious what you need to do to connect things the first time around on any given service(s), and it requires more trial and error than I'd like. When it doesn't work, it generally just doesn't work. Is it a security group? VPC setting? Firewall? IAM role? Something I don't know that I don't know? Do I even need this or that component?
Always seemed that there's a lot of documentation on the parts, but that there's something missing on the whole/overall cohesiveness.
+10.
Lambda's are the unattainable Chalice.
The API Gateway that you have to go through is byzantine.
Then Route53, CloudFront, yada yada - AWS has become such a massive bureaucracy - it changes so fast, documentation incomplete.
The other issue is the inability to keep Lamda's 'hot' - as they often take several seconds to load.
And of course easy shared memory and persistent file access.
Lambda's are simply not designed for use web-app folks - they are designed to to back-end dev-ops and IT tasks.
I think it's been like 5 years now and they are still a mess, I really want to use them, but I wont.
Lambda's are the unattainable Chalice.
The API Gateway that you have to go through is byzantine.
Then Route53, CloudFront, yada yada - AWS has become such a massive bureaucracy - it changes so fast, documentation incomplete.
The other issue is the inability to keep Lamda's 'hot' - as they often take several seconds to load.
And of course easy shared memory and persistent file access.
Lambda's are simply not designed for use web-app folks - they are designed to to back-end dev-ops and IT tasks.
I think it's been like 5 years now and they are still a mess, I really want to use them, but I wont.
Lambda's are simply not designed for use web-app folks - they are designed to to back-end dev-ops and IT tasks.
Absolutely. I see people trying to serve websites out of cloud functions. Reminds me of the mid 90s when people ran httpd from inetd!
Absolutely. I see people trying to serve websites out of cloud functions. Reminds me of the mid 90s when people ran httpd from inetd!
Yeah - but I think there is a 'massive' business case that Amazon is missing out on.
Are you PM's reading this?
Give us:
+ Lamdas without the clumsy API Gateay (or at least a simple 'pass thru' mode.
+ Support direct integration with Express or whatever, so we don't have to create Lambda-specific code
+ Allow us to keep them 'hot' so latency is low.
+ Give us a way to access some kind of persistent file storage with 'fs'.
+ Same thing for shared memory.
If this were true, I would see a massive flood of people moving to Lambda's.
Nobody likes to have to manage Linux instances. We'd all rather something more manageable and easy to use.
I feel we are on the cusp of this and I still can hardy believe nobody has 'got it right' just yet.
Are you PM's reading this?
Give us:
+ Lamdas without the clumsy API Gateay (or at least a simple 'pass thru' mode.
+ Support direct integration with Express or whatever, so we don't have to create Lambda-specific code
+ Allow us to keep them 'hot' so latency is low.
+ Give us a way to access some kind of persistent file storage with 'fs'.
+ Same thing for shared memory.
If this were true, I would see a massive flood of people moving to Lambda's.
Nobody likes to have to manage Linux instances. We'd all rather something more manageable and easy to use.
I feel we are on the cusp of this and I still can hardy believe nobody has 'got it right' just yet.
+ Lamdas without the clumsy API Gateay (or at least a simple 'pass thru' mode).
You can call AWS Lambdas directly through the AWS SDK (or dozens of other event sources like SQS, Timers, etc.)
+ Allow us to keep them 'hot' so latency is low.
You can keep lambdas "hot" with periodic invocations, it's not standardized, but it's a thing
+ Give us a way to access some kind of persistent file storage with 'fs'.
There's also access to 500mb of data on /tmp. It's not always cleared after each invocation of your function, especially if it's invoked multiple times in succession, so you can use it as a "scratchpad" that provides some soft caching under high load.
S3FS works if you just want to expose S3 through an 'fs' interface.
You can call AWS Lambdas directly through the AWS SDK (or dozens of other event sources like SQS, Timers, etc.)
+ Allow us to keep them 'hot' so latency is low.
You can keep lambdas "hot" with periodic invocations, it's not standardized, but it's a thing
+ Give us a way to access some kind of persistent file storage with 'fs'.
There's also access to 500mb of data on /tmp. It's not always cleared after each invocation of your function, especially if it's invoked multiple times in succession, so you can use it as a "scratchpad" that provides some soft caching under high load.
S3FS works if you just want to expose S3 through an 'fs' interface.
That's helpful, thanks, but none of those are full solutions.
Even if they are accessible via a javascript api, we need them accessible via regular HTTP for so many reasons.
'Periodic invocations' my gosh man, that seems like a big hack, requiring yet another service.
I get that there is /tmp - but it's not guaranteed to be persistent. I wish it were.
Anyhow - my main point is ... Lambda's don't seem to be designed for us in mind :)
Thanks for the pointer on S3FS, I will definitely check that out.
Even if they are accessible via a javascript api, we need them accessible via regular HTTP for so many reasons.
'Periodic invocations' my gosh man, that seems like a big hack, requiring yet another service.
I get that there is /tmp - but it's not guaranteed to be persistent. I wish it were.
Anyhow - my main point is ... Lambda's don't seem to be designed for us in mind :)
Thanks for the pointer on S3FS, I will definitely check that out.
I suspect the economics of a lambda that you keep hot would look very different than one that takes a few seconds to spin up. It would be identical billing to you constantly pinging it I expect. At that point if you still wanted to be serverless you would be looking at containers.
"I suspect the economics of a lambda that you keep hot would look very different than one that takes a few seconds to spin up. "
Surely. But what exactly are those economics? It can't be that bad.
Surely. But what exactly are those economics? It can't be that bad.
+10 I just wonder how the pushback of these techs will look like, because that's what's going to happen when everything is in an disarray and a mess. Someone still have to clean things up on Saturday at 3 o'clock in the night.
Excuse my ignorance here, and trust that I'm actually asking because I'm genuinely curious, but what do you mean by a "common runtime"?
We use Cloud Function for a large part of our infrastructure, and it's all just Node under the hood. Some of it we recently ported to Iron.io for cron runs and it was a pretty smooth process. I'm just curious what changes you'd actually like to see made here.
We use Cloud Function for a large part of our infrastructure, and it's all just Node under the hood. Some of it we recently ported to Iron.io for cron runs and it was a pretty smooth process. I'm just curious what changes you'd actually like to see made here.
I'd really love to see a "blessed" environment that I can be sure all of my lambdas are running on: Linux with <insert tools here> always preinstalled, a common process for building native extensions, tooling for making lambda-style compute a commodity rather than a differentiator. I basically don't want to have to do any work when I move from one function execution platform to another.
Granted, I'm a little spoiled in that regard since 90% of my work is on Kubernetes, and besides a few very small pieces of connective tissue everything is identical from cloud to cloud.
Granted, I'm a little spoiled in that regard since 90% of my work is on Kubernetes, and besides a few very small pieces of connective tissue everything is identical from cloud to cloud.
Gotcha, that makes sense. We've attempted to abstract the endpoint and pub/sub logic from Cloud Functions into common libs, but I suspect moving to Lambda with our full stack would still be a real bear.
Have you ever looked at NixOS or NixOps? Nix lets you define an entire OS configuration in one neat config file, and lets you start a shell with any packages you want, independent from the rest of the system.
Can I use it to manage the windows desktops my non-developer researchers use? Can I use it at a customer that only has windows-based server infrastructure, because Enterprise? I need the same system that deploys the server to also deploy the client. It seems every one of these solutions assumes you're writing a web application.
It's sounds like your problem is proprietary Windows, and I feel for you. Other than the fact that Nix runs in Windows, it can't really help you with the consistent deployment thing.
We really need something we can point to to express and legitimize our frustration with Windows to those who don't understand how much more effort it takes to deal with a totally incompatible proprietary system.
We really need something we can point to to express and legitimize our frustration with Windows to those who don't understand how much more effort it takes to deal with a totally incompatible proprietary system.
I'll trade expressing frustration for a tool that actually solves the problem. Every time this topic comes up, I ask the same question hoping someone will point to a tool designed for this use-case, and not just an afterthought compatibility mode for a different solution. Nix on windows is a non-starter because it's not really Nix-on-windows. It's Nix-on-Linux-Subsystem-for-Windows-10-Creators-Edition. Who's running Windows 10 Creators Edition on production? Give me something that runs on Windows Server 2012 and doesn't require all-or-nothing adoption.
I believe Azure Cloud Functions will get you somewhat of the way where you want to go.
As far as I understand you invoke them just like you would run a docker container.
As far as I understand you invoke them just like you would run a docker container.
whatever half-baked monstrosity Azure has cooked up
I think you'll actually find Azure is well in the lead on this one, well ahead of where Amazon is anyway.
I think you'll actually find Azure is well in the lead on this one, well ahead of where Amazon is anyway.
This mischaracterization was a crime of passion. I apologize.
> I refuse to invest in serverless until I know that I can run the same code on minikube on my laptop as I can in <insert cloud provider here> because vendor lock in is real and will bite you in the ass one day.
If that is your concern, then you may want to consider that serverless isn't the right solution for your problem.
All the serverless runtimes across all the providers are basically identical. But that's not what makes them interesting. What makes them interesting are the ecosystems around them.
Lambda is the glue that binds AWS together. Most of your lambdas should be AWS specific, enough so that your vendor lock in won't be because of the specific Lambda runtime, but because of the services that you're using with your Lambda.
If that is your concern, then you may want to consider that serverless isn't the right solution for your problem.
All the serverless runtimes across all the providers are basically identical. But that's not what makes them interesting. What makes them interesting are the ecosystems around them.
Lambda is the glue that binds AWS together. Most of your lambdas should be AWS specific, enough so that your vendor lock in won't be because of the specific Lambda runtime, but because of the services that you're using with your Lambda.
This times a thousand.
Maybe in the future when AI can handle lots of that stuff we'll get there, but as of right now we have a LONG way to go.
Maybe in the future when AI can handle lots of that stuff we'll get there, but as of right now we have a LONG way to go.
Have you tried Openwhisk? It would fit the needs you describe I think.
Openwhisk seems (from my very cursory once-over) to require actually laying down some servers, which is fine, but not really the brave new serverless world we're all gunning for. The promise of serverless computing is freedom from a fleet of boxen, and it seems to require a fleet of boxen.
No - openwhisk is a managed service on IBM bluemix. It's one of the few services of theirs I'd recommend over aws
Small correction: OpenWhisk is an Open Source (incubating) Apache project, http://openwhisk.incubator.apache.org/ or https://github.com/apache/incubator-openwhisk. You can run OpenWhish on your own hardware or in the cloud.
IBM Cloud Functions is a hosted, managed version of that service, https://console.bluemix.net/openwhisk/, running on the IBM Bluemix platform.
IBM Cloud Functions is a hosted, managed version of that service, https://console.bluemix.net/openwhisk/, running on the IBM Bluemix platform.
To be clear - there's the Apache OpenWhisk project (https://openwhisk.incubator.apache.org) which was initially developed and released by IBM.
IBM Bluemix, of course, offers OpenWhisk on their platform, but you can set up your own OpenWhisk platform if you want.
(disclosure: work for IBM, but not in Cloud)
IBM Bluemix, of course, offers OpenWhisk on their platform, but you can set up your own OpenWhisk platform if you want.
(disclosure: work for IBM, but not in Cloud)
The same tired argument has been made every decade since the 70s, with mostly the same cast of characters: artificial intelligence, English somehow being used to specify the behavior, stock libraries of code, etc. I think we're about as far from it today as we were when Prolog was a big deal.
The amount of incipient complexity in programming has been growing, not going down. What's more complex, "hello, world" to the console in Python, or "hello world" in a browser with the best and newest web stack? Mobility and microservices create lots of new edge cases and complexity—do non-programmers seem particularly well-equipped to handle edge cases to you?
The problem has never really been the syntax—if it were, non-programmers would have made great strides with Applescript and SQL, and we'd all be building PowerBuilder libraries for a living. The problem is that programming requires a mode of thinking which is difficult. Lots of people, even people who do it daily, who are trained to do it and exercise great care and use great tool tools, are not great at it. This is not a syntax problem or a lack of decent libraries problem. We have simple programming languages with huge bodies of libraries. What's hard is the actual programming.
The amount of incipient complexity in programming has been growing, not going down. What's more complex, "hello, world" to the console in Python, or "hello world" in a browser with the best and newest web stack? Mobility and microservices create lots of new edge cases and complexity—do non-programmers seem particularly well-equipped to handle edge cases to you?
The problem has never really been the syntax—if it were, non-programmers would have made great strides with Applescript and SQL, and we'd all be building PowerBuilder libraries for a living. The problem is that programming requires a mode of thinking which is difficult. Lots of people, even people who do it daily, who are trained to do it and exercise great care and use great tool tools, are not great at it. This is not a syntax problem or a lack of decent libraries problem. We have simple programming languages with huge bodies of libraries. What's hard is the actual programming.
> What's hard is the actual programming.
I agree. There's a never-ending stream of things (remember Klik & Play?) meant to make programming "easy for everyone" and they never manage to actually do so, because it's not possible to take away difficulty without taking away flexibility.
I agree. There's a never-ending stream of things (remember Klik & Play?) meant to make programming "easy for everyone" and they never manage to actually do so, because it's not possible to take away difficulty without taking away flexibility.
Well it's hard to tell; I didn't learn to code until college, but it seemed pretty natural to me because years ago I'd used KnP and Logo. It's hard to tease the causes apart---was programming easy to pick up because I had KnP, or was I only able to benefit from them because I was that kind of person?
> The same tired argument has been made every decade since the 70s
One of my father's COBOL books from the punch-card days has a similar sales pitch about English-like syntax and ordinary people becoming programmers.
One of my father's COBOL books from the punch-card days has a similar sales pitch about English-like syntax and ordinary people becoming programmers.
Ordinary people have become programmers.
What people do now with, for example, excel, was certainly once reserved to people with programming skills.
What people do now with, for example, excel, was certainly once reserved to people with programming skills.
I have needed to clean up the crap in those Excels afterwards and put them into a proper production database.
Ordinary people have not become programmers.
Ordinary people have not become programmers.
People are becoming less detail oriented. They are willing to close their eyes and fall backwards and trust that engineered goodness will catch them.
Sure they have. They have become bad programmers.
Ordinary people (non-programmers) have been doing fairly complex spreadsheets since the 80s. My dad, a cost accountant, was born in 1934 and was a Lotus 123/Quattro Pro master by the late 80s/early 90s.
In this case it's worse. The people who are spreading serveless everywhere argue not only that it's simpler (anyway, simpler than what?), but most of all less expensive - and that's the main reason the companies should embrace it. Both these statements are false.
It reminds me of a comment on microservices a while back.
The guy claimed that his company had "done it properly", but it required a huge upfront investment in infrastructure, setting up everything properly and keeping it running.
Wasn't the idea that they were supposed to make things simpler and cheaper?
The guy claimed that his company had "done it properly", but it required a huge upfront investment in infrastructure, setting up everything properly and keeping it running.
Wasn't the idea that they were supposed to make things simpler and cheaper?
"For example, seldom do we see brand new web applications delivered with a traditional, server-based, single-codebase model. Increasingly, they are single-page applications, using APIs and front-end frameworks, such as Angular and React, to tie together functionality."
What?
I'd argue that most new startups launch something resembling a 'monolithic back end' (granted probably on the cloud and leveraging other services).
Moreover, this has nothing to do with 'single page apps'.
What?
I'd argue that most new startups launch something resembling a 'monolithic back end' (granted probably on the cloud and leveraging other services).
Moreover, this has nothing to do with 'single page apps'.
They call this 'serverless' and yet it's all about running thing on ... Servers.
I think it's safe to say that if any individual or company uses the word 'serverless' they are either stupid or have been taken over by marketing and can safely be ignored and ridiculed
I think it's safe to say that if any individual or company uses the word 'serverless' they are either stupid or have been taken over by marketing and can safely be ignored and ridiculed
I've developed some resistence against marketing people talking nonsense over the years but this serverless thing is ... some next level bullshit.
Just because I'm not maintaining my car's engine doesn't mean my car's engineless! Just call it "managed cloud" or something -- calling it "serverless" is nothing short of a blatant lie!..
Just because I'm not maintaining my car's engine doesn't mean my car's engineless! Just call it "managed cloud" or something -- calling it "serverless" is nothing short of a blatant lie!..
It's more like you're renting a car rather than owning a car - you'd be well within your rights to call yourself "carless" then, no?
This is where the good old car analogy falls apart doesn't it :)
I have this software package that I happen to own (the car) whose engine (the backend code) is claimed to be nonexistent, which annoys me slightly more than just "slightly" which motivates me enough to exchange micro-rants on forums with complete strangers.
I have this software package that I happen to own (the car) whose engine (the backend code) is claimed to be nonexistent, which annoys me slightly more than just "slightly" which motivates me enough to exchange micro-rants on forums with complete strangers.
You wouldn't call someone renting a house homeless, or houseless. I wouldn't call someone with a rented car carless. And I certainly wouldn't call a service running on servers with an abstraction layer inbetween serverless :)
I think a better parallel would be to compare a home-owner with someone who lives completely in air-bnb. I'd have a much easier time calling them houseless.
There two factors that affect it:
1. The unit of time that the rental is active for. 2. Who controls the idle time of the resource.
Personally, when describing Lambda to people new to the concept, I eschew this "serverless" confusion completely by describing it as renting a server in 100ms increments for fractions of a penny. Works well for me!
There two factors that affect it:
1. The unit of time that the rental is active for. 2. Who controls the idle time of the resource.
Personally, when describing Lambda to people new to the concept, I eschew this "serverless" confusion completely by describing it as renting a server in 100ms increments for fractions of a penny. Works well for me!
> You wouldn't call someone renting a house homeless, or houseless.
I'd say "houseless" was an acceptable description. "homeless", ok, that definitely doesn't work for a renter.
I'd say "houseless" was an acceptable description. "homeless", ok, that definitely doesn't work for a renter.
> > You wouldn't call someone renting a house homeless, or houseless.
> I'd say "houseless" was an acceptable description.
“Houseless” would be a very strange description of someone with a legal possessory interest in a house.
> I'd say "houseless" was an acceptable description.
“Houseless” would be a very strange description of someone with a legal possessory interest in a house.
> a legal possessory interest in a house.
I'm not sure renting gives you any "possessory interest" in the house, does it? Can you cite some sources for that?
I'm not sure renting gives you any "possessory interest" in the house, does it? Can you cite some sources for that?
> I'm not sure renting gives you any "possessory interest" in the house, does it?
Yes.
> Can you cite some sources for that?
https://www.law.cornell.edu/wex/possessory_estate
Yes.
> Can you cite some sources for that?
https://www.law.cornell.edu/wex/possessory_estate
Cornell on US law doesn't really help me in the UK (not that you were to know that) but there might well be something similar here.
Ta.
Ta.
Its the pricing model that is serverless. That's about the only truth in the name.
Where does all that anger come from?
Serverless may not be the best choice for a name, but it's the de facto name now. Most people I personally know that have used this word, me included, know that there's a server behind and aren't idiots.
I can't just put "managed cloud" on my CV if I want to get a job or if I want to be easily understood. Does that mean I am stupid and I should be ignored and ridiculed?
Serverless may not be the best choice for a name, but it's the de facto name now. Most people I personally know that have used this word, me included, know that there's a server behind and aren't idiots.
I can't just put "managed cloud" on my CV if I want to get a job or if I want to be easily understood. Does that mean I am stupid and I should be ignored and ridiculed?
I mean... this is essentially our core thesis at StdLib [1]. We took a look at "serverless compute" and asked, "what's next? Where does this model of compute get us? How can this make the average developer's life easier?"
The easy answer was "serverless" represents the first step in enabling the ability to turn remote function calls into first-class citizens of your development environment. Since these "functions as a service" are auto-scaling, self-healing, and you only pay for what you use, you can treat them as disposable and regard them with the same level of utility as locally-run, JIT-compiled functions.
The issue was, and still is, how the hell do you get there? Every provider has a different implementation strategy (different runtimes, function signatures, etc.), different platform offerings, and different business incentives for pushing serverless compute. "Serverless", as it currently stands, is not synonymous with "effortless" - you must still understand nearly all of the underlying HTTP infrastructure to configure it. To the vast majority of software developers, the abstraction of "serverless" compute is just an exercise in incidental complexity to save $$ on overprovisioning.
I don't think the real story of "serverless" compute is about cost savings to avoid over- or under- provisioning. That's what I think this article gets right. The story that (hopefully) will eventually be told is one where this revolution, driven by cost-savings, was reshaped and reformed to allow developers to attain mastery over the cloud as if it were merely an extension of their local development environment. To get there we need rigidly enforced Gateway standards, better ways to build, document, deploy and integrate the functions we're building, and a hell of a lot more. We've taken the first step towards this vision of the future with FaaSlang [2], our open spec for type-safety, error-handling etc. around Functions as a Service - but there's still a lot more to do.
[1] https://stdlib.com/
[2] https://github.com/faaslang/faaslang/
The easy answer was "serverless" represents the first step in enabling the ability to turn remote function calls into first-class citizens of your development environment. Since these "functions as a service" are auto-scaling, self-healing, and you only pay for what you use, you can treat them as disposable and regard them with the same level of utility as locally-run, JIT-compiled functions.
The issue was, and still is, how the hell do you get there? Every provider has a different implementation strategy (different runtimes, function signatures, etc.), different platform offerings, and different business incentives for pushing serverless compute. "Serverless", as it currently stands, is not synonymous with "effortless" - you must still understand nearly all of the underlying HTTP infrastructure to configure it. To the vast majority of software developers, the abstraction of "serverless" compute is just an exercise in incidental complexity to save $$ on overprovisioning.
I don't think the real story of "serverless" compute is about cost savings to avoid over- or under- provisioning. That's what I think this article gets right. The story that (hopefully) will eventually be told is one where this revolution, driven by cost-savings, was reshaped and reformed to allow developers to attain mastery over the cloud as if it were merely an extension of their local development environment. To get there we need rigidly enforced Gateway standards, better ways to build, document, deploy and integrate the functions we're building, and a hell of a lot more. We've taken the first step towards this vision of the future with FaaSlang [2], our open spec for type-safety, error-handling etc. around Functions as a Service - but there's still a lot more to do.
[1] https://stdlib.com/
[2] https://github.com/faaslang/faaslang/
"The issue was, and still is, how the hell do you get there? "
Hm, too me personally it's: Why would I want that? My computer is fast enough to for 99.9% of the stuff I want to run.. and for the last 0.1% it's not that hard to spin up a vm.
What am I missing?
Hm, too me personally it's: Why would I want that? My computer is fast enough to for 99.9% of the stuff I want to run.. and for the last 0.1% it's not that hard to spin up a vm.
What am I missing?
You're missing that (1) this is about shipping code that other people can run, or a company can run for others and (2) that 99% of the software developers in the world just want their code to do a thing and not have to worry about anything else.
It's not "that hard" to spin up a VM in the same way it wasn't that hard to visit Blockbuster video. You shouldn't have to know how to drive or know somebody who does to rent a movie. It doesn't hurt, it's a good skill to have, it's fun to get out and practice, but if you just want to watch a movie, why is it necessary? Think about building web services in this way.
A majority of developers we talk to agree that web development has gotten too complex. It's too hard to solve simple problems. Problem is that it's everybody else that has made things too complex. In the same way you become noseblind to a strong perfume, developers become techdebt blind to old technologies they're the most familiar with, then complain about the smells other people layer on top and around them.
The true innovations around serverless tech are coming from the ground up; at StdLib, for example, we've reimagined web services as essentially JIT-compiled, type safe, remote procedure calls. It means we're throwing out the need to even understand HTTP or REST to build a webservice, but opens up all kinds of neat opportunities and a new programming model.
Anyway... I could go on, but tl;dr is try StdLib out for yourself if you get the chance. Our number one piece of customer feedback is, "I never thought it [web dev, serverless functions, APIs] could be this easy."
It's not "that hard" to spin up a VM in the same way it wasn't that hard to visit Blockbuster video. You shouldn't have to know how to drive or know somebody who does to rent a movie. It doesn't hurt, it's a good skill to have, it's fun to get out and practice, but if you just want to watch a movie, why is it necessary? Think about building web services in this way.
A majority of developers we talk to agree that web development has gotten too complex. It's too hard to solve simple problems. Problem is that it's everybody else that has made things too complex. In the same way you become noseblind to a strong perfume, developers become techdebt blind to old technologies they're the most familiar with, then complain about the smells other people layer on top and around them.
The true innovations around serverless tech are coming from the ground up; at StdLib, for example, we've reimagined web services as essentially JIT-compiled, type safe, remote procedure calls. It means we're throwing out the need to even understand HTTP or REST to build a webservice, but opens up all kinds of neat opportunities and a new programming model.
Anyway... I could go on, but tl;dr is try StdLib out for yourself if you get the chance. Our number one piece of customer feedback is, "I never thought it [web dev, serverless functions, APIs] could be this easy."
Ah, it's basically an easier way to do FaaS? I read "first-class citizens of your development environment" to mean it's purpose is run your code on another machine for your own benefit.
It's interesting. (I don't like JS for backend work so I'm not your target market.)
It's interesting. (I don't like JS for backend work so I'm not your target market.)
> Doug Vanderweide is a Microsoft Certified Solutions Developer: Cloud Platform and Infrastructure and a Microsoft Certified Trainer who currently serves as an Azure course author and subject matter expert for Linux Academy and Cloud Assessments. Follow him on Twitter @dougvdotcom.
Sounds like the author of the article has a conflict of interest.
Sounds like the author of the article has a conflict of interest.
Heavy futurism, well said, even bullshit. Mechanisms which would make the IoT pieces work together do not exist. There is no "evolution" of internet which would make this happen in the long term. Everything is designed by humans by now. When robots are in charge on this planet, then I believe this could happen.
We use AWS lambda, and when our lambdas fail, and they are triggered by AWS services asynchronously (i.e CloudWatch logs, S3 events), AWS does not care a limiting at all, and calls our lambdas in a recursively increasing fashion and it causes hundreds of parallel execution, which DDOS'es our internal servers and we reach the concurrenct execution limit for Lambda, and all other our lambdas suffer from one single failing function. Just a heads up before you make use of "unlimited scaling" of lambda.
Well - isn't this technically a bug in your lambda? If this were running on a traditional server managed by you, it might still do bad things to your service.
Yes, but I could add a rate limiter, and If I try to do the limiting myself, it would contradict the serverless approach
AWS will throttle you at 1000 concurrent functions in a single zone. If you're running across zones, I could see this being a problem, but it sounds more like a problem with your code than with lambdas.
Wouldn't you have the same problem if you had one hugely capable server trying to interact with your internal server which is not as capable?
Wouldn't you have the same problem if you had one hugely capable server trying to interact with your internal server which is not as capable?
Yes, you are right, but as a managed service, it would be nice to have a function level concurrency limit, not account level limit. You can have an accident, you might just forget a simple thing, and it should not cause account wide distruption.
This kind of hand-wavy futurism never quite seems to actually happen.
The pie in the sky is really just a mirage worshiped by cargo cultists. I'd much rather focus on more pragmatic and less pseudo-ideological approaches. Don't deliberately try to change the paradigm just for the sake of it; just focus on improving things that work, or finding new things that work (without preemptively patting yourself on the back and calling your solution revolutionary).
The apparent pressure to deliver a revolution seems inorganic and forced. It looks like ambition, but I think it's more like hype.
The apparent pressure to deliver a revolution seems inorganic and forced. It looks like ambition, but I think it's more like hype.
> All it’s going to take is the AI that can parse that statement and turn it into a workflow.
Or you write your own glue code. You would be surprised of how much can be done with just copy pasting and gluing code together. The interacting API's needs to be much simpler then today though. This is why I like Node.JS, here's an example:
Or you write your own glue code. You would be surprised of how much can be done with just copy pasting and gluing code together. The interacting API's needs to be much simpler then today though. This is why I like Node.JS, here's an example:
// Siri, I want to make a web photo gallery
var photoGallery = require("photo-gallery");
// Use pictures from Instagram with the hashtag #ashley30
var instagram = require("instagram");
instagram.getPictures({hashtag: "#ashley30"}, function gotPictures(err, pictures) {
if(err) throw err;
photoGallery.addPictures(pictures);
photoGallery.listen({port: 80}, function serverStarted(err, conf) {
if(err) throw err;
console.log("Photo gallery now running on port " + conf.port);
});
});Yes, imagine all my devices, home, car cell phone all sending my data back to Satya. No thanks. Microsoft doesn't even try to hide it desire to put spyware in everything. They are the spyware company now. Yes valuable insights will be found...for Microsoft and partners to pound me for money.
What makes you say that? Have you had a look at e.g. https://microsoft.com/trust ? We* are not in the business of selling your data. *I work at Microsoft
By that rationale, everyone should believe what politicians say then. I'm not saying that Microsoft is doing something "wrong" with the data they collect, the problem is the way they collect the data and their response (or lack of) in open source communities when they enable telemetry even at the language level.
Recent articles about Windows 10:
"Windows 10 is essentially spyware"
"Windows 10 is possibly the worst spyware ever made"
"Windows 10 is spying on almost everything you do"
"You still can't turn off Windows 10 built-in spyware"
"Microsoft Windows 10 has permission to spy on you"
I'm tired of this tech bullshit doublespeak. Not selling is not the same as not collecting.
"Windows 10 is possibly the worst spyware ever made"
"Windows 10 is spying on almost everything you do"
"You still can't turn off Windows 10 built-in spyware"
"Microsoft Windows 10 has permission to spy on you"
I'm tired of this tech bullshit doublespeak. Not selling is not the same as not collecting.
computers generally being able to parse complex instructios as in the example is akin to strong AI. Which is at least one or two decades way as others have commented.
HOWEVER I do share the sentiment of the autor that some Revolution is in the air and something is possible today. Maybe an assisted parser, where a human and a computer co-operate to transform the mentioned instructions into some kind of standard code.
That's why we are experimnting with the angle programming language [1] "debuggale applescript for python that actualy works".
[1] https://github.com/pannous/angle (lisp for siri)
HOWEVER I do share the sentiment of the autor that some Revolution is in the air and something is possible today. Maybe an assisted parser, where a human and a computer co-operate to transform the mentioned instructions into some kind of standard code.
That's why we are experimnting with the angle programming language [1] "debuggale applescript for python that actualy works".
[1] https://github.com/pannous/angle (lisp for siri)
Other people's servers.
1. Permissions are a nightmare. You have to give both users trying to run lambdas and the lambdas' service accounts some crazy permissions sometimes in order to get anything to work. This is especially true with a lot of the "make serverless easy!" libraries out there, which seem to want an IAM user with all sorts of access that's against our normal security policy.
2. Networking is equally nightmarish. We operate with lots of VPCs connected to on-premise hardware and network infrastructure via DirectConnects, and the only path out to the internet is through our corporate data center (again, security requirements). Most Lambda-centric tools seem not to like this arrangement, and often barf when there isn't an internet gateway attached to the VPC. Moreover, especially in development environments we use relatively small subnets, which Lambda can consume nearly instantly if a large volume of requests come through. Finally, there's some secret sauce to running Lambdas in VPCs that I still don't quite have down-it seems to only work half the time.
3. If the future of compute is serverless, then Lambda, Google Cloud Functions, and whatever half-baked monstrosity Azure has cooked up are going to have to get together and define a common runtime for these environments. I refuse to invest in serverless until I know that I can run the same code on minikube on my laptop as I can in <insert cloud provider here> because vendor lock in is real and will bite you in the ass one day.
/rant
With reference to this article specifically, please, please chop off my hands and pull out my eyeballs if cloud computing becomes yet another workflow engine. I though we killed those off in the 90s.