Buy vs. build software: The eternal question
The question of whether to buy vs. build software may be an old one, but it’s still relevant. Particularly as companies face rising IT costs, it’s important to consider the most cost-effective options for your business.
When you have an internal development team, it’s tempting to believe that “just having them whip something up” is cheaper than purchasing an off-the-shelf software solution. However, this ignores the opportunity cost of having your skilled developers focus their efforts on non-core activities and ones typically that deliver less value to the business.
To put a number on it, the national average salary for a software developer is $85,000. Including benefits, that’s about $110,000. . So a back-of-the-napkin estimate puts an hour of a developer’s time at $55. Then, consider the number of developers involved, and that you may not be as stringent in budgeting their time for “side projects” as you might for your core work.
So it’s expensive to build. Isn’t the outcome the same?
Actually, probably not. Though internally developed solutions may in theory have the same functionality as purchased software – for example, “it turns instances off when you don’t need them” – they will require additional work to integrate with team structures and to cover a broad variety of use cases. In that example, what about the reporting and savings information? After all, isn’t that the point of turning the instances off in the first place? And then there’s advanced features and the cost to maintain homegrown solutions over time as new requirements creep in.
For one look at how an off-the-shelf solution may compare in functionality to homegrown scripted solutions, here’s a simple side-by-side comparison we put together, showing ParkMyCloud vs. an in-house developed solution.
|Functionality||In-house Developed Scripting||ParkMyCloud|
|Multi-User / Multi-Team||· In small environments, may be difficult to meet demand for skilled DevOps personnel with knowledge of scripting & automation|
· In small environments, Significant risk if knowledge of infrastructure and scripting is managed by single individual (knowledge transfer)
In large environments, unless highly centralized, difficult to ensure consistency and standardization of automation approach across entire organization
· DevOps support for all AWS environments across multiple teams / business units will get complex and resource intensive
· DevOps resources distracted from core business activities – PMC offers API for integration into DevOps process
· Opportunity Cost
· Ability to devolve management of AWS instances to non-technical teams for scheduling on/off (PMC requires NO scripting)
· Supporting existing team structures and ensuring appropriate controls is difficult to achieve without building out complete custom solution.
|· Role-based access controls (RBAC) and access-based enumeration (ABE) for enhanced security|
· Unlimited teams
· Unlimited users
· Laser development focus on EC2 cost optimization
· One way to automate on/off times with enterprise-wide visibility
· Options for centralizing or decentralizing control to departments, teams & individuals
· Designed to support global operations
· Single view of all resources across locations, account and cloud service providers (CSPs)
· $3.00 or less per instance per month
· Configures in 15 minutes or less
|Multiple Credentials /|
|· Must develop means to securely handle and manage credentials and other sensitive account information.|
· Must keep up-to-date on changes / updates to public cloud which is constantly evolving and adding and changing services.
· Must develop approach to assign access to different credentials by different teams with PMC RBAC
· Must develop approach and interface across multiple CSPs
|· Unlimited number of credentials / accounts|
· IAM Role and IAM User support (for AWS)
· Secure credential management (AES-256 encryption)
· Multiple public CSPs (coming soon) – ability to manage AWS, Azure and Google for single platform
|Platform Coverage||· Must develop means to create a single view and the ability to manage and start/stop ASG’s|
· Must develop means to create, manage and start/stop logical groups
|· Ability to manage & park Auto-scaling Groups|
· Ability to create, manage and park Logical Groups
· Global view of ALL AWS Regions and Availability Zones in a single pane of glass
|Always ‘off’ Scheduling||· Must develop a process to enable on-demand access to stopped instances in off hours|
· Must be able to re-apply schedule when off hour work is done
· Must do this across multiple accounts and CSPs
|· Ability to temporarily suspend parking schedules during off-hours to enable ad hoc instance control|
|Cost Visibility||· Need to develop custom application to determine cost savings based upon application of automation or removal of schedules (to date we have not encountered anyone who has developed such an application)|
· Would need ability for ad hoc reports over arbitrary date ranges
|· Forecasts & displays future savings based upon selected schedules|
· Displays real-time actual month-to-date savings
· Generates & distribute ad hoc detailed cost and savings reports
|Policy Engine||· Hard to enforce consistent and standardized policies within organization within decentralized structures where different automation tools are being used|
· This would need to be done across all CSP accounts and across CSPs
· Difficult to build something like Never Park or Snooze Only
|· Enterprise-wide policies based on Tags to auto enforce actions (automate parking schedule assignment, Never Park for production instances, & assignment of instances to teams)|
As you can see, there is a technical advantage of purchasing software that’s been purpose-built with a dedicated development team over a long period of time. You’ll get more functionality for less money.
This year, we resolve not to “build” when we should “buy.”