• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Reply to: Serverless

Collapse

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on "Serverless"

Collapse

  • tazdevil
    replied
    Originally posted by vwdan View Post
    but the trend is moving rapidly towards more and more service lock in.
    It's the new dynamic, a way of forcing customer loyalty by locking out competitors. I'm repeatedly having issues with clients buying hosted services only to find the hosting company assumes proprietorial rights over the data and makes efficient access very difficult for other 3rd parties.

    Leave a comment:


  • vwdan
    replied
    Originally posted by DimPrawn View Post
    ^This. Current cluster**** I'm working on is implemented using all this proprietary Amazon guff. If Amazon hike the prices or pull the services, the client will be up tulip Creek without a system.
    This is where my concern comes in - cloud service providers seem willing to drop services whenever they feel like it. Yes, keeping your ancient server running in a basement isn't much better, but giving up all this control and then being forced into a corner really worries me.

    And not only that, but the trend is moving rapidly towards more and more service lock in. At least if your Azure VM gets taken away you can spin up the same stuff on another VM anywhere else. When they take away your Azure serverless service you're going to be left floundering.

    Leave a comment:


  • NigelJK
    replied
    Start learning UWP if you want to be truly serverless

    Leave a comment:


  • squarepeg
    replied
    Originally posted by Lance View Post
    That's where Microsoft beat Amazon (and Google). Azure might cost a little more but you know where the data is (roughly anyway by geographic area).
    Same with Amazon and Google cloud... you know which geo region your data sits in.

    Leave a comment:


  • Lance
    replied
    Originally posted by Mordac View Post
    I'm sort of wondering, how everyone is going to prove themselves inside EU GDPR. They don't have a fooking clue where their data is, or who is looking after it.
    That's where Microsoft beat Amazon (and Google). Azure might cost a little more but you know where the data is (roughly anyway by geographic area).

    Leave a comment:


  • Mordac
    replied
    Originally posted by DimPrawn View Post
    ^This. Current cluster**** I'm working on is implemented using all this proprietary Amazon guff. If Amazon hike the prices or pull the services, the client will be up tulip Creek without a system.
    And this: And to think, the mongs in charge of making these decisions think everything will be alright. I'm sort of wondering, how everyone is going to prove themselves inside EU GDPR. They don't have a fooking clue where their data is, or who is looking after it.

    Leave a comment:


  • DimPrawn
    replied
    Originally posted by TheGreenBastard View Post
    This line of argument is stupid; if you're using a specific instruction set, a generic runtime isn't for you; depending on the language you could always toggle syscalls / specific ASM instructions depending on architecture.

    That said... I'm not actually a big fan of serverless - from my experience with AWS Lambda you're just tying yourself into another vendor in most cases, by virtue of gluing together your Lambdas / state machines (step functions) using proprietary AWS infra - Kinesis, SQS, DynamoDB events. This stuff will be the Oracle legacy systems of the future.
    ^This. Current cluster**** I'm working on is implemented using all this proprietary Amazon guff. If Amazon hike the prices or pull the services, the client will be up tulip Creek without a system.

    Leave a comment:


  • TheGreenBastard
    replied
    Originally posted by darmstadt View Post
    The problem I see here is if my 25 lines of C# code require hardware calls then what runs on x86_64 won't run on ARM64 so I still need to know the hardware I'm running on. Maybe I'll ring up someone who hosts serverless systems and say I have some code I want to run and then try to deploy some APL, I mean it doesn't matter what hardware does it, it just deploys...
    This line of argument is stupid; if you're using a specific instruction set, a generic runtime isn't for you; depending on the language you could always toggle syscalls / specific ASM instructions depending on architecture.

    That said... I'm not actually a big fan of serverless - from my experience with AWS Lambda you're just tying yourself into another vendor in most cases, by virtue of gluing together your Lambdas / state machines (step functions) using proprietary AWS infra - Kinesis, SQS, DynamoDB events. This stuff will be the Oracle legacy systems of the future.

    Leave a comment:


  • squarepeg
    replied
    Originally posted by darmstadt View Post
    So you're still coding for a specific hardware stack which means you know the hardware so not really serverless...
    No, you are coding for a specific runtime.

    Leave a comment:


  • darmstadt
    replied
    Originally posted by squarepeg View Post
    So you're still coding for a specific hardware stack which means you know the hardware so not really serverless...

    Leave a comment:


  • squarepeg
    replied
    Originally posted by darmstadt View Post
    The problem I see here is if my 25 lines of C# code require hardware calls then what runs on x86_64 won't run on ARM64 so I still need to know the hardware I'm running on. Maybe I'll ring up someone who hosts serverless systems and say I have some code I want to run and then try to deploy some APL, I mean it doesn't matter what hardware does it, it just deploys...
    Serverless providers tell you in advance which stack and what version they support. E.g.

    https://docs.microsoft.com/en-gb/azure/azure-functions/

    https://docs.aws.amazon.com/lambda/l...-model-v2.html

    https://cloud.google.com/functions/

    Leave a comment:


  • darmstadt
    replied
    Originally posted by tomtomagain View Post

    Does it run on a server? Well it runs on a computer somewhere. But I have no idea what flavour it is. It might be Windows, it could be UNIX, it could even be some special ".NET Only Machine" I am not exposed to the server, I don't have responsibility for maintaining it. It might all be running on a single box in one of Microsoft Azure DC's, but its most likely running in some sort of distributed, highly resilient Farm. The sort of infrastructure that not even a major FTSE company can afford. Again, I don't know, and I don't care.

    I simply wrote my 25 lines of C# and deployed it.
    The problem I see here is if my 25 lines of C# code require hardware calls then what runs on x86_64 won't run on ARM64 so I still need to know the hardware I'm running on. Maybe I'll ring up someone who hosts serverless systems and say I have some code I want to run and then try to deploy some APL, I mean it doesn't matter what hardware does it, it just deploys...

    Leave a comment:


  • Mordac
    replied
    Originally posted by tomtomagain View Post
    So all companies should own their own power-supply? After all, if the leccy goes off, nothing can get done.
    And that happens almost never. And if you were at risk of such an event, you'd have a UPS backup facility, and generators etc. I've specced out several such plans, the most expensive came out at £600k, and they paid it. Grudgingly, it has to be said. Since nothing has actually gone wrong in the intervening decade, they probably think it's money down the drain, but what if something terrible happened.....?

    Leave a comment:


  • Lance
    replied
    Originally posted by tomtomagain View Post
    Then I'd need to deploy onto a VM, which gives me a hosting cost ( About £11 a month for the cheapest option in Azure ), then I've got a server to worry about .... all for a bit of useful code that runs occasionally.
    And the cheapest VMs are sloooooooooow.
    The A0 is waste of time. A1 not much better.
    A2 works as a single use, low volume server, but costs upwards of £80 a month. Which, now I've just checked and realised, is about to be downgraded to A1 until I need it.

    Leave a comment:


  • tomtomagain
    replied
    Originally posted by darmstadt View Post
    It's just another buzzword for clueless management to put into plans and reports. This came up in a webcast last year I had with a large SW/HW corporation and even the employees were laughing and there were some quite serious discussions being held about it. In the end the actual developers ignored it as regardless of whether you have the server or someone else hosts it for you, there is still going to be a server there. Management continue to use it...

    https://www.ibm.com/blogs/cloud-comp...ure-openwhisk/
    IT has been, and always will be, full of buzzwords. But I would not right-off Serverless. It's an additional deployment option and in some instances makes perfect sense. In others, it won't.

    An example of how I use it.

    My SAAS is listed in AppSource. When some when registers an interest in it Microsoft push their details into an Azure Storage Table that I own. My Azure function is notified that the table changes, reads the data, processes it. Ends.

    It's worked flawlessly for months and runs about 15 times a day. Costs a few pence a month to run.

    Does it run on a server? Well it runs on a computer somewhere. But I have no idea what flavour it is. It might be Windows, it could be UNIX, it could even be some special ".NET Only Machine" I am not exposed to the server, I don't have responsibility for maintaining it. It might all be running on a single box in one of Microsoft Azure DC's, but its most likely running in some sort of distributed, highly resilient Farm. The sort of infrastructure that not even a major FTSE company can afford. Again, I don't know, and I don't care.

    I simply wrote my 25 lines of C# and deployed it.

    Compared to the more traditional options it's trivial. I'd have to code my 25 lines as before, but then I'd need more "Fluff" around the side, maybe create a REST API, Hook up the notification handlers etc etc.

    Then I'd need to deploy onto a VM, which gives me a hosting cost ( About £11 a month for the cheapest option in Azure ), then I've got a server to worry about .... all for a bit of useful code that runs occasionally.

    What took me an around an hour to do could easily have taken a day.

    Leave a comment:

Working...
X