5 ms·
Nothing wrong with using Ruby, but if this is a justification build something that doesn't scale you're incredibly wrong and complacent. Scale creeps and when i
by Sparkyte 4y ago
Nothing wrong with using Ruby, but if this is a justification build something that doesn't scale you're incredibly wrong and complacent. Scale creeps and when it creeps it quickly takes over. You should always build infrastructure with scalability in mind from day 1. If you're writing in Ruby it shouldn't matter if you container it, but what surrounds that application is what matters. It also matters if you build a monolith or not.
- mmcnl 4y agoAre you sure there is no survivorship bias at play here? I've seen more projects fail due to overengineering for future scenarios that never materialized than due to lack of scalability.
- rawoke083600 4y agoExactly!
- Sparkyte 4y agoUm what are you smoking?
- rawoke083600 4y agoDefinitely not "unfiltered scalability day one" cigars
- Sparkyte 4y agoIf you think about planning scalability as over engineering you're greatly mistaken. Probably also a terrible engineer. In fact you are likely to save money with a scalable solution. Because if a particular load is not required and it scales back as well as out with limits it prevents an over exertion of budget.
- kaliszad 4y agoNormal VPSes and other relevant offerings are pretty cheap these days if you don't consider one of the big three clouds. They will cover most use cases and loads just fine for a long time also and there are practically no autoscaling issues, budget overruns etc. You could of course show some concrete examples from you experience. In my experience, you save the most time and money when you work with a solution that is less dynamic and more general purpose, like a VPS instead of specific scalable services without fixed price. Also, it is quite easy to switch providers with a VPS. With specific scalable services less so.
- Sparkyte 4y agoVPS hosting kubernetes totally fine. VPS that is just a few static sized nodes problematic. Lets say a node fails over dies kaput. In a proper scalable solution the service would come back almost instantly. You have some sort golden ami and leverage containers no post deploy comfiguration. Even cheaper Lambda with API gateway. Now entirely dependant on API design but often works well.
- rawoke083600 4y agoScalability from day 1??? No sir, that is how you end up with premature optimization, k8s,microservice architecture and 3 deployment tools, abstract classes and factories for all those future usecases and dao's You probably should focus on really understanding the problem your software is trying to solve first, your next few versions(iterations) will be to adjust your solution you thought would work. But you usually only understand the problem and the shortcomings of your solution (software) after the first few version. All while you probably haven't even considered product-market-fit or talked to a few customers. Focus on scalability day 1, definitely a big no in my book !
- Sparkyte 4y agoDefinitely definitely you don't know anything scalability if you're saying that above. Scalability is about CI/CD solutions that don't rely on bootstrapping everytime a system comes live. It is about focusing on speed and delivery. Because the faster you can deliver the faster a system maintains availability. If you have a deploy cycle that takes longer than 5-10 mins excluding testing you're doing everything wrong.
- kaliszad 4y agoI think you are redefining scalability here. Tight development/ deployment cycle is just that, it is not scalability. Availability of the service shouldn't be dependent on how fast you can deliver new versions of the application.
- Sparkyte 4y agoYou do need scalability as a fundamental component in availability. Release cadances are important toward maintaining stability and vulnerabilities. Without a maintained application you lose availability. You are still asking where does scalability fall in? There are several points for building a scalable system. One is a design on load. So if you work on a ruby application you will know that typically unicorn is single threaded unless you want to do something like sidecart nginx. Not always the best. Going toward infrastructure with a ruby system. Someone might say oh lets stand up an instance let puppet manage it. This is where someone just decided to use an orchestration system that typically supports ruby. The flaw in this is that if you are leverage a non-binary deploy and forcing the need to use gems at setup on an application you create a massive potential for drift to exist across your instances. Suddenly you say I will use ansible to run scripts to verify the host and applications run and that they didn't lose coherency. The flaw with this is that you just overly complicated your system and likely dug yourself a mile of tech debt. What you would use is a scalable system be it lambda or containerized solution liek kubernetes. One of the biggest wins is speed and deploy cycles too. Kubernetes and lambdas are scalable solutions. So as an application organically grows in load a scalable system will allow organic resizing on the basiss of demand ensuring that it maintains availability. You should embed one reliability engineer on a team who can also code.
- kaliszad 4y agoNo, you should get the business going first. You can improve infrastructure later. E.g. start with a VPS. With most offerings, they are pretty reliable. If you need, make a failover cluster of two to make updates with very short downtime easier. You can add load-balancing and downtime-less updates capability later as it will make the whole system quite a bit more complex in most cases that are somewhat interesting. Of course, if you just have a static website or something more or less state-less, doing the right thing from the get go is way easier. I have more interesting, stateful applications in mind here.
- rawoke083600 4y agoRight !!?? The phrase "experience can't be taught it has to be experienced" comes to mind :p