Checkly Inc.

When adding a new feature to Checkly rearchitecting some older piece, I tend to pick Heroku for rolling it out. But not always, because sometimes I pick AWS Lambda . The short story:

• Developer Experience trumps everything.
• AWS Lambda is cheap. Up to a limit though. This impact not only your wallet.
• If you need geographic spread, AWS is lonely at the top.

The setup

Recently, I was doing a brainstorm at a startup here in Berlin on the future of their infrastructure. They were ready to move on from their initial, almost 100% Ec2 + Chef based setup. Everything was on the table. But we crossed out a lot quite quickly:

• Pure, uncut, self hosted Kubernetes — way too much complexity
• Managed Kubernetes in various flavors — still too much complexity
• Zeit — Maybe, but no Docker support
• Elastic Beanstalk — Maybe, bit old but does the job
• Heroku
• Lambda

It became clear a mix of PaaS and FaaS was the way to go. What a surprise! That is exactly what I use for Checkly! But when do you pick which model?

I chopped that question up into the following categories:

• Developer Experience / DX 🤓
• Ops Experience / OX 🐂 (?)
• Cost 💵
• Lock in 🔐

Read the full post linked below for all details

Vue.js Intercom JavaScript Node.js vuex Vue Router

My SaaS recently switched to Intercom for all customer support and communication. To get the most out of Intercom, you need to integrate it with your app. This means instrumenting some code and tweaking some bits of your app's navigation. Checkly is a 100% Vue.js app, so in this post we'll look at the following:

• Identifying a user with some handy attributes
• Getting page views right with Vue Router
• Sending events with Vuex
• Some nice things you can now do in Intercom

After finishing this integration, you can actively segment your customers into trial, lapsed, active etc. etc.

AWS Lambda Serverless Amazon CloudWatch Azure Functions Google Cloud Functions Node.js

In the last year or so, I moved all Checkly monitoring workloads to AWS Lambda. Here are some stats:

• We run three core functions in all AWS regions. They handle API checks, browser checks and setup / teardown scripts. Check our docs to find out what that means.
• All functions are hooked up to SNS topics but can also be triggered directly through AWS SDK calls.
• The busiest function is a plumbing function that forwards data to our database. It is invoked anywhere between 7000 and 10.000 times per hour with an average duration of about 179 ms.
• We run separate dev and test versions of each function in each region.

Moving all this to AWS Lambda took some work and considerations. The blog post linked below goes into the following topics:

• Why Lambda is an almost perfect match for SaaS. Especially when you're small.
• Why I don't use a "big" framework around it.
• Why distributed background jobs triggered by queues are Lambda's raison d'être.
• Why monitoring & logging is still an issue.

https://blog.checklyhq.com/how-i-made-aws-lambda-work-for-my-saas/

Let's Encrypt Amazon EC2 Heroku Node.js Vue.js JavaScript

We recently went through building and setting up free SSL for custom domains for our @{#SaaS}|topic:null| customers. This feature is used for hosting public status pages and dashboards under the customers' own domain name.

We are in the #Node.js, #AWS and #Heroku world, but most of the things we learned are applicable to other stacks too.

The post linked goes into three things:

1. Configuring the Let's Encrypt / ACME client called Greenlock.
2. Getting DNS right on @{Amazon Route 53}|tool:38|
3. Actually determining what content to serve based on hostname.

All seem pretty straightforward, but there are gotcha's at each step.

Hope this helps other budding SaaS operators or ops peeps that need this functionality.