devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes

    Optimizing Cloud Costs for DevOps With AI-Assisted Kubernetes

    As indicated in my prior blog, Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration, an AI-assisted Kubernetes orchestrator is needed to optimize cloud costs for DevOps, DevSecOps and SRE. This blog describes the landscape for cloud-native optimization approaches and a features requirement blueprint for an AI-assisted Kubernetes orchestrator. The blog also describes a roadmap for implementing an AI-assisted Kubernetes orchestrator and the benefits of a solution using an AI-assisted Kubernetes orchestrator.

    Cloud-Native Optimization Approaches Landscape

    As indicated in the article Tricks for Cloud Cost Optimization, “Cloud cost optimization (CCO) is a technique of running cloud-native applications effectively, at minimal possible cost, without affecting the health of the services.” The most typical approaches are variants of the following:

    • Rightsizing pre-paid, fixed and reserved instances: Cloud service pricing models are intended to fit your application and business needs with the hundreds of choices available from cloud service providers. This approach can be cost-efficient when application and business needs are constant over time. However, this approach is not sufficiently cost-efficient for many applications and business needs that are constantly changing, such as use cases for DevOps, DevSecOps and SRE.

    • Spot instances can offer low cost-per-instance, but reliability is not guaranteed because the cloud provider can interrupt these services anytime. Unless the use of spot instances is limited to workloads that do not require a high level of reliability, this approach is limited. This approach does have the potential to have a broader application if a smart management layer is implemented to orchestrate the use of the spot instances.

    • Pay-as-you-go offerings by cloud service providers, used together with infrastructure-as-code (IaC) and auto-scaling, can help save on cloud costs. This approach facilitates the automatic spin-up of resources when needed and automatic shutdown when not needed. However, to realize the benefits of this approach requires constant supervision of cloud usage and manual adjustments to realize the benefits. Businesses may not even be aware of the resource scaling until the monthly bill arrives.

    • Cloud auto-stopping of entire applications and clusters can help to manage cloud resources automatically to ensure that they run only when needed, never when idle. This approach is not granular enough to sufficiently reduce costs for rapidly fluctuating resource needs for DevOps, DevSecOps and SRE use cases.

    • Manual cloud costs management, in which team members are taught to understand their own cloud spend and cloud cost management practices, can help reduce costs. However, this approach is subject to human involvement, is slow and generally does not provide granular controls needed to sufficiently deliver cloud cost savings 24/7.

    None of the traditional cloud cost optimization approaches described above have the requisite smarts, speed or granularity to sufficiently optimize the highly dynamic requirements for DevOps, DevSecOps and SRE use cases. An AI-assisted orchestration approach, when supported with the right features, can make up for the deficiencies of the typical optimization approaches.

    Features for AI-assisted Kubernetes Orchestrator

    As indicated by CAST AI an AI-Assisted Kubernetes orchestrator needs the following features:

    • Easy to start – It should take less than five minutes to fully onboard a cluster.
    • Easy to use – The orchestrator should abstract layers of complexity, so little knowledge is needed to use it other than a basic knowledge of running Kubernetes clusters in a public cloud. For example, a working knowledge of the kubectl command line utility for creating and managing Kubernetes clusters.
    • SaaS configuration – Avoids the need to host and manage the orchestrator itself.
    • Autoscaler policies – Define threshold values and upper bounds so instances are automatically added or removed as per the policy.
    • Cloud Support for AWS EKS, GCS GKS, Azure AKS and kOps clusters
    • Reports to monitor and track cost savings for each cluster.
    • Features to optimize each cluster.
    • High availability to ensure the orchestrator itself is not a failure point.
    • Collect and analyze each cluster configuration to provide the most optimal setup along with a savings estimation for the current cloud environment.
    • Security – Detect and monitor K8s vulnerabilities and configuration issues.

    Roadmap for Implementing AI-Assisted Kubernetes Orchestrator

    According to the article Roadmap To Cloud Cost Optimization, organizations need to understand that they need to deploy cloud computing the right way. This not only paves way for the actual digital transformation but is even instrumental to cloud cost management.”

    The article Top 3 Issues in Kubernetes Cost Management indicates, “Teams cannot manage and monitor Kubernetes’ costs without having the right tools in hand. No doubt, you can collect all the data yourself and create the right solutions. It wouldn’t be easy to modify these solutions if changes are required.” The speed of change with DevOps, DevSecOps and SRE is not compatible with the typical tools.

    A good example AI tool, CAST AI, indicates how easy it can be to onboard a Kubernetes cluster. First, connect your Kubernetes cluster to CAST AI and see how much you can save by optimizing cluster configuration. After exploring the available savings and cost reports, you can onboard the cluster into CAST AI and set the Autoscaler policies, which will manage the cluster for you. It takes less than five minutes to fully onboard a cluster.

    Benefits of Solutions Using AI-Assisted Kubernetes Orchestrator

    An AI-assisted cloud orchestrator can provide the following benefits.

    • Spot instance automation
    • Spot instance fallback
    • Real-time autoscaling
    • Instant rebalancing
    • Visibility into cloud usage and costs
    • Avoids over-provisioning
    • Cloud resources are not left idle
    • A consistent approach between teams and departments
    • Reduce monthly average cloud spend by up to 60%

    Summary

    The prior blog Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration explained why an AI-assisted Kubernetes orchestrator is needed to optimize cloud costs for DevOps, DevSecOps and SRE. In this blog, specific requirements for such an AI-assisted Kubernetes orchestrator was explained using CAST AI as an example. The steps to onboard a cluster to the AI tool was explained.

  • Organizations Prioritizing Java Application Modernization

    Organizations Prioritizing Java Application Modernization

    A survey found that modernizing existing Java applications is a higher priority than other projects for 87% of respondents, with more than 80% of these applications expected to be re-engineered over the next five years. The survey polled 450 IT professionals working in organizations in the U.S. and United Kingdom that have more than 500 employees.

    Conducted by the market research firm Vanson Bourne on behalf of Diffblue, a provider of a generative artificial intelligence (AI) platform for refactoring applications and generating unit tests, the survey also found enterprises plan to invest nearly half (45%) of their software development resources on modernization of existing applications versus developing new ones. A full 90% of respondents expected to rely on automation to accomplish those tasks, the survey found.

    Specifically, survey respondents reported they planned to rely on automation to improve security (50%), increase development velocity (45%) and improve developer experience (42%). Well over half of respondents (58%) said they had already been working on these projects for more than 12 months.

    If organizations don’t modernize Java applications, more than half of respondents (51%) said too much time would be spent on unproductive coding, while 50% said development velocity would be adversely affected. The biggest obstacles cited are choosing the right technical approach (45%) and securing budget (42%).

    More than half of organizations (59%) have created a dedicated modernization budget to support their efforts. Nealy half (48%) said funds are being provided by business teams for projects, while 49% said general operating budgets have increased.

    Diffblue CEO Matthew Lodge said it’s clear there is a huge commitment to application modernization. The reality is the majority of work IT teams do involves applications that have already been deployed. The challenge they face is that the effort required to modernize these applications is still far too dependent on manual processes, he added.

    Overall, the survey found 96% of respondents considered Java applications extremely or very important to their organizations. On average, 65% reported additional Java applications are still being developed. Only 4% said they planned to migrate away from Java as part of a modernization effort.

    Over half of the respondents expected to use Java 11 (53%) or Java 17 (56%) in their applications, compared to 19% using Java 8. More than a quarter (27%) expected to use a forthcoming Java 21 release. A full 100% expected to use the Spring framework to build these applications, with more than half (54%) planning to upgrade to the latest version that supports Java 17. A full 97% said unit testing is an “extremely” or “very important” element of their application modernization effort.

    After experiencing something akin to a mid-life crisis, Java has itself been modernized with the release of Java 17, noted Lodge. The Java community is now adopting many concepts that may have been pioneered in other programming languages, he added.

    Regardless of whether organizations are modernizing existing Java applications or writing new ones, the one thing that appears certain is the venerable programming language isn’t about to disappear any time soon.

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • Akamai Makes Case For Next Era of Cloud Computing

    Akamai Makes Case For Next Era of Cloud Computing

    Akamai Technologies today unveiled a cloud computing service that combines its ability to deploy applications at the edge with the cloud platform it gained via its acquisition of Linode.

    Shawn Michels, vice president of product management for compute and apps at Akamai, said Akamai Connected Cloud will provide the foundation for running a new generation of modern applications that require access to both core infrastructure resources in the cloud alongside highly distributed edge computing services.

    As part of the effort to deliver that combination of services, in the second quarter Akamai is adding three sites in the U.S. to the 11 it already provides. In addition, Akamai revealed it had identified 10 additional cloud sites and 50 distributed edge computing sites that it will add throughout the rest of this year.

    As a long-time provider of a content delivery network, Akamai manages a massive distributed computing environment that spans 4,100 locations across 135 countries. The acquisition of Linode added a set of cloud computing services that enable Akamai to offer the same set of services, including CDN services, as cloud service providers.

    Akamai is now signaling it will compete more aggressively by discounting the egress fees charged whenever data is moved off a cloud platform. One of the most expensive and unpredictable costs is the egress fees cloud service providers charge whenever data is moved off their platforms, noted Michels.

    Finally, Akamai also revealed it has achieved ISO, SOC2 and HIPAA standards compliance for its services.

    Akamai is making a case for an alternative approach to cloud computing that it said will be optimized for both existing monolithic applications running on virtual machines and cloud-native applications based on containers and serverless computing frameworks. A recent survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of devopsy.kinsta.cloud, found 43% of respondents are considering adding additional cloud service providers in the next 12 months. Nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted with one.

    It’s not clear whether IT organizations might actually migrate existing applications from one cloud service provider to another. At the very least, Akamai expects that as new applications are developed, the company will be able to gain a larger share of the overall market.

    There’s no doubt that a new era of cloud computing is dawning as organizations look to deploy distributed applications that process and analyze data closer to the point where it is created and consumed. These applications will then share the results of the data processed at the edge with, for example, centralized data lakes that make it possible to analyze data collected across a distributed computing environment.

    The one thing DevOps teams can count on is that as this next era of cloud computing evolves, the management of IT environments will become much more challenging for all concerned.

  • We Are Living in an Ephemeral World

    We Are Living in an Ephemeral World

    We are lucky to live and work in the times that we do. Oh, we have our challenges, and I talk about them a fair amount here on these pages. But the things we can do in IT today have not been possible in the past, and the change isn’t over. Soon you will be able to relegate pretty much all of the busywork of IT to automated systems, Note that I did not say “AI/ML”–some of that automation will be, but we throw the term around too much right now, and not all automation will be based on AI/ML. In fact, quite a bit of the best automation is simply rule-based systems that we finally have things standardized enough to write up. And I intend to talk specifically about automation that is not AI/ML today.

    We have reached the point in DevOps where we can automate the entire build/release process using containers. The CI tool, running in a container, can spawn a container that performs the build. Then, when it is done, if it passed, it can spawn another container to run tests, do security scans, etc. Finally, the product can be promoted and released … in a container. Human involvement is only required for approvals and then only for organizations that want checkpoints on the way to production (which is definitely most but not all of us).

    If you take the totality of what is going on out there in DevOps, it is finally catching up to DevOps. The biggest issue will be making it efficient and doable for the DevOps team. To date, by focusing on DevOps, teams have been able to avoid the simple fact that complex deployments on infrastructure that spans environments and uses external resources is hard. By keeping the DevOps side simple (or not part of the DevOps process), developers can crank out code faster, facilitated by DevOps tools and Agile methodologies, and operations can continue to wrangle the beasts of networking, storage, etc. to get the app running in production. Once ops has completed the process, then it can be automated based on steps taken.

    But we now have Software-Defined Everything ™ combined with containers. That means that for many–though not anywhere near all–applications, a commit that updated a constant in a single source file can spawn the entire process in iterative containers all the way through release. That is very cool, and we should take a second to appreciate how far we’ve come in a short time.

    Then we need to talk about those worker containers. They need a ton of centralized logging and reporting. Spinning them up, letting them run and then automatically destroying them is fine—as long as the organization has access to the information it needs to review and analyze the results. In-application tooling will cover the released product and even the test environment, but not an ephemeral build process. By not keeping a ton of build tools running all of the time, the enterprise is, by definition, more secure—the blast radius is reduced if build tools are only available when they’re active, and logging of who/what kicked of a build is kept. But don’t forget the reporting. At build time, our tools know exactly which error failed a build; the container needs to submit a ticket before being destroyed or log heavily. I say, “Always create a ticket,” but I’ve worked in enough environments to know that your reality may not make that possible. As long as notifications occur, it doesn’t really matter how they occur.

    So crank it up; start super-automating. Tool up those build environments, then make them into disposable container instances. Others have been doing this for a while, so there is help available for setting it up, but it is just now taking off, so it is a good time to dive in. And keep rocking it. How the apps are built and deployed is only important in the sense that you are driving the company forward. Keep doing it.

  • Azure Migration Strategy: Tools, Costs and Best Practices

    Azure Migration Strategy: Tools, Costs and Best Practices

    Azure migration refers to the process of moving applications, data and other resources from on-premises or other cloud environments to Microsoft Azure, which is a cloud computing platform and service offered by Microsoft. 

    Azure migration can include migrating virtual machines, databases and storage to Azure, as well as re-architecting applications to take advantage of Azure services. Typically, the goal of Azure cloud migration is to take advantage of the scalability, security and cost benefits of the Azure platform.

    4 Azure Migration Tools

    Here are several tools provided by the Azure cloud which can help you migrate applications to the Microsoft cloud.

    Azure Migrate

    Azure Migrate is a service offered by Microsoft as part of Azure that helps customers discover, assess, and migrate their on-premises workloads to Azure. It provides a centralized hub for the discovery and assessment of on-premises workloads and helps customers plan and execute their migration to Azure. Azure Migrate includes the following features:

    • Discovery: Azure Migrate discovers on-premises servers and their dependencies and creates an inventory of them.
    • Assessment: Azure Migrate assesses the readiness of on-premises servers for migration to Azure and provides recommendations for target Azure resources.
    • Migration: Azure Migrate helps customers plan and execute their migration to Azure using various migration tools such as Azure Site Recovery, Azure Database Migration Service and Azure Data Box.

    By using Azure Migrate, customers can move their workloads to Azure with confidence, knowing that they have a comprehensive plan and the right tools in place to ensure a successful migration.

    Azure Database Migration Service

    Azure Database Migration Service (DMS) is a fully managed service offered by Microsoft as part of Azure that simplifies and accelerates the process of migrating on-premises databases to Azure. The service supports a variety of databases, including SQL Server, Oracle, MySQL, and PostgreSQL.

    Azure DMS can perform both online and offline migrations, depending on the requirements and availability of the source database. Online migrations are performed while the source database is still in use, while offline migrations require the source database to be taken offline during the migration process.

    The service supports several migration scenarios:

    • One-time migration: Move a database to Azure once and leave it running in Azure
    • Lift and shift: Migrate an on-premises database to Azure and keep the same database engine running in Azure
    • Change the engine: Migrate an on-premises database to Azure, but change the database engine running in Azure to a different one.

    The Azure DMS provides a simple and efficient way to move your on-premises databases to Azure with minimal downtime, and it’s integrated with Azure Migrate for a holistic migration experience.

    Azure Data Box

    Azure Data Box is a service offered by Microsoft as part of Azure that allows customers to transfer large amounts of data to Azure for storage and processing. The service is designed for customers who have a large amount of data that needs to be transferred to Azure, but have limited network bandwidth or other constraints that make it difficult to transfer the data over the Internet.

    Azure Data Box provides customers with a physical device (called an “Azure Data Box”) that they can use to transfer data to Azure. The device is shipped to the customer, who can then copy data to the device and ship it back to Microsoft. Microsoft will then transfer the data to the customer’s Azure storage account.

    There are several different types of Azure Data Box, each with different storage capacities and data transfer speeds:

    • Azure Data Box: 100TB storage capacity, data transfer speed of 100Mbps
    • Azure Data Box Disk: 40TB storage capacity, data transfer speed of 40Mbps
    • Azure Data Box Heavy: 1PB storage capacity, data transfer speed of 100Mbps
    • Azure Data Box Edge: 100TB storage capacity, data transfer speed of 100Mbps and AI and IoT edge computing capabilities.

    Azure Data Box is particularly useful for customers who have large amounts of data to transfer, and don’t have the network bandwidth or other resources to transfer the data over the Internet.

    Azure Synapse Pathway

    Azure Synapse Pathway is a new feature of Azure Synapse, which is a fully managed cloud-based data integration and analytics platform. Azure Synapse Pathway is designed to make it easy for customers to move their existing data integration and analytics workloads to Azure Synapse without requiring significant re-architecting or rewriting of their existing code.

    Azure Synapse Pathway supports several migration scenarios, such as:

    • Lifting and shifting on-premises SQL Server Integration Services (SSIS) packages to Azure Data Factory.
    • Migrating on-premises SQL Server Analysis Services tabular models to Azure Analysis Services.
    • Migrating on-premises Power BI reports to Power BI in Azure Synapse.

    Azure Synapse Pathway also provides a migration tool that helps customers to move their existing data integration and analytics workloads to Azure Synapse, with minimal changes to their existing code. This allows customers to take advantage of the benefits of Azure Synapse without significant re-architecting or rewriting of their existing code.

    Azure Migration Strategy and Best Practices

    Prepare an Inventory of Digital Assets

    Understanding your digital estate is an important part of creating an effective Azure migration strategy. A digital estate refers to the collection of digital assets and resources that an organization uses to run its business, including applications, data, and infrastructure. In order to migrate your digital estate to Azure, you need to understand what you have and where it’s running. This information can be used to create a migration plan that is tailored to your specific needs.

    To understand your digital estate, you should start by creating an inventory of your applications, data, and infrastructure. This inventory should include information such as:

    • The name and purpose of each application
    • The technology stack used by each application
    • The location of the application and its data
    • The dependencies between applications and data
    • The number of users and usage patterns for each application
    • The storage and compute requirements for each application

    Once you have an inventory of your digital estate, you can use it to create a migration plan that takes into account the specific needs of each application, as well as any dependencies or constraints that need to be considered.

    Best practices for inventorying your digital assets:

    • Start by identifying the most critical applications and data that need to be migrated first.
    • Assess the readiness of your existing infrastructure and applications for migration to Azure.
    • Understand the dependencies between your applications and data, and plan for them accordingly.
    • Identify any constraints or limitations that need to be considered when planning your migration.

    By understanding your digital estate and creating a migration plan that takes into account the specific needs of your applications and data, you can ensure that your migration to Azure is successful and that your business is able to continue to operate during and after the migration.

    Estimate Monthly Workload Costs

    Estimating the monthly costs of your workloads is an important part of creating an Azure migration strategy. By understanding the costs associated with running your workloads in Azure, you can make informed decisions about how to migrate your workloads and how to optimize your cloud costs after migration.

    To estimate the monthly costs of your workloads in Azure, you can use the Azure pricing calculator. The pricing calculator allows you to estimate the costs of running various Azure services, such as virtual machines, storage, and networking, based on the specifications of your workloads. You can also use the Azure TCO calculator to estimate the total cost of ownership of your workloads in Azure, taking into account costs such as data transfer, management, and support. There are multiple other Azure calculators you can use to estimate storage costs, networking costs, and more.

    Image Source: Azure

    When estimating the costs of your workloads in Azure, it’s important to consider the following factors:

    • The size and number of virtual machines required to run your workloads
    • The storage and network requirements of your workloads
    • The number of users and usage patterns of your workloads
    • The services and features required to run your workloads, such as Azure Backup or Azure Security Center

    It’s also important to consider how the costs of your workloads may change over time, such as how the number of users and usage patterns may change or how the costs of Azure services may change.

    Best practices for estimating the monthly costs of your workloads in Azure:

    • Use the Azure pricing calculator and TCO calculator to estimate the costs of running your workloads in Azure.
    • Understand how the costs of your workloads may change over time and plan accordingly.
    • Optimize your costs after migration by using Azure cost management and Azure reservations.
    • Continuously monitor your costs and usage to ensure you’re getting the most value from your investment in Azure.

    By understanding the costs associated with running your workloads in Azure, you can create a migration strategy that is optimized for cost and that enables you to get the most value from your investment in Azure.

    Migrate Workloads and Optimize

    Migrating your workloads to Azure and optimizing them for the cloud environment is an important step in creating an Azure migration strategy. Once you have a clear understanding of your digital estate and have estimated the costs of running your workloads in Azure, you can begin migrating your workloads and optimizing them for the cloud.

    There are several ways to migrate workloads to Azure, depending on the type of workload and the migration requirements. Some common migration methods include:

    • Lift and shift: This method involves moving an existing workload to Azure without making any changes to the workload. This is typically used for simple workloads that do not require significant changes to run in the cloud.
    • Re-architecting: This method involves making changes to the workload to take advantage of the features and capabilities of Azure. This may include re-architecting the application to suit the target Azure service, such as Azure SQL Database or Azure Storage.
    • Refactoring: This method involves making changes to the workload to optimize it for the cloud environment. This may include refactoring the application using cloud-native patterns and practices, such as microservices or containerization.

    Once your workloads are migrated to Azure, you can optimize them for the cloud environment by:

    • Scaling your workloads to match demand.
    • Using Azure services and features to improve the performance and security of your workloads.
    • Monitoring and managing your workloads to ensure that they are running efficiently.
    • Optimizing costs by using Azure cost management and Azure reservations.

    Best practices for migrating your workloads and optimizing for the cloud environment:

    • Start by migrating your most critical workloads first.
    • Understand the migration method that is best suited for your workloads and plan accordingly.
    • Use Azure services and features to improve the performance and security of your workloads.
    • Continuously monitor and manage your workloads to ensure that they are running efficiently.
    • Optimize your costs by using Azure cost management and Azure reservations.

    By following these best practices, you can ensure that your workloads are migrated to Azure and optimized for the cloud environment, which will help you to get the most value from your investment in Azure.

    Monitoring

    Monitoring is an important part of creating an Azure migration strategy and ensuring that your workloads are running efficiently in the cloud. By monitoring your workloads, you can identify and address issues that may arise during or after migration and ensure that your workloads are meeting the needs of your business.

    Azure provides a variety of tools and services for monitoring your workloads, including:

    • Azure Monitor: A service that provides a unified monitoring solution for Azure resources, including virtual machines, storage, and networking.
    • Azure Log Analytics: A service that allows you to collect and analyze log data from your workloads.
    • Azure Application Insights: A service that allows you to monitor the performance and availability of your applications.
    • Azure Security Center: A service that provides security monitoring and management for your workloads.

    When monitoring your workloads in Azure, it’s important to consider the following factors:

    • The performance and availability of your workloads
    • The usage and costs of your workloads
    • The security and compliance of your workloads

    It’s also important to consider how your monitoring needs may change over time, as your workloads and usage patterns may change.

    Best practices for monitoring your workloads in Azure:

    • Use Azure Monitor, Log Analytics, Application Insights, and Security Center to monitor your workloads.
    • Continuously monitor your workloads to ensure that they are running efficiently.
    • Use Azure alerts to notify you of issues that may arise.
    • Use Azure dashboards to create custom views of your monitoring data.
    • Continuously assess and monitor your digital estate to ensure that it’s up-to-date and that your migration plan is still valid.

    By monitoring your workloads in Azure, you can identify and address issues that may arise during or after migration, and ensure that your workloads are meeting the needs of your business. This will help you to get the most value from your investment in Azure and ensure a successful migration.

    Conclusion

    In conclusion, migrating to Azure is a great way to take advantage of the scalability, security, and cost benefits of the cloud. However, migrating your workloads to Azure requires a well-planned strategy that takes into account the specific needs of your business and your digital estate. 

    To create an effective Azure migration strategy, it is important to understand your digital estate, estimate the costs of running your workloads in Azure, choose the right strategy, and optimize them for the cloud environment. 

    Additionally, monitoring your workloads in Azure is crucial to ensure that they are running efficiently, and to address any issues that may arise during or after migration. By following best practices and using the tools and services provided by Azure, you can ensure a successful migration and get the most value from your investment in Azure.

  • Looking Ahead, 2023 Edition

    Looking Ahead, 2023 Edition

    DevOps is in a perpetual state of change that keeps all of us engaged and busy, but makes a mess of things overall. Do you cloud-first? Are your APIs GraphQL yet? Are you doing SDN to connect to the VPN so you can put files on the CDN and build closer to the market? Sorry, had to do it. You get the point.

    The point is that the ground is forever changing under us, and often things that seem straightforward are not. Like “cloud-native,” including Kubernetes. Yeah, I get it, you mean software-defined infrastructure that works well with infrastructure-as-code (IaC); this field is confusing enough—calling it cloud is dumb when, these days, cloud has a specific meaning in the minds of IT.

    In our current round of change, a few patterns are showing up. Automation is king. Sometimes it is sold as AI/ML because those are the buzzwords of the day, but it is just continuing the trend of automation to make IT more responsive and predictable. We are rapidly approaching a point where the entirety of the application development/deployment process can be automated reliably and configured to create predictable results. By that I mean that development has more assistance writing code, test has more assistance running tests and processing results, deployment environments can be grabbed from application release automation/orchestration tooling and the final product all of that means that builds can be deployed with very little human interaction unless something breaks.

    Highly automated systems are a prerequisite of high-volume output, though – automobile factories are the easiest example of that statement. My problem is that we don’t seem to be asking “Should we be high-volume producers?” Does the average enterprise require non-stop development? I think that the initial answer is yes, and the more considered answer is “Only because the business wants more, consistently.”

    At some point, the gains we received from DevOps need to be looked at from the “What value is added?” perspective. And that is a business function with IT input. Before SaaS and DevOps made IT easier (to get something running; not minimizing our work here), the business had to consider carefully if it needed that application or that change to an existing one. Today, that consideration is pretty much “Because we want it, put it on the backlog.” But all of our new development adds to our technical debt. While the wave of automation we have been living through since “The Pheonix Project” was first published is keeping us ahead of the curve, we will inevitably need to consider flattening the curve. I suggest that the time is now.

    Getting started with this is actually pretty easy. For many organizations, simply stating, “We do not need two ways to do that” will yield benefits quickly. Other organizations will have to ask “Why can’t we use the functionality of existing tools/apps to do that?” and yet others will need to ask the business, “Do we even need to do that?” Prioritization still exists, and management does an okay job of pushing back at all of the organizations I talk to. Still, at some point it goes beyond “prioritize your wishlist,” and IT managers will have to start asking if a project is even necessary–even if doing so makes waves.

    Continue to rock it, but we’re past time to look for redundancy, synergy and misdirection. There is more complexity coming, and more sweet solutions to problems (both known and unknown) are right around the corner. But, as I’ve said before, simplify as you go because you need to be able to handle the next wave, and eventually, automation won’t cover the gap.

  • Microsoft Outage Outrage: Was it BGP or DNS?

    Microsoft Outage Outrage: Was it BGP or DNS?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

  • Don’t Hire for Product Expertise

    Don’t Hire for Product Expertise

    We all know the jokes about talent recruitment that “requires a century of experience in AI/ML.” With the number of layoffs, no doubt this type of approach will get worse. But that is not generally a tech problem; it is an HR problem–the problem of having people hire in tech that aren’t active in or knowledgeable about tech.

    The real concern that is very much a tech problem is hiring for product and/or technology. I will say outright: Stop doing that except in very special circumstances. Hire for the ability to find information. One of the other things we all joke about is increasingly convoluted interviews where the hiring company wants you to solve their problems in a fraction of the time it would actually take them to do it. Again, if you’re a hiring company doing this, knock it off.

    IT is an ever-evolving field, more so once Agile and DevOps are taken into account. Indeed, we would not be far off if we renamed the field Continuous Evolution, because tomorrow is guaranteed to hold different solutions, no matter what. The idea that requiring experience in Grafana or mastery of Python is an indicator of long-term success is downright farcical. There are positions where this is tolerable–if a position is for maintenance of a traditional app that is not going anywhere and is not getting massive updates, then a list of what tools are desired for the role is easy to build and will be lasting. But I would argue that hiring specifically for that application’s needs is not in the best interest of the organization as a whole, because that person is not portable and adaptable. For modern development, particularly of new products that are just now being architected, the needs are going to change in the process, so claiming you want X years of experience in Spring (when it may use a different framework by deployment time) is not productive.

    As we move into belt-tightening yet again, employees who can do the job and know how to look up new information will be worth their weight in gold. Having a person who can work on existing applications and drive innovation in future applications all in one body is important. Giving them a chance to exercise that drive to learn is also important, but is a separate issue. None of the areas I cover–applications, operations and security–are standing still or even coming close to standing still. The need for people who can go find out what is needed is huge.

    And while the internet is a horrendous mix of good and bad, the ability to find information—and even solutions to problems—is undeniably better than it ever has been. Having people skilled at using that information resource is the key to moving forward.

    So, find people that can solve problems given a modern context. Hiring for technology will solve today’s problems, but problems are not restricted to today, so solve ongoing problems. Gate for basic tech knowledge and skills, then evaluate for the ability to find answers. A far better use of everyone’s time during interviews would be—using email as an example—“Hosted Exchange just went down. Walk me through your troubleshooting steps. You have a couple minutes.” Or—using development as an example—“We just discovered that an OSS library we use has unacceptable vulnerabilities. Walk me through how you would find instances of it and what steps you would take to find replacements. Compliance is breathing down our neck, you have a couple of minutes to show us.” You get to see how they approach likely problems, they get to ask about the environment. Far better than “Show us all the steps to get BGP routing configured,” or “Develop an entire B-Tree while we watch,” questions. Certainly better than any question that ends with “And don’t use the internet.” Are you kidding? Can we talk about the field and what year it is?

    As I’ve said off and on over the years, you want the best coworkers you can get or the best employees you can get. Either way, hiring for expertise with a given tech product is not the best route to that goal. You rock—so get people with you who do, too. It’s not going to get less complex, so have peeps that can keep up and carry a load, no matter what tomorrow’s technology looks like.

  • Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration

    Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration

    Kubernetes continues to grow as the leading container orchestrator for high-performance, cloud-native DevOps, DevSecOps and site reliability engineering (SRE) use cases. While Kubernetes offers excellent orchestration capabilities, it does not, by itself, assure cloud computing costs are optimized.

    The current state of cloud expenditures for many organizations indicates a lot of waste. So much so that there is a trend to replatform from the cloud to private infrastructures to save money—escalating cloud costs are too high and the deep level of real-time optimizations are too hard and too slow.

    According to an article from VentureBeat, Cloud computing: Cost at scale, “Large enterprises have started exploring cloud repatriation. What is worse, the forecasted trends are that “cloud spending could go up as high as 80% of the cost of the revenue for software companies. Moreover, the $100 billion market value among 50 software companies is lost due to the impact of the cloud on their margins.”

    An article by CAST AI indicated 60% of cloud costs could be eliminated by being smarter about the use of cloud resources and augment Kubernetes with AI tooling, no matter the size of the deployments. Given the large number of human and automated users associated with DevOps, DevSecOps and SRE use cases for enterprise cloud resources, the savings potential can equate to tens of thousands of dollars per month.

    However, typical optimization methods are not fast enough nor smart enough to process the resource changes quickly enough to achieve these optimizations at speed. An AI-assisted Kubernetes orchestration is needed to achieve this.

    Kubernetes Landscape

    According to 2021 State of Cloud Native Development Report, Kubernetes is used by 31% of all backend developers. Currently, 5.6 million developers use Kubernetes. The edge computing category has experienced rapid growth in the adoption of Kubernetes and has the highest usage rates of both containers and Kubernetes at 63%.

    A report from the Cloud Native Computing Foundation (CNCF) indicated that spending on Kubernetes, the primary means of orchestrating containerized applications, was up year-over-year from 2020 to 2021. Of those surveyed, 67% reported an increase of 20% or more over the last 12 months, and 10% spent more than $1 million per month on their deployments. Fewer than 25% accurately predicted how much they’d spend to within 5% of the actual cost. And over 20% could not predict their cloud bill. That’s no way to run an operation.

    Cloud Cost Use Cases for DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE have many use cases for orchestrating cloud computing. The list of computing tasks below is only a partial set of computing resources that need to be orchestrated for every value stream.

    • Communication—emails, chats
    • Experimentation, planning and research-related computing tasks
    • Configuration tasks associated with infrastructure-as-a-service, platform-as-a-service, software-as-a-service and serverless.
    • Version and artifact repositories transactions
    • Application and microservice transactions
    • API transactions
    • DevOps administration tasks
    • Developer pre-commit builds and testing
    • Continuous integration commits, builds, scans, tests, and tools
    • Continuous delivery—pre-prod tests and deployment development
    • Continuous deployment automation and deployment strategies
    • Production operation, backups, rollbacks, production testing
    • Replication of hybrid cloud and multi-cloud instances
    • Software repositories, data lake transactions
    • Monitoring, logging, synthetic monitoring
    • Tracing, metrics, collectors, analytics and dashboards
    • Release and value steam management
    • Anti-fragility—Chaos engineering, disaster recovery, fire drills, security red/blue/purple teams
    • Diagnostics, issue reporting and tracking
    • On-call support and retrospectives
    • Documentation and training (computer-based) transactions

    Sources of Waste and Potential Savings

    According to the State of Kubernetes Report: Overprovisioning in Real-Life Containerized Applications, 37% of cloud compute capacity is not used. The primary reasons behind cloud waste are:

    • Lack of visibility into cloud usage and costs
    • Overprovisioning
    • Leaving cloud resources idle
    • Fragmentation of usage between teams and departments

    One of the major drivers of wasted cloud spend is the inability to scale back once application demand drops. By eliminating this sort of overprovisioning, organizations stand to reduce their monthly cloud spend by almost 50%. By adding spot instances to the mix, organizations could cut their cloud spend by 60% on average.

    Complexities Impacting Ability to Optimize

    According to the article Cloud Cost Management for DevOps, “When properly done, cloud cost management can truly save organizations significant amounts of money. But, there is a learning curve and traditional approaches cannot keep pace with the rapidly changing requirements for DevOps, DevSecOps and SRE use cases.”

    Trial and error are needed to identify optimization challenges that DevOps team members can anticipate. Before you can even begin planning around cost optimization, you need an accurate picture of your current infrastructure and spending landscape. Cost attribution cannot be done by simply opening your AWS bill. Cost data from monthly bills is not granular and cannot attribute costs to projects and teams. Furthermore, there are additional expenses that are included in your bill that are not tied to your cost of goods sold, such as research and development expenses.

    Accurately allocating costs requires accurate and disciplined tagging infrastructure. The act of tagging infrastructure requires a fair amount of manual work for each piece of infrastructure in each sub-account. Enforcing tag hygiene can be a challenge of its own.

    Opportunity for an AI-Assisted Kubernetes Orchestrator

    Overcoming the complexity of optimizing cloud compute resource orchestration for the many uses cases for DevOps, DevSecOps and SRE requires a smarter, more responsive approach than traditional approaches that require manual planning and implementation. There is an opportunity to save an average of 60% of cloud spend by using an AI-assisted Kubernetes orchestrator.

    What This Means

    While Kubernetes offers excellent orchestration capabilities, it does not, by itself, assure cloud computing costs are optimized for the many use cases required for DevOps, DevSecOps and SRE. An article by CAST AI indicated 60% of cloud costs could be eliminated by being smarter about the use of cloud resources, no matter the size of the deployments. Given the large number of human and automated users associated with DevOps, DevSecOps and SRE use cases for cloud resources in enterprises, the savings potential can equate to tens of thousands of dollars per month.

    An AI-assisted Kubernetes orchestration capability is needed to process cloud resource changes quickly enough to achieve optimizations at the speed needed for DevOps, DevSecOps and SRE use cases.

    This article explained the landscape of requirements for an AI-assisted Kubernetes orchestrator to optimize cloud costs for DevOps, DevSecOps and SRE use cases. Future articles will discuss a solution for such an orchestrator and detail specific applications of the AI-assisted Kubernetes orchestrator for DevOps, DevSecOps and SRE use cases.