Moving my serverless project to Ruby on Rails

by goranmoomin • 6 years ago

350 184 6 years ago

k__7• 6 years ago

Understandable.

As I wrote in my last article [0], serverless advocates pushed too much FaaS in the last years.

FaaS is awesome, but should be the last resort, if you throw too many functions at a problem you can easily end up with a distributed monolith, which is often worse than a regular one.

[0] https://dev.to/fllstck/serverless-myths-56dc

simplecto• 6 years ago

Serverless functions for a distributed monolith.

What a beautiful house of cards.

k__7• 6 years ago

Yes.

The orchestration vs choreography problem.

https://theburningmonk.com/2020/08/choreography-vs-orchestra...

Lammy• 6 years ago

I've seen a lot more discussion of Ruby recently than in past years, and maybe I'm just finding what I'm on the lookout for, but either way it makes me happy :)

joelbluminator6• 6 years ago

I think it's past the latest hate cycle to good all boring now, kinda like php but with a bit of a better rep. I'm not sure actually why php and ruby are so despised.

Nextgrid2• 6 years ago

php

I personally quit PHP around 2013 because of the inconsistent standard library. I spent more time looking up the docs than developing because the language just wasn't intuitive compared to let's say Python. However, beyond that, PHP has some pretty great frameworks nowadays (and I am forever grateful to Laravel for teaching me the concepts of an MVC framework, which proved useful when I switched to Django).

jaredcwhite2• 6 years ago

I'm a committed Rubyist but I'd jump into using PHP/Laravel in a heartbeat if I couldn't use Rails any more. It seems way more sensible and well-designed than the terrible state of affairs you find in JS backend land. (shudder!)

ksec• 6 years ago

It is a combination of factors.

It is not that Ruby suddenly popular again, the scaling issues is still there, Scaling not impossible but mostly have to do with being expensive. If you are an average dev in UK or US with 100K+ Salary of course scaling is cheap. But not everyone has that luxury or operate on the same budget. But the combination of Ruby and Rails getting faster and Hardware is finally getting cheaper. ( 128 Core EPYC, on a 2 Socket Server Changes the Unit Cost of Core per VM across the whole industry ) Along with wages rises across other part of the world.

And the world has finally woken up to may be Javascript Ecosystem isn't exactly what they have hoped for in the backend.

jspash• 6 years ago

Every time I read that one of the “downsides” of RoR is that it “doesn’t sound cool” I know I’m in the right place! I’ll have mature teammates who understand the right tool for the right job. I won’t have to work with magpie developers with an acute case of not-invented-here syndrome.

Granted Rails isn’t the answer to everything. I’ve been loving what we can accomplish with elixir/Phoenix. But I’ll leave the hipsterism to the JS community and marvel as they reinvent wheels over and over again.

rualca6• 6 years ago

(...) I’ll have mature teammates who understand the right tool for the right job. I

Honest question: what leads you to believe that Ruby on Rails, or even Ruby, is the right tool for the right job? You didn't even mentioned the job, so why do you automatically assume Ruby is the right tool?

Additionally, by ignoring popularity you're also ignoring availability of documentation and examples and mindshare. You're also ignoring experience, and prior onboarding into a language stack, which automatically means odds are anyone onboarding into the project will quickly be up and running.

Speaking as someone who was forced to onboard into a Ruby project just because a predecessor jumped on the bandwagon, the experience was an unmitigated disaster. A minor onboarding task that consisted of tweaking a hard codes settin in a module required me and a couple of colleagues to spend a few days a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with idiomatic Ruby, d) learning how to troubleshoot and debug Ruby applications, e) properly setup a software dev environment, and f) finally fix the issue.

If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.

How does can this sort of snafu pass off as the right tool for the right job?

derwiki• 6 years ago

It sounds like more than RoR. Anecdata counterpoint: I’ve worked on a few RoR projects that were well architected and only took me a few days to fully ramp up.

ysavir• 6 years ago

Sounds like this is less about whether RoR was the right tool for the job and more that no one other the implementer was familiar with Ruby/Rails (and maybe not even them).

This might mean that this wasn't the right tool _for your team_, but it's not a comment on what jobs are a good fit with RoR.

realusername• 6 years ago

If my predecessor opted to use Python instead of succumbing to bandwagons and resume-driven development practices, the same thing would take a couple of man/hours.

That's my opinion but after maintaining some large Rails apps and large Django apps, I would still take Rails any day. Just the testing quality and the batteries included makes it worth it, whereas the main downsides of Rails (speed and lack of typing) are also there anyways on a Django project.

That aside, if people building the project don't have any experience with what they are doing, it will be messy regardless of the framework or the language.

schnable• 6 years ago

If you knew Ruby and not the Python, the whole scenario would have been flipped.

rangoon6263• 6 years ago

I too have had experience after experience where every Ruby on Rails project in maintenance mode is a complete disaster.

It seems like it’s great for quickly building things, but it is unmaintainable, unless you wrote the thing. I am very flexible otherwise, but Ruby on Rails is banned from any project I’m involved in.

thinkingemote• 6 years ago

