As public cloud computing has grown over the past decade, the concept of cloud management has developed in order to maintain control of resource allocation, governance, security, and – most important of all – cost.

Due to the complexity of optimizing cloud compute resources, many organizations have implemented cloud management software. However, in the same way that no two organizations are the same, no two cloud management solutions are identical.

All cloud service providers offer tools to help manage their cloud environments. Some are excellent at helping organizations optimize their resources. Others are more practical for organizations that wish to create permission tiers and allow team members different levels of access to their projects.

However, many solutions overcomplicate cloud management by providing functions that most organizations find unnecessary. These additional functions are factored into the cost of the solution, eating into the financial benefits of the cloud management software.

ParkMyCloud is an ideal solution for organizations that want an effective tool suitable for minimizing cloud management costs. By “parking” non-productive instances and VMs when they are not required, organizations can save up to 60% on AWS, Microsoft and Google cloud computing costs.

By providing a single dashboard view of instances and VMs across multiple accounts, types and zones, ParkMyCloud also enables administrators to make informed decisions about resource allocation and governance – simplifying cloud management and reducing costs further.

To find out more about our versatile cloud management software, contact us today.

Don’t Waste Money on Unused Reserved Instances

Among the various ways to lose money on idle or orphaned resources in the cloud, here’s another for AWS users to add to the list: unused reserved Instances. At first, the idea of wasting money on AWS Reserved Instances seems counterintuitive. After all, aren’t RIs meant to save money? The short answer is yes – but only if you use them efficiently.

How Unused Reserved Instances Occur

To understand how unused Reserved Instances contribute to cloud waste, consider how they work. With AWS Reserved Instances, you’re making a commitment of usage by renting instances for a fixed amount of time in exchange for a lower rate (per-hour or per-second) than on-demand. You’re still free to use all the same families, OS types, and instance sizes with either one, except with RIs your ability to use certain instance types is limited to the purchasing plan you choose.

The only real difference between an AWS On-Demand instance and an AWS Reserved Instance is how you get billed for them on the backend – and this is where it gets tricky. You don’t know if your Reserved Instances have been used until you get the bill. Instead, you run your instances as you always would, with no insight into what will get billed as reserved instances. It’s only when your bill is created the following month that AWS reviews your reservations alongside your usage to apply the Reserved Instances that match up with your workload. This leaves you with little visibility into what your costs will be, forcing you to track usage on your own, and running the risk of unused reservations that result in, you guessed it – wasted money.

Ways to Avoid Losing Money Unused Reserved Instances

Reserved Instances require commitment of usage, ongoing awareness and insight into your future costs, and the possibility of going unused if AWS can’t apply them sufficiently. But that doesn’t mean you should shy away from using them. Reserved Instances can be cost-effective if used with a few things in mind:

Pick the RI type that suits your usage and workload. The best plan is one of prevention. Before you get started with purchasing reservations, get a detailed look at your usage and the most optimal instance types for your workload (something you should already be doing as part of your cost control measures). By design, Reserved Instances work best with steady state workloads and consistent usage. Once you confirm that your usage makes you a good candidate, you’ll want to choose the RI instance type that will benefit your needs most:

  • Standard RIs – Recommended for steady-state usage, and provide the most savings.
  • Convertible RIs – a smaller discount from On-Demand instances, but in return provide flexibility to change families, OS types, and tenancies.
  • Scheduled RIs – similar to Standard RIs, but only apply to instances launched within the time windows you select, which can recur on a daily, weekly, or monthly schedule.

Sell unused reserved instances on the Reserved Instance Marketplace. Using the marketplace allows you to list your reservation for purchase by other users. The cheapest reservations are sold first, and once someone purchases yours, you’ll be the charged the on-demand rate whenever you use that instance type moving forward.  

Purchase convertible reservations. With convertible reservations, you have the option to convert your reserved instances to other types, so long as the new type is more expensive. You won’t get as much of a discount, but flexibility and more options for use make up for the smaller savings.

The Lesson to be Learned

Just like any other idle or unused cloud resource, unused reserved instances can only do one thing – waste your money. Cloud services were meant to help you keep infrastructure costs in check, but only if you use them smartly. Optimize your cloud spend with awareness of your usage, ongoing insight into your infrastructure needs, and running instances only when you need them.

More questions answered in our recent blog, AWS Reserved Instance FAQs.

Read more ›

The #1 ParkMyCloud Alternative

Sometimes we ask potential customers what their top ParkMyCloud alternative is. Usually, they don’t have one, but sometimes, they’re considering scripting their own on/off solution instead.

It makes sense: at a glance at the problem of scheduling cloud resources, it’s easy to say, “my team can write a scheduler.” However, there are more factors than you may have considered – including cost optimization over a variety of resources, maintenance time, visibility and reporting, opportunity cost, and more.

11 Things to Include in Your Scripts – Besides Scheduling

While you may be able to write scripts to turn resources on and off on a schedule, there are a number of associated functionalities that would be more difficult and time consuming:

  1. Multi-account/user – scripting typically doesn’t support multi-cloud/multi-user/multi-account access, and it is difficult to support existing team structures and ensure appropriate controls
  2. Schedule override – difficult to let users override schedules when they need to access them while scheduled
  3. Custom usage-based schedules – must determine a way to create custom schedules per resource based on usage analytics
  4. Logical Groups – hard to find a way to let users group resources and start/stop sequentially
  5. Scale group parking – must develop means to create a single view and the ability to manage and start/stop scale groups
  6. On-demand access – must develop a process to enable on-demand access to stopped instances in off hours
  7. Visibility – need to develop custom application to determine cost savings based upon application of automation or removal of schedules (to date we have not encountered anyone who has developed such an application)
  8. Reporting – not only do cost savings need to be tracked, they need to be reportable via ad hoc utilization, savings, and scheduling reports over arbitrary date ranges
  9. Policies – difficult to build custom policies regarding the scheduling of instances like “Never Park” or “Snooze Only”
  10. Standardization – difficult to ensure consistency and standardization of automation approach across entire organization unless highly centralized
  11. Easy-to-use UI for non-developers – no easy way to create a UI that allows you to devolve management of cloud resources to non-technical teams who may not be familiar with the cloud provider console

ParkMyCloud provides you the ability to do all of the above – with no scripting necessary. See a full comparison here.

The Cost of Scripting

If you’re interested in automating on/off times for your cloud resources, then you’re probably interested in optimizing costs. So don’t lose sight of the cost behind “building” – the man-hours and opportunity cost. After all, every time you have your team working on creating solutions for side projects, you distract them from your core business activities.

And it will take more time than you think. In addition to the functionality listed above, consider the following maintenance tasks:

  • Must keep up-to-date on changes to public cloud APIs
  • Must keep up-to-date on change/updates to public cloud services
  • When your business’s desired policies, schedules, or behavior change, must update and test

Is Scripting a Viable ParkMyCloud Alternative?

Of course, it’s up to you to determine whether scripting is a worthwhile ParkMyCloud alternative for your business. We’d say, it’s not worth the cost and sacrifice of value. Besides, ParkMyCloud users save an average of $12 on their cloud bills per dollar spent on the product – that’s an ROI that will keep your finance team happy. And that’s just the paid versions. If it’s still hard for you to justify, then use ParkMyCloud’s free tier – with no cost, there’s no reason to waste your time scripting.

Ready to try the easy way? Get started.

Read more ›

How Cloud Trends are Changing (& Happy Birthday, ParkMyCloud!)

ParkMyCloud just turned 3 years old, and from here, the future looks great. The market is growing, cloud is the norm, and cost control is always top of mind for companies big and small. In fact, over 600 enterprises in 25+ countries now use our platform to “park idle cloud resources (including instances, databases and scale groups) in AWS, Azure, GCP and now Alibaba.

As we look to the future, we’re taking a moment to consider current cloud trends and how cost control needs are changing. To provide context, let’s take a quick look at where the market was three years ago.

The Problem that Got Us Started

When we founded the company three years ago, we set out to build a self-service, SaaS platform which would allow DevOps users to automate cloud cost control and integrate it into their cloud operations. We saw a need for this platform as we were talking to enterprises using AWS about broader cloud management needs as a service play. They wanted a self-service, purpose-built easy button for instance scheduling that could be centrally managed and governed but left up to the end user to control – enter ParkMyCloud.

