and every Monday at 5:00PM (UTC) HTTP facing Lambda functionsĪfter the trial period of Lambda-powered background jobs, we were sure that Serverless was ready for prime-time. # serverless.yml - Sample function that deletes expired drops functions: deleteExpiredDrops: handler: DeleteExpiredDropsHandler.handle events: - schedule: rate(10 minutes) # Will run every 10 minutes - schedule: cron(0 5 ? * MON *) #. You can also use standard “cron” syntax to make function run on a specific day or hour. Just upload your Node.JS code, setup rate and you’re ready to go.
Lambda’s native ability to schedule function invocations is a great drop-in replacement for CRON tasks. It’s also easy to monitor each of your SNS-consumers and spot anomalous rates of invocation failures. That way, we could easily set up separated Lambda functions that were (e.g.) invoked only when new drop was created.Īll of the functions run in parallel, so it’s very scalable approach. Each type of event had its own SNS channel. We decided to try AWS SNS as our primary “messaging” system. We found out that these were ideal components to rewrite with our serverless approach. We also had a couple of Ruby functions invoked by CRON. Prior to going serverless, we had Scala daemons that were constantly running in our ECS cluster and consumed Redis lists of events. The first part of our Serverless Proof of Concept was to migrate all of our background workers. We didn’t see any spikes with MongoDB connections number, as Lambda containers are nicely reused and will use the same connection pool. Single microservices may have Lambda handlers invoked by different types of events (e.g HTTP, SNS or Scheduled).Īs we still use MongoDB and Redis, Lambda functions that need access to the database are running in our separated VPC that is peered with the databases’ private network. We divide Lambda microservices by their business domain - like "Payments" or "Jira Integration". Server Side Rendered web applications - yep, we do SSR on Lambda :-).All of these integrations are running serverless. Integrations’ microservices - Droplr is richly integrated with other platforms like Jira, Confluence and Trello.We needed to take care of all the public-facing microservices… : Once we had this done, the fun part started. Functions invoked by events - when a new drop (a file that is being shared) is created, multiple Lambda functions are invoked in parallel by AWS SNS notification.Scheduled tasks - things that should run periodically, CRON-like.For that reason we approached the process strategically.įirst of all, we decided to migrate all of our workers that are processing background jobs: Our Serverless architectureįrom the very beginning, we knew we wanted to make a large portion of our infrastructure Serverless. It's been quite a journey, but well worth setting off on! Read on for a deeper dive. Today we're leveraging several Lambda-hosted microservices on top of our existing architecture. So, we started doing some PoCs on the Serverless Framework. Our main goals were to boost productivity and inspire innovation-make it super easy and fun for developers to deploy their own production-grade microservices. Our main goal was to make our development process even as streamlined as possible. We immediately knew we wanted to give Lambda a try. Lambda could help us eliminate some of that unneeded complexity. It carried some problems: rapid deployments, complexity of Docker-based microservices architecture and underutilized EC2. When we first heard about AWS Lambda, we were using a Docker-based microservices architecture. We're used by more than 500,000 users, who share thousands of screenshots, screencasts and files every day-so we're constantly looking for technologies that empower growth. I'm Antoni Orfin, a Solution Architect at Droplr.
0 kommentar(er)
