Serverless and startups
aws.amazon.com
Serverless and startups
1–10 of 79 posts
Re: Serverless and startups
#2I 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"
Re: Serverless and startups
#3Next to the nice drawings and good tips on testing I 100% agree with the message. Lambda has enabled me to run a fledgling business and I’m porting my last Puppeteer EC2 workloads to Lambda as we speak. Node 8 and the new Layers feature made this possible.
Re: Serverless and startups
#4I 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"
I think there is place for all kinds of software and infrastructure, based on your business model and scale.
You can start with serverless, move to normal cloud instances and finally to bare metal or the other way around!
For example, the core value provided by an ERP software is not performance but the business logic. Serverless is a good fit for startups creating such software. If you are running a conference call business or serving tons of video like Netflix, a different architecture better suits your need. Such as having edge servers with every ISP.
Re: Serverless and startups
#5I 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"
Yes but probably not for the reasons you're thinking.
If you try to get things perfect the first time you'll never ship on time.
Doing the right things in the right order usually involves optimizing different constraints at the start and re-balancing your optimizations as you prove your product idea, learn what you don't yet know, and gain additional resources and time.
Re: Serverless and startups
#6I 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"
Yes but probably not for the reasons you're thinking. If you try to get things perfect the first time you'll never ship on time. Doing the right things in the right order usually involves optimizing different constraints at the start and re-balancing your optimizations as you prove your product idea, learn what you don't yet know, and gain additional resources and time.
Absolutely. Saving 30% on a cloud bill is not a super high priority for new companies. Staying frugal is important, but I find this mostly applies to unnecessary expenses, not necessary but slightly more costly expenses.
Don’t get the 27” inch iMac, get a second hand office chair. This will free up enough cash so you can take the more expensive but quicker hosting / infra options like Heroku and Lambda.
Re: Serverless and startups
#7Honest question how is it easier for a startup vs DO with few VPSes and say manual DB fail-over.
Re: Serverless and startups
#8I 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 not have the time or expertise to build out robust auto-scaling systems. They also don't have the money to dump onto a bunch of servers they can fall back to when needed.
But auto-scaling is arguably more important for startups than for well-established companies. Thanks to the unpredictablity of some random high-visibility influencer or journalist sharing your product without notifying you, it's easy for smaller startups to suddenly get hit with traffic that they can't handle with whatever infrastructure they have in place. Sometimes you only get one shot, and if a hundred thousand people hit an empty 503 page on their first visit, they may not come back for another try. Serverless design greatly mitigates that problem.
Re: Serverless and startups
#9Earlier quoted context omitted.
Yes but probably not for the reasons you're thinking. If you try to get things perfect the first time you'll never ship on time. Doing the right things in the right order usually involves optimizing different constraints at the start and re-balancing your optimizations as you prove your product idea, learn what you don't yet know, and gain additional resources and time.
Absolutely. Saving 30% on a cloud bill is not a super high priority for new companies. Staying frugal is important, but I find this mostly applies to unnecessary expenses, not necessary but slightly more costly expenses. Don’t get the 27” inch iMac, get a second hand office chair. This will free up enough cash so you can take the more expensive but quicker hosting / infra options like Heroku and Lambda.
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.
Re: Serverless and startups
#10Honest question how is it easier for a startup vs DO with few VPSes and say manual DB fail-over.
Two things, based on my experience (we migrated from Heroku to Lambda in 2016, so been there for a while)
1. you don’t need to worry about reserving capacity, so you don’t need to pay for growth you expect to happen, or worry about not meeting a spike in demand if it happens
2. Most of the operations stuff (apart from packaging) is included in the price, so things like monitoring, alerts, dead-letter queues, traffic shifting beween canary versions, failovers, balancing... and it’s priced per request, so this comes to effectively free if you don’t have a lot of traffic.
The big catch is that you don’t control the containers, so there’s no session stickiness. Getting the benefits from Lambda requires re-thinking how you do sessions and storage.