Today I would like to show you how to build Slack Bot using serverless approach on AWS infrastructure. We are going to support our efforts using AWS Chalice framework. Our Slack Bot is going to be a dummy one. It will respond with a message we send to it. However this article is not about implementing sophisticated bot behavior. We want to setup whole stack which will be a foundation for further development.
Motivation You may have noticed the first part here. If not, it is more or less a business case for serverless computing. I have explained there the what and whys behind serverless, but also talked about the architectural, economic and operational impact that it has on your systems and products. We have left a fascinating question there, wondering if the first word in FaaS acronym (function as a service) means something, for the functional programmers.
Motivation Can we use a functional programming language with AWS Lambda? Someone in our team, a year ago It is incredible how a single question can direct you into an exciting place. Journey through that rabbit hole turned out to be a crazy, but excellent chance to build know-how which we can leverage for our clients. Today I do not tell you how much yak-shaving is required to use our beloved functional languages in serverless.
We don’t need expressive language, except when we need it By the end of August AWS released a developer preview of the Cloud Development Kit (aws-cdk in short), which allows you to codify infrastructure code in your language of choice. A real programming language. You may ask: why is it a big deal? Imagine that you have to prepare 30 IAM user accounts and S3 buckets with the following permissions:
What is it? If you have not heard about Cloud Olympics organized by Chmurowisko I encourage you to check our review of the qualification round here. If you read that one, you noticed that I did not make it to the finals (I was 3rd in the Cracow’s qualification round, just first two places were promoted to finals). But… life is full of surprises! It turned out that one of the guys from the first two places could not make it.
gen_event confused me from the beginning, so I wanted to investigate the topic more deeply. I did that here. Then I left that topic, and it returned recently to me when I was wondering how the situation changed since then. Here is the updated version of the initial investigation, which started with the following statement: I never used a gen_event, I think it is a bad pattern. At first, it may look like a controversial statement, but I heard a lot of those complaints from other people.
What is this about? You may want to check our previous article to gather some insights about Microservices in general. In this blog post, I’d like to present my very subjective view on 10 traits that when present, will make Microservices much pleasant to use by developers … and ultimately put a smile on their faces :) Ten traits of Microservices that make developers happy Recently I had a meeting with experienced architects - we wanted to define what Microservice means.
Motivation In this blog, we want to gather valuable resources about Microservices in a single place. Bookmark it, because we update it in the future. Theory Martin Fowler described Microservices well, and we believe it is a good start. The best way to start with microservice topic is following presentation: Above presentation is an excellent introduction to Fowler’s article available here. Keep in mind that presentation does not cover the whole article, so we encourage to read a whole article.
Joy or Pain of Constant Cooperation? The biggest lie of Computer Science studies is the premise that we will work solely with computers. Dealing only with tough engineering problems, we will work only with predictable and logical silicone matter. That is an engineering utopia. If you work long enough in that business, you know that it is not going to happen. IT is immensely teamwork oriented. People-stuff will surface everywhere, and that is good.
In this post I want to show how to add another endpoint in Phoenix Framework, that is going to listen on a different port. I found out that this topic is not well described in the internet. In our case, this endpoint will be serving a very simple API returning status of the app. The following instructions work with Phoenix version 1.3.2 A separate endpoint gives extra security The first question that comes to mind is “why?