Our value proposition started simply and has stayed relatively constant: save 20% on your cloud bill in 15 minutes or less (it’s 65% per parked resource). The ease of use, verifiable ROI, and richness of our platform capabilities allow global companies like McDonald’s, Unilever, Sysco, Sage and many others to adopt ParkMyCloud on their own, with no services, and begin to automate their cloud cost control in minutes – not days or weeks.

I went back and looked at our pre-launch pitch decks. At that time, the cloud Infrastructure-as-a-Service (IaaS) market was $10B or so, and dominated by AWS, and others like Rackspace and HP were in the game with the other usual suspects. Today, Gartner estimates enterprises will spend $41B on IaaS in 2018, and it’s still dominated by AWS, but the number of players is really down to 4 or 6 depending on where you want to put IBM and Oracle.

But the cloud waste problem is still prominent and growing, most analysts and industry pundits estimate that 25% or more of your bill is wasted on unused, idle or over provisioned resources – that equates to $10B+ based on 2018 IaaS predictions being wasted – that’s a BIG nut. In fact, if you break that down that’s $1MM in wasted cloud spend every hour. And it’s important. Most enterprises rank cloud security/governance and cost management as their primary concerns with cloud adoption.

Cloud Trends Driving the Market

So how are things changing? We see three key trends that will drive our company and platform vision over the next 3 years:

  1. Multi-cloud – it’s been long discussed, but it’s now a reality: 20% of the enterprises using PMC manage 2 or more CSPs in the platform, and that number is growing. As always, cost control is an important factor in a multi-cloud strategy.  
  2. PaaS – Platform as a Service (PaaS) use is growing, so users are looking to optimize these resources. ParkMyCloud offers optimization for databases, scale groups, and logical groups. We plan to expand into containers and stacks to meet this need.
  3. Data-driven automation (AIOps) – our customers, large and small, are pushing us to expand our data-driven policies and automation – everyone is becoming more comfortable with the idea of automation. Our first priority on this front is to optimize overprovisioned resources – often referred to as RightSizing … RightSizeMyCloud!

 

Cloud trends are not always easy to predict, but one thing is for certain: costs will need to be controlled. Good fun ahead.

Read more ›

6 Types of Overprovisioned Resources Wasting Money on Your Cloud Bill

In our ongoing discussion on cloud waste, we recently talked about orphaned resources eating away at your cloud budget, but there’s another type of resource that’s costing you money needlessly and this one is hidden in plain sight – overprovisioned resources. When you looked at your initial budget and made your selection of cloud services, you probably had some idea of what resources you needed and in what sizes. Now that you’re well into your usage, have you taken the time to look at those metrics and analyze whether or not you’ve overprovisioned?

One of the easiest ways to waste money is by paying for more than you need and not realizing it. Here are 6 types of overprovisioned resources that contribute to cloud waste.  

Unattached/Underutilized Volumes

As a rule of thumb, it’s a good idea to delete volumes that are not attached to instances or VMs. Take the example of AWS EBS volumes unattached to EC2 instances – if you’re not using them, then all they’re doing is needlessly accruing charges on your monthly bill. And even if your volume is attached to an instance, it’s billed separately, so you should also make a practice of deleting volumes you no longer need (after you backup the data, of course).

Underutilized database warehouses

Data warehouses like Amazon Redshift, Google Cloud Datastore, and Microsoft Azure SQL Data Warehouse  were designed as a simple and cost-effective way to analyze data using standard SQL and your existing Business Intelligence (BI) tools. But to get the most cost savings benefits, you’ll want to identify any clusters that appear to be underutilized and rightsize them to lower costs on your monthly bill.

Underutilized relational databases

Relational databases such as Amazon RDS, Azure SQL, and Google Cloud SQL offer the ability to directly run and manage a relational database without managing the infrastructure that the database is running on or having to worry about patching of the database software itself.

As a best practice, Amazon recommends that you check the configuration of your RDS for any idle DB instances. You should consider a DB instance idle if it has not had a connection for a prolonged period of time, and proceed by deleting the instance to avoid unnecessary charges. If you need to keep storage for data on the instance, there are other cost-effective alternatives to deleting altogether, like taking snapshots. But remember – manual snapshots are retained, taking up storage and costing you money until you delete them.

Underutilized Instances/VMs

We often preach about idle instances and how they waste money, but sizing your instances incorrectly is just as detrimental to your monthly bill. It’s easy to overspend on large instances or VMs that are you don’t need. With any cloud service, whether it’s AWS, Azure, or GCP, you should always “rightsize” your instances and VMs by picking the instance size that is optimized for the size of your workload – be it compute optimized, memory optimized, GPU optimized, or storage optimized.

Once your instance has been running for some time, you’ll have a better idea of whether not the chosen size is optimal. Review your usage and make cost estimates with AWS Management Console, Amazon CloudWatch, and AWS Trusted Advisor if you’re using AWS. Azure users can review their metrics from Azure Monitor data, and Google users can import GCP metrics data for GCP virtual machines. Use this information to find under-utilized resources that can be resized to better optimize costs

Inefficient Containerization

Application containerization allows multiple applications to be distributed across a single host operating system without requiring their own VM, which can lead to significant cost savings. It’s possible that developers will launch multiple containers and fail to terminate them when they are no longer required, wasting money. Due to the number of containers being launched compared to VMs, it will not take long for container-related cloud waste to match that of VM-related cloud waste.

The problem with controlling cloud spend using cloud management software is that many solutions fail to identify unused containers because the solutions are host-centric rather than role-centric.  

Idle hosted caching tools (Redis)

Hosted caching tools like Amazon ElastiCache offer high performance, scalable, and cost-effective caching. ElastiCache also supports Redis, an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker. While caching tools are highly useful and can save money, it’s important to identify idle cluster nodes and delete them from your account to avoid accruing charges on your monthly bill. Be cognizant of average CPU utilization and get into the practice of deleting the node if your average utilization is under designated minimum criteria that you set.

How to Combat Overprovisioned Resources (and lower your cloud costs)

Now that you have a good idea of ways you could be overprovisioning your cloud resources and needlessly running up your cloud bill – what can you do about it? The end-all-be-all answer is “be vigilant.” The only way to be sure that your resources are cost-optimal is with constant monitoring of your resources and usage metrics. Luckily, optimization tools can help you identify and automate some of these best practices and do a lot of the work for you, saving time and money.

Read more ›

Is Cloud to Cloud Migration Worth the Effort?

When we talk about cloud migration challenges, the conversation is about a company switching their workloads from an on-premise datacenter to a public cloud environment. But what about cloud to cloud migration?

The Benefits of Cloud to Cloud Migration

Why would a company go through the trouble of moving its entire infrastructure to the cloud, investing in one cloud service provider only to switch to another?

The cloud shift is no longer anything new. Companies have accepted cloud adoption and are becoming more comfortable with using cloud services. Now with AWS, Azure, and Google Cloud Platform currently leading the market (plus others growing rapidly), and constantly offering new and better options in terms of pricing and services, switching providers could prove to be fruitful.

Choosing a cloud provider to begin with is a monumental task. Businesses have to make choices regarding a number of factors – cost, reliability, security, and more. But even with all factors considered, business environments are always changing. Cost can become more or less important, your geographical region might evolve (which affects cost and availability of services), and priorities can shift to the point where another platform might be a better fit.  

Perhaps your migration to AWS a few years ago was driven mainly by reliability and risk mitigation. While other providers were up and coming, you wanted to go with the gold standard. A few years later, productivity tools like Google’s G Suite became useful to your business. You now have business partners using other platforms like Azure or Google Cloud. You realize that your needs for software have changed, business partnerships have influence, and it becomes clear that another provider could be of greater benefit. Not to mention, cloud services themselves are ever-changing, and you might find better pricing, service-level agreements, scalability, and improved performance with another provider as offerings change over time.

While all of this makes sense, theoretically speaking, let’s take a look at a real example:

The Case of GitLab

A number of users were up in arms over Microsoft’s acquisition of Github, so much so that hundreds of thousands have already moved to another Git-repository manager – GitLab. And in a twist of fate, GitLab has made the announcement that they’ve decided to swap Microsoft Azure for another cloud provider – Google Cloud Platform.

Ask Andrew Newdigate, the Google Cloud Platform Migration Project Lead at GitLab, about why they’re making the move to GCP and he’ll likely mention service performance, reliability, and something along the lines of Kubernetes is the future.

