Traditional IT companies may dominate in a few fields, but in others, they will never catch up to those companies “born in the cloud.”
I actually have a unique perspective on these two worlds, as prior to this adventure at ParkMyCloud, I worked at IBM for many years. I was originally with Micromuse, where we had a fault and service assurance solution (Netcool) to manage and optimize Network and IT Operations. Micromuse was acquired by IBM in 2006 by the Tivoli Software Group business unit (later to be named Smarter Cloud). IBM was great – I learned a lot and met a lot of very smart, bright people. I was in Worldwide Sales Management so I had visibility across the globe into IT trends.
In the 2012/2013 timeframe, I noticed we were losing a lot of IT management, monitoring and assurance deals to companies like ServiceNow, New Relic, Splunk, Microsoft, and the like – all these “born in cloud” companies offering SaaS-based solutions to solve complex enterprise problems (that is, “born in the cloud” other than Microsoft – I’ll come back to them).
At first these SaaS-based IT infrastructure management companies were managing traditional on-premise servers and networks, but as more and more companies moved their infrastructure into the cloud, the SaaS companies were positioned to manage that as well – but at IBM, we were not. All of the sudden we were trying to sell complex, expensive IT management solutions for stuff running in this “cloud” called Amazon Web Services (AWS) – a mere 5 years ago. And then Softlayer, Rackspace, and Microsoft Azure popped up. I start thinking, there must be something here, but what is it and who’s going to manage and optimize this infrastructure?
After a few years sitting on the SaaS side of the table, now I know. Many meetings and discussions with very large Fortune 100 enterprises have taught me several very salient points about the cloud:
Public cloud is here to stay – see Capital One or McDonald’s at recent AWS re:Invent Keynotes (both customers of ParkMyCloud, by the way)
Enterprises are NOT using “traditional” IT tools to build, test, run and manage infrastructure and applications in the cloud
What’s different about the cloud is that it’s a YUGE utility, which means companies now focus on cost control. Since it’s an OpEx model rather than a CapEx model they want to continually optimize their spend
Agility and innovation drive public cloud adoption but as cloud maturity grows so does the need for optimization – governance, cost control, and analytics.
So where does this leave the traditional companies like Oracle, HPE, and IBM? How are they involved in the migration to and lifecycle management of cloud-based applications? Well, from what I have seen they on the outside looking in – which is why when my good friend sent this to me the other day I was shocked – I guess Oracle decided to spot AWS a $13B lead – pretty smart, I am sure they will make this gap up by oh, let’s say 2052… brilliant strategy.
That said, one company that “gets it” seems to be Microsoft, both in terms of providing cloud infrastructure (Azure) but also being progressive enough to license their technologies for even the smallest of companies to adopt and grow using their applications.
To put a bow on this point, I was at a recent meeting where a Fortune 25 company was talking to us about their migration into the cloud, and the tools they are using:
Clouds – AWS / Azure
Migration – service partner
Monitoring – DataDog
Service Desk and CMDB – ServiceNow
Application Management – NewRelic
Log analytics – Splunk
Pipeline automation – Jenkins
Cost control (yes, that’s a category now) – ParkMyCloud
Now that’s some pretty good company! And not a single “traditional” IT tool on the list. I guess it takes one born in the cloud to manage it.
We spoke to Tosin Ojediran, a DevOps Engineer at a FinTech company, about how he’s using ParkMyCloud as part of his approach to save money in DevOps.
Hi Tosin. So you work in FinTech. Can you tell us about what your team does within the company?
I’m on the DevOps team. We’re in charge of the cloud infrastructure, which ranges from servers to clusters and beyond. We have the task of maintaining the integrations between all the different services we use. Our main goal is to make sure our infrastructure is up and running and to maintain it. Our team just grew from two to three people.
What drove you to search for a cost optimization tool?
Last year, we were scaling our business, and with all the new development and testing, we kept needing to launch new clusters, databases, and instances. We did monitor the costs, but it was the Finance team that came to us and said, “hey, what’s going on with AWS? The costs keep going up, can you guys find a way to reduce this bill or move to a cheaper provider?”
So we looked into different options. We could move to Google for example, or we could move on prem, but at the time we were a team of two running a new project, trying to get things up and running, so we didn’t have the time. We had to find out how we could save money in DevOps without spending all our time to move to anew infrastructure. We went online to do research and came across ParkMyCloud, and started a trial.
What challenges did you experience in using AWS prior to using ParkMyCloud?
Like I mentioned, we were trying to cut costs. To do that, we were brainstorming about how we could write scripts to shut down machines during certain hours and spin them up. The problem was that this would require our time to write, integrate, and maintain.
We have different automation tools and containers – Chef, Docker machines, and Auto Scaling. Each of these takes time to script up. This all takes away from the limited time we have. With ParkMyCloud, we didn’t need to spend time on this automation – it was fast and simple. It allowed me to have all teams, including Analysts and others outside of the DevOps team, park their own resources. If you have a script that you runandif you have a two-man DevOps team, every time someone wants to park their machine, or start it outside of hours, they have to call me and ask me to do start their machines for them. But now with ParkMyCloud, I can assign machines to individual teams, they can start their machines whenever you want them – and it’s easy to use, you don’t have to know programming to use it
It frees up my time, because now everyone can control their own resources, when they used to have to ask me to do it for them.
Can you describe your experience so far using ParkMyCloud?
It’s been great for us to reduce AWS costs. We’re better staying within budget now. ParkMyCloud actually really exceeded my expectations. We sent the savings numbers to our CTO, and he said, “wow, this is awesome.” It’s easy to use, it does what it’s supposed to use. We’re reducing our bill by about 25-30%.
One other thing I love about ParkMyCloud. So, I work with a lot of vendors. A lot of times, they promise you one thing, and you get something else. There’s different terms and conditions, or you have to pay extra to actually qualify for different features. But with ParkMyCloud, it was up and running in 5-10 minutes, it was easy to integrate, easy to use, and you all deliver what you promise.
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.