On our first day as Turbonomic employees, our team had some great discussions with CTO Charles Crouchman about Turbonomic, ParkMyCloud, and the market for infrastructure automation tools. Charles explained his vision of the future of infrastructure automation, which parallels the automation trajectory that cars and other vehicles have been following for decades. It’s a comparison that’s useful in order to understand the goals of fully-automated cloud infrastructure – and the mindset of cloud users adopting this paradigm. (And of course, given our name, we’re all in on driving analogies!)
The Five Levels of Vehicle Autonomy
The idea of the five levels of vehicle autonomy – or six, if you include level 0 – is an idea that comes from the Society of Automotive Engineers.
The levels are as follows:
Level 0 – No Automation. The driver performs all driving tasks with no tools or assistance.
Level 1 – Driver Assistance.The vehicle is controlled by the driver, but the vehicle may have driver-assist features such as cruise control or an automated emergency brake.
Level 2 – Partial Automation or Occasional Self-Driving. The driver must remain in control and engaged in driving and monitoring, but the vehicle has combined automated functions such as acceleration and steering/lane position.
Level 3 – Conditional Automation or Limited Self-Driving. The driver is a necessity, but not required to monitor the environment. The vehicle monitors the road and traffic, and informs the driver when he or she must take control.
Level 4 – High Automation or Full Self-Driving Under Certain Conditions. The vehicle is capable of driving under certain conditions, such as urban ride-sharing, and the driver may have the option to control the vehicle. This is where airplanes are today – for the most part, they can fly themselves, but there’s always a human pilot present.
Level 5 – Full Automation or Full Self-Driving Under All Conditions. The vehicle can drive without a human driver or occupants under all conditions. This is an ideal, but right now, neither the technology nor the people are ready for this level of automation.
How These Levels Apply to Infrastructure Automation Tools
Now let’s take a look at how these levels apply to infrastructure automation tools and infrastructure:
Level 0 – No Automation. No tools in place.
Level 1 – Driver Assistance.Some level of script-based automation with limited applications, such as scripting the installation of an application so it’s just one user command, instead of hand-installing it.
Level 2 – Partial Automation or Occasional Self-Driving. In cloud infrastructure, this translates to having a monitoring system in place that can alert you to potential issues, but cannot take action to resolve those issues.
Level 3 – Conditional Automation or Limited Self-Driving. Think of this as traditional incident resolution or traditional orchestration. You can build specific automations to handle specific use cases, such as opening a ticket in a service desk, but you have to know what the event trigger is in order to automate a response.
Level 4 – High Automation or Full Self-Driving Under Certain Conditions.This is the step where analytics are integrated. A level-4 automated infrastructure system uses analytics to decide what to do. A human can monitor this, but is not needed to take action.
Level 5 – Full Automation or Full Self-Driving Under All Conditions. Full automation. Like in the case of vehicles, both the technology and the people are a long way from this nirvana.
So where are most cloud users in the process right now? There are cloud users and organizations all over this spectrum, which makes sense when you think about vehicle automation: there are early adopters who are perfectly willing to buy a Tesla, turn on auto-pilot, and let the car drive them to their destination. But, there are also plenty of laggards who are not ready to take their hands off the wheel, or even turn on cruise control.
Most public cloud users have at least elements of levels 1 and 2 via scripts and monitoring solutions. Many are at level 3, and with the most advanced platforms, organizations reach level 4. However, there is a barrier between levels 4 and 5: you will need an integrated hardware/software solution. The companies that are closest to full automation are the hyperscale cloud companies like Netflix, Facebook, and Google who have basically built their own proprietary stack including the hardware. This is where Kubernetes comes from and things like Netflix Scryer.
In our conversation, Charles said: “The thing getting in the way is heterogeneity, which is to say, most customers buy their hardware from one vendor, application software from another company, storage from another, cloud capacity from another, layer third-party software applications in there, use different development tools –– and none of these things were effectively built to be automated. So right now, automation needs to happen from outside the system, with adaptors into the systems. To get to level 5, the automation needs to be baked in from the system software through the application all the way up the stack.”
What Defines Early Adopters of Infrastructure Automation Tools
While there’s a wide scale of adoption in the market right now, there are a few indicators that can predict whether an organization or an individual will be open to infrastructure automation tools.
The first is a DevOps approach. If an organization using DevOps, they have already agreed to let software automate deployments, which means they’re accepting of automation in general – and likely to be open to more.
Another is whether resource management is centralized within the organization or not. If it is centralized, the team or department doing the management tends to be more open to automation and software solutions. If ownership is distributed throughout the organization, it’s naturally more difficult to make unified change.
Ultimately, the goal we should all be striving for is to use infrastructure automation tools to step up the levels of automated resource configuration and cost control. Through automation, we can reduce management time and room for human error to achieve optimized environments.
In today’s entry in our exploration of container services, we’ll look at Azure Kubernetes Service (AKS). Azure AKS manages your hosted Kubernetes environment, making it simple to deploy and manage containerized applications without container orchestration expertise, divesting much of that responsibility to Azure – much like EKS and GKE do for AWS and Google Cloud. Critical tasks like health monitoring of ongoing operations and maintenance by provisioning, upgrading, and scaling resources on demand are handled by Azure.
Azure AKS Overview
Azure AKS is, as of this writing, just over a year old, released for general availability in June 2018. With AKS, you can deploy, scale, and manage Docker containers and applications. Azure AKS gives developers greater flexibility, automation and reduced management overhead for administrators and developers. This is because it’s a managed service, which takes some of the management burden off the user.
As applications grow to span multiple containers deployed across multiple servers, operating them becomes more complex. To manage this complexity, Azure AKS provides an open source API to deploy, scale and manage Docker containers and container-based applications across a cluster of container hosts.
Use cases for AKS include:
Easily migrating existing applications to Kubernetes
Simplifying the deployment and management of microservices based applications
Easily integrated DevSecOps
IoT device deployment and management on demand
Machine Learning model training with AKS
If AKS is free, what do you pay for?
Yes, Azure AKS is a free service since there is no charge for managing Kubernetes clusters. However, you pay for the VM instances, storage and networking resources consumed by your Kubernetes cluster. These should be managed like any other cloud resources, with attention paid to potential areas of waste.
AKS vs. ACS
Microsoft’s experience with cluster orchestration began with Azure Container Service back in 2017, which supported Kubernetes, Docker Swarm and Mesosphere’s DC/OS. It was the simplest most open and flexible way to run container applications in the cloud then, and now followed by Azure Kubernetes Services (AKS), which was made generally available in 2018.
ACS users who run on Kubernetes can possibly migrate to AKS, but migration should be planned and reviewed for it to be successful as there are many key areas in which they are different. If considering migration, check out Azure’s guide to migrating from ACS to AKS here.
Should you use Azure AKS?
Chances are, you’re locked into a cloud provider – or have a preferred cloud provider – already, so you’re likely to use the container management service offered on your provider of choice. If you’re on Azure, AKS will be the natural choice as you increase use of microservices and app portability with containers.
Google Cloud recently released a new pricing option: Google Cloud capacity reservations. This new option intended for users with anticipated spikes in usage, such as over holidays or planned backups. It also expanded its Committed Use discount program to apply to more types of resources.
Manish Dalwadi, product manager for Compute Engine, said in Google’s announcement of these releases, “you shouldn’t need an advanced degree in finance to get the most out of your cloud investment.”
We’ve noted Google Cloud’s positioning as “best in customer-first pricing” in previous articles on Sustained Use Discounts and Resource-Based Pricing. However, the new options – particularly capacity reservations – may not be the best example of this.
How Google Cloud Capacity Reservations Work
Google Cloud capacity reservations are a bit different from options we see at the other major cloud providers. They are not a cost-savings plan like the AWS and Azure’s “reserved instance” programs that allow users to pay upfront for lower prices. Instead, they actually reserve capacity, to ensure it’s available when you need it. Use cases include holiday/Black Friday demand, planned organic growth, and backup/disaster recovery.
VMs you have reserved in advance will be billed at the same rate as on-demand. However, other discounts may apply. As you consume reserved VMs, you’ll also get the benefit of any applicable Sustained and Committed Use discounts.
One potential issue is that once you make a reservation, you will continue to consume and be charged for the resources until the reservation expires or you delete it. By default, any instance that matches the reservation configuration will be allocated against the reservation. On the one hand, this can prevent you from having to pay for reserved capacity above what you are using, but this may actually defeat your purpose of trying to have additional guaranteed capacity available. To guarantee the extra capacity for a specific instance even if it is stopped (or “parked” as we like to say), you will need to explicitly set an option when the instance is created. Note that you will still be paying for the reservation if you do not have any running instances that match the reservation.
Another caveat is that “a VM instance can only use a reservation if its properties exactly match the properties of the reservation.“ In other words, you cannot buy a bunch of small reservations and expect that they can be combined into a big reservation, like you can do with certain types of reserved instances from the other cloud providers. This is consistent with the idea of a capacity reservation, rather than a discount program, and is worth keeping in mind.
This is a new avenue for customers to easily commit themselves to spending on resources they may not actually need, so we encourage you to evaluate carefully before reserving capacity and to keep a close watch on your monthly bill and review the cloud waste checklist.
More Committed Use Discounts
Alongside the capacity reservations, Google also announced an expansion of Committed Use Discounts to include GPUs, Cloud TPU Pods, and local SSDs.
Ultimately, Google Cloud pricing fares well on measures of user-friendliness and options for cost savings, but we question if the reserved capacity changes will do anything to improve the readability of the bill. On the other hand, the expansion of Committed Use discounts does provide more savings-in-hand options for customers.
Take a few minutes to ensure you’re not oversizing or spending money on resources that should be turned off, and you’ll be well on your way to an optimized Google Cloud bill.
As applications and systems have evolved from single-host mainframes to distributed microservices architectures, infrastructure automation has become a key part of the toolkit for modern sysadmins and operations teams. This automation has gone from doing basic Operating System installation and setup to full-blown multi-step deployments of production code from a single developer’s commit. By automating these mundane processes and eliminating the human error, production systems have a much higher stability than ever before.
But why stop at automating deployments? There are other elements that need to be automated, too –– one of which is cost.
Rolling out new infrastructure over and over again without ever taking a step back to analyze the cost just leads to the panic-driven cloud-bill-based phone calls from your finance department. Instead, taking similar automation decisions as Puppet, Chef, Ansible, Terraform, or Jenkins and applying them to your cloud costs can help you incrementally save money so you never have that giant surprise bill.
Scaling Up Without Ever Spinning Down
Developers and operations teams often use infrastructure automation early in application development and deployment processes to get servers and databases deployed and functioning. Modern automation tools aren’t just powerful, but also quick to deploy and fit into your current workflow. This is fantastic, but the problem is that the automation effort can start to taper off once the environments are running. Too often, users and teams move on to the next project before figuring out a way to keep costs from getting out of control. Then it becomes too late, and they simply accept that money needs to be dumped into the deployment pipeline to keep everything on task.
Easy-to-use automation is the key to spinning these environments up efficiently, and can also be key for keeping the costs of these environments low. Sure, you may need to keep the production systems scaled up for maximum application performance and customer satisfaction, but what about the test lab, sandbox environment, dev systems, UAT servers, QA deployments, staging hosts, and other pre-production workloads? Having giant environments with system sizes that match production can be useful for some testing, but leaving it all running can be easily doubling your cloud costs for each environment like this that you have, for things that are used for a fraction of the time.
As your infrastructure automation toolkit grows and evolves, there’s a few things that you’ll start building in to all of your applications and deployments:
As this list grows, there’s one more thing you need: Continuous Cost Control.
By building in cost control automation from the very beginning, you can keep your cloud costs low while maintaining the flexibility required to keep up the pace of innovation. Without this, your costs are destined to rise faster than you intended, and is only going to cause headaches (and endless meetings) for your future self. It may not be coming out of your bank account directly, but saving money at an enterprise organization is everyone’s job, and automating this is the key.
And that’s actually what thousands of customers around the world are using ParkMyCloud for today! Get started with continuous cost control today.
Trends in cloud jobs can be overall indicators into trends in the cloud computing space. With an ever-evolving and increasing use of cloud services, new and important changes are needed to the skillsets, roles, and responsibilities of cloud professionals. Here are some trends we’re seeing.
The Cloud Job Market is on the Rise
There is exponential growth in the cloud computing industry, so it’s no surprise that the demand for cloud computing intellect and skills is also increasing, with no slowing down in the foreseeable future. According to Gartner TalentNeuron, an online real-time labor market insight portal, “there are about 50,248 cloud computing positions available in the U.S. from 3,701 employers, and 101,913 open positions worldwide.”
As more and more enterprises drive value from container platforms, infrastructure-as-code solutions, software-defined networking, storage, continuous integration/delivery, and AI, they need people and skills on board with ever more niche expertise and deep technological understanding. Anecdotally, many organizations we talk to share that getting and keeping talent on board is a challenge as they seek to evolve their use of cloud services. The cloud jobs that are available in the market today are a result of employer demand to drive innovation and are paramount for new business applications and services to the end-user.
Cloud Talent Demand Trends
Here are a few roles and talent areas that will see increased demand this year.
Cloud Architects are experts responsible for the supervision of a company’s cloud computing system, overseeing the organization’s cloud computing strategy through deployment, management, and support of cloud applications. A Cloud Architect has a strong background in networking, programming, multiple operating systems, and security. In addition, they also have a strong knowledge of cloud services such as AWS, Google or Azure, with experience on ITSM, I&O, governance, automation, and vendor management. Here at ParkMyCloud, we talk to a lot of Cloud Architects!
Cloud consultants are “the experts” who can help an organization conduct an overall technical analysis and assessment of the enterprise and recommend suitable cloud technology options to promote productivity and efficiency. A Cloud Consultant’s education background includes IT or business administration, IT consulting experience and highly effective communication skills. A Cloud Consultant’s expert knowledge of cloud service providers and cloud technologies available is key to provide maximum value to an enterprise.
You may find of interest, cloud computing careers relatable to Cloud Consultants include Cloud Security Engineers, Cloud Operations Engineers, and Cloud Infrastructure Engineers. An educational path to becoming a Cloud Consultant ranges from studying different programming languages to getting certified – although not necessarily required – in a single or multi-cloud computing systems.
Business Intelligence Analyst
A BI analyst has strong skills in database technology, analytics, and reporting tools and excellent knowledge and understanding of computer science, information systems or engineering. Skills necessary to understand a company’s cloud needs through data interpretation and be able to collate and cogently communicate cloud-based services and cloud strategy solutions to drive actionable results. An important role in the cloud management of businesses as demand for data and data analysts increases. BI analyst will collaborate with many individuals in the IT department in an organization to maximize proficiency and productivity.
BI Analyst can also be described as BI Developers, BI Managers, and Big Data Engineer or Data Scientist. To work in BI, you do not need to be certified, but it may help you get an advantage when considered for a job, with certifications like Certified Business Intelligence Professional and Certified Application Associate: Business Intelligence.
An internet of things (IoT) engineer is an IT professional who is an expert in at least one or more of the core IoT disciplines: devices, connectivity, edge and cloud analytics, enterprise integration, platforms, and development and DevOps. Job titles for IoT engineers in the industry depend on the discipline they focus on, for example, the can be called IoT Architect, IoT Data Scientist or IoT Hardware Engineer, but all have in common an in-depth knowledge in specific subject matters of IoT in comparison to other engineers, making them the right person when it comes to decision making regarding the specific IoT subject matter. The main responsibility of IoT engineers is to help businesses keep up with IoT technology trends.
According to Gartner, “By 2022, 80% of leading I&O organizations will devise I&O strategies for digital business initiatives such as artificial intelligence and IoT.” And, if you have any doubt that this is important in the cloud space, just see how many of AWS’s new services this year are IoT-focused.
Cloud computing growth continues to accelerate at unprecedented rates as businesses continue to invest in cloud services like SaaS, PaaS, and IaaS. The adoption of cloud technology platforms, empowers businesses with unlimited possibilities for innovation, but in order to stay at pace with this innovation and the dizzying array of services being offered by Amazon, Microsoft, Google, IBM all businesses will need skilled resources offering cloud computing professionals a very promising career in the cloud industry for years to come.
What trends are you seeing? Let us know in the comments below.
Among the many ways to purchase and consume Azure resources are Azure low priority VMs. These virtual machines are compute instances allocated from spare capacity, offered at a highly discounted rate compared to “on demand” VMs. This means they can be a great option for cost savings – for the right workloads. And we love cost savings! Here’s what you need to know about this purchasing option.
How Azure Low Priority VMs Work
The great part about these virtual machines is the price: it’s quite attractive with a fixed discount of 60-80% compared to on-demand. The “low priority” part means that these VMs can be “evicted” for higher priority jobs, which makes them suitable for fault-tolerant applications such as batch processing, rendering, testing, some dev/test workloads, containerized applications, etc.
Low priority VMs are available through Azure Batch and VM scale sets. Through Azure Batch, you can run jobs and tasks across compute pools called “batch pools”. Since batch jobs consist of discrete tasks run using multiple VMs, they are a good fit to take advantage of low priority VMs.
On the other hand, VM scale sets scale up to meet demand, and when used with low priority VMs, will only allocate when capacity is available. To deploy low priority VMs on scale sets, you can use the Azure portal, Azure CLI, Azure PowerShell, or Azure Resource Manager templates.
When it comes to eviction, you have two policy options to choose between:
Stop/Deallocate (default) – when evicted, the VM is deallocated, but you keep (and pay for) underlying disks. This is ideal for cases where the state is stored on disks.
Delete – when evicted, the VM and underlying disks are deleted. This is the recommended option for auto scaling because deallocated instances are counted against your capacity count on the scale set.
Azure Low Priority VMs vs. AWS Spot Instances
So are low priority VMs the same as AWS Spot Instances? In some ways, yes: both options allow you to purchase excess capacity at a discounted rate.
However, there are a few key differences between these options:
Fixed vs. variable pricing – AWS spot instances have variable pricing while Azure low priority VMs have a fixed price as listed on the website
Integration & flexibility – AWS’s offering is better integrated into their general environment, while Azure offers limited options for low priority VMs (for example, you can’t launch a single instance) with limited integration to other Azure services.
Visibility – AWS has broad availability of spot instances as well as a Spot Instance Advisor to help users predict availability and interruptibility. On the other hand, Azure has lower visibility into the available capacity, so it’s hard to predict if/when your workloads will run.
Should You Use Azure Low Priority VMs?
If you have fault-tolerant batch processing jobs, then yes, low priority VMs are worth a try to see if they work well for you. If you’ve used these VMs, we’re curious to hear your feedback. Have you had issues with availability? Does the lack of integrations cause any problems for you? Are you happy with the cost savings you’re getting? Let us know in the comments below.