a) learning a brand new programming language, b) learning exotic frameworks, c) getting acquainted with ..language.., d) learning how to troubleshoot and debug ... applications, e) properly setup a software dev environment, and f) finally fix the issue.

Applies with every language and framework one is not familiar with.

joelbluminator6• 6 years ago

Holy crap! you were paid to work on a Rails app and you actually had to learn Ruby/Rails to get stuff done? The horror! I would seek compensation from my employer for that, not way is that legal.

Dunedan9• 6 years ago

A lambda publishes a message to SNS, another one picks it up and writes something to DynamoDB, the third one takes that new record and sends an email…

Or, you know, just do related functionality in the same AWS Lambda function. While I would probably do the sending of an e-mail asynchronously as well (as AWS Lambda function triggered by a DynamoDB stream), the indirection over SNS to write something to DynamoDB seems overly complex.

Why would you do something asynchronously with a Serverless architecture you'd do synchronously with Ruby on Rails?

[…] and random hardcoded configs in AWS console.

Just don't do that. A Serverless application will always be a pita if it relies on manual configuration. Ensure all relevant configuration is part of Infrastructure as Code (e.g. CloudFormation or Terraform).

Impossible to replicate production environment

If the project is set up properly with Infrastructure as Code replicating the production environment is as easy as it can possibly get. And because it's Serverless, if an environment isn't used, it usually doesn't even incur notable costs.

There is no silver bullet and I believe Serverless as well as other approaches have their place, but what I miss are similar posts about great experiences with Serverless applications. I for myself wouldn't want to go back and I'm really happy with the problems Serverless applications solve.

alerighi• 6 years ago

The impossible to replicate the production environment I think was referred to impossible to replicate locally, on your machine.

At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline. Having each time to upload some code to debug it is time consuming. Also you have to rely only on logs to debug, you obviously cannot use a debugger, and thus the solution is to insert a ton of print statements in the code and remove them, which is not a problem to me (I usually do that even in code that I debug locally) but the service to read these logs (ColoudWatch) is not great at all, you don't even have all your logs in one place, it's a mess.

I think serverless is overrated, sure it maybe the right tool for a simple project, but when the complexity grows it's best to use other more classical solutions.

k__7• 6 years ago

Thundra offers online and offline debugging.

Also, AWS SAM CLI allows to run things locally.

rualca6• 6 years ago

At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline.

AWS's Serverless Application Model explicitly supports local testing.

https://docs.aws.amazon.com/serverless-application-model/lat...

Which problems did you experienced?

Dunedan9• 6 years ago

I agree. Iteration speed and the ability to debug applications are the biggest downsides for me as well when developing Serverless applications.

To make debugging at least a bit easier, I prefer doing structured logging (e.g. by utilizing AWS Lambda Powertools [1]) to get the ability to query the logs efficiently with CloudWatch Insights [2]. Also AWS X-Ray [3] is really valuable to understand how a Serverless application behaves.

[1] https://github.com/awslabs/aws-lambda-powertools-python

[2] https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Ana...

[3] https://aws.amazon.com/xray/

ed25519FUUU• 6 years ago

At my job I use AWS serverless services and I get a lot of frustration not being able to test and debug code offline.

For my purposes debugging is as simple as crafting a payload and feeding it through the handler locally. I match credentials locally with what my lambda runs as. Since it’s a monolith function it behaves basically the same way, including the usage of a debugger.

To make life a little easier any time there’s an exception it persists that ordinal payload so I can just replay it locally.

But I agree that serverless is mostly overrated for most use cases.

neurostimulant3• 6 years ago

Ugh, I rewrote my serverless service for exactly these reasons. It felt magical the first time where you can deploy a service without spinning up a server so I put up with all these annoyances. But then docker gains popularity and suddenly there is no practical advantage in using serverless anymore, at least for me. I rewrote the service in django, packaged it as a docker image, then run it on any platform that can run docker.

On the other hand, I use cloudflare worker on a bunch of my projects. Unlike aws serverless, cloudflare worker is actually useful because it can do many things that can't be done by traditional backend, such as running and intercepting requests on the edge servers that sit between your server and your visitors.

zerubeus4• 6 years ago

I think you never heard about SAM/Serverless Framework, this is why you suffer.

claudiusd• 6 years ago

Completely agree. Most of the criticism I've seen comes from people who don't have a good grasp of the platform or tools, or haven't adapted their style to the "serverless mindset".

There's definitely a new technique I've had to teach myself in order to build serverless systems effectively. Today I'm getting great results from the approach.

Dunedan9• 6 years ago

Yes, absolutely. And to be honest to get started with it for a software developer which doesn't have any "cloud" experience is pretty rough. Suddenly that developer needs to have a understanding of AWS in general, IAM, CloudFormation and all the services which can be utilized to avoid having to write custom code. It's a steep and long learning curve.

zerubeus4• 6 years ago

I'm just really sad reading all this comments, knowing that some people will take the decision based on them, PLEASE DON'T, most of the commenters have no idea about what they are talking about.

sheeshkebab• 6 years ago

If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA.

