4 ms·

Having seen a lot of these types of services there is always a question about scale. In other words, these are great for quick prototyping, but at a certain lev

Having seen a lot of these types of services there is always a question about scale. In other words, these are great for quick prototyping, but at a certain level you have to move off a service like this onto a more robust infrastructure. That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale?

chimen 8y ago
What exactly is the "scale" problem here?
- josh_carterPDX 8y ago
  Since this is a general purpose platform with not much in the way of functionality. Meaning, you're not going to build the next Flappy Bird on this platform. My question is what is the ceiling? At what point do you need to move off the platform and how easy is the migration? I find people are pretty gun shy to park their data into a platform that doesn't make it easy to migrate off (Parse comes to mind).
  - ac360 8y ago
    For clarity, the platform here is Amazon Web Services. We're just providing tooling to help you build and manage serverless architectures on AWS easily.
ac360 8y ago
There are many case studies of AWS Lambda's scaling power and its constraints are well documented. The newcomer in the serverless architecture is AWS API Gateway Websockets, and I personally have not performed any tests using this service within a variety of use-cases at significant scale (it's still a new service). When it comes to migration, it depends on your use-case. A few suggestions which may be helpful: * Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures. * Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor. * Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.
RussianCow 8y ago
To clarify, in case it hasn't been made clear already: This is not a new service, but rather some tools built on AWS. So AWS is the platform, and you get all the benefits of Amazon's scale when using Serverless.
leetbulb 8y ago
> That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale? The difficulty really depends how deeply integrated your application becomes with the underlying cloud provider and its services. It may be a simple application consisting of few a JS Lambdas and DynamoDB tables, or it may utilize half of AWS' offerings. In the case of the latter, may god help you.

chimen 8y ago

What exactly is the "scale" problem here?

josh_carterPDX 8y ago
Since this is a general purpose platform with not much in the way of functionality. Meaning, you're not going to build the next Flappy Bird on this platform. My question is what is the ceiling? At what point do you need to move off the platform and how easy is the migration? I find people are pretty gun shy to park their data into a platform that doesn't make it easy to migrate off (Parse comes to mind).
- ac360 8y ago
  For clarity, the platform here is Amazon Web Services. We're just providing tooling to help you build and manage serverless architectures on AWS easily.

ac360 8y ago

There are many case studies of AWS Lambda's scaling power and its constraints are well documented. The newcomer in the serverless architecture is AWS API Gateway Websockets, and I personally have not performed any tests using this service within a variety of use-cases at significant scale (it's still a new service). When it comes to migration, it depends on your use-case. A few suggestions which may be helpful: * Consider your data strategy (much lock-in happens at this level). Most serverless architectures leverage DynamoDB because its design pairs well with stateless compute like AWS Lambda. You can use DynamoDB within all types of architectures. * Don't use AWS API Gateway specific URLs in your application. Use custom domains. This will enable you to easily swap out your websockets endpoint. Fortunately, there is only 1 endpoint in this architecture, so there is little surface area to refactor. * Make sure you understand the cost of these serverless technologies at scale before building with them. But don't forget to factor in the reduced labor costs of using serverless technologies.

RussianCow 8y ago

To clarify, in case it hasn't been made clear already: This is not a new service, but rather some tools built on AWS. So AWS is the platform, and you get all the benefits of Amazon's scale when using Serverless.

leetbulb 8y ago

> That being said, how hard is it to move the data off this platform and migrate it to another once you've reached scale? The difficulty really depends how deeply integrated your application becomes with the underlying cloud provider and its services. It may be a simple application consisting of few a JS Lambdas and DynamoDB tables, or it may utilize half of AWS' offerings. In the case of the latter, may god help you.