Kubernetes, the open source project first released by Google and designed for application management of multiple software containers “makes reliability at massive scale possible.” What’s also appealing is that GitLab gets to use Google Kubernetes Engine, a service designed to simplify operating a Kubernetes cluster, as part of their cloud migration. The use of GKE has been cited as another driving factor for GitLab, looking to focus on “bumping up the stability of scalability of GitLab.com, by moving our worker fleet across to Kubernetes using GKE.”

Sid Sijbrandij, CEO of GitLab, adds better pricing and superior performance as reasons behind the migration. In an interview with VentureBeat, he said:

“Google as a public cloud, they have more experience than the other public cloud providers because they basically made a cloud for themselves […] And you find that in things such as networking, where their network quality is ahead of everyone else. It’s more reliable, it has less jitter, and it’s just really, really impressive how they do that, and we’re happy to start hosting Gitlab.com on that.”

The Challenges of Cloud to Cloud Migration

There’s a long list of factors that influence a company’s decision in selecting a cloud provider, and they don’t stop once you start building infrastructure in a particular cloud. Over time, other providers may prove to be better for the needs of your business. But just as there are challenges with cloud adoption in the first place, similar challenges apply when making the switch from cloud to cloud:

  • Data transfer. Transferring data between different cloud service providers is a complex task, to say the least. Like data transfer from enterprise to cloud, information is transferred over the internet, but between cloud providers instead from server to cloud. This presents the issue of speed at which data downloads, and as a rule of thumb you should avoid transferring large chunks of data at a time. There can even be massive transfer costs of moving the data out of or into a cloud.

 

  • Potential downtime. Downtime is also a risk. It’s important to account for inconsistencies in data, examine network connections, and prepare for the real possibility of applications going down during the migration process.

 

  • Adapting to technologies for the new cloud. You built an application for Azure, but now you’re going Google – it’s not as simple is picking it up from one platform and expecting it to run on another (and with the same benefits). Anticipate a heavy amount of time spent reconfiguring the application code to get the most out of your new platform.

 

  • Keeping costs in check. Consider the time and costs to migrate to the cloud, which tend to be misunderstood or drastically understated. Again, the same applies for cloud to cloud migration. By now, you have a better understanding of cloud service offerings, pricing models, and the complexity of a cloud adoption budget – for the service you were using. Once again, you’ll have to evaluate all of these costs and look into options that will help you save post-migration, like optimization tools.

Cloud to Cloud Migration – Is it worth it?

Before shifting to the cloud, you probably asked yourself the same thing. And just like before, you’ll have to dive deeply into factors like costs, technologies, and risk versus reward to assess whether or not a cloud to cloud migration is the right move for your business.

At first glance, a cloud to cloud migration is just as complicated and time-consuming as moving to the cloud in the first place, and it might seem like it’s just not worth the effort. But why did you move to the cloud? If you did to save costs over time, create better business opportunities, improve reliability and performance – then why would you NOT go with another provider that will benefit your business more in those areas? Not to mention, the more time you spend with one provider, building more applications as you go, the harder it will be to make the switch.    

So cloud to cloud migration – is it worth it? Yes – but only if you’ve considered all the factors to determine whether or not another cloud is better for your business.

 

Read more ›

AWS Reserved Instances FAQ

This AWS Reserved Instances FAQ is a culmination of questions we are often asked about using Reserved Instances to save on your Amazon Web Services (AWS) costs.

First, let’s make sure you’re all on the same page. AWS Reserved Instances are a way to save money on your cloud bill by reserving capacity in advance, which you can choose to pay for all, some, or no upfront. Due to the different billing model and variety of options, these often raise questions.  Let’s explore a few:

Q1: How do I know which instances are reserved?

Because of how AWS billing works, Reserved Instances aren’t applied until you’re actually being charged for the instances. Think of it more like a “voucher” than a specific virtual machine.

This means that you run your instances as you normally would throughout the month, without seeing which will be billed as reserved vs. on-demand. When your bill comes on the 5th of the next month, AWS will look at your reservations and your usage and automatically apply the reservations that match the instances.

This means that you don’t have to decide which instances are reserved, but it also means you don’t have the visibility into what your true costs are going to be. You’ll have to track this on your own, or use some tools to help you manage your Reserved Instances. AWS has included some reports in the Cost Explorer that can help you visualize your month-to-date usage of your reservations.

Q2: What if I don’t need that instance type anymore?

There’s a couple of options for unused reservations, depending on the reason you aren’t using them anymore. The first option is to sell the reservation on the Reserved Instance Marketplace. This marketplace lets you list your reservation and allows others to purchase it from you. The reservations are grouped together, with the cheapest being sold first in that group. Once someone purchases your reservation, you start getting charged at the on-demand rate (if you still use that type).

The other option is to purchase convertible reservations, which allow you to change the attributes of the reservation (as long as it’s to a more expensive instance type). These convertible types give you much more flexibility, especially as your company or application are growing in use, but they do come with a smaller savings rate over standard Reserved Instances.

Q3: How do Reserved Instances work if I have multiple AWS accounts?

Many users of AWS in large organizations have started using a multi-account strategy, either for security reasons or billing reasons. When managing multiple AWS accounts, billing and reservations can get confusing. The good news is that reservations can “float” across multiple linked accounts, even if they weren’t purchased in the master account. Amazon is smart enough to attempt to apply the reservation to the account it was purchased in, but if a suitable instance is not found, it can apply it to an instance in a different account that matches. You can also choose to exclude linked accounts from receiving these floating reservations if you’d like.

Q4: Are AWS Reserved Instances better than On Demand?

Great question. This is actually the subject of the most popular post on the ParkMyCloud blog. In short: usually yes, but only for production environments. Otherwise, On Demand instances with on/off schedules are typically better value.

Conclusion

Reserved Instances can help save a lot of money on your AWS bill, but require a different way of thinking about your instances than the normal pay-as-you-go that you may be used to with cloud computing. These reservations are typically used for steady-state workloads with consistent usage. Did we miss any of your questions in this AWS Reserved Instances FAQ? Let us know!

Read more ›

Announcing Alibaba Cloud Cost Control with ParkMyCloud

We’re happy to announce that ParkMyCloud now supports Alibaba Cloud!

Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) users have saved millions of dollars on their cloud bills using ParkMyCloud’s automated cloud cost optimization platform. Customers like McDonald’s, Sysco, and Unilever use ParkMyCloud to automatically turn off idle cloud resources as part of their DevOps process.

Now, Alibaba Cloud customers can do the same.

Why Alibaba?

Alibaba Cloud is experiencing rapid customer adoption and growth – in the 4th quarter of last year, they saw over 100% growth, with more than 300 products and features launched. The company is clearly expanding their horizons beyond retail and putting a focus on innovation and development in the cloud space – both in China where their core customer base is located, and throughout the world as companies globally choose Alibaba as their primary cloud provider or as part of a multi-cloud strategy.

But the real reason we’re here is to help cloud users solve the enormous problem of cloud waste.

We estimate that Alibaba users will waste $552 million on idle cloud resources this year – that’s $1.5 million per day that could easily be saved with automated cost optimization in place. There’s no time to lose in getting cost control measures in place.

See it In Action

Get a preview of ParkMyCloud – watch this 2-minute demo to see how it works. To see a full demo and get your questions answered, schedule a personalized demo now.

Try Now for Free

You can get started with Alibaba Cloud cost control now with a free 14-day trial of ParkMyCloud, with full access to premium features.

After your trial expires, you can choose to continue using the free tier, or upgrade to use premium features such as SmartParking, full API access, advanced reporting and SSO.

Cheers, and happy parking.

Read more ›

Interview: Hitachi ID Systems Optimizes Training Infrastructure with ParkMyCloud

Hitachi ID Systems recently reached their first ParkMyCloud birthday – to celebrate, we chatted with Patrick McMaster about how they optimize training infrastructure and why he and his team said “We honestly couldn’t be happier with ParkMyCloud.”

Can you start by telling me about Hitachi ID Systems and what you and your team do within the company?

Hitachi ID Systems makes identity and access management (IAM) software. I am the training coordinator, so I handle getting clients and potential partners up to speed with how our software works, how to install it, how to administrate it, etc. For those who are more interested in learning about software, we set them up with a virtual environment and course materials or an instructor to get them up to speed with how the software works.