There might be no “silver bullet”, but aws serverless is like rusted bucket.

Dunedan9• 6 years ago

If you ever dealt with cloudformation you’d know it’s absolutely enormous PITA.

Is it? For me it's working fine.

What problems are you facing when writing CloudFormation templates and what better alternative to declare infrastructure do you suggest?

Most problems I see are people being not aware of the possible attributes of resources or doing indentation mistakes when it's a YAML template. Most of these problems can be avoided by using cfn-lint [1] to ensure the template is valid.

[1] https://github.com/aws-cloudformation/cfn-python-lint

mxz3000• 6 years ago

Totally, cloudformation is terrible and verbose. [Cloud Development Kit](https://aws.amazon.com/cdk/) however, is superb.

nitrogen3• 6 years ago

One of AWS's major flaws is that it provides an encouraging UI that almost begs new teams to create a special snowflake manual configuration.

The AWS UI should ideally be refactored to be a frontend for an infrastructure as code service like CloudFormation.

One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.

hodgesrm• 6 years ago

Why wouldn't Terraform be sufficient? I use Terraform to manage real deployments, but the UI is very useful to scan the environment. This is partly because the aws-cli is so awful^h^h^h^h^h hard to use as an interactive tool.

Dunedan9• 6 years ago

I like that AWS offers the management console. It can be great for quick prototyping and checking out new services where you don't know yet what to expect. An absolute no-go however is that the management console sometimes uses functionality which isn't available as an official API! One of the most prominent examples for that is probably that the management console does support U2F tokens, while the official API doesn't [1].

CloudFormation lagging behind in terms of features is mainly a matter of priorities and I agree, feature parity from day 1 on would be great. However the way they do it allows them to ship features more quickly, so that's something as well.

In the past CloudFormation support was even worse as the CloudFormation team was responsible for implementing the support for new features of all services in CloudFormation. And with an ever growing list of services and features, that was something which simply didn't scale. From my understanding that changed however, so that most service teams are now responsible for CloudFormation support of their service themselves.

One of the other problems with AWS+CF though is that it doesn't support every option from every service, e.g. populating secrets was a hassle when I used it.

That's because creating a secret in AWS Secrets Manager is not a control plane operation (which is what CloudFormation usually implements), but a data plane operation (which CloudFormation usually doesn't implement). However in this particular case it has been apparently painful enough, as creating secrets can be necessary to be able to deploy other resources (e.g. for authentication to the Aurora Data API), that AWS implemented this data plane operation in CloudFormation [2]. The same is true for creating parameters in the SSM Parameter Store [3], while it's still not possible to create objects in S3 or items in DynamoDB without custom CloudFormation resources.

[1] https://github.com/aws/aws-cli/issues/3607

[2] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

[3] https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui...

dkobia• 6 years ago

You can have the best of both worlds with Ruby Jets https://rubyonjets.com/. Build micro services inside of a monolith. Might not make sense, but you're essentially building one app that deploys to micro services in AWS, in your favorite language and a framework that is essentially Rails.

nobody0• 6 years ago

X as a service seems easier at first because complexity is hidden, but it's not going away.

Old boring stacks can still go a long way for small/medium projects.

mt42or• 6 years ago

"You don't need serverless"

knodi2• 6 years ago

Serverless for web apps have one big issues. The cold starts of lambda(s) can be over .5-1 seconds at peek times (us-east-1) any way.

k__7• 6 years ago

Thete are multiple solutions to that problem.

1. API Gateway and AppSync integrate directly with many other AWS services, no Lambdas needed, and thus no cold-starts.

2. Lambda has provisioned capacity.

3. Other cloud providers like Cloudflare offer FaaS without cold-starts.

ricketycricket3• 6 years ago

2. Lambda has provisioned capacity.

I know little about lambda. Provisioned capacity, as in an instance running 24/7? Like a server?

knodi2• 6 years ago

Yes and all of them are bad

thismodernlife• 6 years ago

I have no strong opinion on serverless but I’ve used Rails for 13 years now (in massive $multi-million SaaS products as well as hobby projects) and it still makes me happy. I keep thinking about learning Node and React but I just can’t be bothered because Rails lets me get things done so quickly while also being a joy to write Ruby and Rspec.

Regarding hosting, I think this is actually a great time to host Rails apps either via Heroku, via the new Digital Ocean k8s app cluster or – and this is my new favourite tool – using Hatchbox.io to deploy apps to Digital Ocean or AWS. It’s a dream!

luxurytent• 6 years ago

Replace Rails with Django and this comment seems to hold true for many in the Django community. Boring can be good.

sodapopcan4• 6 years ago

Boring tech is great if your primary concern is writing business logic. Ideally, this should always be true, but of course the reality is that people's jobs often have them working on products they don't really care for. And of course, it's easy to get distracted by tech anyway. Experience also comes into play when it comes to loving "boring" tech—it took my around a decade before I was sufficiently jaded that almost all I want to do is write actual business logic. I still love refactoring, though :)

xwdv• 6 years ago

All you need is one weekend to really learn a useful amount of Node and React. You can’t spare it?

