The cloud is compatible with a wide variety of proprietary and open-source tools. It can be overwhelming to decide which tools to integrate with your infrastructure. Most teams will not have the time or resources to try every tool before deciding which one(s) serve the best interests of their infrastructure.
Through our experience setting up infrastructure and determining which tools to use in the cloud for our clients, here are 10 things to consider when choosing cloud tools.
1. Whether it’s a managed service
Why think about it when someone has already done the thinking? Some cloud tools have already solved the most common problems that most infrastructure teams have. The creators of the tool have already put in the grunt work, so your team doesn’t need to waste time or energy. As the saying goes, if you’re solving problems that are unique to you, that’s good. If you’re solving problems that everyone else has, there’s probably an open source solution.
In exchange for minor access or control restrictions , this is a fairly easy choice to make. A good example is Amazon RDS, which takes care of backups, read-replications, and (optionally) multi-AZ failover while withholding superuser privileges.
2. What are the associated costs
When considering free tools, sometimes there’s concern that you pay for what you get. However, when it comes to the cloud, often this is not true. Many of the commercial counterparts to the free, open-source versions come with what are considered “premium” functionalities.
Typically, open-source solutions will address the most common needs for a cloud-based infrastructure. For example, Terraform and Vault are free and sufficient for most teams, with optional paid Terraform Enterprise and Vault Enterprise features respectively that not every team needs.
3. Whether it is the industry standard
In the cloud industry, when a tool becomes the industry standard, it means that the tool has been through a lot of hands and infrastructures and has been resilient through it all.
It is important to keep in mind however, that sometimes the industry standard will not work for your infrastructure. This is sometimes a budget constraint or a size constraint. Other times, a tool is just not appropriate for your industry or infrastructure. Luckily, for the most part, open-source tools tend to be flexible and extensible to meet the needs of your organization.
For example, many teams use New Relic APM for their application performance monitoring, but the associated cost is too high for smaller teams. Instead, we often will use Elastic APM for our clients with small- to medium-sized businesses.
4. Whether it comes with a graphical user interface
When looking for the best tools, we want extensibility and flexibility. This often means being able to dig deep into the code and make customizations based on our needs.
However, what many overlook when deciding on new tools is the ability to quickly view data or edit configuration. This not only gives us information when debugging an issue, but can also be used by non-technical people to do a quick check-up on the infrastructure.
5. What native options come with your cloud provider
The native option from your cloud provider may not always be the best option in the market, but for the sake of compatibility and simplicity, sometimes the sacrifices are worth sticking to the native option. Especially, if it is a minor tool that you don’t use often or don’t need extensive functionality for.
For example, AWS comes with a plethora of native tools. Some of the most common ones that we use include: Amazon CloudWatch, Amazon CodeBuild, and Amazon CodePipeline.
6. Whether it’s well-documented and supported
Sometimes a tool looks great and comes with all of the right features, but has absolutely no documentation or community support.
Depending on the complexity of the tool, how integral it is to your infrastructure, and how much time you’re willing to invest in it, it may be a better choice to go with one of the following options that has better documentation and support:
A tool with less functionality, but can be modified to your needs
Multiple tools that serve the same overall required functionality
A proprietary tool *
* While we encourage the use of open-source software, we understand that sometimes the best option for a client may be to adopt a proprietary tool, however, we have yet to run into a scenario where we went with a proprietary tool over the first two options
The best documentation that we’ve run into must be from fluentd. It was incredibly easy for our public cloud infrastructure consultants to set up unified logging layers with the open-source data-collector.
7. What the updates and upgrades are like
Both frequency and ease of updates and upgrades are considerations that help keep your decisions long-sighted. A few scenarios that you may want to think about regarding a tool’s update and upgrade habits and cycles are:
A tool that is rarely updated or upgraded, but has a lot of tickets open, could mean that there isn’t enough support in the community to keep the tool functional.
A tool that virtually never releases updates or upgrades could mean that the tool will quickly become outdated.
A tool that is difficult to update or upgrade could mean a lot of extra overhead that outweighs the tool’s benefits.
A good example is how easy it is to update Elasticsearch and Elasticache from the AWS dashboard or through Terraform.
8. Whether it’s easy to learn
As with all other components of your infrastructure, we always want to consider the return on investment: will the number of hours I invest in learning this tool translate into equivalent or greater outcomes?
For some, the steep learning curve can be a deterrent to pick up a more complex tool, but once mastered, these tools typically provide high returns. Depending on your skill-level, a tool may simply not be worth learning.
However, keep in mind that sometimes these tools can be set up once by an expert, like a public cloud infrastructure consultant, exempting whoever is maintaining and updating the tool from the bulk of the grunt work.
For our team, Terraform and Amazon EKS were incredibly easy to learn and use.
9. Whether alternatives even exist
At times, a tool may not be great, but it’s the only tool available. In situations like this, if the tool does not fulfill the needs of your infrastructure, we suggest keeping an eye out for alternatives, creating your own tool, or commissioning a third-party to create a tool for you.
Otherwise, this is an OK time to settle for what you’ve got.
For example, if your infrastructure is stored on AWS, you will have to use Amazon Cloudwatch because it automatically collects your monitoring and operational data.
10. Whether you ACTUALLY need it
If it ain’t broke, don’t fix it. Sometimes a new tool may come out to replace a current one, but the current tool does exactly what it needs to do. At times like this, it’s to your discretion whether this tool may have long-term value for your infrastructure. But in the short run, if your current tool is delivering, keeping it doesn’t make you outdated. New isn’t always better.
At stack.io, we’ve often found that many of the tools from HashiCorp were redundant on our stacks. For example Nomad by HashiCorp overlaps with many of the other tools we’re using and the service discovery in Consul by HashiCorp provides the exact same functionality found in etcd.
Do you need help setting up your public cloud with the right tools? Send us a message and we can get started right away.