They look pretty similar, both provide a visual interface to compose lambda functions, data sources and sinks, etc. to serverless applications.
By comparing the information from aws website I failed to tell the differences between those two products. Could anyone help to give me some insights about the differences?
I have tried read the docs and use cases of both products but failed to find the differences. I would like to know when I should choose Application Composer and when move to Step Functions?
The Application composer will help you create your serverless application. You will put your services together, and then you can deploy them.
The step function does completely different things. It orchestrates already-created services. In a step function, you will set how/when you want to execute your steps (lambda function, dynamodb integrations, etc..), and then you can execute the step function anytime you want.
Related
I'm a mobile/front-end developer and need help with the architecture on the back-end where I'm totally green. I'm building web and mobile front in Flutter that will communicate with the server written in GO. Based on the config file attached the Flutter front I will create few separate apps, but for every single app I need a separate instance of the back-end services or at least separate database.
My question is about what architecture I should use in terms of future scaling to lower the server maintenance costs while having the best performance. Correct me if I'm wrong because what I will write is the image of my understanding of the structure but based on what I wrote above - am I correct that I should use some load balancer with the business logic spread across Kubernetes instances and only have separate database for every single Flutter app? Or is there any other solution I'm unaware about? Any help or guides that will at least lead me to more knowledge I can learn would be much appreciated.
I don't know yet whether it's a perfect solution but I will leave it if someone in future will be looking for it. My friend who codes in PHP introduced me to the multi tenant architecture pattern and after I've researched it I find it a good solution to what I've been looking for.
I am using go build constraints to conditionally compile constants into my test/staging/production cloud functions. How can I pass -tags ENV to the builder used by gcloud beta functions deploy?
As #Guilherme mentioned in the comments, indeed, it seems that it's not possible to pass the go constraints/tags to the builder used by Cloud Functions.
I searched around and while there isn't this option, I think indeed, having the option to send constraints to the builder used by Cloud Functions. Considering that, I would recommend you to raise a Feature Request for this to be checked by Google.
One option that you might want to give a look at it, it's deploying your application using Cloud Run. As it's informed in their official documentation about this application:
Use the programming language of your choice, any language or operating system libraries, or even bring your own binaries.
Cloud Run pairs great with the container ecosystem: Cloud Build, Container Registry, Docker.
So, this might work for you as a workaround. In this below tutorial, there are the steps to build and deploy a quick application with Go in Cloud Run.
Quickstart: Build and Deploy
Let me know if the information helped you!
I have been creating some Lambda functions on AWS using the serverless framework, Flask and SLS WSGI. Some dynamodb tables but that should not matter in this case.
The problem that I am facing is that I can not debug the whole thing end to end, I am able to run sls wsgi serve and run a local instance of my lambda functions, happy days. However, I am a little bit spoiled by other dev tools, languages and IDEs (even just Flask itself) that allow me to set breakpoints and see the scope, step through etc. So I would really like to be able to get that done here as well.
I tried launching the sls command mentioned above in a launch configuration inside vs code, no luck. Next thing I tried was to run the default flask launch config but that obviously didn't include all the configuration stored in the sls.yml file which is essential for accessing the local dynamodb instance.
The last thing I tried was to attach to ptvsd at the end of my app.py file. So I would hit a wait action from ptvsd, attach the debugger in vs code to the specified port, which seems to be successful and returning the code execution. However, it seems like sls wsgi runs the file twice, so that the attaching happens for the first instance and not the second, which then does not trigger a breakpoint when I try to execute an API call through Postman.
I guess I could include the wait step everywhere manually, then attach for each method that I am trying to debug inside the code instead of in the IDE, but that seems like overkill and not very convenient.
I have been looking for answers online and reading through docs and could find no further.
I figured out that I can use Attach using Process Id It is however a little bit tricky because there are always 2 processes running in the list (different pid's). Its not great, but it does the trick
One technique I have found useful, albeit in a node environment but should apply here, is to make use of unit testing as a way to execute code locally with the ability to tie in a debuggerm as well as make use of mocking to stub away the external dependencies such as AWS services (S3, DynamoDB, etc). I wrote a blog post about setting this up for node but you may find it useful as a way to consider setting things up with Pythoin as well: https://serverless.com/blog/serverless-local-development/
However, in the world of serverless development, it ultimately doesn't matter how sophisticated you get with your local development environment, you will have to to test in the cloud environment as well. The unit testing technique I described is good for catching those basic syntactical and logical errors but you still will need to perform a deployment into the cloud and test in that environment. Its one of the reasons at Serverless we are working very hard on ways to improve the ability and time it takes to deploy to the cloud so that testing in AWS is replaces local testing.
I didn't find any posts related to this topic. It seems natural to use Lambda as a getstream backend, but I'm not sure if it heavily depends on persistent connections or other architectural choices that would rule it out. Is it a sensible approach? Has anyone made it work? Any advice?
While you can build an entire website only in Lambda, you have to consider the followings:
Lambda behind API Gateway has a timeout limit of 30 seconds and a Payload size limit (both received and sended) of 6MB. While for most of the cases this is fine, if you have some really big operations or you need to send some really big datas (like a high resolution image), you can't do it with this approach, but you need to think about something else (for instance you can send an SNS to another Lambda function with higher timeout that can do all this asynchronously and then send the result to the client when it's done, supposing the client is capable of receiving events)
Lambda has cold starts, which in terms slow down your APIs when a client calls them for the first time in a while. The cold start time depends on the language you are doing your Lambdas, so you might consider this too. If you are using C# or Java for your Lambdas, than this is probably not the best choice. From this point of view, Node.JS and Python seems to be the best choices, with Golang rising. You can find more about it here. And by the way, you can now specify a Provisioned Throughput for your Lambda, which aims to fix the cold start issue, but I haven't used it yet so I can't tell if there is any difference (but I'm sure there is)
If done correctly you'll end up managing hundreds of Lambda functions, while with a standard Docker Container under ECS you'll manage few APIs with multiple endpoints. This point should not be underestimated, as on one side it will make changes easier in the future, since lambda will be small and you'll easily find the bug and fix it, but on the other side you have to move across these functions, which if you don't know exactly which lambda is responsible of what can be a long process
Lambda can't handle sessions as far as I know. Because after some time the Lambda container gets dropped, you can't store any session inside the Lambda itself. You'll always need a structure to store the session so it can be shared across multiple Lambda invocations, such as some records in a DynamoDB table or something else, but this mean that you have to write the code for this, while in a classic API (like a .NET Core one) all of this is handled by the language itself and you only need to store or retrieve items from the session (most of the times)
So... yeah! A backed written entirely in Lambda is possible. The company I work in does it and I must say is a lot better, both in terms of speed and development time. But those benefits comes later, since you need to face all of the reasons I listed above before, and is not as easy as it could seem
Yes, you can use AWS Lambda as backend and integrate with Stream API there.
Building an entire application on Lambda directly is going to be very complex and requires writing lot of boiler plate code just to enforce some basic organization and structure to your project.
My recommendation is use a serverless framework to do this that takes care of keeping your application well organized and to deploy new versions (and environments).
Serverless is a good option for that: https://serverless.com/framework/docs/providers/aws/guide/intro/
Looking for some advice on the best approach to launch a Lambda immediately after a cloudformation template stack gets run.
The use case is: I run my cloudformation template that setups up An API Gateway with Authorizers, and lambda functions. I then need to get reach out to another SAS/Cloud Service and run some configurations on their side to get everything dialed in.
I was looking into if there is a way to create a Lambda Function with an CloudWatch equivalent of Now, so it will launch immediately and do any finishing work that might need to be done.
I don't imagine I am the only person who might need to do this type of configuration. I could use multiple Cloudformation Scripts, but I'm trying to simply this for others who might not have much AWS experience, and Automate as much as possible. The more I can do in Amazon, the less scripting someone else might have to do.
If anyone has any ideas, or I missed something basic stuff, please let me know.
You can take a look at AWS CloudFormation Custom Resources. From the docs:
Custom resources provide a way for you to write custom provisioning logic in AWS CloudFormation template and have AWS CloudFormation run it during a stack operation, such as when you create, update or delete a stack.
With this custom resource you can call a Lambda function by handing over its ARN to the custom resource. See also this doc article for more background information.
Note: I haven't tried it by myself, but it seems to be the right thing for you.