What is the best way to operate a tomodachi service?

Docker containers are great and can be scaled out in Kubernetes, Nomad or other orchestration engines. Some may instead run several services on the same environment, on the same machine if their workloads are smaller or more consistent. Remember to gather your output and monitor your instances or clusters.

Go for a Dockerized environment if possible – preferably orchestrated with for example Kubernetes to handle automated scaling events to meet demand of incoming requests and/or event queues.

Make sure to follow the recommendations for production on good practices when operating services in production or staging environments.

Are there any more example services?

There are a few examples in the https://github.com/kalaspuff/tomodachi/blob/master/examples folder, including using tomodachi in an example Docker environment (with or without docker-compose).

There are examples to publish events / messages to an AWS SNS topic and subscribe to an AWS SQS queue. There's also a similar code available of how to work with pub/sub for RabbitMQ via the AMQP transport protocol.

• Example code: https://github.com/kalaspuff/tomodachi/blob/master/examples

Why should I use this?

tomodachi is a perfect place to start when experimenting with your architecture or trying out a concept for a new service. It may not have all the features you desire and it may never do, but I believe it's great for bootstrapping microservices in async Python.

I have some great additions!

Sweet! Please send me a PR with your ideas. There's now automatic tests that are running as GitHub actions to verify linting and regressions. Get started by cloning the repo and install the dev dependencies.

• Contribution guide: https://github.com/kalaspuff/tomodachi/blob/master/CONTRIBUTING.rst

Is it safe with beta software in production?

There are some projects and organizations that already run services based on tomodachi in production. The library is provided as is with an unregular release schedule, and as with most software, there will be unfortunate bugs or crashes. Consider this currently as beta software (with a strong ambition to work for production use). Would be great to hear about other use-cases in the wild!

Another good idea is to drop in Sentry or other exception debugging solutions. These are great to catch errors if something wouldn't work as expected in the internal routing or if your service code raises unhandled exceptions.

Who built this and why?

@kalaspuff on GitHub

My name is Carl Oscar Aaro and I'm a coder from Sweden.

When I started writing the first few lines of this library back in 2016, my intention was just to learn more about Python's asyncio, the event loop, event sourcing and message queues. A lot has happened since – now running services in both production and development clusters, while also using microservices for quick proof of concepts and experimentation. 🎉

• GitHub: https://github.com/kalaspuff
• LinkedIn: https://www.linkedin.com/in/carloscaraaro/