Cloud Operations Management: Is the cloud really making operations easier?

As cloud becomes more mature, the need for cloud operations management becomes more pervasive. In my world, it seems pretty much like IT Operations Management (ITOM) from decades ago. In the way-back machine I used to work at Micromuse, the Netcool company, which was acquired by IBM Tivoli, the Smarter Planet company, which then turned Netcool into Smarter Cloud … well you get the drift. Here we are 10+ years later, and IT = Cloud (and maybe chuck in some Watson).

Cloud operations management is the process concerned with designing, overseeing, controlling, and subsequently redesigning cloud operational processes.  This involves management of both hardware and software as well as network infrastructures to promote an efficient and lean cloud.

Analytics is heavily involved in cloud operations management and used to maximize visibility of the cloud environment, which gives the organization the intelligence required to control the resources and running services confidently and cost-effectively.

Cloud operations management can:

  • Improve efficiency and minimize the risk of disruption
  • Deliver the speed and quality that users expect and demand
  • Reduce the cost of delivering cloud services and justify your investments

Since ParkMyCloud helps enterprises control cloud costs, we mostly talk to customers about the part of cloud operations concerned with running and managing resources. We are all about that third bullet – reducing the cost of delivering cloud services and justifying investments. We strive to accomplish that while also helping with the first two bullets to really maximize the value the cloud brings to an enterprise.

So what’s really cool is when we get to ask people what tools they are using to deploy, secure, govern, automate and manage their public cloud infrastructure, as those are the tools that they want us to integrate into as part of their cost optimization efforts, and we need to understand the roles operation folks now play in public cloud (CloudOps).

And, no it’s not easier to manage cloud. In fact I would say it’s harder. The cloud provides numerous benefits – agility, time to market, OpEx vs. CapEx, etc. – but you still have to automate, manage and optimize all those resources. The pace of change is mind boggling – AWS advertises 150+ services now, from basic compute to AI, and everything in between.

So who are these people responsible for cloud operations management? Their titles tend to be DevOps, CloudOps, IT Ops and Infrastructure-focused, and they are tasked with operationalizing their cloud infrastructure while teams of developers, testers, stagers, and the like are constantly building apps in the cloud and leveraging a bottoms-up tools approach. Ten years ago, people could not just stand up a stack in their office and have at it, but they sure as hell can now.

So what does this look like in the cloud? I think KPMG did a pretty good job with this graphic and generally hits on the functional buckets we see people stick tools into for cloud operations management.

So how should you approach your cloud operations management journey? Let’s revisit the goals from above.

  1. Efficiency – Automation is the name of the game. Narrow in on the tools that provide automation to free up your team’s development time.
  2. Deliverability – See the bullet above. When your team has time, they can focus on delivering the best possible product to your customers.
  3. Cost control – Think of “continuous cost control” as a companion to continuous integration and continuous delivery. This area, too, can benefit from automated tools – learn more about continuous cost control.

 

Read more ›

Microsoft’s Start/Stop VM Solution vs. ParkMyCloud

Microsoft recently released a preview of their Start/Stop VM solution in the Azure Marketplace. Users of Azure took notice and started looking into it, only to find that it was lacking some key functionality that they required for their business. Let’s take a look at what this Start/Stop tool offers and what it lacks, then compare it to ParkMyCloud’s comprehensive offering.

Azure Start/Stop VM Solution

The crux of this solution is the use of a few Azure services, specifically Automation and Log Analytics to schedule the VMs and SendGrid to let you know when a system was shut down or started via email. This use of native tools within Azure can be useful if you’re already baked into the Azure ecosystem, but can be prohibitive to exploring other cloud options.

This solution does cost money, but it’s not very easy to estimate the cost (but does that surprise you?). The total cost is based on the underlying services (Automation, Log Analytics, and SendGrid), which means it could be very cheap or very expensive depending on what else you use and how often you’re scheduling resources. The schedules can be based on time, but only for a single start and stop time. The page claims it can be based on utilization, but in the initial setup there is no place to configure that. It also needs to be set up for 4 hours before it can show you any log or monitoring information.

The interface for setting up schedules and automation is not very user-friendly. It requires creating automation scripts that are either for stopping or starting only, and only have one time attached. To create new schedules, you have to create new scripts, which makes the interface confusing for those who aren’t used to the Azure portal. At the end of the setup, you’ll have at least a dozen new objects in your Azure subscription, which only grows if you have any significant number of VMs.

How it stacks up to ParkMyCloud

So if the Start/Stop VM Solution from Microsoft can start and stop VMs, what more do you need? Well, we at ParkMyCloud have heard from customers (ranging from day-1 startups to Fortune 100 companies) that there are features necessary for a cloud cost optimization tool if it is going to get widespread adoption. Here are some of the features ParkMyCloud has that are missing from the Microsoft tool:

  • Single Pane of Glass – ParkMyCloud can work with multiple clouds, multiple accounts within each cloud, and multiple regions within each account, all in one easy-to-use interface.
  • Easy to change or override schedules – Users can change schedules or temporarily “snooze” them through the UI, our API, our Slackbot, or through our iOS app.
  • User Management – Admins can delegate access to users and assign Team Leads to manage sub-groups within the organization, providing user governance over schedules and VMs.
  • No Azure-specific knowledge needed – Users don’t need to know details about setting up Automation Scripts or Log Analytics to get their servers up and running. Many ParkMyCloud administrators provide access to users throughout their organizations via the ParkMyCloud RBAC. This is useful for users who may need to, say, start and stop a demo environment on demand, but who do not have the knowledge necessary to do this through the Azure console.
  • Enterprise features – Single sign-on, savings reports, notifications straight to your email or chat group, and full support access helps your large organization save money quickly.

As you can tell, the Start/Stop VM solution from Microsoft can be useful for very specific cases, but most customers will find it lacking the features they really need to make cloud cost savings a priority. ParkMyCloud offers these features at a low cost, so try out the free trial now to see how quickly you can cut your Azure cloud bill.

Read more ›

AWS Neptune Preview – Amazon’s Graph Database Service

At the AWS DC Meetup we organized last week, we got a preview of AWS Neptune, Amazon’s new managed graph database service. It was announced at AWS re:Invent 2017, is currently in preview and will launch for general availability this summer.

What is a graph database?

A graph database is a database optimized to store and process highly connected data – in short, it’s about relationships. The data structure for these databases consists of vertices and direct links called edges.

Use cases for such highly-connected data include social networking, restaurant recommendations, retail fraud detection, knowledge graphs, life sciences, and network & IT ops. For a restaurant recommendations use case, for example, you may be interested in the relationships between various users, where those users live, what types of restaurants those users like, where the restaurants are located, what sort of cuisine they serve, and more. With a graph database, you can use the relationships between these data points to provide contextual restaurant recommendations to users.

Tired of SQL?

If you’re tired of SQL, AWS Neptune may be for you. A graph database is fundamentally different from SQL. There are no tables, columns, or rows – it feels like a NoSQL database. There are only two data types: vertices and edges, both of which have properties stored as key-value pairs.

AWS Neptune is fully managed, which means that database management tasks like hardware provisioning, software patching, setup, configuration, and backups are taken care of for you.

It’s also highly available and shows up in multiple availability zones. This is very similar to Aurora, the relational database from Amazon, in its architecture and availability.

Neptune supports Property Graph and W3C’s RDF. You can use these to build your own web of data sets that you care about, and build networks across the data sets in the way that makes sense for your data, not with arbitrary presets. You can do this using the graph models’ query languages: Apache TinkerPop Gremlin and SPARQL.

There is no cost to use Neptune during the preview period. Once it’s generally available, pricing will rely on On Demand EC2 instances – which means ParkMyCloud will be looking into ways to assist Neptune users with cost control.

If you’re interested in the new service, you can check out more about AWS Neptune and sign up for the preview.

Read more ›

The M Instance type: EC2 starts here

If you are using AWS EC2 in production, chances are good that you’re using the AWS M instance type. The M family is a “General Purpose” instance type in AWS, most closely matching a typical off-the-shelf server one would buy from Dell, HP, etc, and was the first instance family released by AWS in 2006.

If you are looking for mnemonics for an AWS certification exam, you may want to think of the M instance type as the Main choice, or the happy Medium between the more specialized instances. The M instance provides a good balance of CPU, RAM, and disk size/performance. The other instance types specialize in different ways, providing above average CPU, RAM, or disk size/performance, and include a price premium. The one exception is the “T” instance type, discussed further below.

For a normal web or application server workload, the M instance type is probably the best tool for the job. Unless you KNOW you are going to be running a highly RAM/CPU/IO-intensive workload, you can usually start with an M instance, monitor its performance for a while, and then if the instance is performance-limited by one of the hardware characteristics, switch over to a more specialized instance to remove the constraint. For example:

  • “C” instances for Compute/CPU performance.
  • “R” or “X” instances for lots of memory – RAM or eXtreme RAM
  • “D”, “H”, or “I” instances optimize for storage with different types/quantities of local storage drives (i.e., HDD or SDD that are part of the physical hardware the instance is running on) for high-Density storage (up to 48TB), High sequential throughput, or fast random I/O IOPS, respectively. (The latter two categories are much more specialized – see here for more details)

The “T” instance family is much like the “M” family, in that it is aimed at general purpose workloads, but at a lower price point. The key difference (and perhaps the only difference) is that the CPU performance is restricted to bursts of high performance (or “bursTs”) that are tracked by AWS through a system of CPU credits. Credits build up when the system is idle, and are consumed when the CPU load exceeds a certain baseline. When the CPU credit balance is used-up, the CPU is Throttled to a fraction of its full speed. T instances are good for low-load web servers and non-production systems, such as those used by developers or testers, where continuous predictable high performance is not needed.

