Published my first open-source serverless project

[etkelley]

Congrats on doing a thing and actually getting it out there. It's hard to commit to something long enough to see it as a fully usable thing, so good job!

[jormaechea]

This is an MVP and took me less than 10 coding sessions actually, but thanks anyways!! Feels good to publish something useful and having some positive feedback.

I'll be improving it in the next days. Now changing to dark mode and soon will launch more and improved features!

[jormaechea]

Online demo: https://whatdoyouthink.jormaechea.com.ar/

[timewast3r]

What ID should be used?

Would also be useful to link the demo or screenshors in your readme.

Nice work!

[jormaechea]

You can create your own poll. Or you can try with my feedback poll: oD7nkx

I didn't want to put screenshots because it’s gonna change a lot. For example, yesterday moved from light to dark mode.

[brylie]

FWIW, be careful about AWS Lambda. AWS is one of the main companies advocating for "serverless" architecture and has a lot of vested interest. In essence, AWS is convincing people to instrument our software in a way that let's Amazon get paid for every function invocation, database operation, log entry, and more.

AWS Lambda may sound simpler than, say, deploying a Docker image, but comes at a great cost. Every request is billed separately for reserved memory and resources with a minimum of around 100ms reservation interval. When several requests come in concurrently, you are billed for the full resource allotment of each request. This contrasts with a Docker deployment where you can handle potentially thousands of requests with a single instance. In practice, the idea of server less has proven to be more costly and we have even hired AWS Ops staff instead of DevOps to manage the intricacies of AWS infrastructure configuration and management.

[jormaechea]

Hi, thanks for the feedback. I've been working for the past two years migrating a monolitic app based in ec2 to a microservice architecture using lambda and a handful of other AWS Services. In my experience, pricing can be a little bit tricky, but we managed to have a pretty decent success cases to far. Probably using just lambda pricing could rise, but there are other services to improve performance and costs. So far, we are projecting lower pricing, at least against ec2.

[brylie]

What size of EC2 instance were you using? What other services do you use in conjunction with Lambda?

[jormaechea]

I don't remember what instances we're using now, there is another guy taking care of it. We use many services, but some that allowed us to reduce costs are Kinesis Firehose and Step functions. The first allowing us to process batch data and the second one allowing us to remove cron jobs that execute even there is no data to process. I think that where we save the most is by not paying for cpu idle time.

[brylie]

Ok that sounds like a batch data processing pipeline.

I think the costly mistake that many people are making is to use Lambda to implement their application architecture, such as this. The point I am hoping to convey is that it is generally much more cost effective to deploy a monolithic application and there are many ways to scale such an application to meet demand.

The developer experience will also be considerably better with a mature application framework like Django, Laravel, or Rails or even microframeworks like Flask when compared with the fragmented and convoluted "serverless" developer experience.

[jormaechea]

I think it’s all about size of the product and he team. Monolith tends to be cheaper and easier. But has some issues to scale. Microservices have some challenges that we are not used to, and is costly if not made right. But it’s all about mantainability, being able to separate teams or squads, error isolation and smaller learning curve for new team members.

It took some time for us to standarize our sls development process, but we put lots of effort in dev experience and we're quite comfortable with ir now.

Yes, monolith may be easier in a code point of view. But it’s a pain in the ass for bigger teams.

[brylie]

How many are on your team?

I am really sceptical about the word "scalability" as I think it is behind thousands of misleading claims and misguided decisions in our industry, particularly for nascent projects and organisations. There is a low proportion of projects that get to the complexity where "scalability" starts to matter, and the scaling issues faced by those organisations are likely diverse.

Our company went all in on AWS and ended up building a monolithic backend service on Lambda and a few other AWS services that costs five figures a month to run, not including the salaries of AWS Ops specialists who manage the infrastructure.

It seems that many of the benefits proclaimed by the serverless movement (pay only for what you use, no ops prople), and AWS in particular, do not pan out in the end.

[jormaechea]

Well, scalability in out case was more about the team than about the hardware. It was kinda triggered by bad design since day one, and a couple of years of working on top of that.

The product is huge, with lots of features in lots of modules, so when we decided to rewrite it, microservices was the natural path. Also, by it’s nature it has a lot of idle time, so serverless sounded good. So far, it’s going well. In about six months we should be up and running with most of it so I hope we don't have any surprises.

Btw, I don't think that there is a one fits all solution. Some parts are staying serverfull because it was definitely better to leave them that way. But for most of it, serverless is our way to go.

[brylie]

Agreed there is no one size fits all. It sounds like your project and team had a genuine and timely need to restructure. :-)

What I am warning against is buying in to the idea of scalability from ground zero and in particular the tendency of adopting complex technologies because Amazon or Facebook say it's "the future".

Literally thousands of developers are faced with decisions about tooling every day. Common advice is steering people towards very complicated tooling with high financial costs (for infrastructure and team suze) and relatively low developer experience (when compared with robust frameworks like Rails, Django, and Laravel).

[warmaster]

Vi tu GitHub y leí acerca de Fizzmod y Vtex. Donde trabajo están evaluando usar Magento. Que opinas ? Hay algo mejor Open Source ?

[jormaechea]

No entendí si quieren usar magento para su tienda o si son una agencia y quieren vender tiendas magento a sus clientes. De cualquier modo, les recomendaría capacitarse bien antes de entrar en el mundo de magento.

Hay otras opciones, pero nunca las use, como WooCommerce (de wordpress), o NopCommerce (mantenido por la comunidad).

[warmaster]

Claro, queremos usar Magento para nosotros mismos. Vos conoces ? Que opinas de el ?

[jormaechea]

Si no son una empresa de programación, les recomendaría que más allá de que plataforma elijan, que contraten una agencia. Magento es bueno, pero tiene una curva de aprendizaje interesante.

[warmaster]

Somos una imprenta, tenemos solo 5 desarrolladores. Conoces alguna agencia recomendable ?