In a previous post, I explained the role Apache Kafka plays in production-grade ELK deployments, as a message broker and a transport layer deployed in front of Logstash. As I mentioned in that piece, Redis is another common option. I recently found out that it is even more popular than Kafka! Known for its flexibility, performance and wide language support, Redis is used both as a database and cache but also as a message broker.

As a cloud provider and DevOps-focused company, we definitely want to practice what we preach. We see the benefits of a modern cloud native architecture, so we built our hosting of www.civo.com and api.civo.com (our application) to take full use of these modern decisions. This post describes our approach to Continuous Integration (CI) and Continuous Deployment (CD) from a Chief Technical Officer's perspective.

Ben Kehoe wrote a post about AWS API Gateway to Lambda integration: How you should — and should not — use API Gateway proxy integration with Lambda. In his post, Ben gave a few reasons why he believes using API Gateway Proxy Integration is an anti-pattern. Ben does a great job summarizing how the integration works. He writes: The pattern that I am recommending against is the “API Gateway proxy integration” as shown in the API Gateway documentation here.

Every day that I commute home, I check Google Maps for the next Trimet bus arrival at the usual stop. There’s nothing wrong with this ritual but it always distracts or leaves me stalled for a few empty minutes. Ever the proponent of laziness automation, I decided to build a stack that will do this for me by texting incoming arrival times for my bus home.

No matter what tools your team uses, more effective collaboration results from sharing information and context, being able to react quickly, and automating repetitive processes. Development teams move faster when they can consolidate information in one central hub and can reduce context switching by switching less between different tools.