Statistics

Looking at some statistics, the Botmetric Public Cloud Usage Report for 2017 states that 46% of AWS EC2 usage is on the M family, and 83% of non-production workloads are on T instances. Within the ParkMyCloud environment, we see the following top instance family statistics across our customers’ environments:

  • I instances: 39%
  • M instances: 22%
  • T instances: 27%

Since many of our customers are focused on cost optimization for non-production cloud resources (i.e., a lot of developers and test environments), we are probably seeing more “T” instances than “M” instances as they are less expensive, and the “bursty” nature of T instances is not a factor in their work. For a production workload, M instances with dedicated CPU resources are more predictable. While we cannot say for sure why we are also seeing a very large number of “I” instances, it is quite possible that developers/testers are running database software in an EC2 instance, rather than in RDS, in order to have more direct control and visibility into the database system. Still, 49% of the resources are in the General Purpose M and T families.

The Nitty and/or Gritty

Assuming you have decided that an M instance is the right tool for your job, your next choice will be to decide which one. As of the date of this blog, there are twelve different instance types within the M family, covering two generations of systems.

Table 1 – The M Instance Family Specs (Pricing per hour for on-demand instances in US-East-1 Region)

The M4 generation was released in June 2015. The M4 runs 64-bit operating systems on hardware with the 2.3 GHz Intel Xeon E5-2686 (Broadwell) or 2.4 GHz Intel Xeon E5-2676 H3 (Haswell) processors, potentially jumping to 3GHz with Turbo Boost. None of the M4 instance family supports instance store disks, but are all EBS-optimized by default. These instances also support Enhanced Networking, a no-extra-cost option that allows up to 10 Gbps of network bandwidth.

The M5 generation was just released this past November at re:Invent 2017. The M5 generation is based on custom Intel Xeon Platinum 8175M processors running at 2.5GHz. When communicating with other systems in a Cluster Placement Group (a grouping of instances in a single Availability Zone), the m5.24xlarge instance can support an amazing 25 Gbps of network bandwidth. The M5 type also support EBS via an NVMe driver, a block storage interface designed for flash memory. Interestingly, AWS has not jacked-up the EBS performance guarantee for this faster EBS interface. This may be because it is the customer’s responsibility to install the right driver to get the higher performance on older OS images, so this could also be a cheap/free performance win if you can migrate to M5.

Amazon states that the M5 generation delivers 14% better price/performance on a per-core basis than the M4 generation. In the pricing above, one can do the math and find that all of the M5 instances cost $0.048 per vCPU per hour, and that the M4 instances all cost $0.05 per vCPU per hour. So right out of the box, the M5 is priced 4% cheaper than an equivalently configured M4. Do the same math for RAM vs vCPU and you can see that AWS allocates 4GB of RAM per vCPU in both the M4 and M5 generations. This probably says a lot about how the underlying hardware is sliced/diced for virtual machines in the AWS data centers.

For more thoughts on historic M instance pricing, please see our other blog about the dropping cost of cloud services.

Parting thoughts

Some key takeaways:

  • If you are not sure how your application is going to behave under a production load, start with an M instance and migrate to something more specialized if needed.
  • If you do not need consistent and continuous high CPU performance, like for dev/test or low usage systems, consider using the similarly General Purpose T instance family.
  • If you are launching a new instance, use the M5 generation for the better value.

Overall, the M family gives the best price/performance for General Purpose production systems,  Making it your Main choice for Middlin’ performance of Most workloads!

 

Read more ›

7 Ways Cloud Services Pricing is Confusing

Beware the sticker shock – cloud services pricing is nothing close to simple, especially as you come to terms with the dollar amount on your monthly cloud bill. While cloud service providers like AWS, Azure, and Google were meant to provide compute resources to save enterprises money on their infrastructure, cloud services pricing is complicated, messy, and difficult to understand. Here are 7 ways that cloud providers obscure pricing on your monthly bill:  

1 – They use varying terminology

For the purpose of this post, we’ll focus on the three biggest cloud service providers: AWS, Azure, and Google. Between these three cloud providers alone, different analogies are used for just about every component of services offered.

For example, when you think of a virtual machine (VM), that’s what AWS calls an “instance,” Azure calls a “virtual machine,” and Google calls a “virtual machine instance.” If you have a group of these different machines, or instances, in Amazon and Google they’re called “auto-scaling” groups, whereas in Azure they’re called “scale sets.” There’s also different terminology for their pricing models. AWS offers on-demand instances, Azure calls it “pay as you go,” and Google refers to it as “sustained use.” You’ve also got “reserved instances” in AWS, “reserved VM instances” in Azure, and “committed use” in Google. And you have spot instances in AWS, which are the same as low-priority VMs in Azure, and preemptible instances in Google.

2 – There’s a multitude of variables

Operating systems, compute, network, memory, and disk space are all different factors that go into the pricing and sizing of these instances. Each of these virtual machine instances also have different categories: general purpose, compute optimized, memory optimized, disk optimized and other various types. Then, within each of these different instance types, there are different families. In AWS, the cheapest and smallest instances are in the “t2” family, in Azure they’re called the “A” family. On top of that, there are different generations within each of those families, so in AWS there’s t2, t3, m2, m3, m4, and within each of those processor families, different sizes (small, medium, large, and extra large). So there’s lots of different options available. Oh, and lots confusion, too.  

3 – It’s hard to see what you’re spending

If you aren’t familiar with AWS, Azure, or Google Cloud’s consoles or dashboards, it can be hard to find what you’re looking for. To find specific features, you really need to dig in, but event just trying to figure out the basics of how much you’re currently spending, and predicting how much you will be spending – all can be very hard to understand. You can go with the option of building your own dashboard by pulling in from their APIs, but that takes a lot of upfront effort, or you can purchase an external tool to manage overall cost and spending.

4 – It’s based on what you provision…not what you use

Cloud services pricing can charge on a per-hour, per-minute, or per-second basis. If you’re used to the on-prem model where you just deploy things and leave them running 24/7, then you may not be used to this kind of pricing model. But when you move to the cloud’s on-demand pricing models, everything is based on the amount of time you use it.

When you’re charged per hour, it might seem like 6 cents per hour is not that much, but after running instances for 730 hours in a month, it turns out to be a lot of money. This leads to another sub-point: the bill you get at the end of the month doesn’t come until 5 days after the month ends, and it’s not until that point that you get to see what you’ve used. As you’re using instances (or VMs) during the time you need them, you don’t really think about turning them off or even losing servers. We’ve had customers who have servers in different regions, or on different accounts that don’t get checked regularly, and they didn’t even realize they’ve been running all this time, charging up bill after bill.

You might also be overprovisioning or oversizing resources — for example, provisioning multiple extra large instances thinking you might need them someday or use them down the line. If you’re used to that, and overprovisioning everything by twice as much as you need, it can really come back to bite you when you go look at the bill and you’ve been running resources without utilizing them, but are still getting charged for them – constantly.

5 – They change the pricing frequently

Cloud services pricing has changed quite often. So far, they have been trending downward, so things have been getting cheaper over time due to factors like competition and increased utilization of data centers in their space. However, don’t jump to conclude that price changes will never go up.

Frequent price changes make it hard to map out usage and costs over time. Amazon has already made changes to their price more than 60 times since they’ve been around, making it hard for users to plan a long-term approach. Also for some of these instances, if you have them deployed for a long time, the prices of instances don’t display in a way that is easy to track, so you may not even realize that there’s been a price change if you’ve been running the same instances on a consistent basis.

6 – They offer cost savings options… but they’re difficult to understand (or implement)

In AWS, there are some cost savings measures available for shutting things down on a schedule, but in order to run them you need to be familiar with Amazon’s internal tools like Lambda and RDS. If you’re not already familiar, it may be difficult to actually implement this just for the sake of getting things to turn off on a schedule.  

One of the other things you can use in AWS is Reserved Instances, or with Azure you can pay upfront for a full year or two years. The problem: you need to plan ahead for the next 12 to 24 months and know exactly what you’re going to use over that time, which sort of goes against the nature of cloud as a dynamic environment where you can just use what you need. Not to mention, going back to point #2, the obscure terminology for spot instances, reserved instances, and what the different sizes are.

7 – Each service is billed in a different way

Cloud services pricing shifts between IaaS (infrastructure as a service), which uses VMs that are billed one way, and PaaS (platform as a service) gets billed another way. Different mechanisms for billing can be very confusing as you start expanding into different services that cloud providers offer.

As an example, the Lambda functions in AWS are charged based on the number of requests for your functions, the duration, and the time it takes for your code to execute. The Lambda free tier includes 1M free requests per month and 400,000 GB-seconds of compute time per month, or you can get 1M request free and $0.20 per 1M requests thereafter, OR use “duration” tier and get 400,000 GB-seconds per month free, $0.00001667 for every GB-second used thereafter – simple, right? Not so much.

Another example comes from the databases you can run in Azure. Databases can run as a single server or can be priced by elastic pools, each with different tables based on the type of database, then priced by storage, number of databases, etc.

With Google Kubernetes clusters, you’re getting charged per node in the cluster, and each node is charged based on size. Nodes are auto-scaled, so price will go up and down based on the amount that you need. Once again, there’s no easy way of knowing how much you use or how much you need, making it hard to plan ahead.