Can you describe how you’re using public cloud?

We use AWS exclusively. When we advertise that we’re running a course a few months ahead of time, our infrastructure starts seeing the registrations and will start creating VMs, applying patches, getting the latest version of the appropriate software installers on the desktop and getting everything ready for the students, who will be accessing geographically-local AWS infrastructure.

In the past, everything for this online training was very manual. We on the training team  would spin up the VMs manually, do the updates manually, and send the information to the potential students., Then when the course was over we would go through and do the reverse – shutting the elements down and turning off the virtual machine on AWS.

What does the supporting training infrastructure in AWS look like?

We have a number of VMs running per student or team that only need to be active during the team’s local business hours, plus some additional supporting infrastructure which is required 24/7. We started to realize as we got more students and began offering self-paced training that our AWS fees were increasing from the 24/7 access we were providing, but also just the management of keeping track of which students are where, when they should be brought into the system, when they should be shut down, etc. We needed to find a solution pretty quickly as we experienced that period of rapid growth.

How did that lead you to finding ParkMyCloud?

We knew we needed to automate the manual processes for this. Of course, lots of organizations tend to come up with solutions internally first. We’re a software company, so we had the talent for that, but we never have enough time. I’ve come to terms more and more every year with the benefits of delegating to the other sources. I realized that we are probably not the first organization to have this problem, so I Googled and found ParkMyCloud.

It became quickly evident that the features that you offered were exactly what we were looking for.

Can you describe your experience as a ParkMyCloud user so far?

Sure! So just before our demo of ParkMyCloud, we were fighting with this issue of trying to figure out how we can manage multiple time zones and multiple geographic locations, and not pay for that time that VMs are just spun up.

Then we went through the ParkMyCloud demo process and started our trial. We connected to our system and looked at ways to set up different schedules and pull information from AWS. There was definitely a moment where everyone in the room looked each other and said, “we must be missing something” – there had to be some additional steps we hadn’t thought out because it seemed too easy to work. But it really was that easy.

It just took a week of monitoring to make sure everything was turning off when it was supposed to – the bulk of our effort was really in that first week, and the time we need to spend in the interface is so small. We can go into ParkMyCloud’s dashboard and make exceptions to the schedule when needed, but the time that we actually spend thinking about these things is now about 2 hours a week, whereas before it was something that members of our staff might struggle with for 1-2 days. It’s been a huge improvement.

We did some calculations just in terms of uptime versus what we were doing before, and having the different schedules at our disposal and being able to spend that one week coming up with every scenario we could come up with was time well-spent. Now there are very few exceptions. I don’t think we’ve had to create a new schedule in a long time. Everything is organized logically, it’s very easy for us to find everything we need.

Who is responsible for tracking your AWS spending in the organization? Have they had any feedback?

Our finance department. Since we started using ParkMyCloud, it’s been very very quiet. No news is good news from finance. We are saving about 40% of our bill.

Do you have any other cloud cost savings measures in place?

Not for this training infrastructure. We have a pretty unique use case here. Our next steps are going to be more towards automatic termination, automatic spinning things up, more time-saving measures rather than cost.

This summer ParkMyCloud is working on instance rightsizing, if that’s something that would be helpful for you.

 That’s definitely something that we could use. We are always trying to find better ways of doing things.

OK, great, thanks Patrick! Appreciate your time.

 Thank you, have a good one!

 

Read more ›

4 Types of Idle Cloud Resources That Are Wasting Your Money

We have been talking about idle cloud resources for several years now. Typically, we’re talking about instances purchased On Demand that you’re using for non-production purposes like development, testing, QA, staging, etc. These resources can be “parked” when they’re not being used, such as on nights and weekend, saving 65% or more per resource each month. What we haven’t talked much about is how the problem of idle cloud resources extends beyond just your typical virtual machine.

Why Idle Cloud Resources are a Problem

If you think about it, the problem is pretty straightforward: if a resource is idle, you’re paying your cloud provider for something you’re not actually using. This adds up.

Most non-production resources can be parked about 65% of the time, that is, parked 12 hours per day and all day on weekends (this is confirmed by looking at the resources parked in ParkMyCloud – they’re scheduled to be off just under 65% of the time.) We see that our customers are paying their cloud providers an average list price of $220 per month for their instances. If you’re currently paying $220 per month for an instance and leaving it running all the time, that means you’re wasting $143 per instance per month.

Maybe that doesn’t sound like much. But if that’s the case for 10 instances, you’re wasting $1,430 per month. One hundred instances? You’re up to a bill of $14,300 for time you’re not using. And that’s just a simple micro example. At a macro level that’s literally billions of dollars in wasted cloud spend.

4 Types of Idle Cloud Resources

So what kinds of resources are typically left idle, consuming your budget? Let’s dig into that, looking at the big three cloud providers — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

  • On Demand Instances/VMs – this is the core of the conversation, and what we’ve addressed above. On demand resources – and their associated scale groups – are frequently left running when they’re not being used, especially those used for non-production purposes.
  • Relational Databases – there’s no doubt that databases are frequently left running when not needed as well, in similar circumstances to the On Demand resources. The problem is whether you can park them to cut back on wasted spend. AWS allows you to park certain types of its RDS service, however, you can not park like idle database services in Azure (SQL Database) or GCP (SQL). In this case, you should review your database infrastructure regularly and terminate anything unnecessary – or change to a smaller size if possible.
  • Load Balancers – AWS Elastic Load Balancers (ELB) can not be stopped (or parked), so to avoid getting billed for the time you need to remove it. The same can be said for Azure Load Balancer and GCP Load Balancers. Alerts can be set up in Cloudwatch/Azure Metrics/Google Stackdriver when you have a load balancer with no instances, so be sure to make use of those alerts.
  • Containers – optimizing container use is a project of its own, but there’s no doubt that container services can be a source of waste. In fact, we are evaluating the ability for ParkMyCloud to park container services including ECS and EKS from AWS, ACS and AKS from Azure, and GKE from GCP, and the ability to prune and park the underlying hosts. In the meantime, you’ll want to regularly review the usage of your containers and the utilization of the infrastructure, especially in non-production environments.

Cloud waste is a billion-dollar problem facing businesses today. Make sure you’re turning off idle cloud resources in your environment, by parking those that can be stopped and eliminating those that can’t, to do your part in optimizing cloud spend.

Read more ›

4 Orphaned Cloud Resources Eating Away at Your AWS Budget – and How to Avoid Them

We recently discussed how orphaned volumes and snapshots contribute to cloud waste and what you can do about it, but those are just two examples of orphaned cloud resources that result in unnecessary charges. The public cloud is a pay-as-you-go utility, requiring full visibility of specific infrastructure – you don’t want to be charged for resources you aren’t using. Here are other types of orphaned cloud resources that contribute to cloud waste (and cost you money):

Unassociated Elastic IPs  

Elastic IPs are reserved public IP addresses designed for dynamic cloud computing in AWS. As a static IPv4 address associated with your AWS account, Elastic IPs can continue running an EC2 instance, even if it is stopped and restarted, by quickly remapping the address to another one of your instances. You can allocate an Elastic IP address to any EC2 instance in a given region, until you decide to release it.  

The advantage of having an Elastic IP (EIP) is the ability to mask the failure of an EC2 instance, but if you do not associate the address to your account – you’re still getting charged. To avoid incurring a needless hourly charge from AWS, remember to release any unassociated IPs you no longer need.

Elastic Load Balancers (with no instances)

Cloud load balancing allows users to distribute workloads and traffic with the benefit of the cloud’s scalability. All major cloud providers offer some type of load balancing – AWS users can balance workloads and distribute traffic among EC2 instances with its Elastic Load Balancer, Google Cloud can distribute traffic between VM instances with Google Cloud Load Balancing, and Azure’s Load Balancer distributes traffic across multiple data centers.   

An AWS Elastic Load Balancer (ELB) will incur charges to your bill as long as it’s configured with your account. Like with Elastic IPs, whether you’re using it or not – you’re paying. If you have no instances associated with your ELB, delete to avoid paying needless charges on your monthly bill.   

Unused Machine Images (AMIs)

A Machine Image provides the information required to launch an instance, which is a virtual server in the cloud. In AWS they’re called AMIs, in Azure they’re Managed Images, and in Google Cloud Platform they’re Custom Images.

As part of your measures to reduce unnecessary costs from orphaned volumes, delete unused machine images when you no longer need them. Unless deleted, the snapshot that was created when the image was first created will continue to incur storage costs.

Object Storage

One of the growing pains that organizations face is the management of isolated pools of data in their cloud environment. Fragmented storage can result from data coming from a number of sources used by applications and business processes. Object Storage was designed to break down silos into scalable, cost-effective storage to store data in its native format. AWS offers object storage solutions like Amazon S3 and Amazon Glacier, Google has Google Cloud Storage, and Azure calls its solution Azure Blob Storage. All options help you manage your storage in one place, keeping your data organized and your business more cost effective.  

Although object storage in and of itself is a cost effective solution, there are still ways to optimize and reduce costs within this solution. Delete files you no longer need so that you’re not paying for them. Delete unused files which can be recreated. In S3, use the “lifecycle” feature to delete or overwrite older versions of data. Clean up incomplete uploads that were interrupted, resulting in partial objects that are taking up needless space. And compress your data before storing to give you better performance and reduce your storage requirements.

How to Avoid Wasted Spend on Orphaned Cloud Resources

Don’t let forgotten resources waste money on your cloud bill. Put a stop to cloud waste by eliminating orphaned cloud resources and inactive storage, saving space, time, and money in the process. Remember to:

  • Release unassociated IPs you no longer need.
  • Remove Elastic Load Balancers with no instances attached.
  • Delete unused machine images when you no longer need them.
  • Keep object storage minimal – optimize by “cleaning up” regularly, removing files you don’t need.

The premise of the cloud and the resources available to you were meant to be cost effective, but it’s up to you keep costs in check. Optimize your cloud spend with visibility, management, and cost automation tools like ParkMyCloud to get the most out of your cloud environment.  

Read more ›

How to Keep Costs in Check After Converting a Monolith to Microservices

You’ve gone full-blown DevOps, drank the Agile Kool-Aid, cloudified everything, and turned your monolith to microservices — so why have all of your old monolith costs turned into even bigger microservices costs? There are a few common reasons this happens, and some straightforward first steps to get microservices cost control in place.

Why Monolith to Microservices Drives Costs Up

As companies and departments adapt to modern software development processes and utilize the latest technologies, they assume they’re saving money – or forget to think about it altogether. Smaller applications and services should come with more savings opportunities, but complexity and rapidly-evolving environments can actually make the costs skyrocket. Sometimes, it’s happening right under your nose, but the costs are so hard to compile that you don’t even know it’s happening until it’s too late.

The same thing that makes microservices attractive — smaller pieces of infrastructure that can work independently from each other — can also be the main reason that costs spiral out of control. Isolated systems, with their own costs, maintenance, upgrades, and underlying architecture, can each look cheaper than the monolithic system you were running before, but can skyrocket in cost when aggregated.

How to Control Microservices Costs

If your microservices costs are already out of control, there are a few easy first steps to reining them in.

Keep It Simple

As with many new trends, there is a tendency to jump right in and switch everything to the new hotness. Having a drastic cutover, while scrapping all of your old code, can be refreshing and damaging all at the same time. It makes it hard to keep track of everything, so costs can run rampant while you and your team are struggling just to comprehend what pieces are where. By keeping some of what you already have, but slowly creating new functionality in a microservices model, you can maintain a baseline while focusing on costs and infrastructure of your new code.

The other way to keep it simple is to keep each microservice extremely limited in scope. If a microservice does just one thing, without a bunch of bells and whistles, it’s much easier to see if costs are rising and make the infrastructure match the use case. Additional opportunities for using PaaS or picking a cloud provider that fits your needs can really help maximize utilization.

Scalability and Bursting

Microservices architectures, by the very nature of their design, allow you to optimize individual pieces to minimize bottlenecks. This optimization can also include cost optimization of individual components, even to the point of having idle pieces turned completely off until they are needed. Other pieces might be on, but scaled down to the bare minimum, then rapidly scale out when demand runs high. A fluctuating architecture sounds complex, but can really help keep costs down when load is low.

User Governance

Along with a microservices architecture, you may start having certain users and departments be responsible for just a piece of the system. With that in mind, cloud providers and platform tools can help you separate users to only access the systems and infrastructure they are working on so they can focus on the operation (and costs) of that piece. This allows you to give individual users the role that is necessary for minimal access controls, while still allowing them to get their jobs done.

Ordered Start/Stop and Automation with ParkMyCloud

ParkMyCloud is all about cost control, so we’ve started putting together a cost-savings plan for our customers who are moving from monolith to microservices.

First, they should use ParkMyCloud’s Logical Groups to put multiple instances and databases into a single entity with an ordered list. This way, your users do not have to remember multiple servers to start for their application – instead, they can start one group with a single click. This can help eliminate the support tickets that are due to parts of the system not running.

Additionally, use Logical Groups to set start delays and stop delays between nodes of the group. With delays, ParkMyCloud will know to start database A, then wait 10 minutes before starting instance B, to ensure the database is up and ready to accept connections. Similarly, you can make sure other microservices are shut down before finally shutting down the database.

Everything you can do in the ParkMyCloud user interface can also be done through the ParkMyCloud REST API. This means that you can temporarily override schedules, toggle instances to turn off or on, or change team memberships programmatically. In a microservices setup, you might have certain pieces that are idle for large portions of the day. With the ParkMyCloud API, you could have those nodes turned off on a schedule to save money, then have a separate microservice call the API to turn the node on when it’s needed.

The Goal: Continuous Cost Control

Moving from monolith to microservices can be a huge factor in a successful software development practice. Don’t let cost be a limiting factor – practice continuous cost control, no matter what architecture you choose. By putting a few costs control measures in place with ParkMyCloud, along with some automation and user management, you can make sure your new applications are not only modern, but also cost-effective.

Read more ›

AWS vs Alibaba Cloud Pricing: A Comparison of Compute Options

More cloud users are starting to investigate Alibaba Cloud, so the time is ripe for a comparison of AWS vs Alibaba Cloud pricing. Commonly recognized as the #4 cloud provider (from a revenue perspective anyway), Alibaba is one of the fastest growing companies in the space today.

Alibaba has been getting a lot of attention lately, given its rapid growth, and its opportunities for cloud deployments within mainland China. ParkMyCloud is preparing to release support for Alibaba, and that of course has let us focus on pricing and cost savings – our forte. In this article I am going to dive a bit into the pricing of the Alibaba Elastic Compute Service (ECS), and compare it with that of the AWS EC2 service.

Alibaba vs Aliyun

Finding actual pricing for comparison purposes can be a bit complicated, as the prices are listed in a couple different places and do not quite exactly match up. If one searches for Alibaba pricing, one ends up here, which I am going to call the “Alibaba Cloud” site. However, when you actually get an account and want to purchase an instance, you can up here or here, both of which I will call the “Aliyun” site. [Note that you may not be able to see the Aliyun sites without signing up for an account and actually logging-in.]  

Aliyun (literally translated “Ali Cloud”) was the original name of the company, and the name was changed to Alibaba Cloud in July 2017. Unsurprisingly, the Aliyun name has stuck around on the actual operational guts of the company, reflecting that it is probably hard-coded all over the place, both internally and externally with customers. (Supernor’s 3rd Conjecture: Engineering can never keep up with Marketing.)

Both sites show that like the other major cloud providers, Alibaba’s pricing model includes a Pay-As-You-Go (PAYG) offering, with per-second billing. Note, however, that in order to save money on stopped instances, one must specifically enable a “No fees for stopped instances” feature. Luckily, this is a global one-time setting for instances operating under a VPC, and you can set it and forget it. Unlike AWS, this feature is not available for any instances with local disks (this and other aspects of the description lead me to believe that Alibaba instances tend to be “sticky” to the underlying hardware instance). On AWS, local disks are described as ephemeral, and are simply deallocated when they are not in use. Like AWS, system/data disks continue to accrue costs even when an instance is stopped.

Both sites also show that Alibaba also has a one-month prepaid Subscription model. Based on a review of the pricing listed for the us-east-1 region on the Alibaba Cloud site, the monthly subscription discount reflects a substantial 30-60% discount compared to the cost of a PAYG instance that is left up for a full month. For a non-production environment that may only need to be up during normal business hours (say, 9 hours per day, weekdays only), one can easily see that it may be more cost-effective to go with the PAYG pricing, and use the ParkMyCloud service to shut the instances down during off-hours, saving 73%.

