Nautobot Ecosystem Architecture - Distributed and Scaling

[fischerdouglas]

I'm studying a little about Nautobot's deployment methods, and I confess that I'm a little confused about how to separate the mechanism's gears to have a little more load distribution and who knows even an increase in availability.

It wasn't clear to me which services would need to be in the same monolith, and which could be separated.

Maybe I can't express myself so well in the scope of Nautobot.
But one tool I like to reference is Zabbix and Zabbix-Proxy. This methodology makes it possible to have a more distributed presence, improve the level of availability of part of the services in a simple way, and relieve computational resources from the central point.

Is something like this possible with the different parts of the Nautobot ecosystem?
For example the Napalm/Nornir/Ansible workers...
Do they need to be bound to the monolith? Can I have multiple distributed workers? How does Nautobot handle this?

Thank you in advance for your patience and understanding...

[jdrew82]

@fischerdouglas Great question and I'm glad you asked! Nautobot isn't really a monolith and is meant to be more of a microservices architecture. You can learn more about the specific parts of the Application Stack and how it works at the provided link. The main components to understand about Nautobot's architecture are:

1. The web service handles all UI interactions through the browser and API queries. This would be the normal nautobot container in a container setup.
2. The task worker service handles all Job tasks that are run in the environment. In a container setup, this would be the nautobot-worker container.
3. The database is the last portion and possibly the most important portion of your environment regarding scaling as all interactions with Nautobot will typically utilize the database in some regard.

When talking about distributing and scaling the load that your environment handles you'll need to understand what your usage patterns are and where you expect the load to be. Here are a few typical use cases:

1. Your usage is heavily dependent upon API queries to Nautobot. In this case, you'd want to scale out the web service to handle the additional queries and potentially your database structure depending upon whether these queries are slanted more towards reads or write.
2. Your usage is heavily Jobs based. In this case, you'd want to scale out the task workers and potentially set up Task Groups for certain particular tasks, ie one group for Golden Config stuff, one for pushing changes out to the fleet, etc. Again, you'll need to understand how these tasks utilize the database to understand how you'll want to scale the database.

Regarding the database scaling, if you're doing a large number of reads from the database that it would be prudent to add some read-only slaves to your setup. If you were doing a lot of writes you'll probably want to work on a Master/slave cluster setup with some additional write nodes.