What can you do about it?

Ultimately, cloud service offerings are there to help enterprises save money on their infrastructures, and they’re great options IF you know how to use them. To optimize your cloud environment and save money on costs, we have a few suggestions:

    • Get a single view of your billing. You can write your own scripts (but that’s not the best answer) or use an external tool.  
    • Understand how each of the services you use is billed. Download the bill, look through it, and work with your team to understand how you’re being billed.
    • Make sure you’re not running anything you shouldn’t be. Shut things down when you don’t need them, like dev and test instance on nights and weekends.Try to plan out as much as you can in advance.
    • Review regularly to plan out usage and schedules as much as you can in advance
    • Put governance measures in place so that users can only access certain features, regions, and limits within the environment. 

Cloud services pricing is tricky, complicated, and hard to understand. Don’t let this confusion affect your monthly cloud bill. Try ParkMyCloud for an automated solution to cost control.

Read more ›

How to Use Terraform Provisioning and ParkMyCloud to Manage AWS

Recently, I’ve been on a few phone calls where I get asked about cost management of resources built in AWS using Terraform provisioning. One of the great things about working with ParkMyCloud customers is that I get a chance to talk to a lot of different technical teams from various types of businesses. I get a feel for how the modern IT landscape is shifting and trending, plus I get exposed to the variety of tools that are used in real-world use cases, like Atlassian Bamboo, Jenkins, Slack, Okta, and Hashicorp’s Terraform.

Terraform seems to be the biggest player in the “infrastructure as code” arena. If you’re not already familiar with it, the utilization is fairly straightforward and the benefits quickly become apparent. You take a text file, use it to describe your infrastructure down to the finest detail, then run “terraform apply” and it just happens. Then, if you need to change your infrastructure, or revoke any unwanted changes, Terraform can be updated or roll back to a known state. By working together with AWS, Azure, VMware, Oracle, and much more, Terraform can be your one place for infrastructure deployment and provisioning.

How to Use Terraform Provisioning and ParkMyCloud with AWS Autoscaling Groups

I’ve talked to a few customers recently, and they utilize Terraform as their main provisioning tool, while ParkMyCloud is their ongoing cloud governance and cost control tool. Using these two systems together is great, but one main confusion comes in with AWS’s AutoScaling Groups. The question I usually get asked is around how Terraform handles the changes that ParkMyCloud makes when scheduling ASGs, so let’s take a look at the interaction.

When ParkMyCloud “parks” an ASG, it sets the Min/Max/Desired to 0/0/0 by default, then sets the values for “started” to the values you had originally entered for that ASG. If you run “terraform apply” while the ASG is parked, then terraform will complain that the Min/Max/Desired values are 0 and will change them to the values you state. Then, when ParkMyCloud notices this during the next time it pulls from AWS (which is every 10 minutes), it will see that it is started and stop the ASG as normal.

If you change the value of the Min/Max/Desired in Terraform, this will get picked up by ParkMyCloud as the new “on” values, even if the ASG was parked when you updated it. This means you can keep using Terraform to deploy and update the ASG, while still using ParkMyCloud to park the instances when they’re idle.

How to Use Terraform to Set Up ParkMyCloud

If you currently leverage Terraform provisioning for AWS resources but don’t have ParkMyCloud connected yet, you can also utilize Terraform to do the initial setup of ParkMyCloud. Use this handy Terraform script to create the necessary IAM Role and Policy in your AWS account, then paste the ARN output into your ParkMyCloud account for easy setup. Now you’ll be deploying your instances as usual using Terraform provisioning while parking them easily to save money!

Read more ›

$12.9 Billion in wasted cloud spend this year.

Wake up and smell the wasted cloud spend. The cloud shift is not exactly a shift anymore, it’s an evident transition. It’s less of a “disruption” to the IT market and more of an expectation. And with enterprises following a visible path headed towards the cloud, it’s clear that their IT spend is going in the same direction: up.

Enterprises have a unique advantage as their cloud usage continues to grow and evolve. The ability to see where IT spend is going is a great opportunity to optimize resources and minimize wasted cloud spend, and one of the best ways to do that is by identifying and preventing cloud waste.

So, how much cloud waste is out there and how big is the problem? What difference does this make to the enterprises adopting cloud services at an ever-growing rate? Let’s take a look.

The State of the Cloud Market in 2018

The numbers don’t lie. For a real sense of how much wasted cloud spend there is, the first step is to look at how much money enterprises are spending in this space at an aggregate level.

Gartner’s latest IT spending forecast predicts that worldwide IT spending will reach $3.7 trillion in 2018, up 4.5 percent from 2017. Of that number, the portion spent in the public cloud market is expected to reach $305.8 billion in 2018, up $45.6 billion from 2017.

The last time we examined the numbers back in 2016, the global public cloud market was sitting at around $200 billion and Gartner had predicted that the cloud shift would affect $1 trillion in IT spending by 2020. Well, with an updated forecast and over $100 billion dollars later, growth could very well exceed predictions.

The global cloud market and the portion attributed to public cloud spend are what give us the ‘big picture’ of the cloud shift, and it just keeps growing, and growing, and growing. You get the idea. To start understanding wasted cloud spend at an organizational level, let’s break this down further by looking at an area that Gartner says is driving a lot of this growth: infrastructure as a service (IaaS).

Wasted Cloud Spend in IaaS

As enterprises increasingly turn to cloud service providers like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) to provide compute resources for hosting components of their infrastructures, IaaS plays a significant role in both cloud spend and cloud waste.

Of the forecasted $305.8 billion dollar public cloud market  for 2018, $45.8 billion of that will be spent on IaaS, ⅔ of which goes directly to compute resources. This is where we get into the waste part:

  • 44% of compute resources are used for non-production purposes (i.e. development, staging, testing, QA)
  • The majority of servers used for these functions only need to run during the typical 40-hour work week (Monday through Friday, 9 to 5) and do not need to run 24/7
  • Cloud service providers are still charging you by the hour (or minute, or even by the second) for providing compute resources

The bottom line: for the other 128 hours of the week (or 7,680 minutes, or 460,800 seconds) – you’re getting charged for resources you’re not even using. And there’s a large percent of your waste!

What You Can Do to Prevent Wasted Cloud Spend

Turn off your cloud resources.

The easiest and fastest way to save money on your idle cloud resources when  is by simply by not using them. In other words, turn them off. When you think of the cloud as a utility like electricity, it’s as simple as turning off the lights every night and when you’re not at home. With ParkMyCloud you can automatically schedule your cloud resources to turn off when you don’t need them, like nights and weekends, and eliminate 65% or more on your monthly bill with AWS, Azure, and Google. Wham. bam.

Turn on your SmartParking.

You already know that you don’t need your servers to be on during nights and weekends, so you shut them off. That’s great, but what if you could save even more with valuable insight and information about your exact usage over time?

With ParkMyCloud’s new SmartParking feature, the platform will track your utilization data, look for patterns and create recommended schedules for each instance, allowing you to turn them off when they’re typically idle.

There’s a lot of cloud waste out there, but there’s also something you can do about it: try ParkMyCloud today.

Read more ›

Yeah, Yeah, Yeah we Park %$#@, but what really matters to Enterprises? – Frequently Asked Questions

Here at ParkMyCloud we get to do product demos for a lot of great companies all over the world, from startups to Fortune 500’s, and in many different industries – Software, IT, Financial, Media, Food and Beverage, and many more. And as we talk to industry analysts and venture capitalists they always ask about vertical selling and the like — we used to do this back at Micromuse where had Federal, Enterprise, Service Provider and SMB sales teams, for example. But here at ParkMyCloud we notice in general the questions from enterprises are vertical-agnostic, and since cloud is the great IT equalizer in my book, we decided to summarize the 8 Most Frequently Asked Questions we get from prospects of all shapes and sizes.

These are the more common questions we get beyond turning cloud resources off / on:

How does ParkMyCloud handle system patching?

Answer: The most common way of dealing with patching is to use our API.  The workflow would be to log in through the API, get a list of the resources, then choose which resources you want and choose to “snooze” the schedule (which is a temporary override of the schedule, if you haven’t played with that yet) for a couple of hours, or however long the patching takes.  Once the schedule is snoozed, you can toggle the instance on, then do the patching.  After the patching is complete, you can either cancel the snooze to go back to the original schedule or wait for the snooze to finish and timeout.

If your patching is done on a weekly basis, you could also just implement the patch times into the schedules so the instances turn on, say at 3am on Sunday.

How do I start and stop instances in a sequential order?

Answer: ParkMyCloud has created a feature that we call ‘Logical Groups’, basically you group cloud resources into a group or cluster within the platform and then assign the order you wish them to stop and start, you can also set how long it takes before resource 1 starts / stops and then resource 2 starts / stops and so forth. This way, your web server can stop first and the database can stop second so all the connections close properly. As this feature is very popular, we have had many requests to fully automate this using our policy engine and tags, a work in progress – that will be way cool.

My developers hate UI’s, how does he/she manage the schedules without using your UI?

Answer: Yes, this is an easy one but always gets asked. If you are anti-UI or just don’t want to use yet another UI, you can use the following channels to manage your resources in ParkMyCloud:

Can I govern user access and permissions?

Answer: Yes, we have support for Single-Sign On (SSO) and a full on Role-based Access Control model (RBAC) in the platform that allows you to import users, add them to teams and assign them roles. The common scenario around this is ‘I only want my SAP QA team to have access to the cloud resources they need for that project and nothing else, and limit their permissions’ – handled.