nickthemagicman2• 6 years ago

I personally like Ruby better than Node and Svelte better than React.

So that weekend could rabbit hole into complexity figuring out which framework to use.

sodapopcan4• 6 years ago

Why bother? I work on a very UI-heavy interactive app (it's a gantt chart) for work and therefore have been doing react daily for 1.5 years. React is probably making life a little easier here, and I don't hate it, but I don't love it either. If I didn't love my team so much I would be looking for a job working on a more classic web app in Rails. And when I profess my appreciation for Rails, I could just as easily be talking about Django, Phoenix, or any other _opinionated_ backend framework. [edited for spelling]

neurostimulant3• 6 years ago

What's the benefit of moving from Rails to Node and React productivity-wise? On the backend side, Rails comes with an ORM, authentication, templating system and many more out of the box, while on Node you'll need to mix and match a bunch of 3rd party libs or roll your own, which might be a good thing depending on your priorities but certainly kills productivity. On the frontend side, you can always use react with rails backend, but developing traditional template-based ui is usually faster than developing a react app and you can take advantage of rails templating/rendering feature to speed up development.

ricketycricket3• 6 years ago

They work at Facebook on react native. I’m guessing they know react.

ffdjjjffjj• 6 years ago

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#.

I wanna say something nice about rails too so I’ll say I have never seen a team so quickly deliver high quality web app features than a well oiled rails team. It’s something to behold.

erikrothoff4• 6 years ago

Curious what part of Rails you didn’t find scalable? Our Rails frontend servers run on cheap VMs that are easily scaled horizontally.

dwheeler• 6 years ago

Have you used fragment caching (in "Russian Doll" style)? In my experience, that's the key to making Rails applications fast. Ruby is slow, so there are definitely situations where it's not a good choice, but in many "basic applications" caching makes that irrelevant. Language speed is irrelevant when you don't run much code :-).

prh8• 6 years ago

CPU load being the ceiling in Rails is typically the sign of sloppy development. Most well done apps it will be the database.

dasil003• 6 years ago

This very much depends on the use case. If you are truly CPU-bound than yes, ruby is a bad choice. Similarly, if you are IO-bound or otherwise need a lot of concurrency ruby is not great. I also think it's problematic for large code bases with hundreds of developers. However, there is a huge swath of web apps and APIs that just need to pull a bit of data from a DB or two, munge it together and send it to the client. Rails is perfectly horizontally scalable and plenty fast for this even at scale given Amdahl's law.

That said, there are definitely some self-inflicted wounds people run into here. Of course there are the oft-cited expert beginner problems like n+1 queries and missing indices, but there's a more subtle issue as well: ActiveRecord itself is so convenient that it discourages writing baseline efficient code even when you need it. Basically any time you need to process a medium to large amount of data, ActiveRecord acts like a sort of super boxed type (to use Java terminology) adding a huge amount of overhead. Yes it's true that ruby doesn't even have true primitive types that can achieve the performance of Go or Java, but often times ruby primitives are plenty fast, you just have to be willing to write a bit of extra code, and ActiveRecord as an ORM has plenty of escape hatches at various levels of granularity to facilitate this (eg. pluck, find_by_sql, update_all, execute, etc).

stanislavb• 6 years ago

"the simple fact that Ruby is really, really slow"... it's that slow that Shopify and Stripe don't mind building their global scale products in Ruby.

adrianpike• 6 years ago

Would love to hear what you're doing that's got Ruby pegging the CPU. I've ran a few rather large Rails deployments over the years and it's rare to crush the app tier first, so I wonder if there's something unique here that we can make Rails better at.

joshmn2• 6 years ago

Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen.

I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pitfalls are things like this:

  Tag.all.map(&:name)

versus

  Tag.all.pluck(:name)

Using `#map` will instantiate a `Tag` object and do all the slow(er) metaprogramming to get you the syntactic sugar that makes interacting with an ActiveRecord object a treat. It does this, and then you only hit `#name`, completely wasting all that effort.

`#pluck` will change the SQL from `select * from tags` to `select tags.name from tags` and never instantiate a `Tag` object, instead short-circuiting and directly fetching the resulting SQL rows — which comes back as an array. It's something along the lines of:

  ActiveRecord::Base.connection.exec_query(Tag.select(:id).to_sql)

Another one I see:

  ProgrammingLanguage.where(tag_id: @user.tags.select(&:language_tag?).map(&:id))

versus

  ProgrammingLanguage.where(tag_id: @user.tags.select(:id).where(type: 'LanguageTag'))

The first example loops over the loaded `@user.tags`, loads them if they're not already `#loaded?`, selects ones that are `type == 'LanguageTag'`, only to grab the `#id`.

The second example joins the two resulting SQL statements and calls `#to_sql` on the second statement, building one query from two queries.

Are these times when the first example would be preferred? Yeah, plenty! If your result is already `#loaded?`, then you probably don't need to hit the database again. But for this example and the ones I'm stumbling across while getting our company up-to-speed on "good ways", these are the the commonalities.

Save for only very recently, the company I work for hasn't put emphasis on real-world Ruby/Rails skills, instead "if you can code at a high level for any language, we think you can make reasonable contributions to our codebase." This has lead to hiring skilled developers that just don't know that there's a more preferred way of doing things in Rails for different contexts.

Double-edged sword, really.

cpursley• 6 years ago

Elixir (with Phoenix) really is the sweet-spot for a productive framework that's fast, scalable and easy to pick up for a Rails developer:

https://medium.com/coryodaniel/from-erverless-to-elixir-4875...

freedomben3• 6 years ago

Second this. I did rails for years and liked it a lot, but there were pain points, particularly as a project scaled.

Elixir/Phoenix solves a lot of these pain points and is a joy to work with. If you like Ruby/Rails then you already know quite a bit of Phoenix. Schedule yourself 4 hours to follow a tutorial or book.

WJW• 6 years ago

Isn't normal Rails the fast, scalable and easy to pick up framework for a Rails developer? Elixir has hype factor, but it still lacks the library ecosystem of Ruby. It's entirely possible to get to github scale with just Ruby and not have to learn all the gotchas of BEAM and OTP.

unixhero• 6 years ago

I am not a good programmer. Every time I try to learn a language I end up down rabbit holes and always end up yak shaving.

Whenever I take the plunge I am always reassured; Ruby and Rails does make me happy.

faizshah• 6 years ago

Is there a good way to turn your rails app into a mobile app these days? I remember seeing something from turbolinks showing a way to make hybrid mobile apps using turbolinks.

julianrubisch• 6 years ago

Yep, turbolinks. We’re all waiting for TL6 though to revive the android adapter.

tomerbd• 6 years ago

Spring + Thymeleaf is also great it's practically Ruby on Rails for Java developers.

arcturus17• 6 years ago

Having learned web dev around five years to go, my main stack has been Node/Express or Firebase (serverless) with React front-ends.

However, I got tired of the lack in conventions in Express, and Firebase has quite a few gotchas and limitations, so I'm moving to good old Django. I'm delighted thus far, I love not having to reinvent the wheel every time I start a project or add a feature.

I'm probably keeping React/Next.js as my primary working tools for the front-end nonetheless, but that's just me because I feel highly productive with them and I've become accustomed to the decoupled client/API architecture.

I can see the merits of SSR with templating as seen in RoR or Python, and I'm happy to have that tool in my belt. But conversely I also think it's worth for pretty much everyone to learn React (or Vue, Svelte, or what have you) because they do open different possibilities in UX engineering and app architecture, and the market is quite hot for them too.

nickthemagicman2• 6 years ago

I do know what OP means.

Aren't there any good serverless frameworks that simplify this complexity?

ignoramous• 6 years ago

Serverless has its place. I am not sure if I'd chose to build a shopping cart on Serverless just yet (Next.js' recent forays notwithstanding), but for something that is stateless (like content distribution, capturing metrics and logs, serving static webpages)...oh, is it a breeze.

