3 ms·
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what fra
by gt565k 11y ago
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now. If you’re Facebook, you can get away with using anything and people will still want to work for you, but most companies are not Facebook."
Ugh, I so disagree with that statement and this whole post. The company culture should be one that promotes using any technology, as long as it solves the problem. You should be hiring engineers who are comfortable picking up any language/framework, not fanboys who can only develop in X or Y.
As a start-up, you should be trying to iterate as fast as you can, not future-proofing your application. Chances are, your application will get a complete re-write once you've got enough engineers, or you're just a badass from the get-go and the code is solid all around regardless of what language or framework you used.
I can't stress this enough, but like it or not Rails (and Django) are some of the most feature complete frameworks out there. Particularly because of the ecosystem they've created and the community that supports them.
As far as remarks about Ruby or language X being slow. It really doesn't matter. The primary cause for slow applications is poor architecture and shitty code, not the speed of the language. People building one massive piece of shit monolithic application because they didn't bother to learn about microservices. Not to mention the amount of engineers who haven't gotten a clue about how to scale an application. With some proper HTTP caching and nginx to help you bypass the entire application layer, you can speed up your application by orders of magnitude.
The comment about Django being a Rails clone... wow, just wow. Although they share the Active Record design pattern for the ORM, they are vastly different.
This post makes my blood boil, because it's about language flame wars and fanboys.
- dunkelheit 11y agoI'm curious, how would microservices architecture make the application faster? In my experience monoliths are faster (but they are indeed a pain to maintain) - instead of making the rpc request with all the overhead it implies, you can just pass objects in memory directly!
- gt565k 11y agoMicroservices allow you to scale individual components of your system and reduce technical debt by isolating them. Say you have services X, Y, and Z. Service Z handles a lot of traffic and is becoming a bottleneck to the whole system. You spin up 2-3 more instances, throw a load balancer in front of them, and increase throughput, all without ever touching the rest of the system. Pretty seamless! In addition, monolithic systems tend to be a pain in the ass for release cycles. Microservices allow you to very easily bring components up and down and do zero down time deploys by using a load balancer. Using our previous example, consider doing a release 2.0 for service Y. You spin up an additional instance of service Y with version 2.0 and the old instance is running version 1.0. You take the old instance out of the load balancer and stick the new one in. With the flip of a switch, your end user ends up using version 2.0 of service Y, without ever having to bring the system down. Now obviously microservices aren't the right design decision for every application. But as your system grows and uses different components, it's usually best to separate them out as individual services so that you can scale horizontally using load balancers.
- djur 11y agoA well-optimized monolith is going to be faster, but a less monolithic codebase makes certain bad decisions much more painful. If you know you have to make an RPC call of some sort to access a given resource, you're going to be more careful in how you access it; if you don't, you're going to have unusably slow and brittle software much faster than you would in a monolith. So you end up being forced to optimize earlier, and the process of optimizing a single small component is generally simpler (you can profile just that process, for instance). That said, there's nothing keeping you from gaining many of the same benefits from a well-disciplined, modular monolith, and I think there's a pretty high risk of a fast-moving and over-stressed team (like a lot of startups) being put under more stress by the time and complexity costs of microservices, and thus making much worse decisions than they would on a monolith.
- dcre 11y agoWhen things are "a pain to maintain," code gets worse and worse over time. Performance then suffers because no one understands what's going on. In other words, I believe that in the long run, complexity is a far bigger performance risk than technical overhead like how long it takes to make a web request. It's much easier to optimize away those kinds of problems away than to make an awful codebase understandable. In practice, I see service architecture as a way of making people think harder about how different parts relate to each other.