61–70 of 79 posts
I do wonder if, in a few years time, if we're not going to be seeing a new genre of technical blog posts: "How we migrated off serverless to reduce our costs"
It's already started: https://medium.com/coryodaniel/from-erverless-to-elixir-4875...
And it's fairly trivial to set up autoscaling distributed Elixir on Google's Kubernetes offering.
In retrospect, going serverless (using Serverless Framework) has been a terrible decision for us. First, exposing an API served by AWS Lambda has the infamous cold start problem. It's not fun to wait a couple of seconds for a mobile app to respond just because the request hit in an unfortunate time. One solution we found is to use a Serverless Framework plugin to periodically ping lambdas to keep them hot. But each c…
The Dynamo complaints isn't a Serverless issue, but a NoSQL issue. Hopefully NoSQL first/everywhere is finally dying as people realize all the benefits of a RDBMS (and shortcomings of NoSQL). And, if you knew you were doing something with geo data, picking Dynamo was a tool selection mistake from the get-go.
Earlier quoted context omitted.
Or I can just let AWS do the work and not worry about it running HAProxy, Patroni, etc.
Sadly, you'll still encounter pages in the middle of the night (well, if you implement the monitoring) when AWS services fail and you need to write up a support ticket. Granted, they're usually already aware of it, but it can still take tens of minutes to hours to resolve - time during which you are down.
Yes, I know what happens when client apps/servers cache the DNS entry too long and don’t notice when a failover takes place - been there done that.
And the quickest way to recover from a failure of servers that don’t store state is just to let autoscaling kill it and bring up another instance based on an AMI/startup scripts.
I’m ruthless about not having servers as pets for anything that we have to manage ourselves.
I tell our Devops guy that it is completely useless to keep an inventory of server names, IP addresses, etc. for anything that I’m responsible for.
Earlier quoted context omitted.
Sure but at a very different price point.
And too often, developers (smaller companies) and ops (larger companies) time is considered free because they are salaried and are expected to work more than 40-45 hours per week. Yes, earlier in my career I would have accepted that, but I’ve successfully pushed back a few times and said I won’t babysit a process/server etc but I will design a method where it is auto healing, autoscaling, etc.
The other huge benefit of building this process is we can use dirt cheap spot instances with near abandon. For me, any infrastructure that I can't treat as cattle is on my hit list.
Earlier quoted context omitted.
One of the things with Lambda etc is that while they are cost-effective (and flexible) when a business starts, they also can also lead to lock-in (not just with the serverless functions themselves, but queueing services etc). A few years down the track, a business may find themselves spending quite a lot of money with Amazon, and being unable to move away without a major re-engineering effort.
Well, at least you have a business. I find vendor lock in to be about the lowest priority on my list. Also, the lock in is pretty exaggerated. Just make sure to keep business logic separate from the cloud plumbing, as per the OP example.
There is a reason Amazon gives away a lot of free credits to startups, and it's the same reason drug dealers give away free samples. If the economics are right, and growth is strong then you might be okay - but you also don't want to find yourself with a $100k/month AWS bill in a startup with only $2m of annual revenue.
(P.S Greetings from the other side of the Spree. I love La Lucha on your street!)
I was recently talking with some folks at an incubator about a website I was building, and one of the technical guys suggested I consider switching to serverless before launching (and I thought it was a good suggestion). Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. This is purely anecdotal, but the majority of startups I've seen - including my own work - do n…
> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. But is that kind of scaling really the hard part? If you're already using AWS for example, it is trivial to set up an autoscaling group that will add more EC2 instances the keep up with the rate of traffic. IME, scaling data stores is the hard part of scalability. I'm not saying serverless doesn't make it a littl…
Earlier quoted context omitted.
It's a managed service by Amazon and you access it using the AWS SDK, for which you need an IAM role, so everything is secure. Whereas with RDS, Amazon maintains a database for you, which you just connect to using ordinary TCP. IIRC it's not even possible to run an RDS database exposed to the Internet (well, you can always install Postgres on an EC2 instance, but that's even crazier).
I see, but security aside I am not sure how the latency is impacted by having a serverless on a DynamoDB VPC endpoint. BTW, you can expose RDS out to the internet.
Interesting, looks like that might be possible after all, though the docs are a bit unclear how this would work from Lambda specifically, and it looks like it needs a NAT regardless. Guess I misunderstood the docs at the time. (This ties into my comment about inexperience being our largest mistake. :))
Earlier quoted context omitted.
It's a managed service by Amazon and you access it using the AWS SDK, for which you need an IAM role, so everything is secure. Whereas with RDS, Amazon maintains a database for you, which you just connect to using ordinary TCP. IIRC it's not even possible to run an RDS database exposed to the Internet (well, you can always install Postgres on an EC2 instance, but that's even crazier).
I see, but security aside I am not sure how the latency is impacted by having a serverless on a DynamoDB VPC endpoint. BTW, you can expose RDS out to the internet.
If you run your Lambda in a VPC, your cold start times get worse, so latency increases.
In retrospect, going serverless (using Serverless Framework) has been a terrible decision for us. First, exposing an API served by AWS Lambda has the infamous cold start problem. It's not fun to wait a couple of seconds for a mobile app to respond just because the request hit in an unfortunate time. One solution we found is to use a Serverless Framework plugin to periodically ping lambdas to keep them hot. But each c…
Unless you are going to run your db on the same server as your server application, are you not going to have a NAT regardless? The Dynamo complaints isn't a Serverless issue, but a NoSQL issue. Hopefully NoSQL first/everywhere is finally dying as people realize all the benefits of a RDBMS (and shortcomings of NoSQL). And, if you knew you were doing something with geo data, picking Dynamo was a tool selection mistake…
Which of the following is the more likely failure mode for a new product: A.) So many customers wanted it that we couldn't scale fast enough. B.) We ran out of time or money before we shipped. The author appears to be worried about A, but in my experience it's B that you need to think about when starting out. Imagine if, instead of building any of those crazy 30-node-diagrams of an architecture in the article, he'd h…