Cloud Container Services Comparison

Cloud Container Services Comparison

There’s no doubt that cloud container services adoption is on the rise. A recent survey found that more than 80% of IT professionals and teams reported deploying container technologies — up from 58% in 2017.

With this rise in adoption comes a rise of options in the market, so it quickly becomes difficult to keep track of each service and what they’re best used for. We took a look at 14 container services and container-like services associated with the top cloud providers, and broke down the main use case for each. Scroll to the bottom for a comparison chart.

AWS Cloud Container Services

Amazon Elastic Container Service

Amazon Elastic Container Service (Amazon ECS) is a container orchestration service, used to manage and deploy containers distributed across many AWS virtual machines. Combined with AWS Fargate, it allows you to run containers without selecting servers. Pricing depends on the launch model: for the Fargate model, you pay for vCPU and memory that your containerized application requests. For the EC2 model, you simply pay for the EC2 instances and other resources – such as EBS volumes – you create to store and run your application.

Amazon Elastic Container Registry

Amazon Elastic Container Registry (Amazon ECR) is AWS’s managed solution to store, manage, and deploy Docker container images. It is highly available, scalable, and integrated with Amazon ECS. Payment is based on the amount of data stored in repositories and data transferred to the Internet.

Amazon Elastic Container Service for Kubernetes

Amazon Elastic Container Service for Kubernetes (Amazon EKS) is AWS’s service to manage and deploy containers via Kubernetes container orchestration service. Pricing is $0.20 per hour for each EKS cluster, as well as the cost of AWS resources such as EC2 instances that you create to run your Kubernetes worker nodes.

AWS Fargate

AWS Fargate is a solution for Amazon ECS that allows you to run containers without managing servers or infrastructure, making it easier to focus on applications rather than the infrastructure that runs them. Pricing is based on the vCPU and memory resources used.

AWS Batch

AWS Batch is a way for AWS users to run large quantities of batch computing jobs — which is done by executing them as Docker containers. You pay only for the AWS resources you use to create to store and run your application, with no additional fees.

Azure Cloud Container Services

Azure Kubernetes Service

Azure Kubernetes Service (AKS) is Azure’s fully managed solution to manage & deploy containers via Kubernetes container orchestration service. You pay only for the VMs, storage, and networking resources used for the Kubernetes cluster, with no additional charge.

Azure Container Registry

Azure Container Registry is a way to store and manage container images for container deployment a

cross DC/OS, Docker Swarm, Kubernetes, and Azure services including App Service, Batch, and Service Fabric. Pricing is per day, with several tiers depending on the amount of storage and web hooks needed.

Azure Container Instances

Azure Container Instances (ACI) is a service that allows you to run containers on Azure without managing servers or infrastructure, making it simpler to build applications without focusing on infrastructure. Billing is by “container groups” which are assignments of vCPU and memory resources for your running containers, and is on a per-second basis.

Azure Batch

Azure Batch is a service for running a large number of competitive compute jobs, which users can choose to can run directly on virtual machines or on Docker-compatible containers. You pay only for the compute and other resources used to run the batch jobs, with no additional fees for using Batch.

Azure App Service

Azure App Service is a way to create cloud-based web apps and APIs, which similarly to Azure Batch, has options for running on virtual machines or in containers. Billing is per hour, with several tiers depending on your needs for disk space, number of instances, auto scaling, and network isolation.

Azure Service Fabric

Azure Services Fabric is a way to lift, shift, and modernize .NET applications to microservices using Windows Server containers. Service Fabric is an open source project that powers core Azure infrastructure and other Microsoft services include Skype for Business, Azure SQL Databases, Cortana and more. You pay for compute, volumes, and collections used, though the complicated pricing model makes it hard to estimate.

Google Cloud Container Services

Google Kubernetes Engine

Google Kubernetes Engine (GKE) is Google Cloud’s fully managed solution to manage and deploy containers via Kubernetes container orchestration service. You pay for the Google Compute Engine instances used, with no additional charges.

Google Container Registry

Google Container Registry allows users to store and manage Docker container images for container deployment. You pay for the storage and network used by your Docker resources.

Google App Engine Flexible Environment

