Forem: Carlos M.

CI/CD Tools: How to Choose Yours Wisely

Carlos M. — Tue, 25 Feb 2020 14:56:58 +0000

Continous integration (CI) and continuous deployment (CD) tools allow teams to merge, build, test, and deploy code branches automatically. Implementing them along with conventions like "commit frequently" forces developers to test their code when it's combined with other people's work. Results include shorter development cycles and better visibility of code evolution among different teams.

Once you commit to using CI/CD in your software development cycle, you're immediately faced with a galore of options: Travis, Jenkins, GitLab, CodeShip, TeamCity, and CircleCI, among others. Their names are catchy, but they hardly describe what the tools do. So here's a roadmap for choosing the right tool for your needs.

What Platforms and Integrations Should It Support?

Whether you're part of an enterprise or a startup, you'll first need to figure out all your platform requirements. Think about your operating systems and their versions, programming languages, access to third-party APIs, libraries, frameworks, and testing suites; collect all these data and check that each tool is able to support them all. You don't want painful troubleshooting sessions or loss of commercial provider support because of a version mismatch.

There are some shortcuts that I can provide:

BuildBot is a popular choice among Pythonistas. It's also written in Python, and it's very flexible. FOSS projects like Mozilla Firefox and MariaDB currently use BuildBot for their multi-platform builds and testing.
People using JIRA or Bitbucket will find that Bamboo and Bitbucket pipelines fit their ecosystem. But beware of price increases as your number of environments and need for parallelization grow.
Jenkins' impressive list of plugins offers compatibility with every major developer tool in the market. Java shops will probably be comfortable deploying Jenkins because it's written in that language.
If you're building .NET projects to run on a Microsoft stack, you'll find two natural choices: Visual Studio Team Services (VSTS) and TeamCity. Both include Docker support.

Where Will It Run and Who Will Maintain It?

Some enterprises have regulations to meet, so they can't put their codebases in cloud services. Startups lack the manpower and time to run their own tools. Teams in both groups might be wary of security breaches caused by a wrong decision when using publicly available services. Whichever is your position, here's a set of tips to navigate the cloud vs. on-premises conundrum:

Cloud services ease the workload for our teams—but always at the expense of fees above certain usage.
Extra charges from CI/CD cloud services come in the form of higher concurrency, build events, build time, and/or user count.
Some cloud services have a zero-cost plan for small teams. You could test the waters using that in a greenfield project.
On-premises options like GitLab, Travis-CI, and TeamCity have hosted offerings that let you test before committing to run your own copy.
On-premises tools require resources ready to orchestrate your builds and tests. That means more complex tasks to run, troubleshoot, and maintain.
Teams should be aware of legal and business requirements when uploading code and data to cloud services.

Who Will Use It and How Often?

It's only a matter of time before the results of using CI/CD become visible to management. At that point, your organization will be increasingly dependent on CI/CD. User adoption and build frequency will increase. Take a look at these items before deciding your team's headcount and licensing requirements:

Provide some managers read access to your CI/CD. Giving them visibility improves the chances of them supporting these efforts.
Choose a tool that integrates with your organization's favorite authorization method. Nobody wants one more password.
Get a list of desired environments and take note of how often your teams would hypothetically push code to them.
Recalculate your usage when you add a new team or user. Don't let your bills get out of control.

What Are Our Estimated Costs?

Depending on the nature of your company and team, you'll either prefer an operating expense or a capital expenditure. I'm an advocate of pay-as-you-go services, personally. They allow you to keep costs down when you're starting, and they remove complexity. But as soon as your SaaS yearly bills reach what you'd pay an engineer, you might want to get some of those toolsets under your control or migrate to other providers with lower costs. Here are some gotchas when estimating costs:

TeamCity and Bamboo require extra payment when you need more than one remote agent, so each additional environment costs more.
VSTS is free for teams of five people or less. After that, you pay per additional user each month.
GitLab only supports multiple active directory sources in its enterprise edition. Jenkins, on the other hand, supports it through a plugin.
Some SaaSs charge per build time. If this is the case with your chosen option, configure your pipelines to use prebuilt images with resolved dependencies.
Jenkins, GoCD, BuildBot, and GitLab-CE have OSI-compliant licenses while Bamboo, TeamCity, Travis-CI Enterprise, and GitLab-EE are commercially available. Some of them charge based on the number of users, remote agents, and features.

