AWS Fargate is a serverless compute engine for containers that work with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). With Fargate handling instance provisioning and scaling, users don’t have to worry about spinning up instances when their applications need resources. While this has many benefits, it’s not without its share of challenges which can limit its applicability to a wide variety of use cases.
Moving employees to Azure Virtual Desktop (AVD) or Windows 365 can have many advantages, including: But migrating to a virtual desktop environment also has its challenges. Perhaps the largest is ensuring that applications can be installed on the virtual desktop environment. And then, beyond installation, ensuring that each application performs at least as well as in the users’ former environment.
Kubernetes has what you may consider an aggressive release cycle. There have been three to four releases per year since 1.0 was released in July of 2015. Perhaps you’ve found it all too easy to get behind a couple of versions. Running the latest, or nearly latest release will help protect your organization from security issues. This is because releases are deprecated once they fall three minor versions behind the latest. Staying current isn’t just about security though!
Last week, AWS and NetApp announced the general availability for AWS FSx for NetApp ONTAP. In this blog post, we’ll go through the steps to create a FSx for ONTAP filesystem, and you’ll learn how to create volumes using Kubernetes resources with Astra Trident, and how to mount those volumes to pods. As a prerequisite, make sure to register to the Spot platform, connect your AWS account and have a Kubernetes cluster connected to Ocean using the following guides.
With containerized workloads now the norm, and Kubernetes the chosen method for orchestration, new ways of operating and managing the underlying infrastructure have emerged. In this Kubernetes-first world, the goal is to not have to think about managing compute or storage.
Kubernetes and containerization of applications brings many benefits to software development, enabling speed, agility, and flexibility. The maturation of the Kubernetes ecosystem accelerated quickly in the last few years, leaving users with a multitude of choices when it comes to Kubernetes tooling and services. The major cloud providers (AWS, Azure, and Google Cloud) have introduced services specifically to help users run their Kubernetes applications more efficiently and effectively.
Spot by NetApp allows its users to manage their application infrastructure using a variety of provisioning tools. One of these tools is Terraform, an infrastructure as code (IaC) tool that allows users to build, change, and version infrastructure safely and efficiently. Spot by NetApp solutions supports multiple Terraform resources, such as Elastigroup, EMR Mr scaler, Managed Instance, and Ocean clusters for different cloud providers, and many more.
Modern, cloud-based software development lifecycles have quickly evolved from waterfall and are fully embracing the agile principles of DevOps. As part of this shift, continuous delivery practices have been adopted, giving organizations the capability to deliver and release code faster and more frequently than ever before. CI/CD tools bring velocity — code is always ready to be deployed, enabling organizations to commit multiple times a day.
Together with the release of Spot by NetApp’s Elastigroup support for multiple metrics, we are pleased to share that Elastigroup now also support step scaling, a new functionality that allows Elastigroup customers to configure multiple actions under a single, simple scaling policy. In Elastigroup, each simple scaling policy contains two parts. The first is the AWS metric, which is the metric the data is collected from.
Scalability is one of the main reasons why cloud computing has become so popular. Cloud customers can rapidly react to changes in market needs and demands by automatically launching or terminating resources. This way only the exact number of resources required to serve all incoming requests are running (and being paid for) at any given moment.