Google App Engine Flexible Environment is a platform for deploying web apps and APIs, which you can do on VM instances or on Docker containers. Pricing is based on the compute, storage, and other resources used for the apps

Cloud Container Services Comparison Chart

For quick and easy reference, we’ve condensed this comparison into a chart:

It’s a great time to become familiar with the various cloud container services and try them out — this infrastructure model will only become more prominent!

How to Use an AWS EDP for Discounted Cloud Resources

How to Use an AWS EDP for Discounted Cloud Resources

Lately, many of our AWS customers (especially those purchasing through the AWS marketplace) have mentioned that they are using an AWS EDP, which stands for Amazon Web Services Enterprise Discount Program. Essentially, this is AWS’s way to provide enterprises a discount off its services based on a volume (consumption) commitment.

How does an AWS EDP work?

A simple application of an AWS EDP would work as follows: for the next 3 years, you commit to spend $5MM on AWS services, and receive a 13% discount. Even if you don’t spend $5MM you still owe them $5MM, and of course if you go over you would get billed for the overage.

AWS’s website does not provide a lot of information about these agreements. Here’s what they say:  “Customers also have the option to enroll in an Enterprise Agreement with AWS. Enterprise Agreements give customers the option to tailor agreements that best suit their needs. For additional information on Enterprise Agreements please contact your sales representative.”

What Other Agreements Compare to an AWS EDP?

Going back to my days at IBM, we used to generally referred to discount contracts as Enterprise License Agreements (ELAs). An ELA is a software site license that is sold to a large enterprises. It typically allows for unlimited use of a single or multiple software products throughout the organization, although there were often some restrictions and limitations. During my time at IBM, these were sold upfront for a set dollar amount and term, generally 3 to 5 years and usually had a cap on usage, so at some point overages could kick in – which would help with the renegotiation, of course.

Other terms used with a similar concept include Site License, Enterprise Agreement (this is a common Microsoft term – EA), Volume Purchase Agreement (VPA) and All You Can Eat (AYCE). What all of these have in common is that the vendor gets a large revenue/spend commit, and the enterprise gets discounting and flexibility.

How Else can you Get Discounts on AWS?

AWS does provide enterprises with multiple ways to consume its services based on their business needs and get volume discounts. Traditional on-demand instances allow you to pay for capacity by the hour without any long-term commitments or upfront payments.. Reserved instances are ideal for applications with steady-state or predictable usage and can provide up to a 75% discount compared to on-demand pricing. And of course they promote scale groups, spot instances, and other optimization efforts to reduce spend and waste but those are more cost control opportunities then they are discounts. Plus, you can always wait for better pricing.

Should You Use an AWS EDP?

Before committing to an AWS EDP, ensure that your organization will consume the amount of resources you are committing too. Keep in mind that this can also include the AWS Marketplace. The third party solutions you can buy on the AWS Marketplace also count against your AWS EDP, and leverage that discount structure — so before completing a third-party transaction, make sure you check the Marketplace to see if the cloud solution you buy is listed there.

 

Should You Use the Cloud-Native Instance Scheduler Tools?

Should You Use the Cloud-Native Instance Scheduler Tools?

When adopting or optimizing your public cloud use, it’s important to eliminate wasted spend from idle resources – which is why you need to include an instance scheduler in your plan. An instance scheduler ensures that non-production resources – those used for development, staging, testing, and QA – are stopped when they’re not being used, so you aren’t charged for compute time you’re not actually using.

AWS, Azure, and Google Cloud each offer an instance scheduler option. Will these fit your needs – or will you need something more robust? Let’s take a look at the offerings and see the benefits and drawbacks of each.

AWS Instance Scheduler

AWS has a solution called the AWS Instance Scheduler. AWS provides a CloudFormation template that deploys all the infrastructure needed to schedule EC2 and RDS instances. This infrastructure includes DynamoDB tables, Lambda functions, and CloudWatch alarms and metrics, and relies on tagging of instances to shut down and turn on the resources.

