Well, 504. No cloud auto scaling?
Au Revoir
141–150 of 305 posts
Re: Au Revoir
#142I think their blog being hugged to death is a good example of how this technology (read: web backend tech in general, not containers) is still too complicated for people in general to use it for simple cases, like scaling the load of otherwise static content. (It's wordpress, but still) We need solutions that require less resources and smaller learning curves.
> being hugged to death Whenever I read about this I can't help to think that people don't make a good use of a load balancer like HAProxy in front of their web-servers. Even if it's a single server behind the load balancer. There's this sweet spot where your server is handling requests as fast as it can but if you cross above it everything halts. To make it simple, this usually happens when one or more hardware reso…
I've actually dealt with this precise problem, HAProxy doesn't really solve the problem of an excess of traffic. At some point you'll start dropping connections or people will give up waiting.
What you really want is something more like Varnish, a pass through caching proxy that handles known requests from memory, and any novel requests go through.
Re: Au Revoir
#143Earlier quoted context omitted.
Try getting 5+ marketing people to learn git and GitHub sometime and let me know how it goes.
This has also been my experience when pleading with clients about not using Wordpress... even when they pay me to research SSGs, they seem to always revert back to WP because that's what the non-engineers know how to use.
There are still plenty of CMS options that are built around caching in a way that you effectively get the best of both worlds. I'm a big fan of Grav, which is a flat-file CMS with an optional admin panel.
Re: Au Revoir
#144It always amazes me how you can convince a founder/CEO is not right man for the job, and slowly push him away. Companies that succeed are driven by burning vision, not by day-to-day operation people. It might make feel the companies run smoother for some time, but day-to-day executives are harmful to a company core vision leading to boring companies if they manage to sustain profitability in the long run at all.
There is a reason why most startups don't go big - burning vision is not even close to being the right formula for success. Running a company of 10 people is VERY different from running a company of 100, which is VERY VERY different from running a company of 1000. Just like precious few individual contributors are comfortable with and able to contribute meaningfully in this wide range of environments, it doesn't make…
I agree. I've seen time and time again founders having a certain vision but lack a strategy for getting there. You then get a whole other set of customers that are very different than your early adopters. The priorities in company day to day operations will change as the company morphs into a larger, faster growing business. You then get a whole other set of customers that are very different than your early adopters, and that present unique challenges and different approaches in tackling them.
Re: Au Revoir
#145It always amazes me how you can convince a founder/CEO is not right man for the job, and slowly push him away. Companies that succeed are driven by burning vision, not by day-to-day operation people. It might make feel the companies run smoother for some time, but day-to-day executives are harmful to a company core vision leading to boring companies if they manage to sustain profitability in the long run at all.
> Companies that succeed are driven by burning vision, not by day-to-day operation people. What is the evidence for this? We can throw anecdotes like Apple on one side and Unilever on the other, sure, but is there any study saying e.g. "Of these 100 promising companies founded in 1990, x% of the founder-led ones were successful by 2010 whereas y% of the outside-CEO-led ones were?" Making a bold claim like "Companies…
It’s the standard HN cult of the founder post. Goes right along with the idea that early employees deserve pretty much nothing because “it’s the founders taking all the risk”.
Re: Au Revoir
#146Earlier quoted context omitted.
> Running a company of 10 people is VERY different from running a company of 100, which is VERY VERY different from running a company of 1000 IMO thats a classist lie that keeps people in their place. Any reasonably smart CEO can learn his way from 10 - 10000. Yes, (s)he may not be capable of 10k on day one, but they can grow along the way.
No way is it a lie. The kind of people who enjoy running a company with a ragtag group of 10 employees in the early days are rarely the kind of people who will be able to effectively run a 10000 employee operation. If you’re growing fast there is no time for on-the-job training as CEO. You need to be effective immediately or else you are only hurting your company’s growth.
Oh my God, the company's growth? Then we MUST axe the CEO. He's just a human, after all. Don't want humans to hurt company's growth. Company's growth. Growth.
Re: Au Revoir
#147I think their blog being hugged to death is a good example of how this technology (read: web backend tech in general, not containers) is still too complicated for people in general to use it for simple cases, like scaling the load of otherwise static content. (It's wordpress, but still) We need solutions that require less resources and smaller learning curves.
> being hugged to death Whenever I read about this I can't help to think that people don't make a good use of a load balancer like HAProxy in front of their web-servers. Even if it's a single server behind the load balancer. There's this sweet spot where your server is handling requests as fast as it can but if you cross above it everything halts. To make it simple, this usually happens when one or more hardware reso…
What you're describing is queueing, but the solution you're really looking for is back pressure. Any queue will eventually fill and when you fill it, things fall out. So rather than just dropping requests or letting the requests swamp your box, what you want to do is intelligently reject requests.
On the web, this means sending 503 responses. In a more intelligent client-server model, this might be the client doing an exponential back-off retry with jitter. A plain-old retry can swamp the server and just kill everything. An exponential back-off retry will allow the backend to achieve a level of service that isn't fast, but also isn't unavailable.
Hopefully in this case the haproxy is used intelligently and simply returns cached responses to GET requests without query strings. You don't want to hold onto connections or pass them off to the dynamic layer behind the proxy if you're overloaded. You can also respond to the client with a page with an auto-refresh, implementing an exponential back-off retry.
Re: Au Revoir
#148Earlier quoted context omitted.
I've been mumbling under my breath about this since the 90s. The basic issue as I see it is that nobody wants to do the up front work of separating out static, client side dynamic, and server side dynamic. If that work were done then nominal load would be much less to begin with, and scaling up would be much more straightforward.
Maybe I'm misunderstanding your categories, but why would a server care about the distinction between "static" and "client side dynamic"?
A server would not care. It's the devs who need to separate these things.
Re: Au Revoir
#149Did anyone else well up at that final image? It's been a long week...
Re: Au Revoir
#150Earlier quoted context omitted.
> Running a company of 10 people is VERY different from running a company of 100, which is VERY VERY different from running a company of 1000 IMO thats a classist lie that keeps people in their place. Any reasonably smart CEO can learn his way from 10 - 10000. Yes, (s)he may not be capable of 10k on day one, but they can grow along the way.
What on earth makes it a “classist lie”?
The implication is that the (especially American) upper class is trenched on this belief that CEOs of large companies require a certain pedigree that may not be based on observable, empirical evidence but rather on a mythos to keep the upper class relatively "pure" and the number of rich CEOs controlled to (mostly) existing class members, while attempting to appear egalitarian ("anyone" can go to an ivy league school; "anyone" can fail upward; "anyone" can develop the skills to be a proper CEO, it's just "hard work" that a silver spoon makes "easier").
The relative rarity of CEO jobs at sizes deemed large helps ensure that empiricism is complicated because the sample sizes remain small, so what the truth here is, who can say? It's tough to science.