But this is where the similarities between the sites end. For actual pricing, instance availability, and even the actual instance types, one really needs to dive into a live Alibaba account. In particular, if PAYG is your preference, note that the Alibaba public site appears to have PAYG pricing listed for all of their available instance types, which is not consistent with what I found in the actual purchasing console.

Low-End Instance Types – “Entry Level” and “Basic”

The Alibaba Cloud site breaks down the instance types into “Entry Level” and “Enterprise”, listing numerous instance types under both categories. All of the Entry Level instance types are described as “Shared Performance”, which appears to mean the underlying hardware resources are shared amongst multiple instances in a potentially unpredictable way, or as described by Alibaba: “Their computing performance may be unstable, but the cost is relatively low” – an entertaining description to say the least. I did find these instance types on the internal purchasing site, but did not delve any further with them, as they do not offer a point of reference for our AWS vs. Alibaba Cloud pricing comparison. They may be an interesting path for additional investigation for non-production instance types where unstable computing performance may be OK in exchange for a lower price.

That said…after logging in to the Alibaba management console, reaching the Aliyun side of the website, there is no mention of Entry Level vs Enterprise. Instead we see the top-level options of “Basic Purchase” vs “Advanced Purchase”. Under Basic Purchase, there are four “t5” instance types. The t5 types appear to directly correspond to the first four AWS t2 instance types, in terms of building up CPU credits.

These four instance types do not appear to support the PAYG pricing model. Pricing is only offered on a monthly subscription basis. A 1-year purchase plan is also offered, but the math shows this is just the monthly price x12. It is important to note that the Aliyun site itself has issues, as it lists the t5 instance types in all of the Alibaba regions, but I was unable to purchase any of them in the us-east-1 region – “The configuration for the instance you are creating is currently not supported in this zone.”  (A purchase in us-west-1, slightly more expensive, was fine).

The following shows a price comparison for Alibaba vs AWS for “t” instance prices in a number of regions. The AWS prices reflect the hourly PAYG pricing, multiplied by an average 730 hour month. I was not able to get pricing for any AWS China region, so the Alibaba pricing is provided for reference.

While the AWS prices are higher, the AWS instances are PAYG, and thus could be stopped when not being used, common for t2 instances used in a dev-test environment, and potentially saving over 73%. One can easily see that this kind of savings is needed to compete with the comparatively low Alibaba prices. I do have to wonder what is up with that Windows pricing in China….does Microsoft know about this??

Aliyun “Advanced Purchase”

Looking at the “Advanced” side of the Aliyun purchasing site, we get a lot more options, including Pay-As-You-Go instances. To keep the comparison simple, I am going to limit the scope here to a couple of instance types, trying to compare a couple m5 and i3 instances with their Alibaba equivalents. I will list PAYG pricing where offered.

In this table, the listed monthly AWS prices reflect the hourly pay-as-you-go price, multiplied by an average 730 hour month.

The italicized/grey numbers under Alibaba indicate PAYG numbers that had to be pulled from the public-facing website, as the instance type was not available for PAYG purchase on the internal site. From a review of the various options on the internal Aliyun site, it appears the PAYG option is not actually offered for very many standalone instance types on Alibaba…

The main reason I pulled in the PAYG prices from the second source was for auto scaling, which is normally charged at PAYG prices. In Alibaba, “all ECS instances that Auto Scaling automatically creates, or manually adds, to a scaling group will be charged according to their instance types. Note that you will still be charged for Pay-As-You-Go instances even after you stop them.”  It is possible, however, to manually add subscription-based instances to an auto scaling group, and configure them to be not removed when the group scales-down.

In general, the full price of the AWS Linux instances over a month is 22-35% higher that of an Alibaba 1-month subscription. A full price AWS Windows instance over a month is 9-25%  higher than that of an Alibaba subscription. (And once again, it appears Windows licensing fees are not a factor in China.)

AWS vs Alibaba Cloud Pricing: Alibaba is cheaper, but…

Alibaba definitely comes out as less expensive in this AWS vs Alibaba cloud pricing comparison – the one-month subscription has a definite impact. However, for longer-lived instances, AWS Reserved Instances will certainly be less expensive, running about 40-75% less expensive than AWS PAYG, and thus less than some if not all of the Alibaba monthly subscriptions. AWS RI’s are also more easily applicable to auto scaling groups than a monthly subscription instance.

For non-production instances that can be shut down when not in use, PAYG is less expensive for both cloud providers, where ParkMyCloud can help you schedule the downtime. The difficulty with Alibaba will actually be finding instances types that can actually be purchased with the PAYG option.

Read more ›

New Microsoft Teams Bot to Control Cloud Costs

Today we’d like to announce a new Microsoft Teams bot that allows you to fully interact with ParkMyCloud directly through your chat window, without having to access the web GUI. By combining this chatbot with a direct notifications feed of any ParkMyCloud activities through our webhook integration, you can manage your continuous cost control from the Microsoft Teams channels you live in every day — making it easy to save 65% or more on your instance costs.

Organizations who are utilizing DevOps principles are increasingly utilizing ChatOps to manipulate their environments and provide a self-service platform to access the servers and databases they require for their work. There are a few different chat systems and bot platforms available – we also have a chat bot for Slack – but one that is growing rapidly in popularity is Microsoft Teams.

By setting up the Microsoft Teams bot to interact with your ParkMyCloud account, you can allow users to:

  • Assign schedules
  • Temporarily override schedules on parked instances
  • Toggle instances to turn off or on as needed

Combine this with notifications from ParkMyCloud, and you can have full visibility into your cost control initiatives right from your standard Microsoft Teams chat channels. Notifications allow you to have ParkMyCloud post messages for things like schedule changes or instances that are being turned off automatically.

Now, with the new ParkMyCloud Teams bot, you can reply back to those notifications to:

  • Snooze the schedule
  • Turn a system back on temporarily
  • Assign a new schedule.

The chatbot is open-source, so you can feel free to modify the bot as necessary to fit your environment or use cases. It’s written in NodeJS using the botbuilder library from Microsoft, but even if you’re not a NodeJS expert, we tried to make it easy to edit the commands and responses. We’d love to have you send your ideas and modifications back to us for rapid improvement.

If you haven’t already signed up for ParkMyCloud to help save you 65% on your cloud bills, then start a free trial and get the Microsoft Teams bot hooked up for easy ChatOps control. You’ll find that ParkMyCloud can make continuous cost control easy and help reduce your cloud spend, all while integrating with your favorite DevOps tools.

 

Read more ›

Why Your Spring Cleaning Should Include Unused Cloud Resources

Given that spring is very much in the air – at least it is here in Northern Virginia – our attention has turned to tidying up the yard and getting things in good shape for summer. While things are not so seasonally-focused in the world of cloud, the metaphor of taking time out to clean things up applies to unused cloud resources as well. We have even seen some call this ‘cloud pruning’ (not to be confused with the Japanese gardening method).

Cloud pruning is important for improving both cost and performance of your infrastructure. So what are some of the ways you can go about cleaning up, optimizing, and ensuring that our cloud environments are in great shape?

Delete Old Snapshots

Let’s start with focusing on items that we no longer need. One of the most common types of unused cloud resources is old Snapshots. These are your old EBS volumes on AWS, your storage disks (blobs) on Azure, and persistent disks on GCP. If you have had some form of backup strategy then it’s likely that you will understand the need to manage the number of snapshots you keep for a particular volume, and the need to delete older, unneeded snapshots. Cleaning these up immediately helps save on your storage costs and there are a number of best practices documenting how to streamline this process as well as a number of free and paid-for tools to help support this process.

Delete Old Machine Images

A Machine Image provides the information required to launch an instance, which is a virtual server in the cloud. In AWS these are called AMIs, in Azure they’re called Managed Images, and in GCP Custom Images. When these images are no longer needed, it is possible to deregister them. However, depending on your configuration you are likely to continue to incur costs, as typically the snapshot that was created when the image was first created will continue to incur storage costs. Therefore, if you are finished with an AMI, be sure to ensure that you also delete its accompanying snapshot. Managing your old AMIs does require work, but there are a number of methods to streamline these processes made available both by the cloud providers as well as third-party vendors to manage this type of unused cloud resources.

