Microtica vs. GitLab CI

#devops #aws #docker #kubernetes

Microtica and GitLab CI both have the goal to efficiently and reliably deliver software in the cloud. Although both tools have similar features, the differences between the core concepts are significant. That’s why it’s difficult to make a Microtica vs. GitLab CI comparison. However, we’ll try to do it.

GitLab CI is GitLab’s tool for software development that uses continuous methodologies like Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment (CD).

Microtica is a low-code DevOps automation platform that enables companies and individuals to adopt cloud much faster. Microtica does that by standardizing the way we develop and release infrastructure and applications in the cloud.

Overview

The most significant difference in the Microtica vs. GitLab CI comparison is that Microtica is focused on abstracting complex cloud and Kubernetes integrations supported natively in the platform. At the same time, it provides all core features for optimal CI and CD.

On the other hand, GitLab CI/CD requires the use of additional provisioning tools, and you need to write most of the scripts manually to achieve the same you can do with Microtica.

Another disadvantage with GitLab CI is that it has native support only for its own repos. If your source code is located somewhere else you need to import it into GitLab or build a custom integration.

It also doesn’t offer native integration with cloud providers and Kubernetes. For example, if you want to deploy infrastructure and applications on AWS or Azure, you need to know the specifics of how those cloud providers work. Moreover, you need to have a great understanding of their APIs and what are the limitations.

Microtica abstracts many complex integrations, manual configurations, infrastructure, and application delivery processes in the cloud. At the same time, it gives customers flexibility for customization.

Let’s dive deeper into the differences between the two CI/CD solutions.

Comparison

