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.
In-house Developed Scripting
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
· Multiple public CSPs (coming soon) – ability to manage AWS, Azure and Google for single platform
· 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
· 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
· 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.”
We were recently asked about our vision for cloud applications in 2017: are we still seeing ported versions of legacy on-premises Software-as-a-Service (SaaS) applications? Or are most applications – even outside of pure-play startups – being built and hosted in the cloud? In other words, how long until full cloud takes over?
Actually, it already has.
Native cloud applications like ours – an 18-month-old startup – that have been built, tested, and run in the cloud are no longer the fringe innovators, but the norm. In fact, outside of a printer, we have no infrastructure at all – we are BYOD, and every application we use for development, marketing, sales and finance is a SaaS-based, cloud-hosted solution that we either use for free or rent and pay month-to-month or year-to-year.
This reliance on 100% cloud solutions has allowed us to rapidly scale our entire business – the cloud, and cloud-based SaaS solutions, have provided ParkMyCloud with the agility, speed, and cost control needed to manage to an OpEx model rather than a CapEx model.
We were able to rapidly prototype our technology, test it, iterate, and leverage “beta” communities in the cloud in a matter of months. We even outsource our development efforts, and seamlessly run agile remotely using the cloud and cloud-based tools. For a peek into the process, here’s a sampling of software development tools we use in a cloud-shrouded nutshell:
Amazon Web Service (AWS) for development, test, QA and production
VersionOne for agile management
Skype for scrum and video communication
GitHub for version control
Zoho for customer support
LogEntries for log integration
Confluence for documentation
Swagger for API management
And I could repeat the same for our Marketing, Sales, and Finance process and tools – the cloud has truly taken over.
We don’t know if these applications are built and run in the public cloud or the private cloud – that’s irrelevant to us, what’s important is they solve a problem, are easily accessible, and meet our price point. We do know that these are all cloud-based SaaS offerings – we don’t use any on premise, traditional software.
The net net is that many companies are just like ParkMyCloud. The question is no longer about how us newbies will enter the world – the question is, how fast will legacy enterprises migrate ALL their applications to cloud? And where will they strike the balance between public and private cloud?
I think most people can agree that eating your own dog food – or drinking your own champagne, to the glass-half-full crowd – is a hallmark of a business that has created a successful product. The opposite is clearly true: when Alan Mullaly was brought in to Ford, he knew there was a problem when he was picked up from the airport in a Land Rover rather than a Ford car – and when he couldn’t find a single Ford vehicle in the executive parking garage.
For those of us in the software world, there’s another piece to that picture. To tell you how we discovered this for ourselves, I’m going to tell you a story.
It was six weeks after ParkMyCloud’s founding. We had the very first beta version of the product at our fingertips – but before sending it out to beta testers, we gathered the ParkMyCloud team in a conference room to do a bit of usability testing for ourselves. I created a ParkMyCloud user account and hooked up our AWS account so there would be instances to display.
“Now try it out, and let me know if you see any problems,” I told the group.
Heads down, focused on laptops, everyone diligently began to click around, playing with the first generation dashboard and parking schedule interface. For a moment, the room was quiet. Then a chorus went around.
“Hey, what happened?”
“Is anyone else getting this error?”
All at once, everyone around the table lost access to the application. It was gone. For a minute, we were left scratching our heads.
“Okay, what was everyone doing just before it shut down? Did anyone park anything?”
Finally, a sheepish marketing contractor spoke up. “I may have parked an instance.”
As it turned out, he had parked a production server. In particular, the production server running the ParkMyCloud application. D’oh!
Apparently, we needed governance. And we needed it fast. We got to work, and soon after, we released a version of ParkMyCloud that allowed for multiple users and teams for each ParkMyCloud account, all governed with role-based access control (RBAC).
We still use those roles today (incidentally, the “demo” team does not have access to production servers).
The lesson here is that using your application for yourself uncovers important usability issues. Some of these can’t be discovered as quickly as the one above, but only over time – like awkward flows, and reports that skip over meaningful data.
But of course, we also get the same benefits that the product gives to our customers – like saving money. In fact, after the approach was suggested to us by one of our customers, we adopted an “always off” schedule for ourselves. All of our non-production servers are parked 24×7. When our developers need to use them, they log in to ParkMyCloud and “snooze” the schedules for the length of time they need to use them.
This eliminates the need for central schedules, which works especially well for our multi-time-zone development team. Using this schedule, we save about 81% on our non-production servers.
I would encourage anyone who creates products to lead by example and use your product internally — and I assure potential ParkMyCloud customers that we drink our own champagne every day.
Below is the transcript of an interview with our friend Jonathan Chashper of Product Savvy about his experience in rapidly building an app, Wolfpack, using various AWS tools. From getting his team in a room and unpacking laptops, to releasing a minimum viable product (MVP) for beta testing took 14 weeks, which Jonathan attributes not only to the skill of his team but to the ease-of-use and agility they gained from AWS.
Thanks for speaking with us, Jonathan! First of all, can you tell us a little bit about Wolfpack? What is it, and why did you decide to start it?
I am a motorcycle rider. A few years ago, I went on a group ride, and very quickly, the group broke apart. Some people missed a turn, some people got stuck at a red light, and a group of six suddenly became three groups of two. It took us about half an hour to figure out where everyone was, since you need to pull over, call everyone, and then – since everyone is riding their motorcycles – wait for them to pull over and call you back. It’s one big mess.
So I thought, there has to be a technical solution to this. I decided we should build a system that would allow me to track everyone I’m riding with, so I could see where the people riding with me are at any given time. If I got disconnected from the group, I could see where they are and pull over to gather back together. This was Eureka #1
Eureka #2 was understanding that communication is the second big problem for moving in groups. When you ride in a group, on motorcycles, you’re usually riding in a column. Let’s say you’re rider #4 and you need gas. You cannot just pull over into a gas station, because you will get separated from the group. So usually what happens is that you speed up, you try to signal to the guy at the head of the column, and you point to the gas tank, you hope he understands and actually pulls into a gas station. It’s dangerous. So this is the second problem that people have when they move in packs, and these are the two problems that Wolfpack is solving: Keeping the group together and allowing for communication during the ride.
Wolfpack is a system for moving in groups. It doesn’t have to be motorcycles, but that’s the first niche we’re releasing it for. It’s also relevant for a group of cars, or even walking on foot with ten people around you, people get separated, and so on.
So we built a system that allows you as a user to install an app on a mobile device (both iOS and Android), that will allow you to manage the groups you want to travel with. Then, once you have the groups defined, you can define a trip with a starting point and an ending point. Everyone in the group then gets a map, and everyone can hop on it and start traveling together.
Here’s WolfPack’s About video, if you’re interested:
What AWS tools did you leverage when building Wolfpack?
Wolfpack is built on AWS, and we’re using CloudFront, we’re using SNS, we’re using S3 buckets, we’re using RDS, and of course EC2 instances, load balancing, Auto Scaling Groups, all the pretty buzzwords. We use them all – even AWS IoT, actually.
Have you had any interaction with AWS?
No, we’ve done it 100% ourselves. We’ve never talked to any solutions architects or anyone at AWS. It’s that easy to use.
What Amazon is doing is unbelievable. Things that used to take months or years to accomplish, you can now accomplish in days by clicking a couple of buttons and writing a little bit of code.
Why did you choose to develop on AWS?
The ecosystem they’ve created. This is why I think AWS is awesome: they’ve identified the pain points for people who want to build software.
The basic problem they identified is the need to buy servers. That’s the very basic solution they’ve given you: you can stand up a server in two minutes, you don’t need to buy or pay ten thousand dollars out of pocket, and so on and so forth, these are the good old EC2 Instances.
Then they went step by step and they said, okay, the next problem is managing databases. Before RDS, I had to have my own database from Oracle, and you’d have to buy a solution for load balancing, a solution for failover, back-up, recovery, etc., and this would cost tens of thousands, if not hundreds of thousands of dollars. AWS took that pain away by providing RDS.
The next step was message queues. Again, in the past, we would go to IBM, we would go to Oracle, back in the day, and you would use their message queues. It was complex, one message queue didn’t work with the other, and it was a mess. So AWS created the SNS to solve that.
And so on and so forth, like a domino. They have the buckets to solve the storage issue. Now the newest thing is IoT, where they understand that there’s billions of devices out there trying to send messages to each other, and very quickly, you clog the system. So AWS said, “okay, we’ll solve that problem now.” And they created the AWS IoT system which allows you to connect any device you want, very quickly, and support, I don’t know, probably billions and billions of messages. Almost for free, it doesn’t really cost anything. It’s a great system.
Have you had any challenges with AWS so far?
No, actually, no technological challenges so far. What they offer is really easy to use and understand. The one thing we do want to do is pay as little as we can for the EC2 servers, which is where we’re using ParkMyCloud to schedule on/off times for our non-production servers.
Are you using any other tools for automation and DevOps?
Yes, we are using Jenkins – we have a continuous integration machine. Our testing is still manual, unfortunately.
Continuous integration is the idea that every time someone completes a piece of code, they submit that to a repository. Jenkins has a script that takes that out of the repository, compiles everything, and deploys it. So at any given time, every time someone submits something, it’s immediately ready for my QA guy to test. The need for “Integration Sessions” went down, drastically. .
How long has the development taken?
From the minute we put the team together, until we had an MVP, we had seven sprints, which is just 14 weeks. And when I say “putting the team together,” I mean they went into a room and unpacked their laptops on March 1st. Now, fourteen weeks later, we had our MVP, which we’re now using for beta testing.
And did your team have deep AWS experience, or were some of them beginners?
Some of them had a little bit of AWS experience, but most of it came from us as on-the-job training. If you’re a software engineer, it’s really easy to get it.
On your non-production servers, where you’re using ParkMyCloud, do you know what percent of savings you’re getting?
We’re running those instances 12 hours a day, 5 days a week. So we’re running them 60 hours a week, so, let’s see, we’re getting about 65% savings. That’s pretty awesome.
I have nothing but the utmost respect for DevOps (development operations) people. They are unsung heroes in my opinion. Living in that precarious place between the developers, IT operations, and the business people, their job is to streamline and stabilize operations related to rollout of new applications and code updates to support the business.
When everything is working well, most people forget they are there. Much like offensive linemen in football, the only time people seem to notice them is on those rare occasions when something goes wrong. It doesn’t seem fair, but such is the life of DevOps.
To achieve near continuous deployment for applications, a high degree of automation is essential from the time new code changes hit the source code repository until they are pushed through test, QA, staging and into production. To accomplish that, DevOps teams require a working knowledge of their applications at a system level, as well as a deep understanding of the IT infrastructure (servers, storage, databases and network), to properly marry the two.
Inherent in this process is constant optimization to streamline the process and keep costs low. They are constantly evaluating build vs. buy for the tools they use in their trade. The preference is to use commercial off-the-shelf products if they are more cost-effective. This frees up their team to focus on keeping the “main thing the main thing”.
/* Begin Shameless Plug */
The whole idea of ParkMyCloud is to help out that part of the DevOps community, who run their environments in Amazon Web Services (AWS).
With ParkMyCloud, you can schedule on/off times for development, testing, QA and staging environments without AWS scripting for as little as $1-$2 per instance per month.
A number of our larger customers have walked away from their own scripted solutions to do this in favor of ParkMyCloud for a few reasons:
It was costing their team more to maintain their AWS scripts
The time spent working on those scripts, was time that could have been spent on mainline business applications (a huge opportunity cost)
Their scripts provided no reporting on cost savings, so that had they no idea whether they were getting a return on their investment. (With ParkMyCloud, the payback is usually within 2-3 months.)
/* End Shameless Plug*/
/* Begin Rant */
So, I told you all of that to air a real pet peeve that I have.
Imagine my surprise when I still talk to potential customers, bent on writing their own AWS scripts to turn instances on & off. It just doesn’t make sense.
When they tell me, “Well, we can do that.” Then my response is, “Does your DevOps team also clean toilets?”
Then they give me this weird look (kind of like the look on your face right now), and respond, “Well, no.”
“Why not?” I ask. “Are they not smart enough to clean toilets?”
“Well of course they are smart enough, but it is not worth their time. We hire a janitorial service to clean our restrooms.”
“So, let me get this straight: You are enlightened enough to realize that cleaning toilets would be a waste of your team’s time, so you hired a janitorial service. Why on earth would you waste your precious DevOps resources to do the moral equivalent of this in IT, by having them waste time writing scripts to schedule on/off times for EC2 instances?”
“They should be spending that time on your main business applications. Leave that to us!”
Increasingly, they get point.
/* End Rant */
In closing, please remember: Friends don’t let DevOps friends waste time on AWS scripting for things not related to application delivery (especially when there are more cost-effective commercial products available to help save time and money). Friends do tell their DevOps friends about ParkMyCloud.
Our hero, Mr. Bobvious, the IT Ops guy who automatically turns off idle AWS instances using ParkMyCloud, was texting with his teenage son not long ago. Afterwards he realized that the challenge of getting his company’s developers to remember to turn off their AWS instances was the same as…well read on and you’ll see:
Mr. Bobvious: Jake? Are you home?
Mr. Bobvious: What’s sup?
Teen: Not much, howboutchoo?
Mr. Bobvious: No I mean what does sup mean?
Teen: What’s up?
Mr. Bobvious: Can you just give me a straight answer pls?
Teen: sup means what is up
Mr. Bobvious: Oh, sorry. Are you home?
Mr. Bobvious: Just make sure you turn the lights off in your room, the bathroom and the hall before you leave.
Mr. Bobvious: And the kitchen, mudroom and any other room you were in today
Teen: Oh. I’m not home. Sorry.
Mr. Bobvious: Did you turn any lights off before you left?
Mr. Bobvious: How many times do we have to discuss this? Electricity is not free.
Mr. Bobvious: What if I left your iPad on all day and the battery was drained when you got home?
Teen: I’d plug it in. I guess.
Mr. Bobvious: Anyway.
Teen: Dad, I’m just a teen. Teens aren’t wired to turn stuff off.
Mr. Bobvious: You know our software developers leave our computer servers on all night.
Mr. Bobvious: Do you know what my boss would do to me if I let that happen?
Teen: Fire you?
Mr. Bobvious: No, no. He’d just be mad that I’m wasting electricity and money.
Teen: So what’d ya do about the computers?
Mr. Bobvious: I bought software that turns off the computers automatically. We’re saving a fortune.
Mr. Bobvious: Thanks!
Teen: Are you on the way home?
Mr. Bobvious: Why?
Teen: Just thinkin about how good some Chipotle would taste right about now.