A couple of yr in the past we began discussing the principle elements and the software program stack that we’d use to construct Caribou.
Caribou is a SaaS developer tool that may be put in in your GitHub account as a GitHub utility and supply insights about how you might be progressing on eradicating technical debt out of your codebase.
For instance, if you wish to transfer your mission from Java to Kotlin and also you wish to monitor this migration then all you could do is outline a rule to inform Caribou which recordsdata you have an interest in monitoring.
Caribou then runs an evaluation after each pull request is merged, offering you with real-time information about how the migration is progressing, when the estimated end date is, who’s contributing to it, and extra!
The principle technical elements wanted for Caribou are:
When it got here to designing our resolution and making technical selections, a very powerful standards was growth pace; we needed to get an MVP out shortly, after which iterate from there primarily based on customers’ suggestions. This meant selecting applied sciences and instruments that we have been accustomed to, prioritizing the utilization of off-the-shelf merchandise reasonably than constructing issues ourselves, and selecting instruments that had the smallest studying curve or had good documentation and communities round them that will assist us rise up to hurry quick.
This text will deal with the three primary choice selections across the backend, particularly:
What we ended up with was a backend written in Kotlin, constructed with a serverless structure on AWS Lambda, utilizing the Micronaut framework. Let’s now undergo these 3 selections in additional element:
The primary query that we set for ourselves is whether or not we’d use a serverless structure for our backend, or stick with a extra conventional resolution of a number of companies deployed inside containers.
Excited about our authentic requirement round pace, serverless intrigued us, because it meant that we would wish to deal with fewer issues. For somebody coming into backend growth for the primary time, the myriads of AWS container companies (ECS, EKS, Fargate, Kubernetes to call a couple of) have a reasonably steep studying curve.
On the flip aspect, serverless has a quite simple mannequin that permits you to solely fear concerning the code that you’re executing, and let the platform service supplier fear about the whole lot else, so far as infrastructure and scalability are involved.
To check our speculation that serverless could be quicker and less complicated for us to make use of than utilizing containers, we constructed a easy dummy backend with AWS Lambda related to a single REST API (utilizing AWS API Gateway) and managed to get a way of which one is the quickest to construct for us. AWS lambda received palms down.
Apart from that it’s value noting that:
Nevertheless, there have been some downsides as properly:
