Many DevOps folks are inclined to use Hashicorp’s Terraform on AWS to manage infrastructure as code. This can have some Schroedinger-esque qualities to it, in that it can simplify your cloud management while also adding a layer of complexity to your toolset. If you’re already using Terraform, or are planning to start implementing infrastructure as code, then use these tips for better management of AWS deployments.
1. Use Terraform AND CloudFormation
This might come as a surprise, but not everyone wants to be involved in the holy war between Terraform and CloudFormation – and many have team members who use both tools. If this rings true for you, there’s no need to give up on CloudFormation. You can make use of the aws_cloudformation_stack resource type in Terraform. By using this, you can incorporate existing CloudFormation templates in your Terraform configurations, or you can make use of any potential features that aren’t available in Terraform. The “parameters” and “outputs” of the resource let you have a bidirectional communication between the two tools as well.
2. Run “terraform plan” early and often
One of the best things about infrastructure as code is that you can know what’s going to happen before it happens. Using the “terraform plan” command to get an output of any AWS infrastructure changes that would happen from the existing terraform configuration can help you plan, communicate, and document everything that happens during your change windows. Making a habit of getting the plan after even minor code changes can save you a bunch of headache from errors or misunderstood edits.
3. Be careful using Autoscaling Groups with Terraform
AWS Autoscaling Groups are a great idea on paper, but can cause headaches (and often at the worst possible times) in practice due to either scaling too much or not enough. The biggest key for this is that you need to not only build out your ASG in Terraform, but also define the scaling policies, scaling boundaries, and know how to handle graceful termination and data storage. You also need to know what it looks like if Terraform expects one setup, but you’ve parked your resources for cost savings or suspended any ASG processes. This can be a challenge when you try to test your scaling policies, or if you don’t use ASGs the same way in development environments.
4. Adopt a “microservices” architecture with your configurations
Splitting your Terraform configuration into multiple files might seem like you’re just adding complexity, but this “microservices” approach can really help with management in large organizations. By making heavy use of output variables, you can coordinate configurations as needed, or you can keep things isolated for risk mitigation in case a configuration doesn’t do what you intended. Separate files also helps you keep track of what’s changing and where for audit logging purposes.
5. Create reusable modules specific to your organization
Along a similar line to number 4 above, creating smaller configurations can help you reuse code for different projects or teams. Reusable modules that are specific to what you do as a company can help accelerate deployment in the future, and can help with non-production workloads when developers want an AWS environment that is as close to production as possible.
Using Terraform on AWS can be a fantastic tool for defining your cloud infrastructure in an easily-deployable way, but can be daunting if you are trying to just get started or scale out to fit a larger enterprise. Use these tips to help save some frustration while making full use of the power of AWS!
When approaching new problems, such as cost optimization or task automation, development and IT teams are faced with the decision to buy vs. build a solution. There are a number of financial and strategic factors to consider when determining the best choice in each case, which can be difficult to parse through. Here are our tips for building a buy vs. build business case, whether for your own use or to present to management.
Reasons to Build Your Own Solution
1. An off-the-shelf product doesn’t exist to solve your problem. If you can’t buy a product, or hack together several different existing solutions, you are probably going to have to build your own software. There is not too much “blue ocean” left out there, but if you have a need and no product can solve it, then it can make sense. Be wary and make sure you’ve completed your research before determining this is the case: perhaps the solution is called something other than what you’re searching, or exists as part of a larger suite of offerings.
2. It will provide you with a significant competitive advantage over your rivals. This typically requires unique IP (some special sauce) that you can build into the product which other existing products can not offer and which will help your company succeed.
3. You can see a business opportunity whereby not only can you use the product yourself in-house, but you will also be able to offer it to your customers, thus leveraging your company’s investment.
4. You have a team of engineers sitting on the bench with nothing better to do (i.e. minimal opportunity cost). This does actually happen from time-to-time and such a project can make them productive.
5. The specialist knowledge already exists within the company and a natural product owner exists. This is not reason enough to decide to build, but without it, things are likely more difficult.
Reasons to Buy Pre-Built Solutions
1. Building software is complex and expensive. If this is a software product that you are going to roll out across the enterprise, it will require support and likely a commitment for the life of the product to feature updates and improvements.
2. Supporting products that your team might build is a significant commitment and typically is where the ‘big bucks are spent’. An MVP style product is unlikely to keep the masses happy for long, and you will need to budget for ongoing updates, improvements, patching and support. This typically multiplies the cost of building v1.0.
3. Commercializing a product built primarily for in-house usage is a great theory but in reality rarely works. Such examples do exist but are few and far between. Building a new product company requires a lot more than just technology and execution risk is high unless it is to become the #1 priority for your company.
4. A long time to value of a new product venture means that you are often missing out on significant value which would be realized if an existing ‘off the shelf’ (today that often means a SaaS solution) were selected.
5. Enterprise-grade software comes with the bells and whistles that enterprises need. This typically means lots of points of integration, single sign-on requirements, and security as a given. Home-baked products typically do not include these items which are considered ‘added extras’ and not core to solving the problem at hand.
Create Your Business Case
If you work in an organization with access to technical resources (which today includes a lot of companies), there is often a desire to build because “they can” and a sense that they can meet the needs in a more custom manner solving the precise needs of their organization. Even if the opportunity cost of diverting resources away from other projects is low, there can be a tendency to overlook to include the longer term maintenance, upgrade, and support requirements of enterprise-grade software. Additionally, we often encounter companies who have started on the journey toward building an in-house solution, only to discover additional complexity or seeing internal priorities change. In such cases, even when there are significant sunk costs, reappraising alternative paths and third-party solutions can still make sense.
Ultimately, every case is unique and weighing the relative pros/cons and building the business case to buy vs. build will require considering both financial and non-financial aspects to help the right decision is made.
One of the key drivers to a multi-cloud strategy is the fear of vendor lock-in. “Vendor lock-in” means that a customer is dependent on a particular vendor for products and services, and unable to use another vendor without substantial switching costs or operational impact. The vendor lock-in problem in cloud computing is the situation where customers are dependent (i.e. locked-in) on a single cloud service provider (CSP) technology implementation and cannot easily move to a different vendor without substantial costs or technical incompatibilities.
Vendor Lock-in: Public Cloud vs. Traditional Infrastructure
Before the cloud, IT was running in dedicated on-premises environments, requiring long-term capital investments and an array of software license commitments and never ending hardware refresh contracts. Based on that experience, it is understandable that a customer would be concerned about lock-in. Many large IT vendors like Oracle, IBM, HP, and Cisco would “lock” customers into 3-5-10 year Enterprise License Agreements (ELAs) or All You Can Eat (AYCE) hardware and software license agreements, promising huge discounts and greater buying power – but only for their products, of course. I used to sell these multi-year contracts. There is a common ground for sure, as the customer was locked-in to the vendor for years. But that was then and this is now. Is vendor lock-in really a concern for public cloud users?
Isn’t the point of cloud to provide organizations the agility to speed innovation and save costs by quickly scaling their infrastructure up and down? I mean, we get it – your servers, data, networking, user management, and much more are in the hands of one company, so the dependence on your CSP is huge. And if something goes wrong, it can be very detrimental to your business – your IT is in the cloud, and if you’re like us, your entire business is developed, built and run in the cloud. Most likely, some or all of your organization’s IT infrastructure where you are developing, building and running applications to power your business and generate revenue, is now off-premise, in the cloud. But although “lock-in” sounds scary, you are not stuck in the same way that you were with traditional hardware and software purchases.
Can You Really Get “Locked In” to Public Cloud?
Let’s talk about the realities of today’s public cloud-based world. Here are a couple of reasons why vendor lock-in isn’t as widespread a problem as you might think:
- No Long-Term Commitments: Customers can adopt the cloud on their own terms. AWS, Azure, and Google Clouds are designed so customers only use the services when they see value, and they are free to use the technology of their choice. Pay-as-you-go pricing provides customers with the ability to shut down their environment, export their data and virtual machines (VMs), and walk away without ever incurring another expense. Customers are billed monthly without any required long-term commitments or contracts regardless of spend or support tier.
- Customer Choice: Today’s cloud customers have alternatives to proprietary tools with advances in open source software technologies, along with a range of ‘as-a-service’ capabilities that can remake traditional IT — IaaS, PaaS, and even SaaS. A wide range of solutions that support industry standards allow customers to choose what they want to invest in and architect for application portability from the beginning, if they so choose.
- Moving Into and Out of a CSP: Generally speaking, cloud services are built to support both migration into and out of their platforms, and CSPs and the industry at large provide many tools and documented techniques to make it easy to do both. Many cloud service providers offer tools to help move data between networks and technology partners. Customers can securely move information in and out of the cloud regardless of where that information is going: cloud-to-cloud or cloud-to-data center.
How to Mitigate Risk with a Multi-Cloud Strategy
Now the cloud is not without risk, and when we talk to customers the primary vendor lock-in concerns we hear are related to moving to another cloud service provider IF something goes awry. You hope that this never has to happen, but it’s a possibility. The general risks include:
- Data transfer risk – it is not easy to move your data from CSP to another.
- Application transfer risk – If you build an application on one CSP that leverages many of its offerings, the reconfiguration of this application to run natively on another provider can be an extremely expensive and difficult process
- Infrastructure transfer risk – Every major CSP does things a little bit differently.
- Human knowledge risk – simply put, AWS is not the same as Azure which is not the same as GCP, and your IT team has likely gained a lot of institutional knowledge about that provider’s tools and configurations.
To minimize the risk of vendor lock-in, your applications should be built or migrated to be as flexible and loosely coupled as possible. Cloud application components should be loosely linked with the application components that interact with them. And, adopt a multi-cloud strategy.
How Much Should You Worry About Vendor Lock-In?
Many companies are familiar with vendor lock-in from dealing with traditional enterprise companies mentioned above – you begin to use a service only to realize too late what the terms of that relationship brings with it in regards to cost and additional features and services. The same is not entirely true with selecting a cloud service provider like AWS, Azure, or Google Cloud. It’s difficult to avoid some form of dependence as you use the new capabilities and native tools of a given cloud platform. In our own case, we use AWS and we can’t just wake up tomorrow and use Azure or Google Cloud. However, it’s quite possible to set your business up to maintain enough freedom and mitigate risk, so you can feel good about your flexibility.
So how much should enterprises worry about vendor lock-in in public cloud? IMHO: they shouldn’t.