Can I automatically assign schedules based on tags?

Answer: Yes, and in general this what most companies do using ParkMyCloud. We have a Policy Engine where you can create policies that allow you to fully automate your cloud resource scheduling. Basically the policy reads the AWS, Azure, or Google Cloud metadata that is brought into the platform, and based on those tags (or even other data like resource name, size, region, etc.) and the corresponding policy, we can automatically assign schedules to cloud resources. And we take that a step further, as those resources can also be automatically parsed to Teams and Users as well based on their roles (see RBAC).

You can only park stuff based on tags? That’s so weak!

Answer: Not so fast my friend … I must admit we sort of threw this one in there but it does come up quite often, and we recently solved this problem with our release of SmartParking, which allows you to bring in metric data, trend it for a period of time, and then automatically create schedules based on those usage patterns – cool stuff.

Can we pick which instances we bring into ParkMyCloud?

Answer: Sort of, through their API the cloud providers don’t allow you to choose which cloud resources in an account you bring into the platform, if you link a cloud account to ParkMyCloud all the cloud resources in that account will populate (assuming our API supports those resources and the cloud provider allows you to ‘park’ them). But we do let you choose which accounts you bring into ParkMyCloud, so link accounts and bring in as many or as few accounts as you wish, and by the way AWS recommends you create accounts based on on function like Production, Dev, Test, QA, etc., and then breaks that down even more granular to Dev 1, Dev 2, Dev 3, etc. – this is ideal for ParkMyCloud.

Where is ParkMyCloud located?

Answer: Northern Virginia of course, in Sterling at Terminal 68 to be precise. It’s a co-working space we share with several other startups; we would also be remiss if we did not mention this area is also one of the finalist locations for Amazon’s H2Q – it’s a hotbed of cloud and data center activity.

We hope this was helpful and would value your feedback on the 8 Most Frequently Asked Questions we get, and if yours are the same or different, or of course our favorite … have you thought of XYZ as a feature? Let us know at info@parkmycloud.com.

Read more ›

The Cost of Cloud Computing Is, in Fact, Dropping Dramatically

You might read the headline statement that the cost of cloud computing is dropping  and say “Well, duh!”. Or maybe you’re on the other side of the fence. A coworker recently referred me to a very interesting blog on the Kapwing site that states Cloud costs aren’t actually dropping dramatically. The author defines“dramatically” based on the targets set by Moore’s Law or the more recently proposed Bezos’ Law, which states that “a unit of [cloud] computing power price is reduced by 50 percent approximately every three years.” The blog focused on the cost of the Google Cloud Platform (GCP) n1-standard-8 machine type, and illustrated historical data for the Iowa region:

Date N1-standard-8 Cost per Hour
January 2016 $0.40
January 2017 $0.40
January 2018 $0.38

The Kapwing blog also illustrates that the GCP storage and network egress costs have not changed at all in three years. These figures certainly add up to a conclusion that Bezos’ Law is not working…at least not for GCP.

Whose law is it anyway?

If we turn this around and try to apply Bezos’ Law to, well, Bezos’ Cloud we see a somewhat different story.

The approach to measuring AWS pricing changes needs to be a bit more systematic than for GCP, as the AWS instance types have been evolving quite a bit over their history. This evolution is shown by the digit that follows the first character in the instance type, indicating the version or generation number of the given instance type . For example, m1.large vs. m5.large. These are similar virtual machines in terms of specifications, with 2 vCPUs and about 8GB RAM, but the m1.large was released in October 2007, and the m5.large in November 2017. While  the “1” in the GCP n1-standard-8 could also be a version number,  it is still the only version I can see back to at least 2013. For AWS, changes in these generation numbers happen more frequently and likely reflect the new generations of underlying hardware on which the instance can be run.

Show me the data!

In any event, when we make use of the Internet Archive to look at  pricing changes of the specific instance type as well as the instance type “family” as it evolves, we see the following (all prices are USD cost per hour for Linux on-demand from the us-east-1 region in the earliest available archived month of data for the quoted year):

m1.large m3.large m4.large m5.large Reduction from previous year/generation 3-year reduction
2008 $0.40
2009 $0.40 0%
2010 $0.34  -18%
2011 $0.34 0% -18%
2012 $0.32 -6% -25%
2013 $0.26 -23% -31%
2014 $0.24 $0.23 -13% -46%
2015 $0.175 $0.14 -64% -103%
2016 $0.175 $0.133 $0.120 -17% -80%
2017 $0.175 $0.133 $0.108 -11% -113%
2018* $0.175 $0.133 $0.100 $0.096 -13% -46%

*Latest Internet Archive data from Dec 2017 but confirmed to match current Jan 2018 AWS pricing.

FWIW: The second generation m2.large instance type was skipped, though in October 2012 AWS released the “Second Generation Standard” instances for Extra Large and Double Extra Large – along with about an 18% price reduction for the first generation.

To confirm that we can safely compare these prices, we need to look at how the mX.large family has evolved over the years:

Instance type Specifications
m1.large (originally defined as the “Standard Large” type) 2vCPU w/ECU of 4, 7.5GB RAM
m3.large 2vCPU w/ECU of 6.5, 7.5GB RAM
m4.large 2vCPU w/ECU of 6.5, 8GB RAM
m5.large 2vCPU w/ECU of 10, 8GB RAM

A couple of notes on this:

  • ECU is “Elastic Compute Unit” –  a standardized measure AWS uses to support comparison between CPUs on different instance types. At one point, 1 ECU was defined as the compute-power of a 1GHz CPU circa 2007.
  • I realize that the AWS mX.large family is not equivalent to the GCP n1-standard-8 machine type mentioned earlier, but I was looking for an AWS machine type family with a long history and fairly consistent configuration(and this is not intended to be a GCP vs AWS cost comparison).

The drop in the cost of cloud computing looks kinda dramatic to me…

The net average of the 3-year reduction figures is -58% per year, so Bezos’ Law is looking pretty good. (And there is probably an interesting grad-student dissertation somewhere about  how serverless technologies fit into Bezos’ Law…)  When you factor the m1.large ECU of 4 versus the m5.large ECU of 10 into the picture, more than doubling the net computing power, one could easily argue that Bezos’ Law significantly understates the situation. Overall, there is a trend here of not just a significantly declining prices, but also greatly increased capability (higher ECU and more RAM), and certainly reflecting an increased value to the customer.

So, why has the pricing of the older m1 and m3 generations gone flat but is still so much more expensive? On the one hand, one could imagine that the older generations of underlying hardware consume more rack space and power, and thus cost Amazon more to operate. On the other hand, they have LONG since amortized this hardware cost, so maybe they could drop the prices. The reality is probably somewhere in between, where they are trying to motivate customers to migrate to newer hardware, allowing them to eventually retire the old hardware and reuse the rack space.

Intergenerational Rightsizing

There is definite motivation here to do a lateral inter-generation “rightsizing” move. We most commonly think of rightsizing as moving an over-powered/under-utilized virtual machine from one instance size to another, like m5.large to m5.medium, but intergenerational rightsizing can add up to some serious savings very quickly. For example, an older m3.large instance could be moved to an m5.large instance in about 1 minute or less (I just did it in 55 seconds: Stop instance, Change Instance Type, Start Instance), immediately saving 39%. This can frequently be done without any impact to the underlying OS. I essentially just pulled out my old CPU and RAM chips and dropped in new ones. Note that it is not necessarily this easy for all instance types – some older AMI’s can break the transition to a newer instance type because of network or other drivers, but it is worth a shot, and the AWS Console should let you know if the transition is not supported (of course: as always make a snapshot first!)

Conclusion

For the full view of cloud compute cost trends, we need to look at both the cost of specific instance types, and the continually evolving generations of that instance type. When we do this, we can see that the cost of cloud computing is, in fact, dropping dramatically…at least on AWS.

Read more ›

Why Serverless Computing Will Be Bigger Than Containers

One of the more popular trends in public cloud adoption is the use of serverless computing in AWS, Microsoft Azure, and Google Cloud. All of the major public cloud vendors offer serverless computing options, including databases, functions/scripts, load balancers, and more. When designing new or updated applications, many developers are looking at serverless components as an option. This new craze is coming at a time when the last big thing, containers, is still around and a topic of conversation. So, when users are starting up new projects or streamlining applications, will they stick with traditional virtual machines or go with a new paradigm? And out of all these buzzy trends, will anything come out on top and endure?

Virtual Machines: The Status Quo

The “traditional” approach to deployment of an application is to use a fleet of virtual machines running software on your favorite operating system. This approach is what most deployments have been like for 20 years, which means that there are countless resources available for installation, management, and upkeep. However, that also means you and your team have to spend the time and energy to install, manage, and keep that fleet going. You also have to plan for things like high availability, load balancing, and upgrades, as well as decide if these VMs are going to be on-prem or in the cloud. I don’t see the use of virtual machines declining anytime soon, but there are better options for some use cases.

Containers: The New Hotness, But Too Complex to be Useful

Containerization involves isolating an application by making it think it’s the only application on a server, with only the hardware available that you allow. Containers can divide up a virtual machine in a similar way that virtual machines can divide up a physical server. This idea has been around since the early 1980s, but has really started to pick up steam due to the release of Docker in 2013. The main benefits of containerization are the ability to maximize the utilization of physical hardware while deploying pieces of a microservices architecture that can easily run on any OS.