Feature	Microtica	GitLab CI
Native support for different Git providers	✅ Microtica supports native integration with the following VCSs: BitBucket GitHub 🔵 GitLab and other providers are in our roadmap	❌ GitLab has native support only for its own repos. If your source code is located somewhere else you need to import it into GitLab or build custom integration.
Declarative pipelines	✅ Declare pipelines in source code microtica.yaml	✅ Declare pipelines in source code .gitlab-ci.yml
Define multiple pipelines per repo	✅ In Microtica you can define multiple pipelines per Git repository.	❌ While GitLab has multi-project pipelines that give you a view across projects, each pipeline definition lives in a YAML file tied to a specific project. Today, GitLab lacks the ability to define multiple pipelines in a single YAML file
Automatic retry for failed CI jobs	❌ Microtica currently does not support automatic retry of CI pipelines.	✅ You can specify a retry keyword in your .gitlab-ci.yml file to make GitLab CI/CD retry a job for a specific number of times before marking it as failed.
Out-of-the-box support for transferring state between pipeline steps	✅ Everything created in one step is automatically shared with the next steps without any additional configuration. Microtica uses Docker volumes to share state between steps which dramatically reduces the delay overhead.	❌ To transfer state between pipeline jobs in GitLab CI you need to explicitly define and reference artifacts/cache between steps. Artifacts are downloaded and uploaded on each job execution that references the artifacts which slows down the whole pipeline.
Container Registry	✅ Microtica uses AWS ECR as a container registry. For privacy and security reasons we do not store any container images on our cloud accounts Instead, all images are stored in customer’s private cloud accounts (currently AWS). The customer has full access control.	✅ GitLab Container Registry is a secure and private registry for Docker images. It allows easy image upload and download from GitLab CI. It’s fully integrated with Git repository management. 🟡 For SaaS configuration, container images are stored on GitLab premises.
Kubernetes Infrastructure	✅ Microtica offers ready-to-use components for Kubernetes clusters on AWS with scaling enabled by default. Tested intensively in production environments. 🔵 Since every customer has specific requirements for architecture, scaling, and deployment strategies, we’ve made our Kubernetes components flexible for change to accommodate those needs, compared to GitLab where they do not provide support for custom solutions.	✅ Create a Kubernetes cluster on AWS.
Deploying on Kubernetes	✅ Kubernetes applications are first-class citizens here. You don’t need additional configuration to deploy application/service in Kubernetes cluster. Microtica provides native support for: 1. Complete setup of Kubernetes infrastructure 2. Application deployment, health status monitoring, and logs directly from Microtica Kubernetes Dashboard 3. Automatic annotations and detection of services deployed by Microtica You do the entire life-cycle management of Kubernetes applications from one place, with no need for additional tools or configuration.	✅ GitLab’s Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes. 🟡 Status monitoring for Kubernetes applications and logs are available only with the most expensive plan. 🟡 To make this feature work properly you need to do a lot of manual work, which could take a lot of time especially for cases with a lot of applications (microservices): 1. Configure GitLab Runner with the Docker or Kubernetes executor 2. Configure the Kubernetes service in your project for the cluster 3. Ensure Kubernetes annotations are applied to the deployments, replica sets, pods, etc.
Easy integration of existing Kubernetes clusters	✅ In Microtica you can add your existing Kubernetes clusters provisioned on AWS, Azure, GCP or on-premises and easily configure CI/CD pipelines and Kubernetes monitoring of your applications.	✅ Add your existing Kubernetes cluster to your project, and easily access it from your CI/CD pipelines to host Review Apps and to deploy your application.
Native support for Cloud providers	✅ Provides native support for AWS cloud integration. No need for custom scripts to deploy infrastructure in the cloud. Microtica integrates with AWS CloudFormation using best practices for cloud infrastructure setup. 🔵 Native support for other cloud providers like Azure and GCP is in our roadmap.	❌ The integration for each cloud provider should be defined manually by the DevOps engineer using custom CI/CD pipelines.
Infrastructure and application framework	✅ Microtica provides a framework for writing standardized cloud infrastructures and applications across the organization. Standardization covers: Each piece of infra/app should define the build procedure in the source code along with the app or infrastructure specification Each piece of infra/app should define its own schema for validation during deployment This does not limit developers to write their own custom cloud infrastructure and applications, instead, guides them to quickly start working in the cloud in a standardized way.	❌ The core concept in GitLab is a Git repository. GitLab does not support semantical specification of what certain repository contains, what it supports, how it should be validated during deployment etc. Because of this, combining multiple repositories to deliver complex infrastructure is rather complex and unpredictable
Deployment plan	✅ Enables developers to review changes that are about to happen before deployment for full transparency. This feature brings a lot of value especially in case a certain resource is to be removed with the deployment (e.g. production database).	❌
Transactional infrastructure deployments	✅ Define complex cloud infrastructure combining multiple Git repositories and orchestrate transactional deployment. Transactional means that if during deployment something fails, the automated roll-back procedure will take place and return the environment in the previous successful state. Especially important for a production environment where keeping the system always up and running is a must.	❌ In GitLab, every repository has its own lifecycle from a delivery point of view. Orchestrating the delivery of cloud infrastructure from multiple repositories is rather complex, unpredictable, and sometimes not possible. If something fails during deployment, it’s the developer’s job to define a rollback strategy within the pipeline or do it manually.
Environment replication	✅ Create a copy of the entire environment infrastructure with one click, without having to reconfigure the whole cloud infrastructure. Compared with GitLab, Microtica offers replication of the entire environment, not just per repository bases. A possible use case would be a temporary production-like environment for performance tests.	✅ GitLab supports the creation of temporary environments. Temporary environments are only per repository and not on the whole infrastructure setup.
Native support for advanced deployment validation	✅ Microtica validates the configuration of infrastructures and applications before each deployment. The validation rules are defined by the owner and Microtica executes them without exception. Validation and schema are really important for the following reasons: 1. To prevent failed deployments instead of fixing them in production 2. To increase deployment confidence Much easier for other team members to pick up and use infrastructure/application written by other teams/team members	❌ GitLab doesn’t natively support the validation of the input data during deployment. To achieve this, you would need to write a custom validation logic for the same value. It’s not obvious what certain Git repositories require to deliver them in the cloud.
Auto DevOps	❌ This feature was not implemented in Microtica intentionally, at least for now. We did this to avoid a lot of problems in the software delivery when customers expect full automation but they only end up fixing problems in the pipeline caused by Auto DevOps.	✅🟡 Very nice idea but still considered as a highly unpredictable (unreliable) feature. Some problems occur using this feature: Unexpected errors appear all the time. Experienced engineers can probably fix them but that would defeat the whole purpose of Auto DevOps. Doesn’t work the same for all programming languages. Could be suitable for small starter projects but cannot work in all possible cases.

Conclusion

Microtica doesn’t require expert knowledge to set up proper delivery automation in the cloud. The complexity is already solved. It also offers fully-integrated production-ready Kubernetes with just a few clicks. The deployment and monitoring of the applications happen within the app. Microtica can work with all popular Git providers and can support additional providers easily.

Both Microtica and GitLab CI have a similar purpose: delivering software efficiently and reliably in the cloud. In the end, the tools we choose to work with really depends on our specific needs and what we want to accomplish.