How I use the good parts of AWS
twitter.com
twitter.com
Doing test/staging on a nano and then pushing to production on an m5? What? Like get ready to troubleshoot random issues completely unrelated to your code. And then equating different AMI's to containers is vastly oversimplifying things.
With docker I can just get up and running on my local box and every dev I share this with has the exact same environment and config.
I can package up those images and send them up to ECS/Kubernetes and not deal with the same headaches. The learning curve is a bit steeper, but absolutely worth it.
I walked the same path here (starting out with single VMs for environments, installing services locally on my laptop) and the headaches down the line are not worth it and it isn't even a case of over-thinking the solution. You don't need to ride the cutting edge but modern tooling saves a ton of time.
It was a PITA migrating our old VM stuff over, but absolutely worth it. If you don't want to deal with maintaining systems there are other solutions mentioned ranging from full PaaS to something like GKE.
I’m moving away from ECS and going to EKS. The rationale is k8s has a significantly larger user base and I will benefit from that.
Well, that's the dream. The reality is like that sometimes, but also sometimes like "I ran `docker-compose up -d` like you said, and the local-dynamodb container seems fine, but the app container output 'Cannot find /volumeforsomething' and died...?" and then there's a slack thread for a couple hours about which version of Docker and is it native or Docker for Mac, and whether to try upgrading Docker for Mac first or just `docker volume rm -f volumeforsomething` or even `docker volume prune -f`...
I used to really struggle getting Docker and docker-compose to do what I want, but after a few years working with it, I'm not blocked by the various volume or network or what-have-yous that used to come up.
Alternative proposal: run your containers in docker-compose environments on an ec2 instance. Everyone wins?
We've mostly moved to EKS now but we had plenty of time to do it right thanks to this approach.
It's also totally reasonable to say, "It shouldn't have taken you years." It probably shouldn't have!
I use Terraform to setup my infrastructure as service on AWS, including Route53 zones.
After the latest 0.12 upgrade to the language, Terraform is quite a bit more user friendly than CloudFormation, and importantly, not locked down to just Amazon -- it supports multiple clouds and on-premises solutions for declarative orchestration of resources.
To that end, over the years, I've come across a couple of tools which help write CFN templates and manage rollout keeping cross-stack dependencies in mind. If anyone does a lot of CFN, I highly recommend Troposphere (python abstraction for cloudformation) [1] and Stacker (manager stack rollout via dependency DAG) [2]
1: https://github.com/cloudtools/troposphere 2: https://github.com/cloudtools/stacker
Why?
Tbh, I don’t think it’s prohibited, but CloudFormation was the default choice.
There's also a fast-growing ecosystem around Terraform: lots of open source modules, automated testing frameworks, and a growing number of tooling solutions. In the early years of Terraform, bugs and stability were major issues. With 0.12, the maturity factor is becoming very compelling.
On a separate note, I'm surprised the author endorses plain old EC2 over Docker. I get the point of "choose boring tech," but it seems like launching your app on EC2 requires a whole bunch of rework around automation that's already done for you in ECS, EKS, or dare I say even Elastic Beanstalk + Docker.
However, if you really can't change your ways of working, which I understand if you can't, then try out the "terraform refresh" command. I've been importing state recently, to move some of our own infrastructure over to TF, and have found it to be quite useful for things like manual security group changes. Basically, I'm building things up bit by bit, and when one of my states gets out of sync I've been updating the local config and running that command, which brings the state back in line.
In general, once you get your workflows sorted out and running for a while, you're unlikely to have any major issues with Terraform. Just make sure to use remote states and version them whenever you can (for example, turn on versioning on the S3 bucket if you use S3 as the remote).
I have a service that has to run tasks immediately that can take a while to complete, often in a minute, but occasionally taking hours. (And we're working on the obvious solutions of making it both fast and interruptable, but this is tricky.)
With ECS, if you want the automation to place your services, you run into trouble with these when you're deploying a new version because ECS assumes that tasks can be stopped quickly.
Especially, if ECS has asked a task to stop and the task is taking time to shut down, it can't deploy new work to that host until that process reports that it's done.
Does EKS handle this better? I'm inclined to drop ECS entirely and just bake an AMI because the automation feels like it's getting in the way more than anything.
If you're use case is to create 10+ objects in parallel (as a response to a customer action) I really like cloud formation...
We built a system around it, and I love the robustness of CF... It's "fire and forget". We can literally create a virtually unlimited number of stacks in parallel and check on them later to make sure they are successful... Granted this is probably an unusual use case, but we user a stack to represent a customer... In essence... And we're providing a real (temporary) server or set if servers for student/education (so it's not like we can redesign this for something other than making EC2 instances). We can support an influx of 100 users per minute using CF, but using Terraform or ansible we had to spin up temporary worker nodes to run their scripts and could only contact as many stacks as we had worked nodes... So CF let's is have one $30/month server super nearly infinite scalability.. but ansible was requiring us to spin up nodes 1:1 with how many we wanted to construct in parallel and Terraform looked no better.
In addition.... And on this I can't speak for specifically Terraform.. but we also have been burned because community modules changing and breaking backward compatibility... We've been version locked on ansible because version 2.6 broke security groups and version 2.7 broke another module... These are the popular built in but community maintained modules... But people redesigning modules don't know all use cases that could be available in CF (like referencing a security group in another account across a VPC link).. so a rehearsal expression update and presto.. a valid SG reference is no longer usage in that ansible version.
Since we use Infrastructure as Code, obviously we still see there are still benefits. I 100% recommend codifying your system! However, I still like to throw in caution that these solutions are not typically as featured as the native tools. The third party tools are also not always the "correct" solution. In addition, "cloud agnostic" seems like a misleading term, since you can't pick up your Terraform or ansible code and go to another provider. So I think it's more accurate to say "they can do multi-cloud orchestration of components" than "they are cloud agnostic".
I do recommend using Docker though. Containers are more portable and easier to deploy and replace on a running server, along with the ability to run multiple instances, mount volumes, setup ports and local networks, and eventually migrate to something like ECS/K8S if you really need it.
As for scale, I think that's massively overstated. Servers are really fast and most apps aren't anywhere near capacity. Even a $10 digitalocean server is plenty of power, and there's no cold starts. Even YC's advice is to focus on features and dev speed, and worry about scaling when it truly becomes an issue.
There are times to go serverless and times to avoid it, but with what you're saying you want to optimize for, serverless is the answer.
I get your point but I think with products like Knative/Cloud Run everything will converge on a lambda-for-containers model eventually which combines the best of both worlds.
If putting a container on a service at scale were simple then services like Lambda would have never been popularized and orchestration frameworks like kubernetes wouldn't exist
I'm also the first to recommend Kubernetes as soon as you need it as it's a solid platform, but most apps stay small and don't need all that upfront complexity. However I stand by Knative being the best of both, have you had a chance to look at that?
I don’t get this sort of anti-serverless sentiment. If you have even one good SRE, then it’s an absolute breeze. Writing a lambda function is writing business logic, and almost nothing else. I can’t see how you could possibly do any better in terms of development velocity. I don’t get this ‘testing functions is hard’ trope either. Writing unit test that run on your local is easy.
IMO lambda is awesome to handle infrastructure automation.
Not really, aside from the other AWS services you consume (KMS, parameter store...). A cloud function takes an event, executes your business logic, and returns a response. The structure of the event can change slightly, but they’re remarkably portable, and I’ve moved them before. If you’re doing it right, most of your API gateway config will be an OpenAPI spec, and equally portable.
> it is more expensive if you need to scale
This is context specific.
> it has higher latency
Again context specific, and likely not something actually worth caring about.
> it is harder to test locally
This is one I simply cannot understand. You can run your functions locally, they’re just regular code. I’ve never had a problem testing my functions locally. If anything I’d say it’s easier.
There’s upsides and downsides to any architecture design. Serverless models have their downsides, but these anti-serverless discussions tend to miss what the downsides actually are, and kinda strawman a bunch of things that aren’t really.
I’d say the most common downside with serverless is that the persistence layer is immature. If you want to use a document database, it’s great, if you want to use a relational one, you might have to make a few design compromises. But that said, this is something that’s improving pretty quickly.
However, once you are running enough containers, your server bill becomes something you can't ignore...
Making enough servers with enough memory capacity to keep all or containers running with fail over support was $400/month.. and that was just 60 containers (an easy number to hit in micro-services architectures).
And your right, we never got near server capacity by CPU usage .. completely agree there, we ran out of memory to keep the containers in memory ready for use.
If you don't know what I mean by that, then you should probably go with a serverless architecture instead of whatever your company has going right now.
Our company runs services written in C# running on .NET Core in containers. It's fast, secure, and makes development simple.
Instead of wrapping security layers around it ourselves with docker, selinux configs etc, it's safer to let gcp or aws filter that out for you because they're likely to have way better security.
Serverless ( there's still servers/containers ) just means that you don't touch the devops and scaling. You can still have your DB and APIs separately in order to be cost effective.
In your case your servers are not using node on the backend to run the servers thus you don't have this vulnerability.
Cloud functions products have been incredibly useful trade off for me. Whenever I want to process a lot of small files (read: tens or hundreds of thousands), I'll wrap some JavaScript into a function and it'll magically horizontally scale a function for a huge amount of tasks at the same time.
Has it done in seconds.
The fact that this has to exist is also interesting...
It’s not restricting amazon’s access that I’m worried about, more privilege escalation (e.g non-constrained iam:PassRole in combination with anything is a good one)
It all essentially boils down to some basic operations with binary numbers; the decimal repsresentations of IP addresses are useful shortcuts, but to really get a sense of what's happening, you need to look at the binary forms.
It can be a source of friction for someone that is just trying to accomplish a specific goal, in this case it might just be to use AWS to go live.
If building a database-backed prototype is your goal, designing a schema is only tangentially related to that goal. Schema design ability can slow you down if you have limited familiarity with SQL and/or the entity relationship model used by RDBMS.
NoSQL allows you to reach that specific goal faster than with an RDBMS by lowering the friction of creating database records and it does it by flipping the schema model from schema-on-write to schema-on-read which is a huge time saver. This made NoSQL great for building prototypes, especially for devs with little or no familiarity with SQL, because it eliminates the upfront effort of designing a schema (that is certain to change anyway) before you can begin to store records in the database.
In other words, the use of a far more familiar language (JavaScript vs. SQL) and the simpler programming model (document-model vs. entity relationship model) is a big part of why MongoDB was able to earn mind share among devs evaluating NoSQLs databases.
That was never my intention and I have absolutely no connection to them in any way whatsoever.
MongoDB just turned out to be an example I felt a lot of HNers could readily relate to considering some of their guffaws as they grew made front-page like this one: https://stackoverflow.com/questions/16833100/why-does-the-mo...
Using RDBMS has a stepper learning curve, but organizing your data right will pay back in bundles.
VPC is similar.
It's not that hard to configure it, it is actually very trivial compared to setting on prem data center, you can learn it or how someone who knows this.
Same with RDBMS, learn it (it is not hard) or hire a DBA.
I worked at one of popular car shopping sites, and while they used postgresql they stored car information as a thrift encoded blob. Every car trim was a separate row. A data had to be ETL to a NoSQL database to be extracted, that means to look up all car makes took 7 hours (the ETL happened through AMQP, don't ask) of course it was them stored in dedicated collection, but it was ridiculous. Out of curiosity I wrote code to convert the data from that form to relational database (postgresql) this actually helped to find that the were duplicates. The queries on postgresql database also had lower latency it didn't look like it would have a problem handling the traffic. This data it's also read only for users so it is trivial to scale out.
They also had a database to map up and latitude/longitude to a zip code. The data on MongoDB was taking 30GB and they had to use instances with enough RAM to hold all the data otherwise MongoDB would choke. The same exact data when stored in postgresql using right types (PostGIS and ip4r) took a bit over 600MB.
They also used Solr for storing inventory data.
I'm sure you are shaking your head that you would not do such things, bit of you have NoSQL blinkers on you often will run into problems that aren't problems at all.
I think the attitude that not everyone needs to know these things leads to people mistakenly thinking they can always have them be someone else's problem which furthermore results (needlessly!) in brittle systems.
I'm not asking for every developer to become a networking expert, but learning at least the very basics about your dependencies (you depend on networking, after all) is what I think a professional should do.
To address your NoSQL example, certainly it can be convenient to prototype with a dynamic schema, but you as a developer should still understand that even if it is dynamic, your data still has a schema and a concrete structure, which will affect your application in various ways. For rapid prototyping it's fine to ignore all this, but again once you start thinking about production, you no longer have the luxury.
If vpc is "ec2 v2", I would like to see a v3 that allows you to start off with a naive/simple setup and gracefully transition to the complicated setup of vpc when/if you need to.
I had a list at one point, not much VPC and IAM Roles, but routing tables, CIDR blocks, NAT Gateways, I can't remember what all else.
I just remember thinking that, while such configuration options might be powerful in the right hands, if you expect your application developers to manage all that, your cloud services are designed at the wrong level of abstraction.
Perhaps this is severely less secure by default, but it sure does make for a lower barrier to entry, and for reduced distraction from app development.
I also liked Heroku quite well. Felt at one point like I needed to move to Azure for some technical reason but right now, I can't recall the reason.
Originally in AWS I wanted to send emails from within a Lambda Function, and doing so required me to rework my networking configuration that I felt like I had barely gotten running AND pay ~$30/mo for some additional required networking service. IP Gateway or NAT Gateway or some other such. That was what finally ran me off from AWS.
The only annoying thing is that GCP uses json certification files for service accounts rather than just API key/secret pairs which are more portable, but you can usually avoid dealing with this by setting the account for the underlying VM or managed service.
Far too often I see clients who move their development and operations teams to the cloud but not their network or IAM/GRC teams. And they expect that because AWS (et al) is the cloud, it's just the DevOps people who need access and they can handle it all. So now you have developers and system administrators doing networking, firewalls, IAM, etc.
There's a big difference between enterprise cloud environments and developer-friendly cloud environments.
Anything whose main value proposition is about “ability to scale” will likely trade off your “ability to be agile & survive”. That’s rarely a good trade off.”
I don’t see these as being about scalability. Rather, they’re about fast time to market and ability to change. Moving up the stack and adding managed services such as API Gateway will definetly give your product a better chance of survival.
What if you want to send telemetry to a third party? Or use a cache? Or deploy something bigger than 250MB? Or handle WebSockets (without having to read/write state in DDB on every message)? Or buffer something on the filesystem? Or run something for more than 15 mins? etc etc.
How do all those things not impact agility? (In the web app/service space at least.)
>What if you want to send telemetry to a third party?
Can't you do this from your own Lambda code? Sure, your code could crash before it can reach your telemetry service - but isn't this a concern on a server based app as well?
>Or use a cache?
Elasticache or Mongo or whatever NoSQL 3rd party service you want to use works straight from Lambda. If you're talking about caching Lambda responses, you can again add custom code, which you would also have to do in a server environment.
>Or deploy something bigger than 250MB?
Yeah, you're SOL here. 250MB is huge for any non-GUI software and it would take a long time to get set up on Lambda's containers. If you're in this spot, I wholeheartedly recommend ditching Lambda for EC2. However, don't count Lambda out entirely - you can still have it take over repetitive, simple tasks so the server hosting your monster 250MB backend doesn't get overwhelmed!
>Or handle WebSockets (without having to read/write state in DDB on every message)?
I'm sure when PHP introduced sessions there were a bunch of devs complaining about having to maintain a MySQL table for session keys. Ultimately, if you're making a web app, 95% of its routes are probably glorified Excel formulas, so you'd need to pull and push state through a database anyways.
Where else do you store WebSocket state? In memory? What happens when you got millions of connections at once (think slither.io scale)? At the end of the day you have to put it into something that can scale. I'm assuming if you're using Lambda you care about scaling up - otherwise you could literally run your backend on an IoT toaster with a MySQL database hosted on some IoT coffee maker that had "admin" as its root password and nobody would tell the difference. Again, if this is you - Lambda wasn't meant for your use case. Go buy a coffee maker.
>Or buffer something on the filesystem?
I'm not really sure how to answer this one. There is obviously no permanent file system on Lambda unless you count S3 (although I'm sure you know that).
I did some searching and found this: https://stackoverflow.com/a/31660175 If you're talking about uploading huge files, direct upload to S3 seems like your best bet.
>Or run something for more than 15 mins?
Lambda wasn't meant for this. Set up a server and schedule a cron job. I'm guessing if it takes >15min it's probably some kind of backup, statistical analysis, ML model training, database dump parsing, yadda yadda yadda...Lambda is for handling events. Everything I mentioned seems like an internal business operation the users have no part in, so that also seems like a good candidate for just having one server instance floating around and throwing all your odd long jobs onto it.
I haven't used Lambda Step Functions, but I vaguely recall hearing something about being able to run long tasks with those? Not sure. I wouldn't bother, though, I'd just head straight for a server (the example Amazon gives is starting a job to retrieve a specific item in a warehouse, sending an order to an inbox, and waiting for a warehouse worker to mark the item as retrieved...I don't know why Amazon chose that specific example, but it sounds like they have a very specific target audience!)
>How do all those things not impact agility?
I'm of the opinion that tools do not impact agility, decisions do. If you decide to use Lambda in a situation where a server would prevail, you're wasting time on the wrong thing. If you decide to a use a server in a situation where Lambda would prevail, you're...not really doing anything wrong, I think. It'll likely cost you more than a Lambda function but those numbers only start to matter once you actually have to care about scale.
Like I said, it's ultimately about what you're trying to do. Don't put a square hole through a rectangular screw, or something like that.
BTW, about this “What happens when you got millions of connections at once (think slither.io scale)? At the end of the day you have to put it into something that can scale.”
API Gateway has a hard limit of 500 WebSocket connections per second. It can’t be increased! https://docs.aws.amazon.com/apigateway/latest/developerguide... —- That’s about the capacity of 1 C5.4XL instance :)
The whole scalability argument of API Gateway and Lambda is highly overrated IMO. There are all sorts of soft and hard limits, and you still have to monitor utilization of concurrency rate and invocation frequency and manually request limit increases when approaching them. Doesn’t sound much different than using EC2.
I don't understand when people see "server less" and start thinking it is without realizing that all what lambda is still using EC2 instances running on your behalf, it just hides that away from you. You should only use lambdas when your use case would reduce the cost (lambdas charge per invocation) which means it is for services with low number of requests. Otherwise it will end up being more expensive.
That particular limit is new connections per second, not total connections per second. Starting from zero, you could have 1.8M connections after an hour (per account, per region).
Otherwise I dig.
But what about maintenance?
Working in a place where we have hundreds of small apps, the issue of maintaining umpteen servers is a great pain. Docker reduces the footprint of what has to be maintained substantially.
Don't quite follow the latter.
Maybe AWS spins up an actual EC2 instance for each container, it's an implementation detail.
EC2 is a legacy tool with different abstractions, but if you replace "VM" by "hypervisor" and "container" by "microkernel-app", you could do the same thing with one less layer and the same tech we always used
You absolutely want your application to be disconnected from the system you running it on. Languages like Python or Java were designed to run the same not only on different OS but also on different architecture, why would you be ruining that?
With Python I highly recommend if you use redhat or CentOS to use IUS repo which let's you choose exact Python version you want to use. Then create a virtualenv with the exact dependencies you need. If your ops are standing on the way of this they are misinformed, because what they are suggesting ads a lot of unnecessary work for themselves as well with no tangible gain.
The layers make it a lot lot easier here.
If you ever do, please give container orchestration a look. It makes it honestly easy.
When developing a monolithic application your choices make sense. When you're taking an approach designed to allow for feature development by multiple teams in an Enterprise setting they start to be a bottleneck.
There is also NixOS together with NixOps it has some steep learning curve, but I think it is worth it. You edit configuration.nix which is like Dockerfile, and then you can either use standard AMI and provide the configuration, that will result in setup similar to salt, ansible, chef etc. You can also use NixOps to provision such machine, you can then place /etc/NIXOS_LUSTRATE file which removes state after next reboot, stop it and generate AMI that essentially emulates what packer is doing. You can also use nix build to generate an image file and upload that to AWS.
NixOps is also a great tool to test, you can deploy your configuration to local virtual box, or public cloud provider.
I just started developing with .Net Core, Node, and Python last year. My “Linux deployments” were all Lambda. The Node/Express app used the lambda proxy integration.
I needed to move past the lambda limitations - 6MB request body and cold starts - and I didn’t want to introduce Linux servers into a Windows shop or host Node on a Windows server and I didn’t know Linux well enough myself. I was able to deploy a Linux Docker Container on Fargate and have all of the console output to go to Cloudwatch.
I suppose you could bake everything into the AMI except your code, and hardcode the git sha into UserData to ensure your builds are reproducible. It just seems like it might get complex when coordinating lock-step code/dependency changes.
Nix approach is to build everything from ground up without depending on anything outside of it. It caches results so you don't have to rebuild the whole system when building your application. This approach makes fully reproducible builds[1], because the entire environment is known.
Nix by itself can be used for deployments, you can install it on any machine that has nix installed and don't need to worry about any other dependencies, since nix will take care of all of them. It can generate a docker image of you need it, and it will only contain your application with is dependencies. You can use nix-shell to define CDE with all developer tools installed with exact same versions that way developers only need to have nix installed and nix will take care of all other dependencies you need.
NixOS takes what Nix does and takes it one step further and uses a configuration that similarly describes an entire operating system. The single configuration.nix describes what your system supposed to have installed, and configured. You can either deploy that and have nix configure machine on boot, configure machine create /etc/NIXOS_LUSTRATE file which removes all state on next reboot and create AMI out of it (equivalent to what packer does). Or have nix generate an image file and upload that to AWS.
NixOps supposed to be for deployments, but to me it replaces vagrant and docker you can create configuration.nix and deploy it with local vbox, ec2 and other cloud providers. The great thing is that your configuration file will just work fine no matter which provider you use.
There are some rough edges though, for example I needed to update NixOps to use boto3 so it works with assume role and MFA, I hope it will be merged soon.
I believe the issue is that what they are doing is very ambitious and they have limited number of developers to handle all of the work, but from all devops tooling I used they seem to have the right approach. They provide the immutability reproducibility at the right level and doing it the right way (declarative (through use of pure, functional, lazily evaluated language starting with a fully known state) vs an iterative language with a partially known state)
[1] your need to pin your build down to specific version of nixpkgs
PaaS is a problem for me because so many developers don't understand (or own) the tradeoffs of choosing PaaS, so i have to constantly have the "no-PaaS" argument to people who have never dealt with the responsibility of uptime response and can't fathom why I'd want to "do more work when the PaaS does it for you"
But in the meantime? PaaS services solved a lot of issues for you for less money than it would take you to interview a sysops person. Use them as much as you can, whether it's complete app hosting, abstracted container deployment, or something else.
Interesting that he sees micromanaging infra on AWS as more agile than using managed services.
Also, serverless systems don't cost you money when you(r customers) don't use them, so that's a huge plus on survival.
Finally, code you write is always a liability, if you got a good architecture (hexagonal, etc.) you can just swap out one service that saved you time in the past with another service that will save you time in the future.
All the horror stories I see surrounding huge surprise Lambda bills always bring me back to this point. If I have to pay $5/mo for a server I only use for two hours once every few months, that's something that should go on Lambda. If it's something that I'm using constantly, all day every day, a server will be cheaper.
If I only use my car once every few weeks, Uber makes a lot of sense. If I use it every day back and forth to work and the grocery store, Uber's gonna be a lot more expensive.
Lambda is for small tasks that don't execute often. And using it right can save startups gobsmackingly large amounts of money.
Maybe using serverless technology is too hard for your corp, because you don't have the skills, so it could lead to problems in the future (surprise Lambda bills).
But it could also be that your competitors get a huge advantage by investing in the serverless paradigm and run you away in the future.
To me that Twitter thread sounded too much like a guy who invested in some tech over the last 11 years and now tries to convince potential customers of him to use the tech he knows about.
He could be right, he could be wrong. I don't know. I started back-end development with serverless, so I'm biased in the other direction, haha.
Well, that and Google's managed k8s solution was down for multiple days awhile back when I was doing a comparison. Another reason I use EKS atm.... despite I think GKE is a bit better.
Having your teams doing little POCs with other providers will ease your project/company cloud bus-factor significantly.
That being said, for me, the fact that it's Google is a big detractor. Non existent support, the worst documentation last I checked, and I read a "my account was closed unexpectedly" story every now and then.
Then there's the privacy angle, but the alternative companies are hardly bastions of user privacy themselves.
I worry that I will overcome my fears and start using it one day, only to years later try to undo that decision and wean off it like with Android, Search, Chrome, and (not yet) Gmail/GSuite.
>Then there's the privacy angle
Don't think that's a big issue at dev level. They're interest in billions of users not tracking thousands of esoteric devs doing work stuff that has limited ad resale value.
>the worst documentation last I checked
Seemed fine to me. Probably better than azure
I thought it looked like one of the more mature-seeming choices on the market.
Any thoughts?
"Anything whose main value proposition is about “ability to scale” will likely trade off your “ability to be agile & survive”."
At Remind (remind.com) we have nearly 600 separate Cloudformation stacks which build and maintain our stage and prod environments. This would be insane without stacker.
As for this tweet, I'm fairly confident he is talking about a side projects or early startups and I agree with most of what he said.
Personal, I don't use AWS for side projects, I use offerings from Linode, Digital Ocean, and vultr. They are cheaper and scale up vertically with a click of a button, which is really what you need for the first couple of years, unless you hit the growth/scaling lottery, which isn't typically the case.
For example, over the last two weekends I was able to use Digital Ocean Spaces (alternative to AWS S3) to build my wife a secure digital downloads store.
All uploads and downloads use presigned POST and GET urls created via Boto3! I was suprised how perfect Digital Ocean implemented S3's API in their Spaces offering.
https://russell.ballestrini.net/pre-signed-get-and-post-for-...
I think the sentiment is more "don't build your entire app on lambda"
I really started to enjoy AWS when I got into the habit of deploying all EC2 instances using Autoscaling groups. Even single node instances and configurations that don't need any scaling, just everything. Autoscaling is free and it forces you into the immutable/disposable infrastructure paradigm, which just makes administration of the nodes just so much easier. And for all stateful stuff there is RDS, S3, dynamo, SQS, etc.
Not sure how this guy can give this advice.
containers make rapid development so much easier. There's no distinction between your dev environment and your prod environment except for a couple properties/env variables and some scaling factors.
Also "no" to cloudformation and "yes" to terraform.
And if I were to write a simple application, I'd probably try with lambda next time around.
Is there a more user-hostile webapp than Twitter? I think not.
And yet, the project seems to have stagnated somewhat. Maybe it just did everything it set out to do? I'm not sure, but when people say "forget about Lambda because you'll have to roll your own shit" I wonder if they've heard of Zappa or not.
Zappa got me out of a massive hole several times. I'm not a webdev, and we arn't a web company, so we don't have a web deployment pipeline.
Having Zappa makes our life very simple and cheap. The best part is that local and "prod" are equally easy to spin up.
The simple integration to DNS, SSL, api gateway, is a wonder.
The only downside is the permissions management is a massive pain, and assumes that you have admin permissions.
I understand that primary use of Zappa is a web application, but I have reservation about that as well. The "serverless" applications aren't really server less, they just have VMs spun on demand and it's only good idea when you have a service that most of the time is idle.
- Super nice, low config API
- easy to deploy
- great out-of-the-box support for async tasks (no Celery! woo!)
but:
- It was a nightmare getting certain Python libraries (eg. Pillow, psycopg) to work in the AWS Lambda environment
- It really sucked having to deploy to AWS in order to debug issues which cannot be reproduced locally (eg. library)
- It seems hard to get away from using AWS tools to observe your code in prod (eg. CloudWatch for logs)
- I still needed a database to maintain state, DynamoDB didn't work with Django's ORM and was surprisingly expensive, and if I'm going to shell out $10/mo for a Postgres RDS instance then I may as well run the whole thing on EC2 anyway
I think Zappa is a really nice tool for some niche use cases, and I'd definitely turn to it if I needed to stand up some small, stateless serverless service, but I would hate to support and debug it as a web app in prod.
project: https://memories.ninja
zappa version: https://github.com/MattSegal/family-photos/tree/lambda-hosti...
ec2 version: https://github.com/MattSegal/family-photos