If you're looking for an open-source API Gateway (less lock-in) with Lambda Integration then Kong (https://github.com/Mashape/kong) could be a useful complementary tool for your serverless architecture.
Serverless Architectures
131–140 of 215 posts
Re: Serverless Architectures
#132Earlier quoted context omitted.
> If successful this could lead reduction in developers needed in companies that use say AWS lambda. How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?
> cheaper relative to hosting fees maybe Currently serverless is more expensive in the average case from what I gather, mainly since it's new and there's little competition.
If avg case is that you stay within an average load for long periods of time, then it'll likely be more expensive (given a certain floor of actual load - for in-dev apps its dirt cheap - you won't have many servers running doing nothing.
Re: Serverless Architectures
#133If you're looking for an open-source API Gateway (less lock-in) with Lambda Integration then Kong ( https://github.com/Mashape/kong ) could be a useful complementary tool for your serverless architecture.
I think you're missing the point of the 'serverless' part, as Kong still requires you to have a dedicated server to run it. One of the early stage benefits of the serverless architecture and AWS's api gateway is that you don't have to pay for resources that you don't consume - so if you've only got a small amount of customers, you don't have to pay for dedicated instances to be running.
Re: Serverless Architectures
#134For my first serverless project, I built a service that manages an advertising account, by analysing ads and optimising the spend spread for a configured goal. I was surprised to find that one of the most difficult aspects, was in throttling outgoing API requests. Basically, I needed to avoid abusing a 3rd party service by hammering it with parallel or rapid fire requests. I discovered all kinds of weird solutions: -…
> "- Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm to fire when the queue length was >= 1 for at least one second. Have a variety of lambdas respond to the alert by checking if the have any work to do, and then racing to pop the queue and do one operation. I think I needed SNS in there too, for some reason. Fanout?"
Did you want AWS Kinesis? The integration with Lambda polls the queue every few seconds and sends batches of records to a Lambda function when the queue has work to do. http://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.htm...
When you evaluate the AWS serverless platform, I recommend looking at everything that is an event source, sink, or processor: Lambda, SNS, SQS, SWF, SES, Cognito, IAM, Kinesis, IoT, API Gateway, S3, DynamoDB.
It's a pretty rich palette to work with.
Re: Serverless Architectures
#135One of the big issues here that is only very very slightly glossed over is the security you give up. The only sort of security filtering you get is AWS' WAF, which is considerably weaker than a firewall like mod_security with a default ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a tiny ruleset with only a few conditions, and outbound filtering doesn't exist at all.
This lack of firewalling continues up and down the stack. As such, it's a lot harder to create rules regarding any API calls you make to third party services, harder to audit how your app interacts with any datastores, and generally an administrative nightmare. It may be useful for some apps, but just feels like a nightmare to maintain for any decently sized setup.
Re: Serverless Architectures
#136If you're looking for an open-source API Gateway (less lock-in) with Lambda Integration then Kong ( https://github.com/Mashape/kong ) could be a useful complementary tool for your serverless architecture.
I think you're missing the point of the 'serverless' part, as Kong still requires you to have a dedicated server to run it. One of the early stage benefits of the serverless architecture and AWS's api gateway is that you don't have to pay for resources that you don't consume - so if you've only got a small amount of customers, you don't have to pay for dedicated instances to be running.
imho serverless architecture doesn't mean that your app is without servers 100%. Backend still serverless, but everything on top (like an API gateway, load balancer, service discovery, etc) can have dedicated resources.
Re: Serverless Architectures
#137So apparently "serverless" means you don't have to requisition a cloud instance to run the service. I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else. Just because you're doing something old "in the cloud" now doe…
Does it matter whether something is new or not? The fact is there are services such as AWS lambda that people are using and talking about, so we need terminology for that.
Not really, as long as it's useful. But call it what it is -- hosted services. Don't make up a new, nonsensical name.
Re: Serverless Architectures
#138Earlier quoted context omitted.
The question is how much are you willing to trade-off for the managed infrastructure benefits. The database is a level but BaaS is a totally different level. Next would be the programming language. Would you feel comfortable to base your project on a proprietary amazon programming language? (i.e See Apex of SalesForce). Maybe yes but I can't see this becoming mainstream anytime soon. It would be a backward step. I us…
But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about? For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use…
I didn't say there is a proprietary language. I just said that the current trend leeds to total lock-in. After BaaS,the programming language is the only open piece of your stack.
I hope you can see the difference between licese per core and cloud services. The cloud vendor can render your code/business useless at any time. You control nothing on your stack. Some are comfortable with that but I don't think it's a good thing for the industry or society. Proprietary software is sometimes a necessary evil but it's not really the case with BaaS. At leat not in the current form.
Re: Serverless Architectures
#139How is this different then something like Heroku and their add-on ecosystem?
Heroku gives you servers, but manages them for you - so you have long running processes, for web or worker etc. Lambda allows you to have the process run for literally the lifecycle of the job (request, streaming job etc.). In fact, your job can't run for more than a few seconds or it is terminated. Heroku charges you for the hours your dynos run - but what if they're idle most of the time? You still pay for them - not with lambda.
Re: Serverless Architectures
#140Earlier quoted context omitted.
I think you're missing the point of the 'serverless' part, as Kong still requires you to have a dedicated server to run it. One of the early stage benefits of the serverless architecture and AWS's api gateway is that you don't have to pay for resources that you don't consume - so if you've only got a small amount of customers, you don't have to pay for dedicated instances to be running.
imho serverless architecture doesn't mean that your app is without servers 100%. Backend still serverless, but everything on top (like an API gateway, load balancer, service discovery, etc) can have dedicated resources.
Fair enough - there are definitely use cases where I could see that making sense. I love the value lambda provides for early stage, when every penny counts.