3 ms·

I wish articles like these would include sections about how their developers dev / test / promote through different environments. Only seeing how a production s

I wish articles like these would include sections about how their developers dev / test / promote through different environments. Only seeing how a production system is structured is less than half the battle and can mask true complications of going serverless.

scarface74 6y ago
Deploying serverless code through the cycle is no different conceptually than deploying regular code. In our case we deploy Cloudformation templates that reference the same Lambda package in S3 across accounts. Rolling back is redeploying the old template v
carlsborg 6y ago
Typically you spin up a dev stack with the same cloudformation templates, so you get an exactly prod parallel environment (with parameters for things like DDB dev table names)
ledauphin 6y ago
chiming in here to agree with the other replies - one of the big benefits of serverless for us is that every environment is a "complete" environment, using an identical architecture to prod and no mocking or sharing of services. And costs maybe $50/mo/dev, most of which is a NAT gateway.
calpaterson 6y ago
Typically they simply don't test! If you do test, you really can only test each unit in isolation - testing the kind of setup in the article is just too hard and the tooling for doing automated tests on that kind of thing is not very mature. There is stuff like localstack/samstack/etc but I haven't seen anyone really use it as part of a workable test strategy for serverless AWS. Consider what happens outside of serverlessland: when people have 15+ microservices each of which needs a different docker container and different data store. Do they tend to do whole-system testing of it? No, in my experience people tend mumble something about "contracts" and test individual bits in isolation. This is on top of the open secret which is: it's very, very hard to predict what the ongoing costs of a serverless solution will be. Most of the services are priced by usage but the units are small (seconds, minutes, etc) and the sums are too (eg $0.000452 per hour of xyz). Post-project bill shock is a considerable problem. Source: worked at an AWS partner consultancy on many cloud "architectures" similar to the article.
- corporateslave5 6y ago
  Actually using cloud formation, it’s really easy to do integration testing. Often times server less can be cheaper because the systems only pay for what they use. High tps is expensive on server less, but low tps is dirt cheap. Source is I work at aws

scarface74 6y ago

Deploying serverless code through the cycle is no different conceptually than deploying regular code. In our case we deploy Cloudformation templates that reference the same Lambda package in S3 across accounts. Rolling back is redeploying the old template v

carlsborg 6y ago

Typically you spin up a dev stack with the same cloudformation templates, so you get an exactly prod parallel environment (with parameters for things like DDB dev table names)

ledauphin 6y ago

chiming in here to agree with the other replies - one of the big benefits of serverless for us is that every environment is a "complete" environment, using an identical architecture to prod and no mocking or sharing of services. And costs maybe $50/mo/dev, most of which is a NAT gateway.

calpaterson 6y ago

Typically they simply don't test! If you do test, you really can only test each unit in isolation - testing the kind of setup in the article is just too hard and the tooling for doing automated tests on that kind of thing is not very mature. There is stuff like localstack/samstack/etc but I haven't seen anyone really use it as part of a workable test strategy for serverless AWS. Consider what happens outside of serverlessland: when people have 15+ microservices each of which needs a different docker container and different data store. Do they tend to do whole-system testing of it? No, in my experience people tend mumble something about "contracts" and test individual bits in isolation. This is on top of the open secret which is: it's very, very hard to predict what the ongoing costs of a serverless solution will be. Most of the services are priced by usage but the units are small (seconds, minutes, etc) and the sums are too (eg $0.000452 per hour of xyz). Post-project bill shock is a considerable problem. Source: worked at an AWS partner consultancy on many cloud "architectures" similar to the article.

corporateslave5 6y ago
Actually using cloud formation, it’s really easy to do integration testing. Often times server less can be cheaper because the systems only pay for what they use. High tps is expensive on server less, but low tps is dirt cheap. Source is I work at aws