wanna be a software craftman step by step

When I think of Lambda, an AWS serverless service, it seemed like a magical box. Once I create a lambda function, I imaged that AWS will do everything that I need except for business logic. However, I found that there are several things to think of when you are about to decide to go with lambda. 1. Cold start Before reading the official documents, the word "serverless" meant to me that containers are already provisioned and waiting for me to deploy the program. Honestly, I expected AWS to provide me warmed-up computing power. However, it turned out that AWS doesn't maintain containers. So the first invoke will take too long and if you attach VPC to the lambda function, elapsing time become worse. In my experiences, the average elapsed time to invoke function at first was about 18~20 secs. All the thing my function did was residing in VPC and querying to empty RDS database table. After that it took 300~500ms. ( Please be noted that I invoke lambda function in AWS reg...

Last week, I developed Lambda functions on AWS. I made 7 functions and each function was responsible for the corresponding API. Lambda functions' role was relaying an HTTP request to a 3rd-party server, storing the process result and responding with it. In short, each lambda function is functioning as an API service. From the whole project, my role is developing the backend side of the project. This week was the first sprint. My manager told me to complete the basic development by the end of the sprint. Basic development means that APIs are exposed so that Web developers could build the web pages. It doesn't have to be fully functioning. But It should be able to guide Web developers on how to build the web site. Goal - Make running lambdas in accordance with spec document. Sprint - Start date: Monday - Due date: Friday What I did -Monday: learn how to use Lambda, search about pooling with Lambda -Tuesday: add a basic handler and 5 other handlers. -Wednesday: add ...

 Recently, I have received a task at work. There is a microservice which is a push message broker. It is provided with messages from service servers and sends those messages to GCM, APNS, and etc. This service handles requests well and everything is fine.  However, scalability and availability were not considered when this service was implemented at first. As I am making use of Auto Scaling Group on AWS environment now, I need to think about adding these necessary features to the service.  After below review, using ASG on this service deferred. Let me explain why. Current Architecture  As a push message broker, the service is consists of two modules: producer and consumer. Also, this service should store push messages somewhere. Currently, Cassandra is adopted as message storage. So basically, producers put push messages to Cassandra and consumers take out messages from Cassandra.  To deal with massive traffic from service servers, I am managi...