Terraform from HashiCorp is a cloud infrastructure automation tool that enables users to create, change, and improve production infrastructure, and it allows infrastructure to be expressed as code. It codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. It is available Open Source, and via Cloud and Self-Hosted editions.
$0
Liquibase
Score 8.0 out of 10
Enterprise companies (1,001+ employees)
Liquibase is a database change management tool that extends DevOps best practices to the database, helping teams release software faster and safer by bringing the database change process into existing CI/CD automation. According to the 2021 Accelerate State of DevOps Report, elite performers are 3.4 times more likely to incorporate database change management into their process than low performers. Liquibase value proposition: Liquibase speeds up the development…
Dbt was fine, but you end up with an extremely bloated repo/project. Often where all of the models are the same, named similarly, and generally just doesn't adhere to the concept of DRY coding. In Terraform we're able to template a lot of this work and dynamically generate …
HashiCorp Terraform is much better than Cloud Formation. For one, the language is just easier to use, but more importantly, the provider ecosystem is much better in HashiCorp Terraform than in Cloud Formation.
I'm beginning to look at Pulumi. In my opinion, it looks like it would be a good replacement for HashiCorp Terraform, and it has the advantage of configuration via scripting, rather than via HCL, which is HashiCorp Terraform configuration markup language. In my opinion, the …
We have used Vagrant to develop our application in a virtual box environment and prepare it to be packed with Packer. The image created from these two tools will be deployed by Terraform.
We are using Consul for service discovery and as a job locking so we don't have two jobs or …
CloudFormation is only for AWS so if you're trying to deploy to another cloud provider then Terraform is your product. Terraform has lots of public support so you can find answers to questions by Googling. CloudFormation is easy to view the resources/services that are …
Terraform is a large step ahead of the previous generation of infrastructure-as-code providers. I'd never go back to, e.g. Puppet or Chef, Ansible, etc. That said I think that Pulumi has a good chance of displaying it, in no small part because the Terraform language itself …
AWS CloudFormation is better if you just want to stick with AWS because it's integration with AWS is better, provides auto-rollback in case of failures, and has GUI to manage and view the stacks built. Terraform is better when we want to stay cloud-agnostic. Terraform is better …
I can't find these applications listed, but other IaC tools I have used include: AWS CloudFormation, Azure Resource Manager Templates, and GCP Cloud Deployment Templates. For a comparable tool, I have the most experience with CloudFormation.
Chef and Terraform are not apples to apples because Chef is more focused on config management, whereas Terraform is more focused on provisioning. However, I can say that where they do overlap in configuration management is that Terraform is the preferred tool because it has an …
Terraform is the solid leader in the space. It allows you to do more then just provisioning within a pre-existing servers. It is more extensible and has more providers available than it competitors. It is also open source and more adopted by the community then some of the other …
Terraform is open source and has strong community support. It is cloud-agnostic versus competing products like AWS cloud formation, hence has a distinct advantage. The scripts once set up are easy for developers to administer during development, hence during production …
- Terraform syntax is much easier to read and learn than Cloud Formation.
- Terraform already supports AWS as well as several other cloud providers.
- Terraform is backed by a great and supportive open-source community.
Terraform shares the methodology of creating configuration files for your infrastructure with tools like CloudFormation. However, Terraform is cloud-agnostic unlike CloudFormation which is AWS specific. Terraform can be used to maintain AWS and OpenStack clusters …
CloudFormation is the lingua franca of AWS. You certainly can't go wrong using it, but I like the syntax and open-source nature of Terraform. That's mostly a personal preference. I have not tried any other non-Amazon tools for provisioning AWS. And, of course, the AWS tools …
With Flyway you need to Write rollback scripts manually. With Liquibase we have a lot of customization with to rollback with options such rollback-one-changeset or rollback-one-update.
Liquibase supports a wide range of database management systems (DBMS) including MySQL, PostgreSQL, Oracle, SQL Server, and more. It is written in Java and offers command-line, XML, YAML, and JSON configurations. where as Alembic is primarily targeted at SQLAlchemy users, which …
There is no real competitor when it comes to what Liquibase does - at least not at the time we considered it three years ago. It was an easy choice in this regard, but we could have said no to it if it made our workload more difficult. But our proof of concept showed there were …
We adopted Liquibase to complete our Ci/Cd scenarios. Without Liquibase, DB changes were out to scope in our DevOps scenarios. Log and accountability are more clear now.
Liquibase makes it easy to integrate into CI/CD pipelines, keeping the database and code in sync. The switch from one database management system to another is made easier by modeling the structure of the database in DBMS-independent XML rather than SQL. A user-friendly web …
Liquibase is much more powerful compared to Flyway since it is much more flexible in nature. You can apply changes programmatically, works with any kind of database and provides features version controlling database schemas. All these features were missing in Flyway and that's …
To be honest, the option of having a free community plan to start testing in a test environment, followed by taking it in production a few months is a great way to evaluate wether or not to do the subscription based plan.
Liquibase is preferred over Flyway if your engineers doesn’t have knowledge in the DDL language used in each database product supported. If you only need to support a single database product and your engineers have the skills I would recommend Flyway instead. Liquibase is …
Both liquibase and Flyway help you deploy database changes associated with new application deployments. They will both help with reducing database administration tasks and ensure reliability of the application service. Comparing Liquibase and Flyway, I found liquibase to be …
These other products were for infrastucture as code and not as well-suited for managing database changes; instead Liquibase was more oriented towards it and was easier to pick up its syntax also.
Liquibase is head and shoulders better than relying on SQL Compare alone for deployments. I haven't used Flyway, but based on our evaluation, Liquibase seemed to have a lot of functional overlap for considerably less cost. I would recommend the use of GitHub or BitBucket in …
At the time, Liquibase offered a community version and I think Flyway didn’t. In our case, we did not have any previous experience with any database management tools, so we just went with what was free to try out.
8 because it's currently best-in-class and is completely essential to use in contrast to not expressing your infrastructure as code. That said, new contenders are nipping at its heels, and I expect stronger tools to emerge in the coming years. Hopefully the Terraform team is able to keep pace.
Any Codebase that does schema or table changes all the time for development or where Development and code is mostly in the database or SQL liquibase is a must. In a codebase where the database is pretty static or is just a place to dump data, liquibase is probably too much. You also need to have a team for it to really make sense. Doing a solo or small team project doing full version control on the database is probably more overhead than it is worth.
The errors generated by the plan and preview commands are pretty cryptic, it can be hard for newcomers to the scripting language to understand how to address problems.
Access controls around workspaces is limited which makes it harder to secure reduce the scope of teams ability.
Analytics around user usage, applies and plans would be helpful for managemenet.
Reducing Compatibility issues, when we upgraded Liquibase from 4.2 to 4.9. The same changeset which we were able to run on successfully using 4.2, part of it was now failing when tried to deploy using 4.9
We are not able to see detailed logs (for different changes) in uDeploy when deploying changes through Liquibase
Liquibase should rollback the if any one of the changes fails.
We are and will continue using Liquibase and it has become an integral part of our portfolio offering, any new product is by default adopting Liquibase stack.
I love Terraform and I think it has done some great things for people that are working to automate their provisioning processes and also for those that are in the process of moving to the cloud or managing cloud resources. There are some quirks to HCL that take a little bit of getting used to and give picking up Terraform a little bit of a learning curve, thus the rating
Terraform's performance is quite amazing when it comes to deployment of resources in AWS. Of course, the deployment times depend on various parameters like the number of resources to deploy and different regions to deploy. Terraform cannot control that. The only minor drawback probably shows up when a terraform job is terminated mid way. Then in many cases, time-consuming manual cleanup is required.
Terraform is community driven but does offer support for it's Enterprise product. When contacting the team at HashiCorp we have always gotten resolution to our issues. They have been very responsive in returning our calls and answering our questions as they come up. We are currently using the open source model.
Liquibase's customer support team has been very instrumental in helping us drive the whole Database CI/CD initiative. We have always received very quick resolution to our queries or any roadblock we hit. Right from setting up Liquibase in our environment to this date the Liquibase team has always helped us deliver quality and innovative solutions.
dbt was fine, but you end up with an extremely bloated repo/project. Often where all of the models are the same, named similarly, and generally just doesn't adhere to the concept of DRY coding. In Terraform we're able to template a lot of this work and dynamically generate assets based on variables instead.
In my previous project and organization I have used Flyway for database change management and version control similar to Liquibase which I am currently using. Comparing it with Flyway, Liquibase provides more feature flexibility and enhancements to handle complex workflows with rollback capability and its usage of contexts and labels allow us to target changes to specific environments, which Flyway doesn’t support natively. Also Liquibase provides way to compare different schema and generate changelogs for syncing environments automatically where in it allows to have declarative schema management by using XML/YAML/SQL script format.
Using code, we are able to build and deploy cloud resources faster and more consistently than producing the same resources in the console manually.
For applications that share architectures, we can reuse code to expedite development. We can also do the same with modules that are shared across the organization.
By defining all of our resources as code, we can deploy complete environments with "batteries included." For example, we can use code that spins up servers in a cloud provider and at the same time, creates monitors with in our monitoring provider. Likewise, when the servers are decommissioned, the monitors are decommed along with them. In the past, the creation and decom of the monitors would have been a disjointed, manual step. With Terraform we get it all with one "terraform apply."
We are still in the early phases, where the costs are potentially greater than the benefit. Trying to get Liquibase integrated into a pipeline has taken time investment and required some trial and error.
We are still a relatively small shop with a relatively small number of schema changes (perhaps 1 every week or so). As such, we aren't at a place where we couldn't have managed control of this without a tool. However, there is no doubt that investing in a tool at this stage was the right move. Now we have established guidelines and a pattern for how to do schema changes in a way that will make things easily scalable as we continue to grow.