This sounds great in theory, but there are a couple of downsides to this approach. The primary problem is the additional operational complexity, as you still have to manage the physical hardware and the virtual machines, along with the container orchestration without much of a performance boost. The added complexity without removing any current orchestration means that you now have to think about more, not less, You also need to build in redundancy, train your users and developers, and ensure communication between pieces on top of your existing physical and virtual infrastructure.

Speaking of container orchestration, the other main downside is the multitude of options surrounding containers and their management, as there’s no one clear choice of what to use (and it’s hard to tell if any of the existing ones will just go away one day and leave you with a mess). Kubernetes seems to be the front runner in this area, but Apache Mesos and Docker Swarm are big players as well. Which do you choose, and do you force all users and teams to use the same one? What if the company who manages those applications makes a change that you didn’t plan for? There’s a lot of questions and unknowns, along with just having to make the choice that could have ramifications for years to come.

Serverless Computing: Less Setup, More Functionality

When users or developers are working on a project that involves a database and some python scripts, they just want the database and the scripts, not a server that is running database software and a server that runs scripts. That’s because the main idea behind serverless architecture is the goal of trying to eliminate all the overhead that comes along with these requests for specific software. This is a big benefit to those who just want to get something up and running without installing operating systems, tweaking configuration files, and worrying about redundancy and uptime.

This isn’t all sunshine and rainbows, however. One of the big downsides to serverless comes hand-in-hand with that reduced complexity, in that you also typically have reduced customization. Running an older database version or having a long-running python function might not be possible using serverless services. Another possible downside is that you are typically locked in to a vendor once you start developing your applications around serverless architecture, as the APIs are often going to be vendor-specific.

That being said, it appears that the reduced complexity is a big deal for the users who want things to “just work”. Dealing with less headaches and less management so they can get creative and deploy some cool applications is one of the main goals of folks who are trying to push the boundaries of what’s possible. If Amazon, Microsoft, or Google want to handle database patching and python versioning so you don’t have to, then let them deal with it and move on to the fun stuff!

Here at ParkMyCloud, we’re doing a mix of serverless and traditional virtual machines to maximize the benefits and minimize the overhead for what we do.  By using serverless where it makes sense without forcing a square peg into a round hole, we can run virtual machines to handle the code we’ve already written while using serverless architecture for things like databases, load balancing, and email messages.  We’re starting to see more customers going with this approach as well, who then use ParkMyCloud to keep the costs of virtual machines low when they aren’t in use. (If you’d like to do the same, check out a trial of ParkMyCloud to get your hybrid infrastructure optimized.)

When it comes to development and operations, there are numerous decisions to make that all have pros and cons. Serverless architecture is the latest deployment option available, and it clearly helps reduce complexity and accounts for things that may give you headaches. The reduced mobility is something that containers can handle really well, but involves more complexity in deployment and ongoing management. Software installed on virtual machines is a tried-and-true method, but does mean you are doing a lot of the work yourself. It’s the fact that serverless computing is so simple to implement that makes it more than a trend: this is a paradigm that will endure, where containers won’t.

Read more ›

ParkMyCloud Reviews – Customer Video Testimonials

A few weeks ago at the 2017 AWS re:Invent conference in Las Vegas, we had the opportunity to meet some of our customers at the booth, get their product feedback, and a few shared their ParkMyCloud reviews as video testimonials. As part of our ongoing efforts to save money on cloud costs with a fully automated, simple-to-use SaaS platform, we rely on our customers to give us insight into how ParkMyCloud has helped them. Here’s what they had to say:

TJ McAteer, Prosight Specialty Insurance

“It’s all very well documented. We got it set up within an afternoon with our trial, and then it was very easy to differentiate and show that value – and that’s really the most attractive piece of it.”

As the person responsible for running the cloud engineering infrastructure at ProSight Specialty Insurance, ParkMyCloud had everything TJ was looking for. Not only that, but it was easy to use, well managed, and demonstrated its value right away.

James LaRocque, Decision Resources Group

“What’s nice about it is the ability to track financials of what you’re actually saving, and open it up to different team members to be able to suspend it from the parked schedules and turn it back on when needed.”

As a Senior DevOps engineer at Decision Resources Group, James LaRocque discovered ParkMyCloud at the 2016 AWS re:Invent and has been a customer ever since. He noted that while he could have gone with scripting, ParkMyCloud offered the increased benefits of financial tracking and user capabilities.

“The return on investment is huge.”

Kurt Brochu, Sysco Foods

“We had instant gratification as soon as we enabled it.”

Kurt Brochu, Senior Manager of the Cloud Enablement Team at Sysco Foods, was immediately pleased to see ParkMyCloud saving money on cloud costs as soon as they put it into action. Once he was able to see how much they could save on their monthly cloud bill, the next step was simple.   

“We were able to save over $500 in monthly spend by just using it against one team. We are rolling out to 14 other teams over the course of the next 2 weeks.”

Mark Graff, Dolby Labs

“The main reason why we went for it was that it was easy to give our users the ability to start and stop instances without having to give them access to the console.”

Mike Graff, the Senior Infrastructure Manager at Dolby Labs, became a ParkMyCloud customer thanks to one of his engineers in Europe.

“We just give them credentials, they can hop into ParkMyCloud and go to start and stop instances. You don’t have to have any user permissions in AWS – that was a big win for us.”


We continue to innovate and improve our platform’s cloud cost management capabilities with the addition of SmartParking recommendations, SmartSizing, Alicloud and more. Customer feedback is essential to making sure that not only are we saving our customers time and money, but also gaining valuable insight into what makes ParkMyCloud a great tool.

If you use our platform, we’d love to get a ParkMyCloud review from you and hear about how ParkMyCloud has helped your business – there’s a hoodie in it for you! Please feel free to participate in the comments below or with a direct email to info@parkmycloud.com

 

Read more ›

Why ParkMyCloud is the leader in Automated Cloud Cost Control – It’s About the Platform: 2017 Year in Review

2017 was a big year for ParkMyCloud and automated cloud cost control. From working closely with our customers and understanding industry trends, we continued to strengthen and grow our cloud cost control platform, continuously innovating and adding new features to make ParkMyCloud easier to use, more automated, and continue doing what we do best: saving you money on your cloud costs. Here are the highlights of what improved in ParkMyCloud during 2017:

January

Auto-Scheduling for Microsoft Azure

You asked, we answered. After a year of growth and success with optimizing cloud resources for users of Amazon Web Services (AWS), ParkMyCloud broadened its appeal by optimizing and reducing cloud spend for Microsoft Azure. CEO Jay Chapel weighed in, “Support for Azure was the top requested feature, so today’s launch will help us drive even bigger growth during 2017 as we become a go-to resource for DevOps and IT users on all the major cloud service providers.”

February

Single Sign-On

In February, signing into ParkMyCloud became easier than ever with support for single sign-on using SAML. Signing in is simple – use your preferred identity provider for a more streamlined experience, reduce the numbers needed to remember and type in, and use SSO for security by keeping by keeping a single point of authentication.

April

Free Tier for ParkMyCloud

This release gave users the option for free cloud optimization using ParkMyCloud – forever. The free tier option was created to support developers who were resorting to writing their own scheduling scripts in order to turn off non-production resources when not in use, saving not only money, but lots of time.

Support for OneLogin for Single Sign-On

ParkMyCloud integrated with OneLogin’s App Catalog marketplace, further simplifying Single Sign-On configuration using SAML 2.0. Benefits included reducing the number of passwords needed to track and allowing administrators to control user access from one place.

May

More support for Single Sign-On

In May, ParkMyCloud made more SSO integrations make signing in easy and simple. You can connect with Okta through the Okta App Network (OAN), Centrify, and with Microsoft Active Directory Federation Services (ADFS). The updates rounded out to six major SSO providers that can be used to connect to ParkMyCloud: ADFS, Azure Active Directory, Google G-Suite, Okta, OneLogin, and Ping Identity.  

June

Support for Google Cloud Platform

In addition to AWS and Azure, ParkMyCloud added support for Google Cloud Platform, making automated cost savings available for all of the ‘big three’ cloud service providers. With the new addition, ParkMyCloud’s continuous cost control platform covered a majority of the $23 billion public cloud market, enabling enterprises to eliminate wasted cloud spend – an estimated $6 billion problem for 2017, projected to become a $17 billion problem by 2020.

Stop/Start for AWS RDS Instances

In June, ParkMyCloud announced that it would now be offering “parking” for AWS RDS instances, allowing users to automatically put database resources on on/off schedules, so they only pay for what they’re actually using. This was the first parking feature on the market to be fully integrated with AWS’s RDS start/stop capability.

July

Notifications via Slack and Email

You asked, we answered (again). This user-requested feature improved the user experience by providing notifications about your environment and ParkMyCloud account via email, Slack, and other webooks. Notifications include information about parking actions, system errors, and more. Additionally, ParkMyCloud’s SlackBot allows users to manage resources and schedules through their Slack channel.

August

Cloud Savings Dashboard

After turning two, ParkMyCloud continued shaping and growing its vision with a new reporting dashboard. This feature made it easy to access reports, providing greater insight information regarding cloud costs, team rosters, and more.

November

Mobile App for Cloud Cost Optimization

In the last two months of 2017, ParkMyCloud was not about to slow down. Cloud cost optimization reached a new level with the addition of the new ParkMyCloud mobile app. Users are now able to park idle instances directly from their mobile devices. Reduce cloud waste and cut monthly spend by 65% or more, now with even more capability and ease of use.

AWS Utilization Metric Tracking

