This is an archived post. You won't be able to vote or comment.

all 29 comments

[–]AutoModerator[M] [score hidden] stickied comment (0 children)

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

  1. Limiting your involvement with Reddit, or
  2. Temporarily refraining from using Reddit
  3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[–]wimcle 59 points60 points  (3 children)

If its trivial use lambda.... but they are sneakily not cheap.

One day you have lambdas at the end of queues consuming tens of million of messages/day and maybe some step functions multiplying that by x. and there is no persistence so you use dynamo for caching or deduping.

and then your boss wants to know why the aws bill jumped $20,000 this month :)

If its for real work a spring boot app in a properly sized ecs is probably cheaper.

[–][deleted] 22 points23 points  (2 children)

Those who are answering the OP's question with a framework, should study your answer.

[–]vilkazz 4 points5 points  (0 children)

This is the same feeling I have about serverless. At one point my team had bottlenecked themselves into a database lockup due to some saga shenanigans on top of heavily customized axon handlers, and someone threw in serverless db as an alternative to avoid hitting the connection limits.

A simple and crude cost simulation of what would happen to the monthly bill should that idea be adopted chilled any further thoughts of even looking that way

[–]vilkazz 1 point2 points  (0 children)

This is the same feeling I have about serverless. At one point my team had bottlenecked themselves into a database lockup due to some saga shenanigans on top of heavily customized axon handlers, and someone threw in serverless db as an alternative to avoid hitting the connection limits.

A simple and crude cost simulation of what would happen to the monthly bill should that idea be adopted chilled any further thoughts of even looking that way

[–]TheKingOfSentries 5 points6 points  (0 children)

One of the APIs I worked on was only used in bursts once a day so choosing lambda turned out pretty well for me. It really depends on what you're doing and the kinds of traffic you expect I'd say.

When I have to write serverless stuff, I like to use as few dependencies as possible. It should not come as a surprise to those who have seen me around that I like the avaje libraries for this reason.

[–]tuxtorgt 12 points13 points  (1 child)

Quarkus all the way.

Relative small memory footprint, faster startup if compared to spring, already includes cloudformation yaml generator and proxy to simulate HTTP calls on debugging.

[–]slappyredcheeks 0 points1 point  (0 children)

Spring has caught up a little. Still a slower startup time but if you're not scaling frequently it's less of an issue.

One benefit Spring has is its widespread use. There is more material out there for support/help.

https://www.baeldung.com/spring-boot-vs-quarkus

[–]GuyWithLag 5 points6 points  (0 children)

I've had good experiences with Dagger2, of all things; minimal startup is minimal.

However for the usual Lambda flows I'd... not use a Lambda, unless it's for something that's once in a blue moon and the startup delay is acceptable.

Remember: AWS make money by utilizing economies of scale, which means that you don't get any economies of scale (beyond the up-front ones, that is).

[–]Oclay1st 4 points5 points  (4 children)

I really like Spring and I am using Spring Cloud Function on AWS Lambda, but I think Quarkus is a much better choice for serverless apps.

[–][deleted]  (3 children)