That said, I see many promising upstarts and incumbents in the space trying to make stateful Serverless easier by the day. Things can only improve and improve they will. I'm bullish.

troughway• 6 years ago

I'm looking at Blazor/wasm nowadays and it's causing me an awful lot of nostalgia when I think back to the early days of Rails (if '08 can be called early days per-se), because of the shit show back then with various tech stacks and the grunt work required to get a site up with some DB backed data source and whatnot.

And I feel like today we are back to some kind of a point of having to shoehorn FE/BE tech together unless we use some isomorphic approach which, predominantly, forces the use of JS.

And I remember DHH commenting on this regarding Java and saying something to the tune of "Why would I write Java when Ruby is so much better?". Back then I thought such a statement was too indignant, like someone getting on their high horse about a particular kind of building material that is better above all else. But nowadays, I see the wisdom behind it all the same.

I just want simple bloody tech that treats the browser as a layout and input handling engine and lets me write code in any language I see fit, whether it's Ruby, F#, C#, Clojure, whatever. I'm hoping Blazor or something like it can deliver on that vision.

hu3• 6 years ago

Server side Blazor is promissing to me. Simpler development by merging frontend and backend into one C# codebase but might not work well on unstable connections due to websockets. Some of my clients fall into this case.

I'm keeping a close eye on it. I also need to test how it scales with regards to handling traffic.

polote• 6 years ago

Lambda is a product for big non agile companies who want to show they can be agile.

If you are a single developer there are barely any reason to use it

leptons• 6 years ago

I'm a single developer and I'm glad I chose serverless for my project. I never have to worry about scale, and for a single developer that's important, as there aren't 10 other developers to leverage when scale becomes an issue after the fact.

I also don't have to pay for what I'm not using, also important for a single developer. If I had chosen a more traditional approach of using EC2 to host a server, I would be paying quite a lot more for my project to sit idle on an EC2 instance 24/7/365 if I'm not getting enough traffic to support paying for the idle server.

0x445442• 6 years ago

Having worked with AWS serverless for a couple of years, I think the architecture is not well suited for replacing a monolithic application. If horizontal scaling is an issue, I think containers are better suited. Serverless seems to be a better fit for ETL/Data Transformation workflows.

ledauphin• 6 years ago

serverless (well, lambdas) would be very expensive for any truly significant ETL work. if you have long-running jobs of any kind, that's precisely the opposite of where serverless shines.

VWWHFSfQ2• 6 years ago

I pretty much just start all of my projects, no matter how small, with Django. Working with microframeworks or serverless is great at first but as soon as you need any more of the typical features that a webapp requires then you start pulling in dependencies or re-implementing half of Django yourself anyway. First you just need a little url router to some basic views. OK that's great, anything can do that. Now you need to validate some forms. Now you need to manage some session cookies. Now you need to let users reset their passwords. Now you need to look at your data and maybe export a csv. It just goes on and on.

rangoon6263• 6 years ago

What you wrote about is something that I really struggled with wrt serverless when I first started learning it. Lambda, at this point, feels to me like doing a php project without using any framework. You are doing it all yourself, all the tedious stuff.

I have started to mix Zappa and Django to get the best of both Django and Serverless. So far, I like it. I have not hit any considerable scale yet, so I wonder if Django is too heavy, or just right. It seems fine so far. The other plus - it’s all open source tech, so it’s easy to move away from Lambda if I need to.

It’s even better, too, because you CAN break out some more isolated functionality into stand alone lambdas when they start to get clumsy inside a typical Django proj.

rkangel3• 6 years ago

For people in a similar situation, I'd strongly suggest giving Phoenix (on Elixir) a look. It's a "boring" Rails style server side rendered web framework, but with a few extra powers:

* Elixir is a great functional programming language

* When your backend needs to do more complex or longer running work it's just more Elixir rather than complicated architecture involving task queues etc. (because you have the concurrency of the BEAM to manage it)

* You have options like LiveView for your frontend. You don't have to use it, but it's there.

I agree with what you said about testability for Lambda style architectures. How do you spin up an offline version of some or all of that to see if it works? The BEAM world is nice for me because you can run a similar architecture of separate things (albeit all in one language), but have a much better testing setup.

bdcravens• 6 years ago

You have options like LiveView for your frontend

Worth noting Stimulus Reflex uses the same approach as LiveView (most stacks have similar options)

rkangel3• 6 years ago

The Phoenix framework was created by Chris McCord. He was a long time Rails developer who tried to create a LiveView equivalent in Ruby/Rails but concluded that the concurrency capabilities just resulted in too many edge cases that didn't work well. That process led to him working more with Erlang and Elixir, then creating Phoenix.

I have never used Stimulus or Stimulus Reflex, but based on his output Chris is a smart guy and an excellent developer who's opinion I therefore give some weight to.

heipei• 6 years ago

I'm curious, and I know this is a random thread to post this question, but how do you handle the fact that the Elixir process might be shut down with regards to necessary persistence of any message queues? Put differently: I consider both message queues and databases in my system to be part of the stateful workloads and the web app part of the stateless workloads (can-be-killed-at-any-time). How do you handle the case where your stateful workload (queueing) now lives within your Elixir process which might be killed at any instance?

jgautsch• 6 years ago

You can add a kill/shutdown message handler and move your state somewhere else before the process dies.

rkangel3• 6 years ago

The terminology is a bit ambiguous here with the word 'process' so I'm not 100% sure precisely what you're asking. The BEAM (Elixir VM) uses the the term 'process' to describe its green threads/fibres. The BEAM runs as one OS process, with a thread per core of your machine and schedules each of the application green threads onto one of those threads. BEAM processes are cheap and quick to create and come and go regularly. The BEAM itself is very stable and will stay up permanently (potentially even through SW upgrade if you want). Whenever I say process below I mean a BEAM process.

When you use Phoenix, the Web framework creates a process to handle the specific request. By default everything you do happens in that process (give or take some database stuff). If you make a programming error that process will 'crash' (again a BEAM term that is more like an exception) and the user will get an error. No other processes will be affected, regardless of whether they are to do with other requests or anything else.

If you want a work queue, you would create a separate set of BEAM processes (or maybe just one), probably at startup. In your request handling you would send a message to that work queue process asking it to do things. Your request can block (not affecting any other requests) waiting for it if necessary, or it can return so you can get the result later. If the Web request times out or crashes or whatever, that will kill the handler process, but will leave the work queue process alone.

One other note - under the hood it's all message passing between processes, but to the programmer each process is probably just a Gen Server (an abstraction) and the message send and reply is just a function call. But normal Phoenix stuff doesn't even have that because the Web server does the 'process machinery' for handling requests.

bostonvaulter2• 6 years ago

If you want a persistent task queue in Elixir then I would use a library like oban [1] that uses postgres to manage the jobs, a nice benefit of it is that you can enqueue your jobs as part of a database transaction (and Ecto.Multi gives you a nice interface to transactions). And just because you can have a message queue directly inside your application server doesn't mean you need to or that it's a good fit for every project.

1. https://github.com/sorentwo/oban

namelosw• 6 years ago

Kill at any time is dangerous for stateful Erlang / Elixir workloads. But there are several patterns:

1. Some process group libraries can handle graceful shutdown, which migrates the processes to other nodes. When you kill one of the nodes, it's process goes to other nodes in like tens of seconds.

2. Invent some virtual actor pattern like Microsoft Orleans.

3. Just backup processes states to external storage. Even not for shutting down nodes scenarios, people still tend to backup process state to ETS or stateful processes so that stateless processes can crash-then-revive without troubles.

sam0x173• 6 years ago

For those in this predicament, consider mine -- I'm about to migrate a non-serverless collection of nodejs microservices to Rails via Ruby on Jets, which apparently has full support for running standard Rails apps these days. I can't imagine something more powerful than a Rails app running in a Lambda.

sam0x173• 6 years ago

Also consider giving Crystal lang a look, in particular the Amber and Lucky web frameworks. Amber in particular is designed to feel just like Rails and accomplishes that pretty well in my opinion.

Crystal is designed to feel like Ruby but to be "fast like C". I think in reality by adding a type system it manages to be better than Ruby.

Small but very welcoming community with a number of startups and companies running things in production. Crystal itself is doing well with the 1.0 release looming very soon.

freedomben3• 6 years ago

I jumped on Crystal early and had significant pain, even just building hello worlds. After too much wasted effort I decided to punt and return at 1.0

Has Crystal stabilized?

Can_Not• 6 years ago

I've used crystal (mostly kemal) for almost 1 year and the updates have not been too often and have not broken much.

sam0x173• 6 years ago

Crystal itself has stabilized quite nicely. Amber/lucky are a bit slow to update, but all of my production apps use either Kemal or Spider Gazelle which are too lightweight to matter in that regard.

cayblood• 6 years ago

Did you consider Step Functions for taming some of this complexity?

nickjj• 6 years ago

I've been tinkering with Serverless (on AWS) for some client work recently and my view is about the same as this post. Every complaint he listed is what I encountered too. It's one of the most unfriendly dev experiences I've seen in ~20 years of development.

OP's post contains:

What started as a simple function, grew into a bunch of serverless functions, SNS topics, S3 buckets, DynamoDB tables. All bound together with plenty of YAML glue, schema-less JSON objects passed around and random hardcoded configs in AWS console.

With SAM, it's still a ton of boilerplate too.

And honestly, even most simple functions are going to use SNS topics, S3 buckets and CloudWatch so you can see your logs. Probably a datastore too. Or if you want to access the Lambda over HTTP instead of an SNS trigger, then you'll need something like API gateway or a load balancer too.

It's even more fun if you decide to write to an RDS instance that's locked down by IP address and inside of a VPC while at the same time your Lambda needs external internet access. The amount of hoop jumping to get all of that to work was unreal. And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services.

The infrastructure complexity was more than anything I've ever experienced in any tech stack. But I thought the goal of Serverless was to avoid infrastructure?

Then there's the whole problem of wanting to wire up your main non-serverless service wanting to trigger a Lambda using SNS topics. That's fine until you want to be able to develop the project locally, except SAM and other comparable tools don't mock out SNS. So now you're stuck either having to pay to have your dev environment running on AWS or set up something like localstack to mock out a bunch of AWS services (which isn't free either btw).

The messed up thing is, after all that, it was to be able to run about 20 lines of Python business logic. All it did was call out to a 3rd party API service and store the results into a database.

helsontaveras18• 6 years ago

Whenever I see Medium articles of insane serverless architectures used at the startup stage, my stomach drops. Serverless computing isn’t about fast iteration (for CRUD app development) or even “pay for what you use” (for CRUD app development).

Serverless is typically hard to setup and hard to iterate upon. You want to have a pretty clear understanding of the specific use case you’re addressing beforehand so you can architect the system well, which isn’t easy for a solo developer / small team who just wants to setup a little function in the cloud.

Actually, the best use case for serverless is: - subscription to AWS specific events. It’s all built in and easy to plug into. - elastic ETL pipelines. This is a very enterprise focused use case which involves processing GBs/TBs of data with complex transformations. The variability in data throughput makes serverless an elegant solution. Also, your ETL pipeline isn’t going to change in the same way that a product focused use case of serverless will change.

vikingcaffiene• 6 years ago

I recently migrated part of a platform over to a distributed architecture with a heavy reliance on serverless functions. We had very specific reasons for doing it that I wont get into, but I can confirm that its an unbelievably bad experience from a development standpoint. We tried all the usual tools like localstack and SAM local and it all just suuuuucked. Something that would have been a day or twos worth of work with a tranditional api endpoint would stretch out to weeks. We ended up getting fed up and put all the calls to our serverless functions behind interfaces. Then, when running locally, we swapped out the transport layer to call a simple webserver that can call the the functions directly. We've been leveraging that approach for a few months now and its smoothed out a lot of issues for us. The downside of course is that you aren't using the same networking as whats deployed but so far it hasn't been as much of a problem as I was afraid it would be and our velocity has increased quite a bit.

I would go as far as to say the unfriendly local dev experience is almost the point. They want to lock you into having to use their platform to get anything done. They want to make this stuff as difficult to abstract as possible. They want you to use their proprietary methods for code sharing (looking at you lambda layers...). All of it is designed so that you simply can't run your logic without tying yourself inextricably to their platform. It's a spiderweb that you don't notice until you are trapped in it.

earthboundkid3• 6 years ago

Someone needs to rewrite the old “SOAP is simple” article to be about “serverless.”

theshrike79• 6 years ago

And it ended up costing $33 / month just to have a NAT set up to route all of the internet traffic between these services.

Yep, this matches my experiences with AWS too.

The stuff that you THINK might cost an arm and a leg, are actually really cheap. Billions of lambda calls with thousands running concurrently? meh. Huge SNS/SQS-queues? Meh. Terabytes of data stored in S3? A drop in the bucket.

BUT.

Too many PUT-operations on S3? $$$$$expensive$$$$$ Too much IO on an Aurora instance? Pucker up! Need some sane network configuration? Prepare to pay up the wazoo for gateways.

Yes, all that can be worked around, but it's really non-intuitive to actually see where the pain points in a project will eventually be.

grose• 6 years ago

I like using the “serverless monolith” architecture. You use a catch-all API gateway hooked up to a single lambda. You write it the same as any standard HTTP server and let an adapter handle the lambda bits[1]. During development you run it as a regular HTTP server and connect directly to localhost. To deploy it all you need is a shell script that zips and uploads your binary to lambda. All state is stored in DynamoDB. One log stream for everything.

The downside is dealing with AWS events. There’s a few ways to handle it. You can write it into your monolith, toggling behavior with say an environment variable. You can sometimes work around it, for example avoiding the S3 file uploaded event by having clients ping your HTTP API on upload completion. Of course, there are trade offs for all the techniques. You can easily reconfigure a lambda to retry on failure but you’d have to manually implement that client-side. You can also always just add another lambda if you’re ready.

To put it another way: you probably don’t need to write that record to a queue which gets written to DynamoDB, whose stream calls another lambda etc etc. Just do that stuff within a regular old HTTP handler until the fanciness is absolutely necessary.

For personal projects, I appreciate how serverless scales to zero. I don’t have to worry about axing projects with minimal usage.

[1] for example https://github.com/akrylysov/algnhsa or https://github.com/awslabs/aws-lambda-go-api-proxy

earthboundkid3• 6 years ago

This is what I’ve been doing with Go on Netlify (which is a wrapper around AWS Lambda). https://blog.carlmjohnson.net/post/2020/how-to-host-golang-o...

alexellisuk• 6 years ago

How are you finding managing infra for rails? Is disaster recovery quick for you?

I'm the author of openfaas and hear what you say about the fragmentation for using AWS Lambda. We recently made a rails-esq version of OpenFaaS for users who have a single small app like yourself. I would be interested in your impressions. It's all open source and is a bit more of a more modern stack. On the upside it uses containers and you can write in any language.

https://www.openfaas.com/blog/faasd-tls-terraform/

weeboid• 6 years ago

One thing you have to realize, is that "enterprise" architectures are as much about workforce management as they are about efficiency, or scalability, or et al.

There's a limit to how reduced data, and functions that work on data, and the transports and relationships between it all, can get. Let's call this residual mass "goo". Well, the goo has to go _somewhere_.

g8oz• 6 years ago

Has anyone tried TruffleRuby in a project yet?

desireco42• 6 years ago

I moved to Phoenix and it is wonderful. Except... Ecto just isn't as easy as ActiveRecord and you can't do things the way you would prototype things in IRB. So, yeah, on one hand, I have crazy performance and LiveView etc, but on other, it is huge hassle just to hack around the way I did before.

techthumb• 6 years ago

In OO systems, we often talk about "Simple Objects & Complex Interactions" v/s "Complex Objects & Simple Interactions".

In my experience, being at either extreme becomes counter-productive.

To me, it comes down to finding the "happy middle" for your project.

Monolith v/s Micro-services/Serverless are similar. Neither extreme is productive. There exists a happy middle depending on the situation.

akhilcacharya• 6 years ago

Seems to me that the ideal would be a heavier-weight convention-over-configuration framework that "compiles down" to Cloudformation + Lambda code.

liquidwax• 6 years ago

AWS Amplify[1] actually has neat tooling for serverless projects and lets to deal with just the core of your product and worry less about infra. Admittedly, it helps if you know the underlying connections but in my experience that's true with rails too. Building a blog with rails isn't the same as a more complex product.

[1] https://aws.amazon.com/amplify/

helsinkiandrew• 6 years ago

I’m not sure the issues experienced are due to serverless rather than the architecture chosen. A monolithic app vs services.

Why split up the serverless functionality into separate functions connected with SNS etc? You can call the same ruby code from a single serverless lambda endpoint invoked from a http call in the same way you would from a rails process.

Rails is great, but you could run Rails on a serverless architecture (AWS) too if you really wanted to, and you could create a multi service architecture of Rails components that would be equally hard to maintain and develop.

ptman• 6 years ago

You could probably deploy your RoR service using Google Cloud Run.

Moving my serverless project to Ruby on Rails

Related Stories