KYD joins the serverless train
This blog post is about how the company KYD(https://kydcoin.io) manages their infrastructure using the Amazon Web Services where they run a complete serverless architecture as a backbone for the upcoming KYD platform. They make use of a couple of amazon services including (S3, DynamoDB, API Gateway, Lambda, Cognito) and are able to deploy their complete infrastructure using the ServerlessFramework. They make use of the Gitlab CI to automatically run tests and deploy to Amazon where they run 3 test environments (dev, alpha, beta) and their production environment.
First let me introduce myself.
I am Bob Thomas(23) and currently I am the CTO at KYD where I manage the development team and work on the platform as well. I have been working in the web development sector since I was 18 and have been involved with deploying and building web shops for companies like T-Mobile and KPN. In my free time I build weird IoT projects like skateboards that measure your jump height and keep track of them in a scoreboard.
What is KYD?
Know Your Developer (KYD) is a company that is working on reducing scams in the cryptosphere. They are doing this by personally verifying the people behind cryptocurrency projects. After the project gets verified it will gain a KYD stamp of approval and it gets added to the reviewed list at https://review.kydcoin.io. This is however not the only thing KYD is working on right now. KYD is also building a hiring platform where developers and project owners can register and will be personally verified by KYD as well. Once they are verified they can register new projects or hire other verified developers to work on their projects. By doing this KYD wants to reduce the scamming between developers and project owners.
Why use a serverless architecture?
Why would we use a serverless architecture at KYD?
Well the answer is quite simple. It is because we are a company that just started with a small developer team that is lacking experience with managing servers and scaling systems. Because of this we made the decision of building our platform using the serverless architecture as a backbone because this will save us time and costs during the start of the project.
Why Amazon Web Services?
Why not use Google cloud or Azure or any of the other providers that are out there? The decision to use Amazon Web Service as our serverless provider is because our development team had prior experiences with Amazon Web Services, and we wanted to be able to reuse our knowledge and not keep reinventing the wheel.
The architecture and how it connects
In this section we will discuss which AWS services we use and how we deploy them.
Which AWS services do we use?
To get a better understanding of our architecture you need to know what services from AWS we use and why.
AWS Lambda — > To create functions and control our platform
API Gateway — > To connect our Lambda functions to at URL
DynamoDb — > To store data and retrieve data in our Lambda functions
Cognito — > To handle user authentication and registration
S3 — > To store files and host our frontend
CloudFront — >To add custom domains to our API and frontend
With these services we are able to create our platform without the need of hosting assets and resources ourselves because AWS takes care of all of it. To give some insight on how it would connect see figure 1
Making use of the Serverless Framework
To standardize the creation of new API resources we make use of the serverless framework. This framework gives you the ability of managing and deploying your complete serverless infrastructure and has specific conventions to keep your project readable and maintainable. The reason why we use it is that we want to be able to deploy our full infrastructure. Containing the creation of all the before mentioned services and be able to rollback to previous versions. Or to deploy to one of our testing environments like (alpha, beta, dev). Our project structure is stable and well-defined because of the convention the serverless framework taught us as you can see in the image below (figure 2).
Deploying our platform
To steadily deploy our platform we make use of the gitlab CI. The reason we use Gitlab CI is because we are hosting our code on gitlab, they offer it for free and it’s easy to set up and get going. To give some insight in our setup look at snippet 1 as example of how our backend configuration is structured. This is not the final configuration but just a snippet on how you could structure it.
As you can see we are able to deploy to four stages (alpha, beta, dev, production) by manually clicking the deploy button in Gitlab. We created a similar configuration for our frontend deployment but because the frontend needs to know what API to connect with we need a way to define this in the build process. We do this by adding Gitlab CI variables for every stage. In snippet 2 you can find an example of our frontend deployment configuration this is not a final version but an example of how you can deploy a frontend using the Gitlab CI. In snippet 2 you can clearly see how we attach Gitlab variables like $PROD_API_GATEWAY_URL to a environment variable that will be used during the frontend build.
That was a quick run through our still growing serverless infrastructure. We still have major steps to go and lots to learn about how to handle a serverless application at scale but in the short amount of time we have been working on the platform we accomplished a lot of things and realized many ideas. We hope that this article gave you some clarity about the systems running behind KYD and the way we implemented Amazon Web Services.
For any questions regarding KYD please visit our discord at
For any questions regarding AWS and our architecture place them in comment below and I will answer them to the best of my ability