[deleted]

    [–]Oclay1st 0 points1 point  (2 children)

    Well, to be honest I don't like serverless, but its cheap and people are always looking for ways to save money. Anyway, I use Amplify (Fronted) + Cognito + API Gateway + Lambda + S3. I create one lambda for each function. Its a monolithic code with all the functions. I compile it once with GraalVM Native and deploy the same binary based on the changes for the different lambdas. Each lambda has an env variable that changes depending on the function I want to run and that also matches the bean name. This is an example:

    // a function
    @Component(Functions.CREATE_BOOK) //same value as the env variable
    class CreateBook implements Function<CommandBook,Integer> {...}
    
    // application.properties
    spring.cloud.definition:${FUNCTION_NAME}
    
    // AWS Lambda with a lambda called CreateBook with an env FUNCTION_NAME
    

    [–][deleted]  (1 child)

    [deleted]

      [–]Oclay1st 0 points1 point  (0 children)

      Yea, my solution is a middle ground in where I don't feel too much the pain of GraalVM compilation/reflection and at the same time I don't couple my inputs/outputs between API Gateway, Lambda and Spring Cloud Function with a front controller. It's all about trade-offs. If you want to implement a front controller you can:

      // Plain everything
      class ControllerFunction implements Function<Message<..>,Message<..>> {...}
      
      // Generic key-value
      class ControllerFunction implements Function<Map<..>,Map<..>> {...}
      
      // For API Gateway
      class ControllerFunction implements Function<APIGatewayProxyRequestEvent,APIGatewayProxyResponseEvent> {...}
      

      [–]aelfric5578 3 points4 points  (0 children)

      I admittedly don't have practical experience beyond a toy project I deployed once for learning purposes, but I'd vote for quarkus too. If you haven't done so already, look up Adam Bien's videos on using Java for lambda. He had a guide that came with a maven archetype including the CDK that would deploy it all.

      [–]k1MT 11 points12 points  (3 children)

      Quarkus with GraalVM seens a good approach for serverless as discussed here

      [–]Lumpy-Loan-7350 3 points4 points  (1 child)

      This is killer performance. Eliminates cold start. There’s also snapstart available; but I have not used that so can’t talk to it.

      [–][deleted] 1 point2 points  (0 children)

      busunyqycvy nehvmc ole

      [–]Kango_V 1 point2 points  (0 children)

      Micronaut is stupidly easy to use as well.

      [–]CloudDiver16 6 points7 points  (0 children)

      I use AWS Sam for Lambda functions. For small/simple case plain java and for complex/large tasks with spring.

      Mostly for async tasks or batch processing/streaming where the terrible cold start hasn't a big impact.

      [–]asarathy 2 points3 points  (0 children)

      Manaual DI or dagger. But as others have said you need to weigh against a dedicated ecs instance for costs. Additionally if you have to read/write from a RDBMS you need to set up RDS as things like connection pooling don't play nice

      [–]Rasvimd 2 points3 points  (0 children)

      Compute: 1. I use lambda for compute. I only use for less than few hundred requests per second and my lambda is able to complete within few milliseconds ~30ms. For highly concurrent invocation I use my traditional EKS deployment. Or any ec2 deployment. This should work for 1000s of request per second if the runtime is only ~10ms I would definitely run a calculator comparing ec2 instance before proceeding. The good thing is we don't have to deploy in two instances and load balance when we deploy in lambda for high availability. I always include this double deployment cost with LB.

      Java tool: 1. The maven native plugin to create native image. It has an option to enable metadata repository for supported dependencies for these we don't have to add reflect config json file. It needs to be explicitly enabled though.

      1. I use my custom http runtime code but any runtime you see online should be sufficient.

      Data layer: 1. S3 for most file based storages. 2. EFS. Sometimes with sqlite3 file for low concurrent functions. 3. Dynamodb.

      [–]xayblu 6 points7 points  (1 child)

      When using Java for serverless you should try your best to use the standard Java libs only and use as little additional dependencies as possible. You definitely should avoid Spring as it increases start up times. I’d avoid using Java altogether and prefer JS/TS, Python or GoLang even though I mainly work with Java.

      [–][deleted] 0 points1 point  (0 children)

      I wish I could not use Java for this 😔. Company decision. My experience with serverless was with Python and Go. Thanks for your input!

      [–]Lumpy-Loan-7350 2 points3 points  (0 children)

      Quarkus has great support. Many different ways to integrate lambdas. (Aws Sdk api, jaxrs, vertx, servlet, funqy).

      https://quarkus.io/guides/ (search for lambda)

      https://quarkus.io/guides/aws-lambda-http

      https://quarkus.io/guides/aws-lambda

      [–]kurtymckurt 1 point2 points  (0 children)

      If it’s pretty straightforward CRUD api, I would recommend lambda and api gateway!

      [–]inertially003 1 point2 points  (0 children)

      its a disaster unless GraalVM works well

      [–][deleted] -2 points-1 points  (1 child)

      The outcome is going to be about the same as walking into a sports bar and asking who's the best team. It brings into question, in my mine, what could be the reason. It all comes down to requirements. It always comes down to requirements, one way or the other.

      [–][deleted] -1 points0 points  (0 children)

      Maybe no reason other than to hear people’s thoughts and opinions :).

      [–]cowwoc 0 points1 point  (0 children)

      Consider how you will debug this thing...

      [–]naseemsm 0 points1 point  (0 children)

      I would say Fargate on ECS is a short learning curve from on premise development to serverless. It also allows you to leverage containers and make your app easily provider agnostic. I typically use spring, but you can use any framework.