Optimize Containers

With the widespread adoption of containers in the last few years and much of the focus on their specific benefits, few have paid attention to ensuring these containers are optimized for performance and cost. One of the most effective ways to maximize the benefits of containers is to host multiple containerized application workloads within a single larger instance (typically large or x-large VM) rather than on a number of smaller, separate VMs. In particular, this is something you would could utilize in your dev and test environments rather than in production, where you may just have one machine available to deploy to. As containerization continues to evolve, services such as AWS’s Fargate are enabling much more control of the resources required to run your containers beyond what is available today using traditional VMs. In particular, the ability to specify the exact CPU and memory your code requires (and thus the amount you pay) scales exactly with how many containers you are running.

So alongside pruning your trees or sweeping your deck and taking care of your outside spaces this spring, remember to take a look around your cloud environment and look for opportunities to remove unused cloud resources to optimize not only for cost, but also performance.

Read more ›

How to Use Google Preemptible VMs to Get 80% Savings

Google Cloud has always had a knack for non-standard virtual machines, and their option of creating Google preemptible VMs is no different. Traditional virtual machines are long-running servers with standard operating systems that are only shut down when you say they can be shut down. On the other hand, preemptible VMs last no longer than 24 hours and can be stopped on a moment’s notice (and may not be available at all). So why use them?

Use Cases for Google Preemptible VMs

As with most trade-offs, the biggest reason is cost. Preemptible VMs can save you up to 80% compared to a normal on-demand virtual machine. (By the way – AWS users will want to use Spot Instances for the same reason, and Azure users can check out Low Priority VMs). This is a huge savings if the workload you’re trying to run consists of short-lived processes or things that are not urgent and can be done any time. This can include things like financial modeling, rendering and encoding, and even some parts of your CI/CD pipeline or code testing framework.

How to Create a Google Preemptible VM

To create a preemptible VM, you can use the Google Cloud Platform console, the ‘gcloud’ command line tool, or the Google Cloud API. The process is the same as creating a standard VM: you select your instance size, networking options, disk setup, and SSH keys, with the one minor change that you enable the ‘preemptible’ flag during setup. The other change you’ll want to make is to create a shutdown script to decide what happens to your processes and data if the instance is stopped without your knowledge. This script can even perform different actions if the instance was preempted as opposed to shut down from something you did.

One nice benefit of Google preemptible VMs is the ability to attach local SSD drives and GPUs to the instances. This means you can get added extensibility and performance for the workload that you are running, while still saving money. You can also have preemptible instances in a managed instance group for high scalability when the instances are available. This can help you process more of your jobs at once when the preemptible virtual machines are able to run.

How to Use Google Preemptible VMs to Optimize Costs

Our customers who have the most cost-effective use of Google resources often mix Google preemptible VMs with other instance types based on the workloads. For instance, production systems that need to be up 24/7 can buy committed-use discounts for up to 57% savings on those servers. Non-production systems, like dev, test, QA, and staging, can use on-demand resources with schedules managed by ParkMyCloud to save 65%. Then, any batch workloads or non-urgent jobs can use Google preemptible VMs to run whenever available for up to 80% savings. Questions about optimizing cloud costs? We’re happy to help – email us or use the chat client on this page (staffed by real people, including me!).

Read more ›

New in ParkMyCloud: Park GCP Groups, Schedule Override, New Trial Experience, and More

Today, we share the latest update in ParkMyCloud, which highlights new types of GCP resources you can park, and updates for new and existing users alike.

Park GCP Groups

Now in ParkMyCloud, you can manage and optimize costs for your GCP Managed Instance Groups, both with and without Autoscaling. You can set parking schedules on these groups, but rather than simply turning them “on” and “off”, you can set “high” and “low” stages for your groups, for which you set a maximum and minimum number of resources, respectively. Some additional details:

  • GCP Managed Groups with Autoscaling can have a minimum size of 1 instance in the Low/Off state, and thus they can never be fully shut off to zero instances.
  • GCP Managed Groups without Autoscaling can have a minimum size of 0 instances in the Low/Off state, and can be fully shut off.
  • The Console will show the members of GCP Unmanaged Groups as “regular” resources, allowing them to be scheduled/controlled individually. You wish to assign them to ParkMyCloud Logical Groups in order to start and stop them as a set.

In order to allow ParkMyCloud to support management of GCP Instance Groups, please update your ParkMyCloud Access Role to include the latest set of permissions defined here in the User Guide.

What about other cloud service providers? ParkMyCloud already supports parking for AWS Auto Scaling groups. Management of Azure’s equivalent, Azure scale sets, is coming later this month.

Schedule “Snooze” is now “Override”

ParkMyCloud has long allowed you to “snooze” parking schedules — as in, snooze the on/off actions of the schedule, not the resource. But it was confusing — when people heard “snooze”, they incorrectly assumed it meant, “put the resource to sleep”.

So we’ve renamed it “override”. When you override a schedule on a resource, you can set it to your preferred state of running or parked, either for a set duration (e.g., override the schedule for 3 hours) or until a set time (e.g., override the schedule until 8:00 a.m. on May 16). After that time, normal schedule actions will resume.

For Existing Users…

This release includes a number of other updates that will interest existing users of ParkmyCloud:

    • Recommendations Export: The recommendations screen can now be exported to CSV, via a new Export button, for easy sharing and analysis.
    • Online Help: Each page on the console now has a “?” link to context-sensitive help from the PMC User Guide.
    • Teams: Superadmins now appear as greyed-out users on all team lists, showing their visibility into all teams.
    • Notifications: User-level notifications are now more obvious with a link from the org/team-level notifications screen.
  • Resources Screen:
    • The Schedule/Start/Stop/Team/Group buttons are now always visible, and only enabled when appropriate instances are checked, depending on the function of the button.
    • The resources screen is now more mobile-device friendly. There used to be an issue with how the screen scrolled, which is now fixed.
    • Performance improvements for customers with large numbers of schedules and recommendations.

For New Users…

Don’t tell the existing users above, but we’ve improved the ParkMyCloud free trial for new users. When you start a 14-day free trial, you will now be given Enterprise tier access to the product – that means unlimited instances, teams, users, and cloud accounts across providers in your trial ParkMyCloud account, access to the user import/export feature, database parking, SmartParking, and more. Check it out with a free trial.

Read more ›

5 Ways to Get Discounts on Cloud Resources

Whether you’re just getting started on public cloud, or you’ve gotten a bill that blew your budget out of the water, it’s a good idea to research ways to get discounts on cloud resources. There’s no reason to pay list price when so many cost-savings measures are available (and your peers are probably taking advantage of them!) Here are our top five ways to get discounts on cloud.

1. Buy in Advance

By purchasing your compute power in advance, you can get a discounted rate — the notable examples being AWS Reserved Instances, Azure Reserved Instances, and Google Committed Use Discounts.

So will these save you money? Actually, that’s a great question. There are several factors that weigh into the answer:

  • How much you pay upfront (for example AWS offers all-upfront, partial-upfront, or no-upfront)
  • Contract term: 1-year or 3-year term – the longer term will save more, but there’s risk involved in committing for that long
  • If the cloud provider cuts their prices during your contract term (and they probably will), you’ll save less

This blog post about AWS Reserved Instances digs into these issues further. Bottom line: paying in advance can save you money, but proceed with caution.

2. Use Your Resources More

The primary example of “spending more to save more” in the cloud computing world is Google Sustained Use Discounts. This is a cool option for automatic savings – as long as you use an instance for at least 25% of the month, GCP will charge you less than list price.

But just like the advanced purchasing options above, there are several factors to account for before assuming this will really save you “up to 60%” of the cost. It may actually be better to just turn off your resources when you’re not using them – more in this post about Google Sustained Use Discounts.

3. If You’re Big: Enterprise Agreements and Volume Discounts

Anyone who’s shopped at Costco isn’t surprised that buying in bulk can get you a discount. Last week, Twitter announced that it will be using Google Cloud Platform for cold data storage and flexible compute Hadoop clusters — at an estimated list price of $10,000,000/month. Of course, it’s unthinkable that they would actually pay that much – as such a high-profile customer, Twitter is likely to have massive discounts on GCP’s list prices. We often hear from our Azure customers that they chose Azure due to pre-existing Microsoft Enterprise Agreements that give them substantial discounts.

