Hey cool, you went serverless. Now you just have to worry about all those stale functions For hackers unpatched servers are the best thing since sliced bread. From Heartbleed to WannaCry, slow-to-update servers invite attackers in with a red carpet. Many of the most significant breaches were caused by unpatched servers, and analysts expect things to only get worse. Will we ever rid ourselves of the need to update …
I can't for the life of me fathom out the silver thing from Serverless. Someone somewhere has to maintain the infrastructure theses FARTS run on (Functions As a Real Time Service) exist on.
Then there are those who have been taught that any function with more than eight lines of actual code is too big and needs to be sub-functioned. I wonder what the gazillion functions in their applications run like in a serverless environment?
I am so glad that I'm out of this development makarkey. It sounds like it is all going down the buzzword pan.
Mandates such a functions being no longer than eight (or an arbitrary n) lines of actual or indeed non-actual code should be treated in the same light as not walking under ladders, or avoiding black cats.
From an engineering and support perspective, there are few things worse than oodles of trivial functions that by themselves appear to do nothing, but when carefully choregraphed together do something useful under certain circumstances. Then some idiot comes along and re-uses one of those functions in their own ball of mud to do something different.
I am so glad that I'm out of this development makarkey. It sounds like it is all going down the buzzword pan.
s/going/gone/
I'm currently planning my exit strategy - I'm fed up with the buzzword bollocks being served up by the recruiters, bean-counters and middle damagement.
..patching servers have never have really been an issue in any half decent organisation, even the likes of the NHS could do it.
It's the applications on top that break because they are either badly written, maintained, implemented, tested and on and on.
How many programmes will break if you update Java, or they are dependant on a obsolete PHP that was last updated during the 2012 Olympics.
We could tear across 3000 servers and patch them right now, but now doubt a 1/3 of them will break due the outdated crap that runs on top.
..patching servers have never have really been an issue in any half decent organisation, even the likes of the NHS could do it.
Yes, but here again we meet the real world difference between could and did.
In theory I could get Kylie Minogue in bed, but really, will I? The odds of that are magnitudes better than the odds of the NHS patching its estate. With serverless, they no longer have the opportunity to screw it up.
There are draw backs, as the author points out, but most of these are readily manageable with a credible CI/CD pipeline and capable developers.
Serverless isn't a panacea, but it is the future. It just takes too long to have a server provisioned, installed in a DC, and available to developers. Yes, that might be more a function of organisational politics than technology, but serverless drives a coach an horses through that too.
As a dev, serverless moves problems from beyond my control, to mostly under my control. And as we know, things WE can change always change faster and better than things we have to rely on others to change.
The result will be one TSB and RBS after another. This will not end well.
Those are both a result of cheap offshore developers and support staff. When you choose to offshore, you choose to have that happen. It might sound crazy to us, but that isn't a fuck up, it's a feature of their management plan.
And, to be frank, it matters not what tools, languages, or technology cheap offshorians use, they're going to give you the same piss poor result time after time after time.....
In the "serverful" world, deploying code has significant costs – you need to work harder to deploy the code (which takes time), allocate ongoing compute resources (which costs money), set up constant capacity monitoring (more time), and on top of that you need to continuously patch these servers and secure them against the bad people out there. These costs mean you only deploy code that is worth deploying, providing enough value to justify the price.
Has anyone noticed there's a word missing in there?
Data.
The servers that those allegedly all too expensive admins look after don't just keep the developers' code running, they also house the data. If, in this developer centric world, the "Ops" bit of DevOps is just seen as deploying code, then we can continue to see more and more TITSUP events resulting in data loss.
This post has been deleted by its author
"You put the code the developers write on the same system as your data"
You put the code on some 3rd party "serverless" server. Now where do you put the data? In some other location? Then you expose the data directly to the internet so the serverless server can access it. Let's think of all the ways that could go wrong.
.. "DevOps", "Serverless" is supposed to make things "easy". Usually by short-circuiting all that "hard" stuff involving procedures and testing.
Once you put proper deployment processes in place, and mandate full dependency reporting and change management, the process becomes more orderly and secure. And "harder".
Even better, the DevOps/FaaS crew usually passes of the maintenance portion to a crew of "mature" developers who suddenly have the responsibility of keeping that mess running. Meanwhile the DevOps crew crows with success and begins a new pile of hot mess never looking back at the business crushing horror they have left behind.
"[...] posting production functions straight from a hackathon, because... why not?!"
I have a reason why not. Let me get your opinion. Perhaps a reason not to do this is that no good code gets written at hackathons. Sure, they're fun. You get to play around and come up with good ideas. You get to work with people you like, and depending on who runs it, you may impress somebody and get a job out of it. But eventually, after you've gone home, fallen asleep immediately, and gotten up at 3:30 AM because that's just how things work when you just stayed up far too late, then caught up on the things you need to do, you sit down to look at the code you wrote. And most of it now has to be fixed. Features need to be made into ones that work, rather than ones that work under certain conditions and crash under others. You need to actually make good systems you had placeholders for. If you take code that you wrote at a hackathon, which is by definition first-draft, under stress from the time limit, and proof of concept, and you immediately put it into production, then you are showing me that you don't understand how the process of writing secure software works.
"Last, and potentially worst, most functions contain open-source application dependencies. These libraries are statically embedded inside the function, and so they grow stale even as new versions of the library are released to the public. Over time, vulnerabilities are discovered in these older versions, including some that are very severe, and yet nothing in the serverless flow informs you they exist."
You know? That's terrible. I think that's such a big problem that we probably want to modify the serverless system to make that not a problem anymore. Let me run this past you--how about we keep some dependencies on site so that we can update them. We could just slot in the new libraries when we have to. And we'd have to be careful to ensure that all the dependency trees work well. Actually, if only we could have a repository of code that could be updated independently of the software. Those who can't keep up with new releases could include them statically, but if you could just load them when the program starts, that'd be great. Why don't we have a command on the system that just updates the database and then downloads the new approved versions of the libraries. I have a suggestion for what we should call it. I'm thinking "pacman -Syu". Pacman stands for the Performant Agile Computing Management of Advancing Nodes, and the -Syu command stands for "see you, uberrisks". Can this suggestion be covered in the next DevOps article, please?
Sarcasm note: Obviously, I'm arguing for using a standard operating system that manages libraries automatically and can be patched easily. In case some are not familiar with the command, "pacman -Syu" is the command used to automatically update all packages on arch linux.
There's one litle thing that's been forgotten in all this - THE USER!
This cunning plan makes the user's browser almost impossible to secure, as there may be dozens (in one recent case I counted: 30) untrusted sources of fragments, every one of which is essential to the service and none of which can be verified as clean and legitimate. That's simply taking the target off the provider's back and pinning it firmly to the bum of the customer (sorry - punter).
Until we culturally return to the concept that service provision is for the benefit of the user of the service, we're going to go on passing the buck downstream, as nobody gives a 'fetid dingo's goolies'.
I generally refer to this as the sodumate society (say it slowly).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