From this release, ParkMyCloud partnered with CloudWatch to give AWS users resource utilization data for EC2 instances, viewable through customizable heatmaps. The update gives information about how resources are being used, providing necessary information to help ParkMyCloud gear up for its next release coming soon – SmartParking and SmartSizing.

December

Utilization Heatmaps

Building on the November release of static heat maps displaying AWS EC2 utilization metrics, ParkMyCloud used the utilization data to create animated heat maps. This new feature helps users better identify usage patterns over time and create automated parking schedules. Data is displayed and mapped to a sequence of time, in the form of an animated “video.”  

Coming in 2018…

2017 is over, but there’s no end in sight for ParkMyCloud and automated cloud cost control. In addition to all the features we added last year to make cloud cost automation easy, simple, and more available, we have even more in store for our users in 2018. Coming soon, ParkMyCloud will introduce SmartParking, SmartSizing, PaaS ‘parking’, support for AliCloud and more. Stay tuned for another year of updates, new releases, and saving money on cloud costs with ParkMyCloud.

Read more ›

Cloud Computing 101, the Holidays, DevOps Automation and Moscow Mules – How’s that for a mix!?

I’m back to thinking about Cloud Computing 101, DevOps automation, and the other topics that keep my mind whirring at night – a sure sign that the 2017 holiday season is now officially over. I kicked mine off with an Ugly Sweater Party and wrapped it up with the College BCS games. In between, we had my parents’ 50th wedding anniversary (congrats to them), work-related holiday functions, Christmas with family and friends, New Years Eve with friends, and even chucked in some work and skiing. My liver needs a break but I love those Moscow Mules! Oh, and I have a Fitbit now to tell me how much I sit on my arse all day and peck away at this damn laptop – thanks kids, love you :).

What does this have to do with the cloud, cost control, DevOps and ParkMyCloud? At the different functions and events I went to, people who know me and what we do here at ParkMyCloud asked how business was going. In short, it’s great! In case you didn’t notice, the public cloud is growing, and fast. According to this recent article in Forbes, IaaS is growing 36% year on year – giddy up! Enterprises all over the world use ParkMyCloud to automate cloud cost control as part of their DevOps process. In fact we have customers in 20+ countries now. And people from companies like Sysco Foods rave about the ease of use and cost savings provided by the platform.

Now, when I talked to folks who don’t know what we do or what the cloud is, it’s a whole different discussion. For example, here’s a conversation I had at a party with Lindsey – a fictitious name to protect the innocent (or perhaps it’s USA superstar skier Lindsey Vonn… you will never know.) I like to call this conversation and ones like it “Cloud 101.”

Lindsey: “Hey Jay, how’s it going?”

Jay: “Awesome, great to see you Lindsey. Staying fit I see. How’s the family?” (of course I am holding my Mule in my copper mug – love it!)

Blah blah blah – now to the good stuff.

Lindsey: “So what do you do now?”

Jay: “Do you know what the cloud is?”

Lindsey: “You mean like iTunes?”

Jay: “Sort of. You know all those giant buildings you see when driving around here in Ashburn (VA)? Those buildings are full of servers that run the apps that you use in everyday life. Do you use the Starbucks app?”

Lindsey: “Yes – I’m addicted to Peppermint Mochas.”

Jay: “I am an Iced Venti Skim Chai Tea person myself. So the servers in those data centers are what power the cloud, Starbucks develops apps in the cloud, servers cost money when they’re running, just like the lights in your house. And like the lights in your house, those development servers don’t need to run all the time – only when people are actually using them. So we help companies like Starbucks turn them off when they are not being used. In short, we help companies save money in the cloud.”

Side note to Starbucks — maybe if you used ParkMyCloud to save on your cloud costs with Microsoft and AWS you could stop raising the price of my Iced Venti Skim Chai Tea Latte… just a thought.

It’s thanks to all our customers and partners that I’m able to have this Cloud Computing 101 conversation and include ParkMyCloud in it – with a special thanks to the “Big 3” cloud service providers – AWS, Azure and Google Cloud. Without them, we would not exist as there would not be a cloud to optimize. Kind of like me without my parents, so glad they came together.

Looking ahead to the rest of 2018, we will have lots to write about here at ParkMyCloud — multi-cloud is trending up, automated cloud cost control is trending up, and DevOps will make this all more efficient. And ParkMyCloud will introduce SmartParking, SmartSizing, support for AliCloud and more. It’s all about action and automation baby. Game of Thrones better be back in 2018, too.

Read more ›

ParkMyCloud’s Top 5 Blog Posts of 2017

Before we ring in the new year, ParkMyCloud is taking a look back at 2017. We get a lot of great feedback on our blogs so we decided to summarize our top 5 blog posts, as indicated by our readers (views and shares). In case you missed them, please take a moment and enjoy our most popular posts of 2017!  

Azure vs AWS 2017: Is Azure really surpassing AWS?

Azure vs AWS – what’s the deal? After both cloud providers reported their quarterly earnings at the same time, speculation grew as to whether Azure might have a shot at outpacing Amazon. Provocative headlines teased the idea that Azure is catching up with AWS, making it a great opportunity to compare two out of the ‘big three’ providers. While it may seem like AWS is the one to beat, this blog examines whether Azure is catching up, where they are gaining ground, and why the debate even matters.

AWS vs Google Cloud Pricing – A Comprehensive Look

When it comes to comparing cloud providers, a look at pricing is not only helpful, it’s imperative. AWS and Google Cloud Platform (GCP) use different terminology for their instances, different categories of compute sizing, and take marketing liberties in describing their offerings. To make matters even more confusing, each provider takes a different approach to pricing, charging you by the hour in some cases or by the minute in others, and both having minimums. This blog breaks down all of the jargon and gives you valuable insight into how AWS and GCP are charging you on their monthly cloud bill.

The Cloud Waste Problem That’s Killing Your Business (And What To Do About It)

As enterprises continue shifting to the cloud, service providers like AWS, GCP, Azure, and more offer cloud services as a valuable utility for cost savings. However, as a utility, the cloud has serious potential for waste if not used optimally. What is “cloud waste” and where does it come from? What are the consequences? What can you do to reduce it? This blog answers those burning questions and tells you how to prevent waste and optimize your cloud spend.

Start and Stop RDS Instances – and Schedule with ParkMyCloud

When Amazon announced the release of start and stop RDS instances, AWS users finally had the ability to ‘turn off’ their RDS instances and save money on their cloud bill – nice! However, they would still be charged for provisioned storage, manual snapshots, and automated backup storage. What if there was a solution to starting and stopping RDS instances on an automated schedule, ensuring that they’re not left running when not needed? This blog explains how ParkMyCloud offers automated cost control on a schedule, saving you even more on your monthly cloud bill.

Why We Love the AWS IoT Button

We talk a lot about how ParkMyCloud can save you money on your cloud bill, because we can, but we also love to share the exciting, fun, and innovative offerings that the could brings. The AWS IoT button is a device like no other. You can program it to integrate with any internet-connected device, opening up a whole world of possibilities for what you can do with it. Make a remote control for Netflix, brew coffee in the morning without getting out of bed, or place a takeout order for lunch, all with the push of a button. This blog tells you about how the button was created, how to use it, and some ways that creative developers are using the AWS IoT button.

To another great year…

As we wrap up 2017, the ParkMyCloud team is especially thankful to those of you who have made our blog and our Cloud Cost Control platform successful. We look forward to another great year of keeping up with the cloud, sharing our posts, and of course, saving you money on your cloud bill.

Cheers to 2018! Happy New Year from the ParkMyCloud team and keep an eye open for SmartParking and several great announcements in early January.    

Read more ›

Spot Instance Hibernation – What It Means For You

At AWS re:Invent 2017, one of the announcements that was made is that spot instance hibernation is now available. This change to how AWS spot instances works can mean some tweaks to how you approach this instance type. Let’s explore the ramifications of this and see what it means for you and your infrastructure.

What are Spot Instances?

When you use a cloud provider like AWS, they run data centers so you don’t have to. In doing so, those data centers have similar side effects as traditional on-prem deployments, including spare compute power when utilization is low. AWS decided to let free market forces work to their advantage by offering these spare resources at auction-style prices.

How this worked in practice (prior to this recent hibernation announcement) involved naming your bid price for how much you were willing to pay for an EC2 instance. Once the price of a spot instance went below your bid price, your instance started up and began doing work. Later, when the cost was above your bid price, your instance would be terminated.

Typical Spot Instance Use Cases

As you can tell, spot instances introduce a different way of thinking about your resources.  There are some use cases that don’t make any sense for spot instances, but others that can work well. For instance, high-performance computing scenarios that need a lot of machines for a short period of time can work well with spot instances, as long as the result isn’t extremely urgent. Another possibility is batch processing, like video conversions or scientific analysis, which can typically be done in off-hours without a human present to manually tweak things.

Hibernation vs. Termination

As mentioned above, the loss of a spot instance used to result in termination of the instance, regardless of the data or state of the machine. With Amazon’s recent announcement, you can now have spot instances hibernate instead. This means the system’s memory will be saved to the root EBS volume, then reloaded when the machine is resumed. It’s like time travel, but for your cloud infrastructure!

From a practical perspective, this can change how you approach spot instances. The main benefit is that you don’t have to prepare for sudden termination of your virtual machine, so more workloads could use spot instances with less preparation. The downside to this is that while your workload will eventually finish, you can’t quite be sure of when.

Spot Instances vs. Parking Schedules

