devopsy.kinsta.cloud

Author: JT Giri

  • How to Improve Cloud Management

    How to Improve Cloud Management

    Cloud technology underpins emerging technologies like artificial intelligence (AI), IoT, edge computing and containerization. Organizations must prioritize implementing effective cloud management practices to avoid spiraling costs and potential security and compliance violations.

    The COVID-19 pandemic has vastly accelerated cloud adoption. To support remote work, many businesses have moved workloads from on-premises servers to the public cloud. At the same time, thanks to the proliferation of technologies like AI and machine learning, organizations are generating more data than ever, much of which is also being stored in the cloud. It’s no surprise then, that the explosion in demand for cloud services is showing no sign of slowing down. Gartner predicts that worldwide end-user spending on public cloud services is forecast to grow by 23.1% in 2021 to total $332.3 billion.

    But, it’s not all smooth sailing. As the average organization’s cloud infrastructure grows in complexity and size, it becomes increasingly difficult for teams to manage it effectively. This has significant security, compliance and cost implications. According to Accenture, an astronomical 30% of organizations’ cloud spend is currently wasted.

    So, what can you do to ensure you avoid the most common cloud management pitfalls?

    See the Big Picture

    It’s surprising just how little visibility many businesses—even those with large teams of cloud architects—have into their cloud infrastructure. For instance, one recent survey found that over 25% of IT departments have no idea what their monthly cloud spend actually is.

    Before taking steps to optimize your cloud management practices, it’s crucial that you gain full visibility into your current situation. You need to understand your cost history, audit trail and CPU utilization patterns to identify where you’re overspending.

    Plus, make sure you’re using tagging consistently. A well-defined organization-wide tagging policy is essential, enabling you to accurately visualize expenditure by category. It’s also good practice to set up alerts which are triggered when a user launches instances without tags. This prevents any potential oversights.

    Develop a Change Management Process

    Gone are the days of rigid change management processes handled solely by IT teams. Nowadays, business units can acquire cloud services without even involving IT.

    In the cloud, change management is a series of continuous integrations, deliveries and deployments. Given this fast-moving environment, it’s crucial to implement a robust change management process or risk spiraling costs and potential compliance violations.

    It’s important that your change management process gives you visibility into and control of each infrastructure change without compromising on delivery speed. To achieve this while establishing strong policies and rules, it’s worth considering automation for at least part of the application delivery process. By auto-approving all routine and low-risk changes, you can free up time for your developers to focus on more complex projects.

    In addition, it’s worth integrating your change management process with your DevOps tool stack. You can use collaboration tools like Slack, Teams and/or Jira to ensure everyone has visibility into changes and resolve any issues quickly.

    Continuously Optimize your Cloud Infrastructure

    Unfortunately, when it comes to effective cloud management, your work is never truly done. Conducting a one-off review of your existing cloud infrastructure will only get you so far.

    Many businesses make this mistake and find themselves falling back into their old bad habits a few months down the line. To keep your cloud infrastructure in check, it’s best to continuously track a whole host of factors, including costs, changes, users, permissions and compliance breaches. After all, it’s much easier to solve an issue when you are able to spot it before it gets out of control.

    Now you have an idea of where to start when it comes to improving your cloud management practices. However, manually juggling all of the above considerations is a significant undertaking. It’s prohibitively time-consuming for many organizations whose DevOps teams are already overstretched. This is why a whole host of SaaS-based cloud management tools have sprung up in recent years. These offer unparalleled visibility into changes, resource utilization, costs, security, compliance, performance and more. Yes, they come at a cost. But, most businesses find that the savings such tools enable them to identify significantly exceed any outlays.

  • AWS Well-Architected Framework Elevates Agility

    AWS Well-Architected Framework Elevates Agility

    What started as a white paper from AWS, the Well-Architected Framework has evolved into a large ecosystem of partners and more

    In the past year, agility has become one of the most prized IT attributes as organizations race to deploy more workloads in the cloud. There is a paradox, however: The faster organizations deploy applications, the more likely mistakes will be made. Cloud computing deployments are rife with misconfigurations that are the direct result of developers provisioning cloud infrastructure rapidly and incorrectly. Application environments are almost never as efficient as they could be.

    The challenge and the opportunity IT teams now face is defining a set of best practices for securely and consistently deploying application workloads on cloud infrastructures that complement and extend agile development methodologies. IT organizations should not have to slow down application development and deployment because of security concerns. Identifying high-risk issues (HRIs) and being able to consistently achieve and maintain security without sacrificing agility is an absolute requirement.

    It seems that Amazon Web Services (AWS) couldn’t agree more. The cloud leader has defined the AWS Well-Architected Framework to help organizations build workloads on AWS that are secure, efficient, reliable, cost-optimized and operationally excellent.

    Through this effort, AWS hopes IT organizations benefit from removing the guesswork for building workloads on cloud. Cloud misconfiguration mistakes that conspire to make organizations question their commitment to agile development methodologies are eliminated. The only remaining issue is finding a set of tools that turn those AWS guidelines into a set of policies that can be achieved and enforced easily.

    Agile Meets Well-Architected

    In addition to making it possible to build and deploy applications faster, agile development methodologies make it possible to test the application code. IT teams gain unprecedented visibility into how applications behave. The equivalent of an application development methodology for managing cloud infrastructure is the AWS Well-Architected Framework.

    The Well-Architected Framework is battle-tested, based on best practices AWS has observed over its 14-year history. The pillars of the Well-Architected Framework are:

    1. Operational Excellence: Under this pillar, operations teams need to understand their business and customer needs so they can support business outcomes. Operations teams create and use procedures to respond to operational events and then validate their effectiveness to support business needs. Those teams also collect metrics that are used to measure the achievement of desired business outcomes. It’s important to design operations to support evolution in response to change and to incorporate lessons learned through their performance.
    2. Security: This pillar focuses on the importance of putting in place practices that influence security before any workload is architected. IT teams need to control who can do what. In addition, they need to be able to identify security incidents, protect systems and services, and maintain the confidentiality and integrity of data through data protection.
    3. Reliability: This pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total life cycle. The workload architecture of the distributed system must be designed to prevent and mitigate failures, handle changes in demand or requirements and be able to detect failures and automatically heal itself.
    4. Performance Efficiency: This pillar addresses the need to use computing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve. Teams must gather data on all aspects of the architecture, from the high-level design to the selection and configuration of resource types and make trade-offs in their architecture to improve performance, such as using compression or caching or relaxing consistency requirements.
    5. Cost Optimization: This pillar focuses on how to run systems to deliver business value at the lowest price point. Design decisions are sometimes directed by haste rather than data, and it can be tempting to overcompensate rather than spend time performing benchmarking to determine the most cost-optimal deployment. As a result, deployments can be both overprovisioned and underutilized. Using the appropriate services, resources and configurations for workloads is key to cost savings.

    Each of these pillars requires tools to enable DevOps teams to proactively manage their cloud environments—not only by provisioning and deploying applications faster but also by making more informed decisions when considering trade-offs between performance, reliability, cost and security. It’s a balance as rarely are these decisions independent of each other.

    The COVID-19 Imperative

    The COVID-19 pandemic has made the Well-Architected Framework essential. The number of workloads being deployed on AWS has increased sharply as organizations of all sizes accelerate digital business transformation initiatives. IT projects that once were expected to take months to complete now are expected to be up and running in a matter of weeks.

    Also read:

    Grupo JCPM accelerates delivery of an ecommerce platform on AWS to meet COVID-19 needs of retail customers

    The number of application initiatives underway has increased as well. Organizations are trying to maximize their IT budget like never before as the number of applications being deployed on AWS increases steadily. IT dollars need to go further than ever, at a time most digital business initiatives are still relatively nascent in their ability to drive revenue.

    Cloud optimization is now an absolute necessity. The days are over when organizations could afford to allow developers to spin up virtual machines randomly. Every dollar spent on cloud resources needs to provide a quantifiable return on that investment.

    How and Why Mistakes Are Made

    Of course, haste makes waste. Applications that are built and deployed quickly inevitably wind up not only consuming more resources than required but also are rife with mistakes. Cloud services are riddled with misconfigurations. In addition, developers routinely employ open source tools such as Terraform or vendor tools such as AWS CloudFormation to programmatically provision cloud infrastructure, and while managing IT infrastructure as code absolutely increases productivity, too many developers aren’t familiar with the best practices for securing that type of infrastructure. It’s not uncommon for ports to be left wide open simply because a developer assumed the cloud service provider would take care of that task on their behalf.

    AWS is committed to making sure its platform is secure. The security of the overall environment is a shared responsibility between AWS and its customers. It’s up to each IT organization to make sure the applications they deploy don’t inadvertently expose a vulnerability that could be easily exploited. And it’s up to each DevOps team to ensure applications are deployed reliably and securely without slowing down the deployment rate of those applications.

    For its part, AWS provides financial incentives to get Well-Architected in the form of account credits provided directly to the customer when they implement recommended remediations identified during a Well-Architected Framework Review—an assessment using these best practices guidelines. Customers typically use these credits to offset costs or add the latest AWS services.

    How nOps Resolves Cloud Issues

    nOps provides DevOps teams with an integrated SaaS platform to monitor, analyze and optimize AWS changes, security, performance, reliability and operational excellence while optimizing costs. DevOps teams gain continuous insights into their AWS infrastructure health informed by an always-on, automated discovery process using Well-Architected guidelines, and cloud consultants use it to run AWS Well-Architected Framework Reviews with their customers.

    As an AWS ISV partner, nOps is unique in architecting its platform to align directly with the five pillars of the Well-Architected Framework. There are features that solutions architects love instantly, such as auto-discovery of high-risk issues (HRIs) and dashboards aligned with the Well-Architected pillars that let them instantly drill down to the resource level for fast root-cause analysis. But its real value is helping AWS customers and partners be smart when evaluating the pros and cons of their decisions when balancing cost, security and performance.

    nOps is committed to helping IT teams optimally manage AWS environments as cost-effectively as possible. The continuous feedback provided by nOps enables DevOps teams to make sure that once operational excellence is achieved, there is no sliding back.

    A Well-Architected Movement

    The Well-Architected Framework is being adopted broadly. What started as a white paper now includes hands-on labs, AWS and third-party tools, an ecosystem of trained partners and a broad AWS company  mantra. The principles defined by AWS are being applied broadly in the industry with the help of solution providers including nOps and hundreds of consulting partners certified on Well-Architected. We’re at the beginning of a new era of cloud computing that leverages automation to achieve a level of operational excellence never before possible. We’re committed to partnering with IT teams large and small to make that vision a reality.

    IT organizations that regularly conduct Well-Architected Framework Reviews will be recognized by vendors and peers alike as one of an elite cadre of IT professionals that have mastered AWS to optimize their modern infrastructure for business agility.

    View the AWS Well-Architected webinar and check out nOps to see how it can support your Well-Architected agenda.

    This sponsored article was written on behalf of nOps.

  • Tips on Rightsizing to Reduce AWS Costs Now

    Tips on Rightsizing to Reduce AWS Costs Now

    In this business climate, everyone is looking to reduce costs. CFOs are reevaluating their software and infrastructure spend, and naturally, companies are looking for ways to optimize their AWS costs. In fact, we are now leveraging a major reason cloud is so compelling in the first place: you have more flexibility to control costs based on business needs. 

    How Do You Reduce Costs While Maintaining Performance? 

    A good starting point is to determine where most of the AWS spend is coming from. Once you know that, you can focus on factors that are causing the most charges and determine those services that can be scaled down and those that need the most resources. Depending on the service, there are many options, such as Amazon EC2 Reserved Instances (RI), Amazon EC2 Spot instances and resource rightsizing. In this blog post, I’ll cover rightsizing.

    There are some great AWS and third-party tools (I’m partial to nOps) to help you learn and analyze current usage patterns and make recommendations for rightsizing RI and Spot instances. In my experience, Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (Amazon RDS) and Amazon Simple Storage Service (Amazon S3) show up consistently in the top five items on the AWS bill. So, in this article, I’ll focus on rightsizing strategies with these three services.

    Rightsizing doesn’t just mean migrating from the old instance to the new generation instance. You’re probably not going to save lots of money with that approach. Rightsizing can help to identify resources that are clearly over-provisioned. Furthermore, many of the resources are provisioned using HashiCorp Terraform, AWS CloudFormation or an Auto Scaling group on AWS, so finding the rightsizing opportunities for ephemeral resources, and updating the automation not only reduces cost now but can also lower your future cost on AWS. 

    Optimizing Amazon EC2 and Amazon RDS Instances

    Hands down, Amazon EC2 spend is most-often the most expensive item on your AWS bill. Amazon EC2 comes with a robust set of options for CPU, memory and network I/O, ranging from 0.5GB of memory to 1TB. Having so many options can be a double-edged sword—how do you choose?

    You can choose the appropriate instance type based on your use case: Compute Optimized (for CPU-intensive workloads), Memory Optimized (for memory-intensive workloads) or Network Optimized (for enhanced network throughput).

    Some parameters need to be considered when choosing the optimal instances for your workload. Whether it is an HPC workload, or a simple Python Flask application or a Data Pipeline project, there is an Amazon EC2 instance type best suited for each of those workloads. 

    To select instances wisely, apply the most cost-effective Amazon EC2 instance type based on the network I/O and CPU utilization of the currently running instance. For example, if a t3.xlarge is configured for a Python Flask application and less than half of the memory is in use, the instance type has been over-provisioned for that workload. In such a case, a smaller instance size, such as a t3.small, is probably more appropriate.

    It’s also worth noting that, while most EC2 instances are provisioned with performance in mind, over time the utilization of the program can decrease, resulting in instances that are over-provisioned based on the current CPU/memory usage. I normally look at Amazon CloudWatch for instances that are not consuming all the resources that are currently available to each instance and, based on the historical usage, provide a recommendation to rightsize them. And, I can see the cost savings associated with the suggested changes.

    This approach can also be applied to Amazon RDS. The underlying architecture of Amazon RDS instances is very similar to that of Amazon EC2 instances. Both require an Amazon Virtual Private Cloud (Amazon VPC), security groups and a disk to run the managed database instance. 

    Optimizing Amazon S3 Storage Classes

    Amazon S3 offers a range of storage classes designed for different use cases:

    • S3 Standard for general-purpose storage of frequently accessed data.
    • S3 Intelligent-Tiering for data with unknown or changing access patterns.
    • S3 Standard-Infrequent Access (S3 Standard-IA) and S3 One Zone-Infrequent Access (S3 One Zone-IA) for long-lived, but less frequently accessed data.
    • Amazon S3 Glacier (S3 Glacier) and Amazon S3 Glacier Deep Archive (S3 Glacier Deep Archive) for long-term archive and digital preservation.

    You can determine the most appropriate storage class based on the usage of the objects in that bucket. As a result, you can cut the cost of storage of objects in the bucket and the cost of GET requests needed to download or transfer files from Amazon S3 to any other location.

    Getting Results Fast

    Uber, like many rapid-growth companies, was looking for ways to optimize AWS costs without slowing its high-velocity teams. They were able to save 15% of AWS costs in just 30 days using some of the strategies described above, as well as others. One of the keys for Uber is they are monitoring and optimizing costs continuously–not a one-and-done approach–because they have such high velocity with continuous changes to their AWS environment. They use nOps cloud management for this.

    Nick Cobb, senior engineering manager, Infrastructure Platform, Advanced Technologies Group at Uber, reports he’s able to “operationalize costs and get them in front of the engineers directly, saving 15% in the first month of implementation. In addition to providing reports for leadership and budget processes, our efficiency team can enact behavioral changes for R&D engineers typically used to throwing money at challenging problems.”

    If you’re interested in more details on the strategies that Uber has used, plus other cost-optimization strategies your organization can use right now, Nick will be joining me and AWS for a devopsy.kinsta.cloud webinar on continuous cost optimization on April 21. It’s a hot topic for so many organizations right now, so please join us.

  • 5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    5 Reasons AWS Service Catalog is Sexy for DevOps and Cloud

    Ok, so you’re probably more excited about topics such as microservices and containers right now, but bear with me. AWS Service Catalog is becoming increasingly necessary as cloud infrastructure evolves, allowing IT and developers to share pre-approved services, which helps tear down silos and encourage DevOps-related practices.

    If you’re not familiar with Service Catalog, it allows organizations to create, manage and share catalogs of IT products and services that are approved for use on AWS. You can share simple services, such as an Amazon S3 bucket, or more complex services, such as a multi-tier application containing an auto-scaling group and Amazon RDS with Amazon DynamoDB tables. Amazingly, the end user can provision these services without knowing the complexity behind the AWS services, and if you wanted, without needing write permissions to AWS (more on this later).

    Further, Service Catalog is built on top of AWS CloudFormation, which means that when you design services and follow security best practices and run time, you can add constraints such as controlling instance sizes (I know, everyone loves to launch the biggest instances).

    In this blog post, I’ll share five reasons why you should consider making Service Catalog part of your DevOps and cloud strategy right now.

    Improved Security

    As a sysadmin 10 years ago, I remember our department had full control of bringing all new resources to the infrastructure. We’re fortunate that’s no longer the case and its typical for developers to provision resources.

    Provisioning resources on AWS has never been easier, but many developers who can provision resources have limited understanding of the AWS shared security model. For example, a recent Uber hack was due to someone checking the keys to GitHub. What’s more, the steady and impressive flow of new services from AWS makes it even more difficult to know and follow security best practices for provisioning resources for various services.

    Service Catalog can help improve security. Here’s how:

    • Have developers provision resources without having access to AWS. Yes, you read that right: You can add constraints regarding which IAM role should be used to provision resources.
    • Build your service catalog on top of CloudFormation, which means you can follow the security best practices once, such as enabling data encryption at rest encryption for S3. So, when your users provision resources, all these best practices are applied.

    Cost Savings

    In Service Catalog, you can add constraints on the size resource allowed for provisioning (love the extra-large instances). Your developers can still provision resources, but they’re not going to break the bank. And your CFO will love you for that.

    Using constraints you can control instance type to be either t1.micro or m1.small

    Centralized Management of Service Catalog Across Accounts for Better Compliance

    Although Service Catalog is built on top of CloudFormation, unlike CloudFormation it’s designed for sharing commonly deployed applications to promote collaboration. This means you can share the service catalog across multiple accounts and have the same constraints copy over. Here’s a great article on how to do that.

    Productivity Gains

    Most often I work with companies on Service Catalog to increase productivity. One of the common objections I get is, “We’re not ready for this level of standardization because our infrastructure is changing so fast—we’re in rapid change mode.” Fair enough! However, even during this rapid development phase, your developers are most likely, individually rather than collectively, working on standardization to increase productivity. As an example, let’s say I normally launch a test server that updates the security group with access to VPN. Chances are there are other developers taking similar actions by writing their version of scripts. This is precisely where Service Catalog helps, by providing the platform to share these types of services (such as launching a server with VPN access only) to other employees, which, in return, improves team productivity.

    Facilitating DevOps Culture

    A principal objective of DevOps is to break down silos and align team members around delivering customer value. Service Catalog encourages a culture of sharing and collaboration by instantiating it into practice.

    What’s Next?

    I’m excited about the capabilities of Service Catalog and its promise for DevOps teams. At nClouds, we’re taking our use of Service Catalog to the next level by integrating an approval process to govern provisioned services, and automating the workflow as part of the change management process. Automation and just-enough lightweight process provide the control needed, but without sacrificing DevOps speed. You can read more in this new white paper, “Modern Change Management for AWS.”

    Also, for more information about Service Catalog and DevOps in practice there are some great presentations from AWS re:Invent available for replay: financial services FSV308, Fannie Mae MSC201, and John Wiley & Sons DEV321.

    — JT Giri