Meetup April: SageMaker, DeepLens & Message Driven Architecture

Thanks Mirabeau, for inviting the AWS Amsterdam Community at your HQ.

* 18:00-18:45 Doors open, food & drinks (doors close at 18:45!)
* 19:00-20:00 'Tic Tac Toe' with SageMaker and DeepLens
- short break -
* 20:15-21:00 Message Driven Architecture and SQS, SNS and Kinesis
- drinks & network -

19:00 - 20:00 'Tic Tac Toe' with SageMaker and DeepLens
Lotte-Sara Laan (Mirabeau), Wouter de Geus (Mirabeau) and Thijs de Vries (Binx.io)

AWS launched the AWS DeepLens at re:Invent, a programmable video camera with pre-trained models. The DeepLens has several skills, including object and activity recognition. A great device to build games. With a DeepLens in the center, 2 players will use the speech assistant when they are ready for their move. By positioning their hand or an object in one of the 9 areas, the DeepLens detects the players' move and displays it on an Echo Spot. In this talk, Mirabeau and Binx.io teamed up, and are excited to show their approach and findings so far. Talking about services like Lambda, Athena, SageMaker and of course DeepLens.

20:15 - 21:00 Message Driven Architecture and SQS, SNS and Kinesis
Maik Broxterman (Insided)

If you start with a message driven architecture, you could make many different technical choices. AWS provides with SNS, SQS and Lambda a highly reliable, cost effective, simple and above all flexible messaging solution. This talk discusses the implementation and shows how the alternatives could perfectly complement it.

When we were pointed at this by an AWS evangelist it sounded almost too simple to be true but it is almost flawless.

* Whether you practice Domain Driven Design or not, the benefits of using 1 SNS topic per (domain) event are huge; SNS topics are almost limitless in throughput and subscriptions that you can make to it. The 1 topic per event makes your architecture very explicit. It avoids middleware overhead and gives development teams ultimate freedom to receive only the events they are interested in. Meanwhile you only pay for what you use.
* Through examples I’ll show why we chose SNS + SQS/Lambda as our base messaging architecture over non-AWS solutions like Rabbitmq or Kafka, AWS services like Kinesis, or messaging directly through SQS queues
* How every team can subscribe every single topic to their own service’s SQS queue(s) or Lambda(s) and forward events of interest to Kinesis, Step Functions or non-AWS messaging system that fits their purpose.