Availability of Documentation, Training, and Support

It might not be evident now, but you'll end up deploying to production with this new tool. So you'll want to set up the same kind of expectations you currently have for all your other tooling in production because, at some point, you will probably

need training for more than your vanguard CI/CD team.
troubleshoot problems that affect your availability to internal and external customers.
extend your implementation to more environments, additional third-party integrations, and new business needs.
require emergency support beyond what a user community may offer.
provide onboarding documentation to new team members.

Metrics and Vendor Lock-In

I decided to leave these two strategic factors as final arguments—not for their lack of importance, but because they're only important once you've successfully adopted a CI/CD tool. While it's great to implement a delivery pipeline, it's hard to see improvements over time if you're not measuring and comparing to a baseline.

Here's a set of questions that will help you know what's relevant to measure in your line of business:

What's your business focus? Is it maintaining a reliable platform? Is it increasing your user base? Or is it adding software features ASAP?
Does your team deploy software to production and let it fail as part of debugging?
How many bad builds are slipping through and failing in production?
What is your mean time to recover from a failure in production?
How does your delivery pipeline design affect a push to production during an outage incident?

Now, regarding the vendor lock-in factor, the CI/CD ecosystem is blooming. Odds are that you'll probably change tools when your requirements evolve. Or perhaps your SaaS provider goes out of business. Don't forget to consider how much effort it would take your team to migrate your delivery pipeline to a different tool or provider in case a change is necessary. Here's some food for thought:

Can you export workflows and configurations?
Do exports come in formats that might be automatically transformed as inputs for other tools?
How tightly integrated is your CI/CD tool to specific computing resources?

Take the Next Step

If your current software development cycle is made of stages where people step on each others' toes while trying to survive the minefield created by libraries, APIs, and interservice dependencies, perhaps it's time to choose a CI/CD tool and start optimizing your software delivery pipeline.

Have you experienced this process already? Share your tips with us in the comments section!

Kubernetes: The Next VMware?

Carlos M. — Tue, 11 Feb 2020 16:17:06 +0000

It's been almost 10 years since VMware started selling ESX version 4.0. This set the path for VMware to dominate more than 75% of the virtualization market in 2017. Gartner considers this market "matured" since most of its revenue comes from maintenance instead of new licensing. Many companies have consolidated their workloads with virtualization, but there are new problems to solve.

Delivering, testing, deploying, and scaling applications are among these challenges. Teams that implement microservices also need to automate as much as possible to make them manageable. Kubernetes, Marathon, Swarm, and Nomad compose a new breed of tools that respond to these needs through orchestration. If you host on-premises or in the cloud, consider them to help your business more quickly deliver code to production.

Companies evolving towards data-driven decision-making often implement machine learning and business intelligence tools, looking for an edge in their markets. As information technology professionals, it's our responsibility to make sure our businesses select tools that

perform in a reliable way;
allow quick deployment of new features;
scale properly in response to user demand; and
deploy new software in a safe and reproducible way.

In this article, I explain why I think Kubernetes is a market leader in the orchestration space and how it might steal VMware's thunder in the not-so-distant future.

Kubernetes Is Open-Source

The Kubernetes adoption rate is considerably higher than that of other tools, partly because it's distributed by the CNCF under Apache License 2.0. Choosing an open-source tool comes with the following benefits:

You will have to train your staff in implementation and maintenance, but you will incur zero expenses in commercial licenses. OpEx-oriented managers love this.
Developer contributions accelerate its evolution. Open-source tools release new features in a three-to-four-month cycle, which is faster than commercial software.
Documentation, tutorials, and how-tos are abundant all over the internet. This creates a healthy and diverse ecosystem of knowledge built collectively.
Providers and software vendors offer their own implementations freely. This enables organizations to implement and assume a level of complexity aligned with their IT staff.

Containers Are More Efficient Than Consolidation

When we consolidate workloads in virtual machines, we're still emulating sets of devices that we mostly don't use. Duplication of operating system files is also a prevalent inefficiency. Using containerizing services (e.g., Docker) reduces glut and dedicates more CPU cycles to your business applications.

