61–70 of 71 posts
Earlier quoted context omitted.
And in reverse, it can be surprisingly tricky to convince serverless advocates that it's not so new and GAE fits their definitions.
To most people, serverless==lambda. That's where most of the conversation lives and dies.
One thing that bothers me about serverless functions is that there is virtually no concurrency. Once you return you have no assurance that your code will keep on working. If you want to perform actions that might be throttled (cloudwatch for example) and are not critical for the response, you cannot have a singleton processing them after you return, because they might not be processed.
How could it be orchestrated by the cloud if there's no clear end to your workload?
Earlier quoted context omitted.
I can see both sides, and have used both sides (at my last company we used 1500-2000 EC2 instances at any given time and at my current company we have one non-critical EC2 instance and then a bunch of cloud functions on Firebase/GoogleCloud, though the current company is much earlier in its life than the former one). For a new project, serverless seems to involve a ton of momentum-stealing upfront work before you can…
> you do always feel one step further removed from your code, so it can be a pain to debug and troubleshoot. This reminded me of a story I heard about RMS's kernel, GNU Hurd. Linux being built as a monolith in the 90's, Hurd was being built as a microkernel (microservices) architecture. Guess which one was easier to debug[1]? 1: https://biblioweb.sindominio.net/telematica/open-sources-htm...
Earlier quoted context omitted.
> That's more of a "I don't know what I'm doing" story, isn't it? Sure, but k8s is big enough that "very few people know what they're doing" is a valid argument. It's loosely like saying that git sucks because the technology is solid but it's extremely complex and hard to get a grasp on.
I don't think the ergonomics of k8s are anywhere near as bad as those of git. I think the perception of k8s as complex and confusing is promulgated by people who already don't understand how their process starts and runs on any given Linux box without container orchestration. Naturally these people are overwhelmed by adding k8s on top. The article to which I linked describes itself as "a wild ride of discovery" but a…
> Serverless container services such as Heroku, Netlify, AWS ECS/EKS Fargate, Google Kubernetes Engine, and Azure Kubernetes Service IMO I don't think Heroku and others fit the serverless paradigm. To me serverless is about automatic scaling of performance and cost. With Heroku you need to provision capacity in advance, and you pay for it whether you use it or not. Heroku doesn't scale automatically either, you do th…
Heroku does have autoscale capabilities based on avg response time. You set a min and max dyno count and off you go. It's as simple as it sounds but for run of the mill, follow-the-daytime apps it works.
Isn't the article's vision of things like Kubernetes (and similar) a bit too idyllic? I've heard talks by experienced K8s adopters (I want to say "Kubernetes failure stories", but googling comes up with similar hits but not the specific talk I was thinking of) where they mention that when K8s goes bad, it has all the negatives or knowing the "traditional" tech stack plus all the failure modes of K8s itself. They argu…
Some of these stories (I just Googled for "kubernetes failure stories") have little to do with K8s. This one[1] is just whining that his app is slow when it runs out of CPU. That's more of a "I don't know what I'm doing" story, isn't it? Lifting the CPU rate limits in a container is not exactly a cost-free magic wand. 1: https://medium.com/omio-engineering/cpu-limits-and-aggressiv...
Still not the exact talk, but I think it's from the same guys. I remember they explained how with K8s, the "surface area" of problems grows almost uncontrollably. You have all the problems of doing things manually (or at least, when things go wrong you must have a very good grasp of them), plus all the problems of K8s.
(Do note they are not arguing against K8s, just pointing out its multiple pitfalls)
Earlier quoted context omitted.
> That's more of a "I don't know what I'm doing" story, isn't it? Sure, but k8s is big enough that "very few people know what they're doing" is a valid argument. It's loosely like saying that git sucks because the technology is solid but it's extremely complex and hard to get a grasp on.
I don't think the ergonomics of k8s are anywhere near as bad as those of git. I think the perception of k8s as complex and confusing is promulgated by people who already don't understand how their process starts and runs on any given Linux box without container orchestration. Naturally these people are overwhelmed by adding k8s on top. The article to which I linked describes itself as "a wild ride of discovery" but a…
I absolutely like managing servers. It makes sure I am fully aware where my data is at what time, and what is handling it. in a European world with GDPR that became a lot more important. At the same time this has been a big factor in recent data leaks. Those leaks happened mainly because implementation issues, but those organisations didn't choose to make their data available in unsecured S3 buckets. It was able to h…
Earlier quoted context omitted.
> not because of how the code was structured but that was the only way the build tools allowed him to do it Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith
Microservices are by definition stand-alone, independent, and self-contained. That's the whole point of microservices, and one of the reasons why people tolerate the pain that goes with a distributed system. If your application does not meet any of those requirements then call it something else, as it clearly isn't a microservice.
Not sure you read my post. I called it a "mangled over-engineered monolith"
Earlier quoted context omitted.
> not because of how the code was structured but that was the only way the build tools allowed him to do it Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith
It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context. Regardless, it doesn't sound like microservices, it sounds like a distributed monolith. Having built a product out of microservices and lambdas I definitely have not found that build…
Yea, you are probably right on the money.
IME lots of folks struggle with DRY when trying to actually implement their services. In teams I work with, we frequently see attempts to build a shared library and have to re-hash the discussion every time