The “not being sure when” part is the big differentiator between spot instance hibernation versus on-demand EC2 instances with parking schedules applied via ParkMyCloud. This new hibernation features means lots of benefits and cost savings, but introduces a nebulous time frame that tends to make developers (and executives) nervous. By utilizing known parking schedules that are automatically applied to instances, the cost savings can be quite comparable while maintaining business-hour uptime. The additional flexibility of manual or automated overrides via ParkMyCloud’s UI or API can mean all the difference to your cloud infrastructure team and the application owners who are running these workloads.

AWS claims that you can save up to 90% on your instance costs with spot instances. In the real world, various reports seem to be in the 50%-70% range, based on some stats from large companies like Pinterest and Vimeo. With parking schedules, most development teams turn off systems on nights and weekends, which is around 65% of the time. This means you can get similar savings, but with different timing structures for your use. The best way to save the most is to use a combination, so check out Amazon’s spot instances and try out ParkMyCloud for cost optimization for all workload types!

Read more ›

Amazon’s EC2 Scheduler – How Does it Compare with ParkMyCloud?

Amazon recently announced updates to their EC2 scheduler, responding to the already-answered question: “How do I automatically start and stop my Amazon EC2 instances?”

Been there, done that. ParkMyCloud has been scheduling instances and saving our customers 65% or more on their monthly cloud bills from Amazon, Azure, and Google since 2015. It looks like Amazon is stepping up to the plate with their EC2 scheduler, but are they?

The premise is simple: pay for what you use. It’s what we’ve been saying all along – cloud services are like any other utility (electricity, water, gas) – you should use them only when needed to avoid paying more than necessary. You wouldn’t leave your lights on all night, so why leave your instances running when you’re not using them?

Until now, Amazon had basic scripting suggestions for starting and stopping your instances. With the EC2 scheduler, you’re getting instructions for how to configure a custom start and stop scheduler for your EC2 instances. Implementing the solution will require some work on your part, but will inevitably reduce costs. Welcome to the club, Amazon? Sort of, not really.

EC2 Scheduler vs ParkMyCloud

While the EC2 scheduler sounds good, we think ParkMyCloud is better, and not just because we’re biased. We took a look at the deployment guide for the EC2 scheduler and noticed a few things we offer that Amazon still doesn’t

  • This solution requires knowledge and operation of DynamoDB, Lambda, CloudWatch custom metrics, and Cloudformation templates, including Python scripting and Cloudformation coding.
    • None of that is required with our simple, easy-to-use platform. You don’t need a developer background to use ParkMyCloud, in fact you can use your mobile phone (insert link) or tablet.
  • There’s no UI, so it’s not obvious which instances are on what schedules.
    • ParkMyCloud has a simple UI with an icon driven operational dashboard and reporting so you can easily see and manage not only your AWS resources in a single-pane but your Azure and Google resources as well.
  • Modifications require code changes and CloudFormation deployments, including simple overrides of schedules.
    • Again, ParkMyCloud is easy to use, no coding or custom scripting required. Users can also temporarily override schedules if they need to use an instance on short notice, but will only have access to the resources you grant. And you can use our API and Policy Engine to automate scheduling as part of your DevOps process.
  • No SSO, reporting, notifications
    • Check, check, check. Did we mention that ParkMyCloud added some new features recently? You can now see resource utilization data for EC2 instances, viewable through animated heatmaps.
  • Doesn’t have SmartParking – automated parking recommendations based on usage data.
    • We do.
  • You cannot “snooze” (temporarily override) schedules on parked instances. You would have to do that manually through the AWS interface.
    • You can snooze schedules in ParkMyCloud with a button click.
  • Doesn’t work with Azure or Google.
    • We do.
  • Doesn’t park ASG
    • We do.
  • No Slack integration.
    • We do.

Conclusion

Amazon – nice try.

If you’re looking for an alternative to writing your own scripts (which we’ve known for a long time is not the best answer), you’re purely using AWS and EC2 instances, and are comfortable with all the PaaS offerings mentioned, then you might be okay with the EC2 scheduler. The solution works, although it comes with a lot of the same drawbacks that custom scripting has when compared to ParkMyCloud.

If you’re using more than just EC2 instances or even working with multiple providers, if you’re looking for a solution where you don’t need to be scripting, and if you’d prefer an automated tool that will cut your cloud costs with ease of use, reporting, and parking recommendations, then it’s a no-brainer. Give ParkMyCloud a try.

Read more ›

New in ParkMyCloud: Visualize AWS Usage Data Trends

We are excited to share the latest release in ParkMyCloud: animated heat map displays. This builds on our previous release of static heat maps displaying AWS EC2 instance utilization metrics from CloudWatch. Now, this utilization data is animated to help you better identify usage patterns over time and create automated parking schedules.

The heatmaps will display data from a sequence of weeks, in the form of an animated “video”, letting you see patterns of usage over a period of time. You can take advantage of this feature to better plan ParkMyCloud parking schedules based on your actual instance utilization.

Here is an example of an animated heatmap, which allows you to visualize when instances are used over a period of eight weeks:

The latest ParkMyCloud update also includes:

  • CloudWatch data collection improvements to reduce the number of API calls required to pull instance utilization metrics data
  • Various user interface improvements to a number of screens in the ParkMyCloud console.

As noted in our last release, utilization data also provides the necessary information that will allow ParkMyCloud to make optimal parking and rightsizing recommendations (SmartParking) when this feature is released next month, part of our ongoing efforts to do what we do best – save you money, automatically.

AWS users who sign up now can take advantage of the latest release as we ramp up for automated SmartParking. In order to give you the most optimal cost control over your cloud bill, start your ParkMyCloud trial today to collect several weeks’ worth of CloudWatch data, track your usage patterns, and get recommendations as soon as the SmartParking feature becomes available in a few weeks.

If you are an existing customer, be sure to update your AWS policies to enable ParkMyCloud to access your AWS CloudWatch data. Detailed instructions can be found in our support portal.

Feedback? Anything else you’d like to see ParkMyCloud do? Let us know

Read more ›

Three Big AWS re:Invent Announcements from 2017

AWS re:Invent announcements were in full swing at the conference last week. In addition to all the sessions, workshops, pub crawl, DJ-spinning and all sorts of educational experiences and entertainment options, the technology announcements are really what drive the buzzl. While it’s impossible to cover them all, we picked three big announcements from this year’s AWS re:Invent that will certainly be game-changers:  

New EC2 Instance Types

M5 EC2 instances are the next generation of general purpose EC2 instances. As a general purpose instance, its good for the use of running web & app servers, hosting enterprise applications, supporting online games and building cache fleets.

What sets M5 instances apart is that they were made for high-demand workloads, provide a 14% better price performance than M4 instances per core, and designed based on Custom Intel® Xeon® Platinum 8175M series processors running at 2.5 GHz. The new instances comes with a full package of resources allocations, complete with optimized compute, memory, and storage.

H1 EC2 Instances are the latest in storage optimized instances, designed with lots of space for high performance big data workloads. These instances are powered by “Broadwell” – 2.3 GHz Intel®Xeon® E5 2686 v4 processors, offering more memory compared to D2 instances. H1 instances provide low cost storage, high disk throughput, and high sequential disk I/O access to large data sets. They’re designed for data scientists running big data applications like Elastic MapReduce, big workload clusters, data processing applications like Apache Kafka, distributed filing systems, and networking filing systems.

Public Preview of EC2 Bare Metal Instances

AWS customers now have the ability to run workloads on bare metal servers. Peter DeSantis, VP of Global Infrastructure at AWS, calls it the “best of both worlds” because customers can run an operating system directly on the hardware, yet still reap the benefits of using the cloud by paying as they go instead of up-front. The public preview of bare metal instances are ideal in scenarios where workloads needs access to certain hardware features, and workloads with restrictions due to licensing can still benefit from the AWS cloud offerings. The public preview of the i3.metal instance is only the first of an entire series dedicated to bare metal instances, with more in line to roll out over the next few months.

Spot Instance Hibernation

Among several changes announced to AWS spot instances was a notable new feature – hibernation for spot instances. Instead of terminating a spot instance when it is interrupted, it will now hibernate instead, saving all of your data into an EBS volume. The instance will reboot as soon as spare capacity is available for the given instance type. Hibernation is useful because you won’t be charged for using the instance while it’s in hibernation, storage is charged at standard EBS storage rates, and you can still terminate your instances in hibernation by cancelling your bid at any time.

Conclusion

AWS re:Invent announcements are always exciting. As the largest and most successful public cloud provider to date, Amazon keeps us on our toes and continues giving us so much to look forward to. In the ongoing war between the big three cloud providers, these innovations will certainly drive the competition to innovate and provide even better options for enterprises to choose from. As always, we’ll continue to cover new announcements, product launches, and more as AWS continues to innovate and increase their offerings at a frenetic pace.

Read more ›

3 Things We Learned at AWS re:Invent 2017 (An Insider’s Look from Jay)

The ParkMyCloud team has returned energized and excited from our annual trek to Las Vegas and our third AWS re:Invent conference. It’s an eclectic group of roughly 42K people, but we gleaned a ton of information by asking questions and listening to the enterprise cloud do’ers at our booth. These are the people actually moving, deploying and managing cloud services at the enterprises we consume goods and services from. They are also often the one’s that start the ‘cloud first’ initiatives we hear so much about — after all, they led the public cloud revolution to AWS 10+ years ago.

I’m not going to write about all the announcements AWS made at re:Invent2017 related to all the cool kid, popular buzz words like Artificial Intelligence, Machine Learning, Blockchain, Quantum Computing, Serverless Architecture, etc. However, if you do want to read about those please check out this nice recap from Ron Miller of TechCrunch.