The AWS Instance scheduler is fairly robust in that it allows you to have multiple schedules, override those schedules, connect to other AWS accounts, temporarily resize instances, and manage both EC2 instances and RDS databases.  However, that management is done exclusively through editing DynamoDB table entries, which is not the most user-friendly experience. All of those settings in DynamoDB are applied via instance tags, which is good if your organization is tag-savvy, but can be a problem if not all users have access to change tags.

If you will have multiple users adding and updating schedules, the Instance Scheduler does not provide good auditing or multi-user capabilities. You’ll want to strongly consider an alternative.

Microsoft Azure Automation

Microsoft has a feature called Azure Automation, which includes multiple solutions for VM management. One of those solutions is “Start/Stop VMs during off-hours”, which deploys runbooks, schedules, and log analytics in your Azure subscription for managing instances. Configuration is done in the runbook parameters and variables, and email notifications can be sent for each schedule.

This solution steps you through the setup for timing of start and stop, along with email configuration and the target VMs. However, multiple schedules require multiple deployments of the solution, and connecting to additional Azure subscriptions requires even more deployments. They do include the ability to order or sequence your start/stop, which can be very helpful for multi-component applications, but there’s no option for temporary overrides and no UI for self-service management. One really nice feature is the ability to recognize when instances are idle, and automatically stop them after a set time period, which the other tools don’t provide.

Google Cloud Scheduler

Google also has packaged some of their Cloud components together into a Google Cloud Scheduler. This includes usage of Google Cloud Functions for running the scripts, Google Cloud Pub/Sub messages for driving the actions, and Google Cloud Scheduler Jobs to actually kick-off the start and stop for the VMs. Unlike AWS and Azure, this requires individual setup (instead of being packaged into a deployment), but the documentation takes you step-by-step through the process.

Google Cloud Scheduler relies on instance names instead of tags by default, though the functions are all made available for you to modify as you need. The settings are all built in to those functions, which makes updating or modifying much more complicated than the other services. There’s also no real UI available, and the out-of-the-box experience is fairly limited in scope.

Cloud Native or Third Party?

Each of the instance scheduler tools provided by the cloud providers has a few limitations. One possible dealbreaker is that none of these tools are multi-cloud capable, so if your organization uses multiple public clouds then you may need to go for a third-party tool. They also don’t provide a self-service UI, built-in RBAC capabilities, Single Sign-On, or reporting capabilities. When it comes to cost, all of these tools are “free”, but you end up paying for the deployed infrastructure and services that are used, so the cost can be very hard to pin down.

We built ParkMyCloud to solve the instance scheduler problem (now with rightsizing too). Here’s how the functionality stacks up against the cloud-native options:

 

AWS Instance Scheduler Microsoft Azure Automation Google Cloud Scheduler ParkMyCloud
Virtual Machine scheduling
Database scheduling
Scale Set scheduling
Tag-based scheduling
Usage-based recommendations
Simple UI
Resize instances
Override Schedules
Reporting
Start/Stop notifications
Multi-Account
Multi-Cloud

Overall, the cloud-native instance scheduler tools can help you get started on your cost-saving journey, but may not fulfill your longer-term requirements due to their limitations.

Try ParkMyCloud with a free trial — we think you’ll find that it meets your needs in the long run.  

Best Cloud Blogs of the Year: Top Posts from ParkMyCloud

Best Cloud Blogs of the Year: Top Posts from ParkMyCloud

As we wrap up 2018, we’ve taken a moment to reflect back on the best cloud blogs of 2018 – at least, the best posts on our own blog. We’ve created two categories for comparison: the Readers’ Choice – those you all have viewed the most – and our own favorite posts.

Readers’ Choice

These were the top 5 most viewed posts on the ParkMyCloud blog this year, and have been widely read and circulated:

  1. AWS vs Azure vs Google Cloud Market Share 2018: Is AWS Still in the Lead? After Q1 earnings reports came in, the numbers showed the AWS remained in the lead despite tough competition from Microsoft Azure, Google Cloud Platform, and Alibaba Cloud.
  2. AWS vs Alibaba Cloud Pricing: A Comparison of Compute Options. More cloud users are starting to investigate Alibaba Cloud – the #4 public cloud provider by revenue – so we created this comparison of AWS vs Alibaba Cloud pricing.
  3. EC2 Instance Types Comparison (and how to remember them). AWS offers a range of EC2 instance types optimized for various purposes – which are a great resource, but can be overwhelming for beginners. This blog contains both an at-a-glance comparison table, as well as a video overview.
  4. How to Keep Costs in Check After Converting a Monolith to Microservices. After turning a  monolith to microservices, many organizations expect infrastructure costs to go down – but find exactly the opposite. Here are a few strategies to keeping microservices costs in control.
  5. How to Use Google Preemptible VMs to Get 80% Savings. Google Cloud’s Preemptible VM option offers a significant discount on the price of compute, as long as you’re willing to use VMs that will run for 24 hours or less. Here are a few use cases and a brief guide to get started.

Editor’s Choice

While not the most viewed posts on the blog, these posts are all great reads that look at various aspects of cloud services and costs. In no particular order:

  • $12.9 Billion in wasted cloud spend this year. Wasted cloud spend is a huge drain on organizational resources – and one that is mostly preventable. This post looks at the causes of that waste. Expect an updated version of this analysis for 2019!
  • 7 Ways Cloud Services Pricing is Confusing. If you’ve ever been confused by the bill or pricing charts you’ve seen from cloud service providers, you’re not alone. From terminology to visibility, there are a lot of factors that make the question “what will this cost me?” more complicated than it seems on the surface.
  • The Cost of Cloud Computing Is, in Fact, Dropping Dramatically. A popular blog post made the rounds early last year claiming that the cost of cloud was not dropping. We dug into the numbers and found that – yes, actually – it is.
  • Do Google Sustained Use Discounts Really Save You Money? 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. We ran some analyses to show whether they save you money – and how much they save compared to other operating options.
  • 10,000 Years of Data Says Your Server Sizing is Wrong. As ParkMyCloud expands our cost optimization focus to include rightsizing, we have been working on some reports to see how big of a problem “wrong” sizing actually is. As it turns out, it’s a pretty big problem.

Thanks for making ParkMyCloud one of your own favorites for best cloud blogs in 2018! What type of content would you like to see more of in 2019? Let us know in the comments below!

Resisting Amazon – Why Retailers Choose AWS Alternatives

Resisting Amazon – Why Retailers Choose AWS Alternatives

Although Amazon dominates the market share of cloud services, there’s been a trend among retailers to choose AWS alternatives. Big-name retailers, in verticals from clothing to electronics, are moving away from maintaining their own data centers in favor of the public cloud’s agility and better access to customers worldwide. To highlight a few:

Gap

Gap Inc. signed a five-year contract with Microsoft, choosing Azure as their primary cloud provider. Employees will also be using Microsoft 365 tools and the Enterprise Mobility and Security suite. They chose Azure to support their e-commerce operations, inventory, and workforce systems.

Gap chose Azure among AWS alternatives because they wanted “a partner that is not going to be a competitor […] in any other parts of their businesses,” as told by Shelley Bransten, corporate VP for global retail and consumer goods at Microsoft.

Walmart

Walmart teamed up with Microsoft on a five-year contract back in July. The partnership, promising to “further accelerate digital innovation in retail,” was a natural fit since Microsoft was already partnered with Walmart, handling significant workloads, apps, and teaming up their engineers.

Furthermore, in a move directly targeting Amazon, Walmart has asked their tech vendors to choose AWS alternatives. Wal-Mart spokesman Dan Toporek told CNBC: “Our vendors have the choice of using any cloud provider that meets their needs and their customers’ needs. It shouldn’t be a big surprise that there are cases in which we’d prefer our most sensitive data isn’t sitting on a competitor’s platform.”

Kroger

Supermarket and retail giant Kroger took a multi-cloud approach, first with Pivotal and Microsoft, and later adding on Google Cloud in 2017. In a CNBC interview, Chris Hjelm, Kroger’s chief information officer, explains why the retailer spends millions of dollars on Microsoft and Google in order to avoid AWS: “For obvious reasons competitively, it doesn’t make sense for us to do a ton to help grow that business for them.”

Target

Target, another retail competitor of Amazon, decided to stop financing its rival in mid-2017 and began dropping down their use of AWS. Microsoft, Google, and Oracle all pushed for their business as discussions were kept quiet, with a Target spokesperson only admitting that they use multiple clouds. Earlier this year, Google CEO Sundar Pichai confirmed Target as a big cloud customer.  

And the list goes on…

In addition to the rest, Spotify, eBay, Best Buy, and LL.Bean all turned to Google to meet their cloud needs. One by one, big retailers with recognized names are choosing Microsoft and Google in favor of Amazon.

Why Retailers Choose AWS Alternatives

Cloud migration requires a massive haul of data, costs, and time from a business. Not only is there a lot to consider in terms of pricing, services, and overall offerings, but there are also certain needs unique to a specific industry. Big retailers turning away from AWS and onto other cloud providers highlights an issue for Amazon as a competitor in the retail industry, providing opportunities for other providers like Microsoft and Google to secure enterprise deals.

Meanwhile, not everyone has chosen AWS alternatives. Amazon still holds the market lead and continues to retain a footprint in the retail industry with customers including Nordstrom, Nike, Under Armour, and Lululemon. So while sources suggest that more retailers are looking for other options outside of AWS, time will tell if Amazon can hold its spot among retailers.

Can Custom Machine Types Improve Your Life?

Can Custom Machine Types Improve Your Life?

Today we’re going to look at an interesting trend we are seeing toward the use of custom machine types in Google Cloud Platform. One of the interesting byproducts of managing the ParkMyCloud platform is that we get to see changes and trends in cloud usage in real time. Since we’re directly at the customer level, we can often see these changes before they are spotted by official cloud industry commentators. They start off as small signals in the noise, but practice has allowed us to see when something is shifting and a trend is emerging – as is the case with these custom machine types.

Over the last year, the shift to greater use of Custom Machine Types (launched in 2016 on Google Compute Engine) and to a lesser extent Optimized EC2 instances (launched in 2018 on AWS) are just such a signal that we have observed growing in strength. Interestingly, Microsoft has yet to offer their equivalent version on Azure.

What do GCE custom machine types let you do?

Custom machine types let you build a bespoke instance to match the specific needs of your workload. Many workloads can be matched to off-the-shelf instance types, but there are many workloads for which it is now possible to build a better matching machine which delivers a more cost effective price. The growth in adoption of this particular instance type supports the case and likely benefits of their availability.

So what are the benefits of these new customized machines? First, they provide a granular level of control to match the needs of your specific application workloads. In practice, this leads to compromise as you select the closest instance type to your optimal configuration. Such compromises typically lead to over-provisioning, a situation we see across the board among our customer base. We analyzed usage of the instances in our platform this summer, and found that across all the instances in our platform, the average vCPU utilization was less than 10%!

Secondly, they allow you to finely tune your machine to maximize the cost effectiveness of your infrastructure. Google claims savings of up to 50% when utilizing their customized options compared to traditional predefined instances, which we believe to be a reasonable assessment as we see the standard instance types are often massively overprovisioned.

On GCE, the variables that you can configure include:

  • Quantity and type of vCPU’s;
  • Quantity and type of GPU;
  • Memory size (albeit there are some limits on the maximum per vCPU).

Sustained Use Discounts and Preemptible VM Discounts are also available for these customized instances on GCE which also make this an attractive option.

On AWS, customized options are currently more limited and include only the number and type of vCPU’s, and the options are focused on per-core licensed software problems, rather than cost optimization. It will be interesting if they follow Google and open up cost-based customization options in the coming months, and allow the effective unbundling of fixed off-the-shelf instance types.

Should you use custom machine types?

So just because customization is an option, is this something you should actually pursue? In fact, you will pay a small premium compared to the size of standard instances/VMs, albeit you can optimize for specific workloads, which oftentimes will mean an overall lower cost. To make such an assessment will require that you examine your applications resource use and performance requirements. Such determinations require that you carefully analyze your infrastructure utilization data. This quickly gets complex, although there are a number of platforms which can support thorough analytics and data visualization. Ideally such analytics would be combined with the ability to recommend specific cost-effective customized instance configurations as well as automate their provisioning.

Watch this space for more news on custom machine types!