People don't build flexible apps any more it seems.
Yesterday I used the IDistributeCache in Dot Net Core to add some distributed caching for my session related variables. Then as I switched gears back to the data layer, I remember that NHibernate worked with Redis, which is the primary cache provider that I'm anticipating that we will use.
But, I hadn't written my app to be dependent upon Redis. Instead, I took a page from the Microsoft samples and took it a step further. In the examples, it detects a dev environment and uses an in memory cache instead. In mine, I allowed a config to specify the provider and configuration parameters so that I could support Redis, Sql or in memory. My local environment defaults to in memory and when loaded in Docker the default environment variable sets it to use Redis.
All good.
Now, if I had decided that "screw it, I'm just going to force Redis on everyone" that I could probably find a quick document. But no. I like applications which provide choice. And hey! NHibernate supports IDistributedCache as a cache provider. Sort of.
Firstly, the documentation is scarce. And I couldn't find a single example of anyone actually doing it. I ultimately did get it working. It just happened to take 3 different posts stitched together. But, hey! It works.
And all of this leads me to my bigger point. Historically, when I'm doing something interesting with code, I can find a million people who have blazed that trail before. But, lately, I'm finding that this is increasingly only the case when I want to be stuck in a very niche corner.
I think this mentality goes back to my complaints about solutions like ZoneMinder and Shinobi forcing certain systems on you.
It's bad enough in my opinion that these solutions don't always offer freedom. But, it is even going beyond that. And containerizing things is partly to blame I think. And that problem is control of the solutions involved is often being taken away as well.
The application I'm working on is configurable in and of itself. With that configuration exposed via environment variables. The environment itself is built from a multi-image docker-compose file rather than a single Docker image. All of this lends itself to a solution where even if your choices may be limited, it is easy enough to A) make the choice, and B) control the choice.
Maybe this is just something that is becoming an old fashioned way of thinking. But, if your solution needs to lean on a 3rd party solution which is a complete product in it's own right. Like a database or a cache provider. You should either keep those components separate from your application where possible, or you should at least expose a decent level of configuration of those services from your application.
The reasoning is simple; if you're using something as big as MySQL or as critical to your operations as Redis, you would probably only default those environments to parameters which make sense to a subset of your own customers. You may not even be proficient enough to truly maximize it for any situation.
These are also very common solutions. So, you may be forcing multiple installs on someone who doesn't need it.
That containerization may be to blame in part is a little ironic. It is these exact problems which make these solutions less ideal to scale out as containers were meant to. You end up with monolithic containers which may even be duplicating services which should never have been running on the same physical hardware, let along container.
I know, many people use Docker for more pedestrian tasks. And for them, this can make life easier.
But, many miss the mark in hilarious ways. Shinobi for instance supports SQLite. The Docker image defaults to MariaDB though and it comes pre-installed and pre-configured. I stand by my claim that since the recordings are on disk, most users would likely get good enough (if not better) performance from SQLite than MariaDB, and it would have made the image lighter and the whole thing less wasteful.
Anyway, didn't meant to circle back to that rant.
But, I hadn't written my app to be dependent upon Redis. Instead, I took a page from the Microsoft samples and took it a step further. In the examples, it detects a dev environment and uses an in memory cache instead. In mine, I allowed a config to specify the provider and configuration parameters so that I could support Redis, Sql or in memory. My local environment defaults to in memory and when loaded in Docker the default environment variable sets it to use Redis.
All good.
Now, if I had decided that "screw it, I'm just going to force Redis on everyone" that I could probably find a quick document. But no. I like applications which provide choice. And hey! NHibernate supports IDistributedCache as a cache provider. Sort of.
Firstly, the documentation is scarce. And I couldn't find a single example of anyone actually doing it. I ultimately did get it working. It just happened to take 3 different posts stitched together. But, hey! It works.
And all of this leads me to my bigger point. Historically, when I'm doing something interesting with code, I can find a million people who have blazed that trail before. But, lately, I'm finding that this is increasingly only the case when I want to be stuck in a very niche corner.
I think this mentality goes back to my complaints about solutions like ZoneMinder and Shinobi forcing certain systems on you.
It's bad enough in my opinion that these solutions don't always offer freedom. But, it is even going beyond that. And containerizing things is partly to blame I think. And that problem is control of the solutions involved is often being taken away as well.
The application I'm working on is configurable in and of itself. With that configuration exposed via environment variables. The environment itself is built from a multi-image docker-compose file rather than a single Docker image. All of this lends itself to a solution where even if your choices may be limited, it is easy enough to A) make the choice, and B) control the choice.
Maybe this is just something that is becoming an old fashioned way of thinking. But, if your solution needs to lean on a 3rd party solution which is a complete product in it's own right. Like a database or a cache provider. You should either keep those components separate from your application where possible, or you should at least expose a decent level of configuration of those services from your application.
The reasoning is simple; if you're using something as big as MySQL or as critical to your operations as Redis, you would probably only default those environments to parameters which make sense to a subset of your own customers. You may not even be proficient enough to truly maximize it for any situation.
These are also very common solutions. So, you may be forcing multiple installs on someone who doesn't need it.
That containerization may be to blame in part is a little ironic. It is these exact problems which make these solutions less ideal to scale out as containers were meant to. You end up with monolithic containers which may even be duplicating services which should never have been running on the same physical hardware, let along container.
I know, many people use Docker for more pedestrian tasks. And for them, this can make life easier.
But, many miss the mark in hilarious ways. Shinobi for instance supports SQLite. The Docker image defaults to MariaDB though and it comes pre-installed and pre-configured. I stand by my claim that since the recordings are on disk, most users would likely get good enough (if not better) performance from SQLite than MariaDB, and it would have made the image lighter and the whole thing less wasteful.
Anyway, didn't meant to circle back to that rant.
Comments
Post a Comment