Containers are so passé, they did not even make the cool kid list in 2017… but Microservices Architecture did. Huh, wonder if that’s a new phrase for containers?

For ParkMyCloud it’s a great event. We love talking to everyone there – they’re all cloud focused, they are either using AWS exclusively (born in the cloud), or AWS plus another public cloud, or AWS plus private cloud, and in some cases even AWS plus another public cloud and private cloud, thus they are truly ‘multi-hybrid cloud’. We had a ton of great conversations with cloud users who are either prospects, customers, technology partners, MSPs or swag hunters who want learn how to automate their cloud cost control – our nirvana.

There were a ton of Sessions, Workshops and Chalk Talks, and long lines to get into the good ones. It’s up to you to define the good ones and reserve your spot ahead of time.

Of course, it’s not all work and no play. This year for re:Play we had DJ Snake – giddy up! And while you walked your miles through the various casinos there were DJ’s scattered about spinning tunes for you – I describe re:Invent to my friends as an IT event where “millennials meet technology” — definitely not your father’s tech trade show. Having been to many of these IT tech trade shows around the world for 20+ years now, and outside of the Mobile World Congress in Barcelona, re:Invent is hands down the coolest.

Not only because of the DJ’s and re:Play but because there is a real buzz there, people are part of the new world of IT, and the migration of enterprise services to the world’s #1 cloud provider. And of course the Pub Crawl and Tatonka chicken wing eating contest.

AWS is now so big that the Venetian/Palazzo can’t hold everyone anymore, so they have spread over to the MGM, Mirage, and Aria. AWS refers to this collection of locations as it’s ‘campus’ – interesting, the rest of us refer to it simply as Las Vegas :-).

BTW – bring your sneakers. It’s 1.5 miles or a 22 minute power walk, including a few bridges, from the MGM to the Venetian assuming no stops for a cold beverage. Speaking of which, the Starbucks line is crazy.

Oh, and the swag, holy mother of pearl, people literally walk by the booth with large tote bags stuffed full of swag – if you like swag, hit up the expo hall for your fill of tee shirts, hoodies, koozies, spinners, bottle openers, pens, flash lights, memory sticks, chargers, stickers, hats, socks, glasses, mints, Toblerone chocolate, and lots more!

Well, I probably need to tie this blog / rant back to the headline, so in that vein, here are the top three things we learned at this year’s AWS re:Invent:

  1. Cost control in 2018 will be about aggregating metrics and taking automated actions based on Machine Learning
  2. AWS talks a lot about advanced cloud services and PaaS, but a majority of the customers we talk to still use and spend most of their dollars on EC2, RDS and S3
  3. DevOps / CloudOps folks are in charge of implementing cost control actions and pick the tools they want to use to optimize cloud spend

See you next year – pre-book your Uber/Lyft or bring a scooter!

Read more ›

Cloud Service Provider Comparison – Part Two: IBM vs Oracle

For the second part of our cloud service provider comparison, we’ll continue our discussion of “secondary” cloud providers with two longtime tech industry giants: IBM vs Oracle.

We always talk about the “big three” cloud providers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP). We’ve covered Azure vs AWS, Google vs AWS, and most recently, the rise of Alibaba as the next biggest cloud provider. But what about the rest? IBM and Oracle have solidified themselves in the technology world, but will their offerings bring them success in the public cloud? And if so, does one of them have a better chance?

IBM

  • At the end of June 2017, IBM made waves when it outperformed Amazon in total cloud computing revenue at $15.1 billion to $14.5 billion over a year-long period
  • However, Amazon is still way ahead when it comes to the IaaS market
    • For 2016, Amazon had the highest IaaS revenue, followed by Microsoft, Alibaba, and Google, respectively. IBM did not make the top 5.
    • Alibaba had the highest IaaS growth rate, followed by Google, Microsoft, and Amazon, respectively.
  • IBM was the fourth biggest cloud provider – before Alibaba took over
  • In Q1 of 2017, Synergy rankings showed that IBM has 4 percent of the public cloud market share, just behind Alibaba’s 5 percent
    • AWS had 44 percent, Azure – 11 percent, and Google Cloud – 6 percent

The reality that Alibaba knocked IBM out of fourth place in the ongoing saga of the cloud wars is a bit unsettling, but remember that the enterprise cloud is still just beginning. After all, the term “cloud computing” was only coined just a few years ago, in 2006. As we look forward, IBM and Amazon just released their own television ad campaigns, and the differences in their messaging are an indication of how each provider plans to move forward.

As enterprises continue their shift to the cloud, TV ads tell us a lot about a provider’s purpose, overall message, and target audience. In the IBM ad, “The Cloud for Enterprise, Yours,” the cloud is presented not as a cloud at all, but as an entity “built for your business, designed for your data, and secure to the core.” This messaging opens an otherwise confusing, sometimes difficult to understand service for business leaders, to something tangible, something that makes sense, something that was built for their enterprise. That type of message goes a long way with people who don’t know the first thing about cloud computing.

On the other hand, Amazon’s ad targets a different audience entirely: “the builders” – developers, programmers, and architects who already have a full understanding and reliance on AWS for their building needs. In contrast to IBM, whose ad is all about how their cloud is helping businesses through the power of data and innovation, blockchain, and more, Amazon went straight for the technical experts who know exactly what they’re doing, no explanation necessary. The ad was also perfectly timed for the arrival of AWS re:Invent in Las Vegas this past week (ParkMyCloud was there as a sponsor!), gearing up their technical followers for the big event.

IBM positioned itself as a cloud provider for business leaders as the shift to the cloud only gets bigger. Amazon positioned itself as a haven for technical experts, the people writing code and continuously managing applications and other processes. It will take some time before we see the results of how this messaging plays out, but it certainly says something about who each provider wants to impress. And while pretty much everyone agrees that Amazon is currently leading the cloud, the numbers don’t lie – let’s not forget that IBM outperformed them in overall cloud revenue.

Oracle

  • Oracle’s cloud business is still ramping up, particularly in terms of IaaS
  • In fiscal Q1 of 2018, growth was at 51 percent, down from a 60 percent average in the last four quarters
    • Q4 for fiscal 2017 was at 58 percent
  • Since last quarter, shares have gone down by 10 percent

If things weren’t looking good for Oracle before, they may have just taken a turn for the worst. This past week AWS re:Invent, we witnessed CEO Andy Jassy make quite a dig at Oracle during his keynote speech. There was a cartoon involved, featuring Oracle founder Larry Ellison, and the message was clear: AWS is taking business away from Oracle.

Oracle’s success largely comes from its database business, which is still their biggest revenue producer as many companies use their databases to run critical parts of their operations. AWS decided to take them head on with a database on their own, directly targeting their enterprise customers. After AWS launched Aurora, in competition with Oracle’s SQL database, they efficiently started peeling away longtime Oracle customers. Oracle’s response? Build their own cloud, competing directly with the biggest and most successful cloud provider thus far, AWS.

But in spite of their current position, we can’t rule out Oracle just yet. For customers who still rely on Oracle’s database or other software, the cloud is a welcome offering and probably an easier option. And in an attempt to make things harder for AWS, Oracle made some changes to its licensing, and doubled the cost of using its database on AWS in hopes that customers who already use Oracle’s database will find their cloud a cheaper, more appealing option. However, this also backfired to some degree as customers using AWS cloud in conjunction with Oracle’s database did not appreciate the spike in price. Ultimately, the decision could prove itself to be more beneficial to AWS customers, prompting them to switch their database instead of their cloud provider.

And this brings us back to re:Invent, where Andy Jassy announced a new, serverless database service – Aurora Serverless. Again, this new offering is in direct competition with Oracle’s database, and once it goes live, only time will tell if Oracle can take the heat.

IBM vs Oracle: The Takeaway

IBM vs Oracle – does either of them stand a chance against the bigger, more well known cloud providers? So far, it’s looking pretty good for IBM. They have their sights set on huge success with the introduction of Watson, the AI supercomputer that generated a lot of buzz when it won Jeopardy. They’ve also taken a new approach with their TV ad campaign, setting themselves apart from Amazon with an entirely different audience, wooing business leaders as the best choice in terms of business and innovation strategy. And of course, they’ve taken the lead in cloud computing revenue, which is nothing to scoff at.

On the other hand, Oracle is struggling to find its place, and Amazon is calling them out. With the announcement of Aurora Serverless, we’ll be looking to see how this new offering impacts Oracle as it takes a direct hit to it’s flagship product – their database business. If Oracle wants to keep up and hold it’s own against other cloud providers, they might be wise to take a note from IBM and innovate with a new approach entirely.

In the ongoing battle for the ultimate cloud provider, Amazon’s lead is certainly not a guarantee. Not only are Google and Azure coming in strong, but Alibaba is well on its way, and other secondary providers like IBM and Oracle are working on innovations and improvements to secure their place in the ranks.

In the end, we always find it helpful to come back to one of our favorite Andy Jassy quotes regarding the cloud battle:

“There won’t be just one successful player. There won’t be 30 because scale really matters here in regards to cost structure, as well as the breadth of services, but there are going to be multiple successful players, and who those are I think is still to be written.”

As we continue making comparisons between cloud providers, keeping up to date with ongoing advancements and innovations behind their offerings, we welcome you to participate! Please share any thoughts or feedback in the comment section, we’d love to hear your take!

Read more ›
Page 1 of 3123
Copyright © ParkMyCloud 2016-2018. All rights reserved|Privacy Policy