In the world of infrastructure as code, the biggest divide seems to come in the war between Hashicorp’s Terraform vs. CloudFormation in AWS. Both tools can help you deploy new cloud infrastructure in a repeatable way, but have some pretty big differences that can mean the difference between a smooth rollout or a never ending battle with your tooling. Let’s look at some of the similarities and some of the differences between the two.
While the tools have some very unique features, they also share some common aspects. In general, both CloudFormation and Terraform help you provision new AWS resources from a text file. This means you can iterate and manage the entire infrastructure stack the same as you would any other piece of code. Both tools are also declarative, which means you define what you want the end goal to be, rather than saying how to get there (such as with tools like Chef or Puppet). This isn’t necessarily a good or bad thing, but is good to know if you’re used to other config management tools.
Unique Characteristics of CloudFormation
One of the biggest benefits of using CloudFormation is that it is an AWS product, which means it has tighter tie-ins to other AWS services. This can be a huge benefit if you’re all-in on AWS products and services, as this can help you maximize your cost-effectiveness and efficiency within the AWS ecosystem. CloudFormation also makes use of either YAML or JSON as the format for your code, which might be familiar to those with dev experience. Along the same lines, each change to your infrastructure is a changeset from the previous one, so devs will feel right at home.
There are some additional tools available around CloudFormation, such as:
- Stacker – for handling multiple CloudFormation stacks simultaneously
- Troposphere -if you prefer python for creating your configuration files
- StackMaster – if you prefer Ruby
- Sceptre – for organizing CloudFormation stacks into environments
Unique Characteristics of Terraform
Just as being an AWS product is a benefit of CloudFormation if you’re in AWS, the fact that Terraform isn’t affiliated with any particular cloud makes it much more suited for multi-cloud and hybrid-cloud environments, and of course, for non-AWS clouds. There are Terraform modules for almost any major cloud or hypervisor in the Terraform Registry, and you can even write your own modules if necessary.
Terraform treats all deployed infrastructure as a state, with any subsequent changes to any particular piece being an update to the state (unlike the changesets mentioned above for CloudFormation). This means you can keep the state and share it, so others know what your stack should look like, and also means you can see what would change if you modify part of your configuration before you actually decide to do it. The Terraform configuration files are written in HCL (Hashicorp Configuration Language), which some consider easier to read than JSON or YAML.
More on Terraform: How to Use Terraform Provisioning and ParkMyCloud to Manage AWS
Terraform vs. CloudFormation: Which to choose?
The good news is that if you’re trying to decide between Terraform vs. CloudFormation, you can’t really go wrong with either. Both tools have large communities with lots of support and examples, and both can really get the job done in terms of creating stacks of resources in your environments. They are both also free, with CloudFormation having no costs (aside from the infrastructure that gets created) and Terraform being open-source while offering a paid Enterprise version for additional collaboration and governance options. Each has their pros and cons, but using either one will help you scale up your infrastructure and manage it all as code.
The AWS free tier is a great way to get started using Amazon Web Services — it can be a great boost to individuals, startups, and small businesses. In fact, the AWS free tier was essential to getting ParkMyCloud off the ground when we launched. But of course, this program has limits on what you can use without being charged.
The AWS free tier is designed to give you the AWS experience without the cost, but that also comes with limitations on instance types, storage, hours, and how often you can call operations each month. Of course, all good things must come to an end. If you’ve outgrown the free tier option and are ready to experience the full benefits of AWS, there are a few things you can do to make sure you’re getting the most out of being a paying AWS customer.
#1 Set spending limits
The first thing to consider when your 12 months on forgoing the AWS free tier expire option is the most obvious difference – cost versus no cost. You’re paying for cloud services now, so ensure that you don’t pay more than you intend to.
Use AWS Budgets to create custom cost and usage budgets that notify you when you exceed (or are about to exceed) your budgeted amount. Track budgets by the month, quarter, or year, with custom start and end dates. You can also track costs by services, account, tags, and more, receiving alerts directly to your email or through the Simple Notification Service.
With AWS Budgets, you can also set custom utilization targets for reserved instances including Amazon EC2 instances, Amazon RDS, Amazon Redshift, and Amazon ElastiCache, receiving alerts whenever your usage drops below your set utilization target. To get started with creating and tracking budgets, start from the AWS Budgets dashboard or the Budgets API.
#2 Optimize resource usage
Next, you need to ensure that that budget is only going toward resources you actually need – so cost optimization should be a top priority. You might be overpaying by leaving instances running during non-production times, when you don’t need them. Scheduling stop/start times with automation is an easy way to integrate cost control outside of the AWS free tier.
#3 Set sizing limits
Yet another caveat of cost optimization is right sizing. Besides making sure your instances are turned off when not in use, you should also make a practice of only using as much as you need at a given time, and that’s where right sizing comes into play. Size your workloads according to performance and capacity requirements, both initially and on an ongoing basis to ensure that resources do not end up underused or idle. AWS suggests that you use CloudWatch metrics to get a full view of your environment, and make a habit of right sizing once per month to keep the process smooth, ensure that you’re monitoring costs and keeping track of your billing and usage over time.
See a full list of cost traps to avoid in The Cloud Waste Checklist.
#4 Plan your tagging structure
As your infrastructure grows, it’s important to manage your AWS resources with an effective tagging strategy. Tagging gives you the ability to attach custom metadata to instances, images, and more. Resources can be categorized by owner, purpose, or environment, helping you stay organized, improve visibility, and keep costs in check.
A good tagging strategy gives you a more accurate model for chargeback and showback and better insight in your usage and spend, but it’s up to you to enforce quality of tagging. Soft enforcement gives users notifications when policies are not followed, and hard enforcement automatically removes resources that are not tagged to align with company standard. According to AWS, organizations that use hard enforcement have a better time ensuring that quality of tagging is enforced.
Learn more about tagging best practices.
#5 Establish governance
Scheduling, right sizing, budget limits, and tagging are all methods of keeping costs optimized after you switch from the AWS free tier to a paid, full-service option. But what do all of these practices have in common? Governance. Clear policies and processes to keep usage, capacity requirements, and billing in check are all part of cloud and cost management, and should remain an ongoing priority as you continue using AWS or any cloud service provider.
For more information and how to plan governance after outgrowing the AWS free tier option, learn about how one software company automates governance.
Alibaba Cloud is growing at an amazing rate, recently claiming to have overtaken both Google and IBM as the #3 public cloud provider globally, and certainly the #1 provider in China. Many sites and services hosted outside China are accessible from within China, but can suffer high latency and potentially lost functionality if their web interface requires interaction with blocked social media systems. As such, it is no surprise that a number of our (non-Chinese) customers have expressed interest in actually running virtual machine Alibaba instances in China. In this blog we are going to outline the process…and give an alternate plan.
General Process to Run Alibaba Instances in China
The steps to roll-out a deployment on Alibaba in mainland China are relatively clear:
- Establish a “legal commercial entity” in Mainland China.
- Select what services you want to run on Alibaba Cloud
- Apply for Internet Content Provider (ICP) certification
The first three steps are described in more detail below.
Establish a Legal Commercial Entity
Or putting it another way – you need to have an office in China. This can range from an actual office with your own employees, to a Joint Venture, which is a legal LLC between your organization and an established Chinese company. If your service is more informational in nature and is not actually selling anything via the service, then this can be relatively easy, taking only a couple weeks (at least for the legal side), though you will still need to find a Joint Venture partner and make the deal worth their while financially. For commerce or trade-related services, the complexity, time requirements, and costs start going up significantly.
What to run on Alibaba Cloud
There is a decision-point here, as there is one set of rules for Alibaba-hosted web/app servers, and additional rules for everything else. Base virtual machines, databases and other such core IT building blocks require the ICP registration described below, plus “real-name registration”, where a passport is needed to actually confirm the identity of whomever is purchasing the resource. If all you need is a web server, then you can skip this step. In either case, some of the filing requirements involve having a server and/or DNS record prepared in order to complete the later steps. A web site does not need to be completely finished until launch, but a placeholder may be needed.
Internet Content Provider (ICP) certification
There are two flavors of ICP certification:
- A “simple” ICP Filing – which is the bare minimum needed for informational websites that are not directly generating revenue.
- ICP Commercial Filing – This starts with getting an approved ICP Filing, and then also includes a Commercial License that must be obtained a province/municipality in China. In some cases, this appears to be related to which Alibaba region you are using, and even the physical location of your public IP address.
Many references recommend finding an experienced consultant to guide you through these processes, and it is easy to see why!
OK…WAY too much work. What is Plan B?
The other way to run Alibaba instances in China is to host your site or services in Hong Kong. All of the rules described above apply to “Mainland China”, which does not include Hong Kong. Taiwan is also not included in Mainland China, but Hong Kong has the advantage of being better connected to the rest of China. If the main problem you are trying to solve is to reduce latency to your site for China-based customers, Hong Kong is the closest you can get without actually being there, and Alibaba appears to do a pretty good job optimizing the Hong Kong experience. No local office or legal filings required!
Once you are all set up: Optimize your Costs!
After your instances are set up, make sure you’re optimizing Alibaba costs. Our Mainland China-based customers using Alibaba have confirmed that ParkMyCloud is able to access the Alibaba APIs from our US-based servers – so you can go ahead and try it out.
Earlier this week we discussed ways to improve cloud automation through tagging. Today, I want to extend the conversation to look at how one ParkMyCloud user is applying tagging best practices to improve their cloud governance.
The company we talked to — they’re in media, so let’s call them MediaCorp — has about 10,000 employees, which means the Cloud Engineering team has several hundred cloud users to manage, with a combined 100+ AWS accounts and more than 5,000 active AWS resources. The only way they can maintain security and cost control in a cloud environment of this magnitude is through automated governance. Here’s how they do it.
Tagging Best Practices #1: Always Tag
MediaCorp has a strict policy: every AWS resource must have the same set of five tags attached to it:
- team — essential to establishing ownership of the resource, both for maintenance and for billing
- environment — knowing whether the resource is for production, staging, or QA has implications for on/off schedules
- application — MediaCorp uses this as a trigger for Chef Cookbooks, but can also apply to billing
- expiration date — Any non-production resource has a stated expiration date to prevent orphaned resources
- cost center — The finance department has internal billing codes for all IT resources
How does MediaCorp ensure that all resources are tagged?
Tagging Best Practices #2: Automated Compliance
The key is to use automated rules to enforce that every resource has the five required tags — this is where ParkMyCloud’s policy engine comes into play. MediaCorp has a set of policies set up to check for the five tags. If a resource is missing any, the resource is immediately put on an “always parked” schedule and moved to a team (a way to group instances in ParkMyCloud) specifically for mistagged resources.
When this happens, the Cloud Engineering team gets an email and a Slack notification, so they can track down the creator of the offending resource and correct the process that created it.
Tagging Best Practices #3: Optimize Workflows
Now the tags themselves come into play. MediaCorp uses their five-tag system for three main purposes:
Configuration management: as mentioned above, they use tags as the trigger for Chef cookbooks, and of course the same applies to Puppet Modules, or Ansible Playbooks.
CI/CD: MediaCorp uses Jenkins to provision cloud resources, so they use tags to associate build and deployment servers with their corresponding repository and build number, for both automated and manual development tasks.
Cost control: the “environment” tag determines what parking schedule is applied to each resource. Production resources run 24×7, of course, while “dev” or “test” resources are put on a schedule to park 7:00 PM – 7:00 AM and on weekends. (Users can always log in to override these schedules if needed.)
Conclusion: Tagging is Worth the Effort
It may at first seem unnecessarily harsh to automatically park any resource that doesn’t have proper tags applied, but this process is what allows MediaCorp to keep a well-governed, cost-controlled infrastructure. You can always adapt their use case to your own needs by simply moving resources to another team and notifying that action is needed, without changing the state or schedule on the resource.
Either way, with a rigorous application of tagging best practices in place, you can automate governance and improve your workflows.
Since the beginning of public cloud, users have been attempting to improve cloud automation. This can be driven by laziness, scale, organizational mandate, or some combination of those. Since the rise of DevOps practices and principles, this “automate everything” approach has become even more popular, as it’s one of the main pillars of DevOps. One of the ways you can help sort, filter, and automate your cloud environment is to utilize tags on your cloud resources.
In the cloud infrastructure world, tags are labels or identifiers that are attached to your instances. This is a way for you to provide custom metadata to accompany the existing metadata, such as instance family and size, region, VPC, IP information, and more. Tags are created as key/value pairs, although the value is optional if you just want to use the key. For instance, your key could be “Department” with a value of “Finance”, or you could have a key of just “Finance”.
There are 4 general tag categories, as laid out in the best practices from AWS:
- Technical – This often includes things like the application that is running on the resource, what cluster it belongs to, or which environment it’s running in (such as “dev” or “staging”).
- Automation – These tags are read by automated software, and can include things like dates for when to decommission the resource, a flag for opting in or out of a service, or what version of a script or package to install.
- Business and billing – Companies with lots of resources need to track which department or user owns a resource for billing purposes, which customer an instance is serving, or some sort of tracking ID or internal asset management tag.
- Security – Tags can help with compliance and information security, as well as with access controls for users and roles who may be listing and accessing resources.
In general, more tags are better, even if you aren’t actively using those tags just yet. Planning ahead for ways you might search through or group instances and resources can help save headaches down the line. You should also ensure that you standardize your tags by being consistent with the capitalization/spelling and limiting the scope of both the keys and the values for those keys. Using management and provisioning tools like Terraform or Ansible can automate and maintain your tagging standards.
Once you’ve got your tagging system implemented and your resources labeled properly, you can really dive into your cloud automation strategy. Many different automation tools can read these tags and utilize them, but here are a few ideas to help make your life better:
- Configuration Management – Tools like Chef, Puppet, Ansible, and Salt are often used for installing and configuring systems once they are provisioned. This can determine which settings to change or configuration bundles to run on the instances.
- Cost Control – this is the automation area we focus on at ParkMyCloud – our platform’s automated policies can read the tags on servers, scale groups, and databases to determine which schedule to apply and which team to assign the resource to, among other actions.
- CI/CD – If your build tool (like Jenkins or Bamboo) is set to provision or utilize cloud resources for the build or deployment, you can use tags for the build number or code repository to help with the continuous integration or continuous delivery.
- Cloud Account Clean-up – Scripts and tools that help keep your account tidy can use tags that set an end date for the resource as a way to ensure that only necessary systems are around long-term. You can also take steps to automatically shut down or terminate instances that aren’t properly tagged, so you know your resources won’t be orphaned.
Conclusion: Tagging Will Improve Your Cloud Automation
As your cloud use grows, implementing cloud automation will be a crucial piece of your infrastructure management. Utilizing tags not only helps with human sorting and searching, but also with automated tasks and scripts. If you’re not already tagging your systems, having a strategy on the tagging and the automation can save you both time and money.