Why are you doing a lambda function trigger enabled using pipeline?
For the AWS service to invoke your function directly, you need to create a trigger using the Lambda console. A trigger is a resource you configure to allow another AWS service to invoke your function when certain events or conditions occur. Your function can have multiple triggers. Each trigger acts as a client invoking your function independently, and each event that Lambda passes to your function has data from only one trigger. By using the code pipeline we enabled our lambda function trigger when we needed it.
What is the benefit?
People don’t need to add lambda function roles permission manually and don’t need to enable trigger manually because, after policy gets attached to the particular roles then we can enable trigger and it happens by using pipeline whenever we need every time automation happens.
As the Edtech industry continues to grow and evolve, the need for reliable and secure network infrastructure becomes imperative. Recently I got a chance to work on an Edtech project where we had to manage multiple Virtual Private Clouds (VPCs) and on-premises networks in order to accommodate their different environments – development, testing, and production.
Managing these networks separately was quite challenging and also made it difficult to troubleshoot any issues. This is where we thought of leveraging AWS Transit Gateway. In this blog, we’ll explore the capabilities of AWS Transit Gateway.
Transit Gateway can make your routing easy with the simple configuration just by making simple Transit attachments. See how it works.
What is Transit Gateway?
Transit gateways help you to connect multiple VPCs, multiple Transit Gateway, network Appliance, AWS Direct Connect Gateway, and VPN to transit Gateway. It helps you in making your routing flow understandable and easy to maintain. More over you can say it’s serverless of your VPC peering Service.
There was a cron scheduled in our environment at a particular time which used to run at 8AM. This cron read data from the s3 bucket and used to succeed but failed when there were no objects present.
Problem this Integration solves:
Eliminates the need of keeping a scheduler in the system. Lambda will work as a Scheduler.
No manual intervention will be required in case the file from one service is delayed by a minute or an hour due to any reason.
Data exchange and processing between teams become more efficient and less error-prone.
Eliminates the need of checking the presence of files on S3. It all gets automated.
There are different application categories in the general application world, but we usually define them in two major types, i.e., stateless and stateful applications. In Kubernetes, this distinction becomes especially important when designing and managing workloads.
To have a clearer perspective, we can say that API-based applications are generally stateless, and databases are stateful. In simple words or definition, a stateless application is an application that doesn’t save or persists the client data. On the other hand, a stateful application saves data about each client and uses it for other requests. Continue reading “Kubernetes CSI: Container Storage Interface – Part 1”