Schema and application are bound together and also it's dev's role to mantain both. That's why i see little benefit of using CRD's here. On the other hand all true about Liquibase issues on Spring while rolling out k8s deployments. I was forced to manually disable migration and to supervise rollouts in order to avoid lockouts. Init containers may introduce complexity and additional actors in this nice race condition we used to have. Would it be possible for for Liquibase to make use of a sort of atomic lock? In case of rollouts there is also a question of old pods running against the newer version of database.
@@DevOpsToolkit Application and it's database schema are closely coupled across all versions which emerge during the lifetime. Since devs define the schema it's more natural for them to use their own ecosystem for managing that. If you use CRD based solution you'd rather end up with schema being managed in two places. Viktor, do i miss any benefit which justifies that? :)
@@bartekr5372 Assuming that app is running in Kubernetes when in production, it makes a lot of sense to use the same (or similar) manifests in other envs. That means that devs might be using Docker Desktop (or something similar) to run the app on their laptop. Otherwise, they might need to create separate definitions of the app for different envs. Now, if Kubernetes is used locally, I feel that SchemaHero makes a lot of sense. How do you run your app? `helm install` should do (or whichever other format is used) to deploy it. If that's the case, SchemaHero will likely be part of that Chart so, among other things, schema is managed together with other components required for the app. What I'm trying to say is that if something like `helm install` is used to deploy the app and to create, let's say, PostgreSQL DB, I think that putting schema into that same chart makes perfect sense. Now, it does not have to be SchemaHero. Almost any other solution can run as a container so any other solution should work in a Helm chart. Another note is that Kubernetes is not very user-friendly since (out of the box) it deals with low level components. More often than not, CRDs are a way to create higher-level easier-to-understand-and-manage resources (e.g., Knative).
@@DevOpsToolkit Just for clarity so you can understand more details: my artifacts are free of any environment-related configurations so i am free to use them whatever environment i wish. Environment configuration is passed via values.yaml and db schema does not depend on environment (wchich would be rather terrible idea). This forms a sort of split: application has embedded schema (managed by devs within the code) and environment configuration is defined in values.yaml (managed mostly by me). Reason being that schema relation to the application version is stronger than relation to the configuration version or environment. Question is if application running such database can be schema-agnostic. For relational databases answer is rather no - therefore conclusion: CRD in this one particular case is bad because it forms another source of schema (truth) which you must mantain. Speaking about local development, app-embedded schema can also be used in regular docker locally or even standalone. You just pass endpoint and credentials to connect. In such case app is going to check for any preinjected data or just create empty one. Personally i like idea of using Crossplane CRD's for creating the postgresql database instance as it is part of infrastructure and a given environment. Schema is closely coupled with application and it's version (not with environment) so it is the opposite case. That's why i'd be happy to see that old issues with k8s Deployments resolved.
With these solutions, can you still use database vendor specific features? Example: table partitioning or logical replication, jsonb or custom datatypes in postgres? Do I have to settle for the lowest common denominator of supported databases?
I'm not sure about SchemaHero (I used it always with PostgreSQL and MySQL without using any "special" features). Liquibase does support "specific" features.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Schema and application are bound together and also it's dev's role to mantain both. That's why i see little benefit of using CRD's here. On the other hand all true about Liquibase issues on Spring while rolling out k8s deployments. I was forced to manually disable migration and to supervise rollouts in order to avoid lockouts. Init containers may introduce complexity and additional actors in this nice race condition we used to have. Would it be possible for for Liquibase to make use of a sort of atomic lock? In case of rollouts there is also a question of old pods running against the newer version of database.
I'm curious why you think that CRDs are not for devs?
@@DevOpsToolkit Application and it's database schema are closely coupled across all versions which emerge during the lifetime. Since devs define the schema it's more natural for them to use their own ecosystem for managing that. If you use CRD based solution you'd rather end up with schema being managed in two places.
Viktor, do i miss any benefit which justifies that? :)
@@bartekr5372 Assuming that app is running in Kubernetes when in production, it makes a lot of sense to use the same (or similar) manifests in other envs. That means that devs might be using Docker Desktop (or something similar) to run the app on their laptop. Otherwise, they might need to create separate definitions of the app for different envs. Now, if Kubernetes is used locally, I feel that SchemaHero makes a lot of sense. How do you run your app? `helm install` should do (or whichever other format is used) to deploy it. If that's the case, SchemaHero will likely be part of that Chart so, among other things, schema is managed together with other components required for the app.
What I'm trying to say is that if something like `helm install` is used to deploy the app and to create, let's say, PostgreSQL DB, I think that putting schema into that same chart makes perfect sense. Now, it does not have to be SchemaHero. Almost any other solution can run as a container so any other solution should work in a Helm chart.
Another note is that Kubernetes is not very user-friendly since (out of the box) it deals with low level components. More often than not, CRDs are a way to create higher-level easier-to-understand-and-manage resources (e.g., Knative).
@@DevOpsToolkit Just for clarity so you can understand more details: my artifacts are free of any environment-related configurations so i am free to use them whatever environment i wish. Environment configuration is passed via values.yaml and db schema does not depend on environment (wchich would be rather terrible idea). This forms a sort of split: application has embedded schema (managed by devs within the code) and environment configuration is defined in values.yaml (managed mostly by me). Reason being that schema relation to the application version is stronger than relation to the configuration version or environment. Question is if application running such database can be schema-agnostic. For relational databases answer is rather no - therefore conclusion: CRD in this one particular case is bad because it forms another source of schema (truth) which you must mantain.
Speaking about local development, app-embedded schema can also be used in regular docker locally or even standalone. You just pass endpoint and credentials to connect. In such case app is going to check for any preinjected data or just create empty one.
Personally i like idea of using Crossplane CRD's for creating the postgresql database instance as it is part of infrastructure and a given environment. Schema is closely coupled with application and it's version (not with environment) so it is the opposite case. That's why i'd be happy to see that old issues with k8s Deployments resolved.
Liquibase, hands down.
With these solutions, can you still use database vendor specific features? Example: table partitioning or logical replication, jsonb or custom datatypes in postgres? Do I have to settle for the lowest common denominator of supported databases?
I'm not sure about SchemaHero (I used it always with PostgreSQL and MySQL without using any "special" features). Liquibase does support "specific" features.