If you have or foresee a large volume of infrastructure costs, make sure to look into:

4. If You’re Small: Startup Credits

Each of the major cloud providers offers free credit programs to startups to lure them and get locked in on their services – but that’s not a bad thing. We’ve talked to startups focused on anything from education to location services who have gotten their money’s worth out of these credits while they focus on growth.

If you work for a startup, check out:

5. Wait

So far, history tells us that if you wait a few months, your public cloud provider will drop their prices, giving you a built-in discount.

If you stick with the existing resource types, rather than flocking to the newer, shinier models, you should be all set. The same AWS m1.large instance that cost $0.40/hour in 2008 now goes for $0.175. We’ll just say that’s not exactly on pace with inflation.

It’s Okay if You Don’t Get Discounts on Cloud

What if you’re not a startup, you’re not an enterprise, and you just need some regular compute and database infrastructure now? Should you worry if you don’t get discounts on cloud list prices? No sweat. Even by paying list price, it’s still possible to optimize your spend. Make sure you’re combing through your bill every so often to find orphaned or unused resources that need to be deleted.

Additionally, right-size your resources and turn them off when you’re not using them to pay only for what you actually need – you’ll save money, even without a discount.

Read more ›

Do Google Sustained Use Discounts Really Save You Money?

When looking to keep Google Cloud Platform (GCP) costs in control, the first place users turn are the discount options offered by the cloud service provider itself, such as Google’s Sustained Use discounts. The question is: do Google Sustained Use discounts actually save you money, when you could just turn the instance off?

How Google Sustained Use discounts work

The idea of the Sustained Use discount is that the longer you run a VM instance in any given month, the bigger discount you will get from the list price. The following shows the incremental discount, and its cumulative impact on a hypothetical $100/month VM instance, where the percentages are against the baseline 730-hour month.

I have to say here that the GCP prices listed can be somewhat misleading unless you read the fine print where it says “Note: Listed monthly pricing includes applicable, automatic sustained use discounts, assuming the instance runs for a 730 hour month.”  What this means to us is that the list prices of the instances are actually much higher, but their progressive discount means that no one ever actually pays list price. That said – the list price is what you need to know in order to estimate the actual cost you will pay if you do not plan to leave the instance up for 730 hours/month.

For example, the price shown on the GCP pricing link for an n1-standard-8 instance in the Iowa region is (as of this writing) $194.1800. The list price for this instance would be $194.1800/0.7 = $277.40. This is the figure that must be used as the entry point for the table above to calculate the actual cost, given a certain level of utilization.

What if you parked the VM instance instead?

Here at ParkMyCloud, we’re all about scheduling resources to turn off when you’re not using them, i.e., “parking” them. With this mindset, I wondered about the impact of the sustained use discounts on the schedule-based savings. The following chart plots the cost of that n1-standard-8 VM instance, showing Google sustained use discounts combined with a parking schedule.

We can definitely see progressively more sustained use savings added to progressively less schedule-based savings.  I am sure this would end up getting described as the typical hype of “the more you spend, the more you save!”  But, the reality of the matter must intrude here and show the more you spend…the more you spend!

Looking at what this means for ParkMyCloud users, here is the monthly uptime for a few common parking schedules, and the associated cost:

These are a far cry from the $277.40 list price, and even the $194.18 max discounted price. From this, it can be seen that even with the most wide-open “work day” schedule of 12 hours per weekday, the schedule is barely nudging over the 182.5 hours needed to hit the first price break of 20%. And even then, the 20% discount is only applied to those hours above 182.5 hours. A welcome discount to be sure, but not very enormously impactful to the bottom line.

Another way our users keep these utilization hours low is by keeping their VM instances “always parked” and temporarily overriding the schedule for a set number of hours (such as for an 8-hour workday) when their non-production resources are needed. When the duration of the override expires, the instance is automatically shut down. Giving the best possible savings, and usually never even hitting the first GCP discount tier.

Do Google Sustained Use discounts save you money?

In short: definitely! At least, they do save you money over the price listed by Google. Do they save you the maximum amount of money possible? No, not if it’s a non-production VM instance that is only needed during a regular workday (although it’s close).

To get the optimal savings on your resources, keep them running only when you’re actually using them, and park them when you’re not. If you meet the threshold of 25% usage for the month, Google’s Sustained Use discounts will kick in, and further lower your cost from the list price. These two savings options combined will optimize your costs and provide the maximum savings.

Read more ›

How to: ChatOps Cloud Cost Control

The latest time-saving automation to add to your DevOps tool belt: ChatOps cloud cost control. That’s right – you may already be using ChatOps to make your life easier, but did you know that amongst the advantages, you can also use it to control your cloud resources?

Whatever communication platform you’re already using for chatting with your team members, you can use for chatting with your applications and services. And with the increasing rise of ChatOps, that brings us to one of the questions we’ve been getting asked more frequently by our DevOps users: how can I manage schedules and instances from Slack, Microsoft Teams, Atlassian Stride, and other chat programs?  

One of the cool things you can do using ChatOps is control your cloud resources through ParkMyCloud. Learn how it’s done in this quick YouTube demo:

ParkMyCloud has the ability to send messages to chat rooms via notifications and receive commands from chat bots via the API. This video details the Slackbot specifically, but similar bots can be used with Microsoft Teams or Atlassian Stride. There are multiple settings you can configure within Slack to manage your account, including notifications to let you know when a schedule is shutting an instance down. You can also set up the ability to override a schedule and turn the system on from Slack. Watch the video for a brief overview of how to:

  • Set up a notification that uses the Slack type
  • Adjust settings to be notified of user actions, parking actions, policy actions, and more
  • Set up the ParkMyCloud Slackbot to respond to notifications

Once you set up Slack with ParkMyCloud, you’ll be able to do anything you normally would in the UI or API, including snooze and toggle instances to override their schedules, receive notifications and be able to control your account directly from your Slack chat room. The Slackbot is available on our GitHub. Give it a try, and enjoy full ChatOps control of your cloud costs!

Read more ›

Cloud Computing Green Initiatives on the Rise

Over the past couple of months, we have seen a lot of articles about the Big Three cloud providers and their efforts to be environmentally friendly and make cloud computing green. What are Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) doing to make their IaaS services as green as possible? Does moving to the cloud help enterprises with their green initiatives and use of renewable energy?

It seems the cloud providers are focused on using renewable energy like solar and wind to power their massive data centers and are very actively touting that fact.

For example, Microsoft recently announced a new renewable energy initiative, the Sunseap project. This project, Microsoft’s first Asian clean energy deal, will install solar panels on hundreds of rooftops in Singapore, which they claim will generate 60MW to power Microsoft’s Singapore datacenter — making Microsoft Azure, Office 365 and numerous other cloud services. This deal is the third international clean energy announcement, following two wind deals announced in Ireland and The Netherlands in 2017. That’s pretty cool in my book, so kudos to them.

Google made a similar announcement recently, albeit a little more general, where they tout that Google is now buying enough renewable energy to match the power used in its data centers and offices. Google said that last year its total purchase of energy from sources including wind and solar exceeded the amount of electricity used by its operations around the world. According to a recent blog written by Google, they are the first public cloud, and company of their size, to have achieved that feat, so says Urs Hölzle, Google’s senior vice president of technical infrastructure. Now we can’t verify this but let’s take them at face value given the data in the chart below:

One observation we have in looking at this chart – where are IBM and Oracle? Once again, the Big Three always seem to be several steps ahead.

Speaking of, we’ve looked at Microsoft and Google, what about AWS? According to AWS’s self-reports, it seems that they are behind both Google and Microsoft in terms of relying 100% on renewable energy. AWS states a long-term commitment to achieve 100% renewable energy usage for their global infrastructure footprint, and had set a goal to be powered by 50% renewable energy by the end of 2017 (we could not find a recent 2018 update).

Moving to the cloud has many benefits – time to market, agility, innovation, lower upfront cost, and the commitment to renewable energy.! There’s one other way for cloud computing to be more sustainable – and that’s by all of us using fewer resources. In our small little way, ParkMyCloud helps – we help you turn cloud stuff off when its not being used, kind of like following your kids around the house and shutting off the lights, your at-home green initiative – you know you can automate that using Nest, right? Saving money in the process? That’s a win-win.

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