Dockerizing applications have been shown to be effective in this race to optimize hardware usage. Kubernetes provides a way to manage Docker instances at scale instead of putting them inside virtual machines. If your workloads are Linux-exclusive, you also have the option to run Kubernetes on bare-metal servers. It's not the most popular implementation, but it's a way to maximize hardware efficiency.

Containers Allow Teams to Focus on Delivery, Not Management

Priorities have changed when it comes to the application lifecycle. Configuration management is a takeaway from the era of consolidation. Managing lots of virtual machines used to require expending consistent effort. But spending energy on configuration management is unnecessary in the era of containers. A Docker instance's lifetime is so short that some instances run for just a few hours.

That's why you should add configuration as part of your continuous deployment. Test it automatically in your pipeline and send your configured artifacts to production after passing all your compliance tests. This helps your organization focus their efforts on delivering more stable software, with more features, and to automatically catch errors earlier in your development process.

Kubernetes Pods Let Teams Build With the Same Lego Pieces

Kubernetes applications run in the form of Pods. A Pod may contain one or more containers. Pods help you to group containers that hold a relationship between them. You use a Pod template to specify storage, binaries, and network resources used by its containers. And to define Pod templates, you use the YAML text file format.

Share these YAML definitions with your developers so they can run Pods with minikube in their desktops. You can also use them in your CI/CD pipeline. That's how Pods enable you to provide consistency across your development, testing, integration, and production environments.

Standardizing how your teams create and test software will help you minimize the changes you need to implement at the end of your software development cycle. Operators will also have more confidence when deploying these applications to their production environments. For VMware users, this should sound similar to vApps packaging.

Helm Lets You Save Time by Reusing Community-Packaged Applications

Helm packages in Kubernetes may be the parallel of RPMs in RedHat or .deb packages in Debian/Ubuntu. A YAML file called "Chart" contains a definition and templates to describe the necessary binaries. A server (Tiller) and a client (Helm) interact to deploy releases of your charts to a Kubernetes cluster. Charts require semantic versioning. Couple this with version control and you get rollback capabilities.

Most teams usually have similar needs: "Deploy this application, keep this database up and running, cache content with this app, and load-balance this set of connections." Free open-source software (FOSS) is usually a part of this team's process. Helm packages exist so you avoid rework when implementing FOSS as Kubernetes applications.

You're now probably thinking, "How do I make Pods work with Helm packages?" There's a whole set of best practices to consider when you start modeling your infrastructure with Helm packages. Make sure to review them before making architecture deployment decisions.

Kubernetes Deployments—Safe Software Delivery Included

Kubernetes Deployment manifests allow you to describe how Pods are kept running under a set of rules. You define these rules in YAML files, which allow you to describe an environment with these basic abstractions:

Containers describe what applications run in your deployment.
Environment variables set values that are required to run your code.
Specs allow you to define how many replicas of each container should run at a certain time.

On the other hand, Kubernetes services are meant to define ports available to external entities. That's how you expose your application to the rest of the world.

Now you can build an environment by providing your containers with variables, binaries, computing power, and network access. Everything is defined in plain text files, which should be stored in a central repository using version control. This is the Kubernetes formula. By using it, you can provide consistent environments to all of your teams, and your software may be put into production under deployment methods like blue-green, without extra necessary work.

Kubernetes Orchestration Enables You to Implement Microservices

Teams migrating software from monolith architectures to microservices should pay special attention to this point. Stateless and stateful applications work under different infrastructure assumptions. Make sure your developers are aware that some containers will fail and some Pods will die. If your organization is in the process of transforming to DevOps, it's vital for developers to have full visibility into your production environment.

When designing software to run on Kubernetes look at these relevant principles, which I extracted from "The Twelve Factors" from The Twelve-Factor App:

Decouple backing services as detachable resources.
Improve resiliency by implementing disposable infrastructure and running stateless processes
Apply the process model to help you scale

Once you get on the microservice bandwagon, you need to run it on a stable infrastructure, with a community where you can contribute or get support. Kubernetes is proving to be a FOSS platform that may grow enough to be as dependable and powerful as orchestration tools from commercial vendors like VMWare.

"Code, build, and deploy often" is the new gospel of IT. Kubernetes has built-in features to help teams make all this happen in a safe way. While I recognize that it will be some time until it reaches 75% industry adoption, Kubernetes is already a leader in the field of container orchestration. It's a trending technology that will consolidate as a de facto industry standard, just like VMWare did in its time with virtualization.