devopsy.kinsta.cloud

Tag: cloud strategy

  • How to Manage Multi-Cloud Infrastructure and Reduce Costs

    How to Manage Multi-Cloud Infrastructure and Reduce Costs

    It’s no secret that the public cloud has been a game changer for businesses. In today’s world, every organization is looking for ways to store data more efficiently, support agile application development and reduce the burdens associated with on-premises data centers.

    The public cloud is essential for meeting those objectives and achieving the higher degree of innovation and digital transformation that many organizations seek. While the shift to the cloud has unlocked unprecedented innovation, it has also created a new layer of complexity and sometimes unexpected costs.

    The Nutanix Enterprise Cloud Index found that nearly every organization (99%) has moved one or more applications to a different IT infrastructure in the past year, and the vast majority (86%) agree that moving applications is both complex and costly. Accordingly, 56% plan to focus on gaining more visibility into their cloud consumption and costs this year, while 52% plan to leverage solutions that minimize cloud waste.

    As Scott Sinclair, senior analyst for TechTarget’s Enterprise Strategy Group explains, “The typical enterprise now has multiple data centers and public cloud providers, and many are also using lots of different colocation facilities and multiple edge locations.” As such, “It presents a new paradigm with companies having to look at different factors and considerations like cost, portability and security because their data is no longer all locked in one room.”

    Organizations must carefully plan their cloud strategy to avoid getting bogged down by complexity and sticker shock. But in most cases, this is easier said than done. The majority of companies are not using a single environment — their infrastructure includes some combination of on-premises and public cloud resources. One of the challenges this creates is additional expenses and complexity associated with data mobility and data protection: Moving data around so that it’s available where and when it’s needed while simultaneously keeping it safeguarded requires careful planning and budgeting. In other words, data has gravity, and unless data movement and orchestration are planned, one can end up stranded when the primary location for a dataset is unavailable.

    Even companies that were born in the cloud have their work cut out for them. Managing different cloud environments might be relatively straightforward for a cloud-native organization initially, but if at some point their data needs to be relocated on-premises to address compliance, data sovereignty issues or budget, it can result in soaring costs if not properly executed.

    With this being said, here are four considerations CIOs should take into account to keep cloud complexity and costs in check from the start.

    1. Have Your Head in the Cloud but Your Feet on the Ground

    To reap the benefits of the cloud, organizations need to adjust their expectations and plan realistically. There’s a false perception that companies can run an application on AWS in the morning, Azure in the afternoon, and Google Cloud Platform at night. In actuality, multi-cloud is a medium-to-long-term strategy that occurs over months or years. Building a cloud operating model with this in mind lets organizations benefit from the flexibility of leveraging multiple clouds while avoiding the cost and complexity associated with trying to do too much too fast with the cloud. When appropriate expectations are in place, hybrid multi-cloud is achievable, affordable, and undoubtedly beneficial.

    2. Learn on Others’ Dime as Much as Possible

    There are several best practices organizations should follow as they begin their hybrid multi-cloud journey. These include things like ensuring key application capabilities have API wrappers, containerizing modern applications as much as possible so they are portable, and automating application deployments through CI/CD pipelines to avoid manual errors and reduce costs. Public clouds have been around for almost 15 years, and designing for the public cloud is now quite well understood across the industry. Still, companies need to be mindful of how they leverage public cloud for certain applications or workloads. For example, modernizing a legacy application portfolio might sound like a good idea in theory, but in reality, it is cost-prohibitive and it will not provide ROI —lift and shift is a much better option for legacy applications.

    3. Standardize, Automate and be Paranoid

    Public cloud environments are fundamentally different from traditional on-premises infrastructure, so organizations need to think about them differently—especially where security is concerned. While a fortified exterior with unfettered internal freedom might be a workable model for on-premises, the same model could spell disaster in the cloud. Host-based security approaches have become more critical in the public cloud. Automation and standardization ensure that security measures are applied consistently across all cloud resources and services within an organization and shorten the window to detect unauthorized behaviors. Organizations must also consider the non-technology aspect of this: training and education for their teams. All teams and departments must be on the same page when it comes to security so they can collaborate effectively on security-related initiatives.

    4. Build in Optionality From Day One

    The public cloud is by far the best place to begin innovation. However, as companies experiment in the public cloud and a smaller portfolio of applications gain traction, enterprises need to adjust to the reality that — for the vast majority of applications — the public cloud will always be more expensive than running them on-premises (or perhaps even another cloud). To avoid lock-in, enterprises must build in optionality for migrating their compute when needed, as well as the mechanism to move their data out of public clouds when needed. Organizations that are flush with cloud engineering talent can do this on their own, but the vast majority will require an underlying platform that’s explicitly designed for data and computation mobility.

    The perks of one platform to run all workloads across clouds, on-premises, and the edge are undeniable: From increased flexibility to optimized performance, compliance, agility and more. By heeding the advice above, companies can keep multi-cloud challenges like complexity and unexpected costs at a minimum and fuel innovation.

  • Most Organizations Benefit From a Mature Cloud Strategy

    Most Organizations Benefit From a Mature Cloud Strategy

    Today’s cloud adoptions are wide and varied. Large enterprises are composed of vast, hybrid multi-cloud strata, often incorporating legacy technology acquired at various times and haphazardly equipped from department to department. But a fractured cloud approach can leave IT wanting in terms of shared automation and standard security policies.

    Not all organizations have addressed best practices around common areas like CI/CD, resource optimizations, or common policies for multiple clouds. And many teams are just getting the hang of the new cloud-native stack. But studies show that a mature approach to cloud operations can pay dividends in the long run—and this approach hinges on cloud platform teams.

    HashiCorp recently released the findings from its third annual State of Cloud Strategy Survey, which surveyed 1,000 technology practitioners on their cloud adoptions. In short, the report discovered that increased cloud maturity equates to increased overall value. Below, I’ll distill the major findings from the report to better understand how cloud-native operations are maturing.

    State of Cloud Maturity

    Most organizations are moderately increasing their cloud investments. Overall, 56% increased their cloud spending in the last year. Increases were much higher for higher cloud-maturity organizations and stilted for lower-maturity organizations. The findings demonstrate general confidence in cloud adoption, even amid economic uncertainties.

    There is also persistent optimism in multi-cloud strategies. In fact, 73% of companies said a multi-cloud strategy helped advance or achieve their business goals. And to successfully accomplish a multi-cloud strategy, respondents ranked security, uptime and availability, infrastructure scalability and regulatory compliance as top factors.

    However, there is still a lot of waste in the cloud. Nearly all organizations (94%) said they have avoidable cloud spending. These expenses most commonly stem from areas like over-provisioning resources, idle or unused resources, cost premiums or a lack of expiration date on cloud resources.

    Benefits of Maturing Cloud-Native Operations

    Overall, there are many reasons for adopting a multi-cloud approach—the report found reliability, cost reduction, security and governance and digital transformation as top motivators. And on average, high-maturity cloud adopters tend to reap the rewards more often, the report found. Some of these top rewards ranged from a stronger security posture to better visibility and increased automation. Furthermore, half of high cloud-maturity organizations reported successfully saving money using multi-cloud.

    Most interestingly, perhaps, is that high-maturity cloud adopters said they are better equipped to attract, motivate and retain talent than lower-maturity cloud adopters (74% compared with 48%). It’s generally easier to pull in talent when operating with attractive cutting-edge technologies that look good on a resume.

    Spotlight on Platform Teams

    Even then, skills shortages remained the top bottleneck in most organizations’ ability to operationalize multi-cloud and set up platform teams. This can be side-stepped by reskilling or upskilling staff, incorporating more consultants or increasing the budget. But the best strategy is to standardize on a common operating model.

    In that vein, investments into the platform engineering concept are rising. In fact, 92% of organizations are adopting, standardizing or scaling platform teams. Low cloud maturity firms tend to lag on platformification, most likely due to lacking the necessary skills to build and maintain internal developer-facing infrastructure, like the tools used to measure and improve developer productivity and satisfaction at LinkedIn. Others are still on the cusp of exploring how to implement it.

    The idea of platform engineering is still taking root, so it was interesting to see how organizations described the platform teams’ roles and responsibilities. The results showed platform engineers commonly take the reins on everything from architecting solutions to tooling acquisition and internal evangelism. Here are the five top-cited roles for platform teams:

    • Develop and standardize a cloud infrastructure strategy (95%)
    • Architect cloud solutions (95%)
    • Create and distribute cloud management, operational policies and best practices (94%)
    • Determine which cloud vendors and/or technologies are used in production (93%)
    • Define and measure site reliability (91%)

    The Path to Cloud Maturity

    In general, companies are still confident about their cloud trajectories. But, getting to a mature multi-cloud state will take work. One area that needs further scrutiny is cybersecurity, as password or credential leakage is now seen as the most prevalent cloud security threat. Organizations will require better DevSecOps best practices to avoid such leaks. That, and certain open source cloud-native tools could also aid security and compliance efforts.

    A mature cloud strategy will also require localizing development efforts through shared platforms and increasing infrastructure automation. On that note, 83% of organizations say automation tools are important or extremely important to operationalize their multi-cloud infrastructure. More automation for cloud-native areas like CI/CD, observability and Kubernetes management could also abstract complexity and fill the skills gap.

    As the HashiCorp study clearly showed, those organizations that have matured their cloud strategy are far better off because of it. They tend to understand their workflows better and can more seamlessly introduce new automation. Now, it’s only a matter of getting there …

  • How to Build an Options-Based Observability Strategy

    How to Build an Options-Based Observability Strategy

    The global pandemic forced companies to accelerate their digital transformations, pushing them toward new technologies and architectures as they struggled to adapt to a changing world. Companies wanted fast development and deployment and were happy to trade off efficiency, reliability and sometimes, security, to pursue their goals. Now that the pandemic is receding in many parts of the world, the priorities are rebalancing as companies grapple with choices they made under fire.

    Observability has emerged as a way for enterprises to better understand sprawling infrastructure and application environments. According to Gartner, “Observability enables organizations to reduce the time it takes to identify the root cause of performance-impacting problems. In particular, and in contrast to traditional monitoring, operators can freely interrogate data post-hoc without the need to pre-program dashboards.”

    This sounds promising and the market responded quickly, but predictably. Large and monolithic monitoring platforms embraced the term and added new features, making them even larger and more monolithic. These monolithic platforms represent a failed choice-based strategy. They assume that all observability data is collected, centralized, integrated and only analyzed by a single tool. Enterprises following a choice-based observability strategy find themselves locked-in to multi-year investments without the flexibility to react to evolving technologies.

    While this has been good for vendors in the incumbent monitoring space, end users haven’t benefited from these enormous platform deployments because the choice-based strategy is built on the faulty assumption that a single pane of glass serves all of your monitoring and observability audiences, from SREs to DevOps and SecOps.

    A choice-based strategy also forces customers into limited options in the future as technology continues to evolve and requirements change. Defaulting to choice-based strategies also leaves little leverage for contract negotiations, data integrations and data access.

    Infrastructure and operations teams need to take a different approach to their observability strategy. Instead of focusing on buying products and making choices, teams need to shift their thinking to creating options. The choices you make today limit your options tomorrow. Tomorrow is unpredictable and uncertain. Taking an options-based approach allows you to be flexible and adaptable today and into the future.

    An options-based observability strategy is built on three pillars:

    • Establishing your observability strategy principles
    • Building composable environments
    • Staging your commitments

    Let’s look at each of these.

    Establish the Principles of Your Observability Strategy

    When asked about their observability strategy, many often leap into detailed plans covering every imaginable use case. They talk about the current state of their infrastructure and how things will be at the end of three or five years, including the skills and functions they’ll need in that time. If you’ve read the above, you’ll recognize this as a choice-based strategy: All the choices they need to make over the next several years are already laid out. This leaves little room for adaptation and options as the world evolves around you.

    Instead, think of your observability strategy as a single principle, or a collection of principles, guiding your observability strategy. Let’s say your core principle is that observability is a key enabler of operational efficiency across SREs and DevOps. We can build on that operational efficiency principle to define what key elements of our strategy has to include:

    • Data sources have utility-like accessibility; always on and available across tools.
    • Metrics are primarily driven by total cost of ownership and optimization.
    • Governance is centralized to the team distributing data to downstream systems.

    These elements are different if your core principle is something like customer intimacy or risk management.

    With principles and strategy in hand, we can focus on the next phase: Composing the observability environment.

    Compose your observability environment

    In an options-based strategy, the key success factor is avoiding large ecosystems that limit flexibility. Many vendors take a “give us everything” approach to observability. These approaches appear to start and end at the destination platform, but they begin even earlier, at data origination. It’s common to see agents only sending data to one destination, limiting the usefulness of the data by locking it into a silo.

    Staying modular means selecting tooling that abstracts the data sources from destinations and puts the power back into your hands. By using an abstraction like an observability pipeline, you can send data from one source to multiple destinations, while managing that data in any way you see fit. For example, this is where your centralized governance can occur.

    When new tools are introduced, upgraded or deprecated, an observability pipeline insulates the rest of your environment and users from those changes. A modular approach also gives you more power in contract negotiations with your other vendors because you’re less reliant on one vendor for all of your observability needs.

    Stage Your Commitments

    A choice-based observability strategy is a large commitment, often taking years. Once you start, stopping becomes impossible. That’s simply unacceptable in today’s environment of uncertainty. Choice-based strategies limit your ability to test, experiment, and learn. At the same time, our infrastructure is critical and it must be reliable.

    An options-preserving approach may involve experimenting with freemium products; only paying once the product’s value has been proven. Cloud-based options are another consideration since they are commonly subscription-based and offer easy try-before-you-buy purchasing styles. Even better, cloud-based options don’t require using your own infrastructure to test new options.

    Every IT team feels the need to react and respond to demands from the business. That urgency to make choices, to solve the immediate problem, can have long-term implications for future flexibility and agility. By structuring your observability strategy around a long-term vision based on preserving options, your team can remain adaptable as technologies and business requirements evolve.

  • Designing Cost-Efficient Cloud Environments

    Designing Cost-Efficient Cloud Environments

    Today, the days of on-premises data centers are mostly behind us, and the cloud has largely taken over with the promise of scalability, flexibility and cost-efficiency. Despite these promises, the cloud often falls short of these ideals. Why?

    Because managing the cloud is hard—especially when it comes to managing its costs. There are no automatic savings the moment you sign up with AWS or any other cloud provider. Instead, realizing cloud savings requires lots of capacity planning, careful analysis, consistent monitoring, accurate forecasting and endless adjustments—it’s enough work to make anyone’s head spin.

    But the rewards make it worth the effort. If you manage your cloud correctly, it offers tremendous savings compared to on-premises environments. However, moving to the cloud without first putting a cost strategy in place can cost your organization millions as you scale in the long term.

    So, what guidelines should you follow to ensure you’re maximizing your potential cloud savings? Here are some common do’s and don’ts you can start implementing—or stop doing—now.

    Moving to the Cloud

    Migrating to the cloud is the first, and the most complex step. So before you get started, bear in mind the following:

    Do: Analyze Your Environment Prior to Migration

    Let’s face it—if you have a disorganized and over-provisioned on-premises environment, you’ll have a disorganized and over-provisioned cloud environment. Unless, of course, you clean it up prior to the big move.

    On the bright side, cleaning up your current, familiar environment is less daunting than doing the clean-up once you move to the new and unfamiliar cloud environment. Therefore, it’s critical to analyze your current environment prior to your cloud migration.

    Start by decommissioning all assets that are not currently being used. For example, you may have a virtual machine (VM) that was provisioned for a particular project and not turned off once that project was finished. As a result, you’d have an application running that is no longer needed. Identifying and removing these resources now will lower your future cloud costs while relieving engineers of future headaches.

    Do: Create a Blueprint for Your Cloud Architecture

    Next, you need to re-architect your application stack. Don’t worry, this task isn’t as scary as it sounds. You’ll need to create a list of the infrastructure you’re using now and find its corresponding infrastructure in the cloud. Say, for example, you’re using multiple dedicated servers for message queuing. If you’re moving to AWS, you’ll need to identify similar instance types in AWS prior to your cloud migration.

    Don’t: Follow the “Lift and Shift” Approach

    It may be tempting, but whatever you do, avoid the “lift and shift” approach. There are certainly ways to optimize your current environment, so simply moving exactly what you have into the cloud is a missed opportunity to reorganize, restructure and optimize performance and costs.

    For example, you may be running VMs that are not being used, backing up unused development servers, or storing data that can be allocated to a low-cost archival storage class. Make sure to readjust your architecture to fit the cloud, not the other way around.

    Governance

    The bottom line is, somebody needs to be responsible for managing cloud costs. Depending on your company size, it can be a team or an individual, but it must get done sooner rather than later.

    Do: Ensure Cloud Spend is Managed by a Specific Individual or Team

    Sticking to a cloud budget is easier said than done, but if you delegate this task to a team or specific individual, it will be their top priority to ensure your company stays on target. They will be responsible for handling cloud budgets, establishing who can and cannot provision resources and monitoring use.

    If you fail to establish governance, you run the risk of having many individuals provisioning resources without any liability or accountability, which results in significant overspend and lots of chaos.

    Don’t: Presume Governance Is Only for Large Organizations

    Think your company’s too small for governance? Think again.

    At least one individual should always be responsible for monitoring your cloud spend and ensuring it stays in line with the allocated budget. This person will work hand-in-hand with finance to create budgets, monitor use, create billing alerts and more.

    Cloud Security

    If you’re migrating to the cloud without thinking about security, you’re making a huge mistake. It is estimated that cybercrime will cost the world over $10.5 trillion by 2025. Even worse, according to Verizon’s recent study, cloud security breaches have surpassed their on-premises counterparts for the first time ever.

    So, needless to say, security should be prioritized when moving to the cloud. Here are some tips to get started.

    Do: Develop a Layered, Multi-Tiered Cloud Security Plan

    Your cloud security strategy should safeguard both your data and IT assets in the event of a cyberattack, while being compliant with the standards and regulations specific to your industry.

    Some cloud security strategies include:

    • Building your solution with a well-architected framework
    • Using solutions like threat detection, automated patching or security auditing
    • Connecting your on-premises network to the cloud using a transit gateway or similar technologies
    • Creating enough firewall rules for traditional systems and web applications

    Don’t: Rely Exclusively on Your Cloud Provider’s Security Controls

    While many cloud providers offer great security solutions, relying on them exclusively will not help you cover your bases. AWS regularly refers to the shared responsibility model, which states that AWS covers infrastructure, but the user must secure their own applications.

    Scheduling Your instances

    The longer you run your servers, the larger your bill will be. And, unfortunately for us, creating a new VM in the cloud has become so easy that many forget to turn them off when they are no longer in use. This results in cloud costs that are up to 66% higher than they need to be.

    So, if you’re looking to cut cloud costs, keep the following in mind when scheduling your instances:

    Do: Automatically Schedule Instances

    Let’s face it, it’s easy to forget about shutting down instances after hours. In fact, it’s so easy, it can happen to even the best of us. Automatically scheduling instances, on the other hand, avoids human error while simplifying the shutdown process.

    AWS’s Amazon Instance Scheduler or Azure’s Start/Stop feature makes it easy to shut down instances from non-production environments during “off hours” and spin them back up once they’re needed. In addition to these tools, you should consider implementing alerting so you can be notified if anything goes wrong in the scheduling process.

    Do: Take Advantage of AWS Auto-Scaling

    AWS auto scaling enables you to take full advantage of the cloud’s elasticity. The technology continuously monitors your application’s capacity needs and automatically adjusts resources to fit its current use. As a result, you don’t have to spin out a large VM for your workload. Instead, you can begin with a low-spec server and add it to an auto scaling group. When demand increases, more nodes will be added to your fleet to accommodate scale. Likewise, when the demand decreases, the extra nodes will be spun down.

    This helps optimize both performance and costs so you’re never paying for resources you’re not using and you always have the right number of instances to run your applications.

    Don’t: Allow Your VMs to Run Continuously

    This may seem obvious, but as we mentioned earlier, many forget to shut down VMs when they are not needed. For example, 9 AM to 5 PM on weekdays may be your peak hours. This means you probably won’t need certain VMs to run on Saturdays or at 3 AM—so why pay for them? Instead, shut down VMs during “off hours” to ensure your savings are maximized.

    Tagging Your Assets

    There’s no getting around it—tagging assets is an essential part of understanding your usage patterns and optimizing cloud costs. Asset tags are metadata labels which can be attributed to individual resources in your cloud fleet to track which application it belongs to. Usually, you can assign up to 50 tags per resource, and they can be organized and named according to your needs.

    When tagging assets, make sure to keep in mind the following:

    Do: Implement a Tagging Strategy Early in your Cloud Journey

    It’s never too early to start tagging assets. In fact, the longer you postpone it, the harder it will become. Once your spend and usage increases, which it inevitably will, you will need to have a tagging system in place in order to determine which team is responsible for each asset (so you can have them evaluate resources and costs), deactivate unneeded resources and more.

    Tags are extremely useful in many real-world scenarios. For example, if you’re not using a specific application, you can search for the tag “application” with a value of the application’s name. You will then see all resources related to that application, so you can easily delete them.

    Additionally, tags can be used to enforce budgets and prevent overspending. Simply set a budget threshold on your tag and set up alerts to notify you when you’re getting close to that threshold.

    Don’t: Embark on Cloud Migration Before Tagging Assets

    Tagging is simple if you do it in the beginning when your environment isn’t so complex. But it’s excruciatingly difficult once your environment is more mature. So, if you’re moving to the cloud, make sure to start tagging beforehand so you don’t have any regrets.

    Do: Use Reserved Instances and Savings Plans

    If you’re on AWS, using reserved instances (RIs) and savings plans can save you up to 72% over the cloud giant’s on-demand pricing. The catch is you have to commit to purchasing RIs one to three years in advance, which means you’ll need to predict your usage needs ahead of time. Despite this challenge, RIs offer tremendous savings for those that use them wisely.

    Don’t: Purchase Reserved Instances or Savings Plans Without Building a Strategy

    When using RIs, it’s crucial to develop a strategy to ensure your savings are maximized. Often, people make the mistake of purchasing many RIs, which are not used. This results in upfront savings, but no return. Make sure to come up with a plan for how you handle reserved capacity. Selling them on the AWS marketplace is a good place to start.

    We move to the cloud for the promise of more flexibility and lower costs. But to actualize that promise, we can’t expect the cloud or our cloud provider to do all of the work for us. Unfortunately, cloud savings are not automatic.

    That’s why creating a strategy that covers costs, security, and other critical aspects of cloud migration should be your No. 1 priority. Even if you’ve been using the cloud for years, you should continue to reassess your cloud cost strategy to ensure it is optimized fully. Start by pinpointing practices that result in cloud waste and creating a game plan to prevent it from happening.

    Keep in mind that new technologies are always emerging, so make sure you are aware of any industry changes which could impact your cloud cost strategy.

  • Strategy vs. Tactics

    Strategy vs. Tactics

  • IT Modernization Yields Business Benefits Even in Early Stages

    IT Modernization Yields Business Benefits Even in Early Stages

    In recent years, with the emergence of newer technologies ranging from the cloud to machine learning, IT modernization has evolved from a replacement of end-of-life infrastructure to an enabler of innovation and business value. It is a complex process that can take months or even years, but a recent survey shows that the effort begins to deliver measurable results almost as soon as an organization executes the first steps on its roadmap.

    In The State of IT Modernization 2020, an IDG Research Services survey of 200 IT executives commissioned last December by Insight Enterprises’ Cloud + Data Center Transformation team, respondents that had completed 25% or less of their initial modernization objectives reported achieving business improvements in each of the eight categories measured. Sixty-five percent had already achieved better quality of service. Significant progress had also been made in improving customer experience/satisfaction (52%), cost savings (50%), uptime (44%) and the ability to create new revenue-generating products and services (42%). 

    Organizations that had completed their initial modernization objectives reported even better outcomes on all eight measures, notably including the ability to extract business value from data (56%) and faster time to market for new products and services (50%). 

    The findings clearly demonstrate that a modernized IT ecosystem is a core building block of business transformation. Whether it’s spinning up a new service or application quickly, doing a deep data dive to identify new market opportunities or using artificial intelligence to improve sales forecasts or warehouse operations, it’s essential to have the horsepower, agility and advanced data analysis capabilities to do the job.

    The survey of CIOs, CTOs, CSOs and IT directors working at organizations with an average of 29,294 employees also revealed a wide range of details about the status of IT modernization efforts. Let’s look at some examples.

    Progress Made

    Fifty-six percent of the enterprises surveyed have either achieved initial IT modernization objectives or have made significant progress toward doing so, while 19% have made moderate progress and 26% are in the beginning stages. Interestingly, even those in the earliest stages are pursuing emerging technologies such as AI, machine and/or deep learning (43%), automation to support scale-out and other cloud strategies (37%), cloud native application development (35%) and public cloud container services (35%). 

    Projects Derailed 

    Despite this progress, the road to IT modernization can be bumpy. Forty-one percent of survey respondents reported having delayed or abandoned some of their 2019 IT modernization initiatives. The top reasons cited were competing priorities (46%) and lack of a clear roadmap or strategy (45%). Other causes included data security concerns (39%), inadequate in-house expertise (38%), poor preparation (29%) and outdated processes or tools (27%). 

    Shifting Cloud Strategy

    Whether they have just embarked on their IT modernization journey or have made significant progress on their roadmap, organizations continue to grapple with optimizing their cloud strategy. The survey showed that:

    • Ninety-two percent of survey respondents increased workloads deployed in the public cloud and 91% in the private cloud in 2019, reflecting the ongoing increase in cloud adoption as well as migration from one platform to another.  
    • Eighty-nine percent switched or planned to switch from an all-private or all-public cloud strategy to a hybrid cloud approach – and 87% adopted a multicloud approach using more than one public cloud provider – as they attempted to find the right path for their cloud needs.
    • Eighty-four percent moved select workloads from a public cloud to an alternative cloud or non-cloud location, suggesting a failure to perform appropriate cost modeling, workload/platform alignment and other due diligence before the initial move.

    Poor Public Cloud Cost Controls

    More than two-thirds of survey respondents reported that public cloud costs exceeded their expectations, with cost overruns for roughly half that group ranging from 51% to 100%. Most of the causes can be traced to inadequate due diligence, governance or cloud optimization efforts, often due to a lack of in-house expertise in these areas. Examples include: unexpected data egress charges, subscribing to more cloud resources than required, failure to take advantage of vendor volume discounts, lack of knowledge to analyze monthly cloud costs and failure to optimize cloud workloads to extract maximum value from cloud platforms.

    Managed Services

    Adoption of managed services is widespread at every stage of the IT modernization journey, with an average of 95% of respondents outsourcing one or more IT operating environment functions to a managed services provider and 84% outsourcing cloud management. 

    Top Challenges Faced

    Governance is the number one modernization challenge in 2020, according to survey respondents, with new strategies and processes required to ensure control over areas ranging from cloud deployments to continuous integration and continuous delivery (CI/CD), automation and orchestration, and infrastructure as code. Optimizing and managing the centers of data that are replacing the traditional data center ranks as number two, with workloads located on-premises and in multiple clouds as well as on the edge.

    At the same time, most IT organizations have long-standing cultural and technological norms that need to change in order to move modernization initiatives forward. Hurdles cited elsewhere in the survey range from IT silos to outdated processes and tools, understaffed or underskilled DevOps teams and lack of enabling technology for containerization and automation.

    These challenges also need to be overcome in order to take full advantage of today’s technology to drive innovation, business transformation and the competitive edge that can help businesses both survive and thrive in today’s economy.

  • Making Your Cloud Work For You

    Making Your Cloud Work For You

    Does your cloud work for you, or do you work for your cloud? Given the enormous dependency and costs associated with cloud computing, that is a question more and more DevOps teams are asking these days. After more than a decade of pressure from higher-ups to move workloads to the public cloud, DevOps teams are now facing the reality that there is such a thing as too much cloud.

    Don’t take that the wrong way. I’m not here to tell you the cloud is inherently bad or we should return to the days when all our critical workloads ran on bare-metal servers housed in a closet in the back of the office. Public cloud services offer a number of critical benefits and DevOps teams should take advantage of them.

    However, to use the cloud responsibly, it’s crucial to control for two risks. The first is cloud computing costs, which easily can get out of hand if not managed properly. The second is a rigid dependency on public cloud services that undercuts agility and makes it more difficult to deploy applications at scale—which is exactly the opposite of what the cloud is supposed to do.

    In this article, we’ll take a look at what causes each of these risks and how DevOps teams can respond to ensure their cloud strategy actually delivers value.

    Risk 1: Cloud Computing Cost

    You’ve probably heard a lot of talk about how the cloud saves money. If you use the cloud effectively, that is true. However, because of the complexity of cloud computing cost structures and the difficulty of comparing cloud computing costs to on-premises costs, it’s easy to end up with a cloud hangover after paying a much higher cloud computing bill than you bargained for.

    There are several distinct challenges at play in predicting and understanding the true costs of your cloud. Let’s take a look at each one.

    Never-Ending Cloud Computing Costs

    When you move workloads to the cloud, your costs vary month by month and are spread out over time. At first, moving to the cloud feels like a great money-saver because it frees you from having to make large, upfront purchases of on-premises hardware. However, just as leasing a car ultimately costs more in the long run for most people than owning, paying monthly for cloud services hosted on someone else’s infrastructure adds up. If you ignore this fact, you can end up failing to appreciate the true cost of your cloud computing bill over the long term.

    Unpredictable Cloud Costs

    Another fundamental challenge of cloud computing cost compared to on-premises is that, in the cloud, costs structures are opaque and unpredictable. Public cloud vendors change the prices of services without notice. The same service might cost more in one cloud region than another, while some services have multiple fees attached. For example, if you store data in the public cloud, you pay not just a per-gigabyte cost to store it but also fees whenever you move the data. This adds up to tremendous difficulty in predicting your true cloud computing bill.

    On-premises costs are not entirely straightforward to predict either, of course. There are some fluctuating expenses, such as the cost of electricity. However, the lion’s share of on-premises computing costs is the hardware itself, which is a very simple and tangible expense. It’s also a one-time expenditure that you can amortize over the life of your servers. Once you have purchased a server, you don’t have to worry that its effective cost will change month to month, as you would with a virtual server in the public cloud.

    Overlooked Workloads

    In the cloud, it’s trivially easy to spin up a new workload. It’s also easy to leave a workload running after you no longer need it—and public cloud vendors don’t go out of their way to notify you when you have resources that are activated but sitting idle. You can’t blame them; that would be like a restaurant telling you you’re ordering too much food or a builder telling you your house is bigger than you need.

    If you don’t carefully manage your cloud workloads, they add up to extraneous and unnecessary costs.

    To be sure, you can have unnecessary workloads running in an on-premises environment, too. But the difference is there is no substantial cost increase on-premises that accompanies each extraneous workload. You’ve already paid for the servers and you don’t get a bill for every service you have running on your own infrastructure.

    Risk 2: Lack of Cloud Agility

    Beyond unnecessary costs or inefficient cost structures, relying too heavily on the public cloud also undercuts the agility of DevOps teams.

    When you run a service or workload in the public cloud, moving it to different infrastructure can be challenging. Not only is it usually difficult to migrate from one cloud to another, but also doing so entails adapting to a new cost structure and possibly paying more for the same set of services.

    There is an irony here: Conventional wisdom suggests that one of the main reasons to migrate to the cloud is that the cloud is inherently more scalable and agile than on-premises infrastructure. That may be true in some cases, but when you factor in the cost and the difficulty of migration from one cloud to another, the cloud quickly starts to look less agile and scalable.

    On-premises infrastructure doesn’t always scale painlessly either, of course. I don’t dispute that. But the cloud doesn’t always live up to the hype when it comes to scalability and agility. On-premises and cloud-based infrastructures both have limitations in this regard.

    Cutting the Cord: Making the Cloud Work For You

    Now that we’ve identified the inherent (and underappreciated) cost and agility challenges of cloud computing, let’s consider solutions.

    Optimize Cloud Computing Costs

    Cost optimization is something you should always do on any infrastructure, and the cloud is no exception.

    There are many guides out there on cloud cost optimization. Some vendors also offer tools designed to monitor your cloud workloads and identify underused resources or help you right-size cloud service instances. These are all good ways to help reduce your cloud-computing bill.

    Be Cloud-Agnostic

    Another useful strategy is to architect your cloud workloads in a way that makes them as cloud-agnostic as possible. Instead of deeply integrating with a particular cloud vendor’s services, rely on third-party tooling whenever you can.

    For example, if you run containerized apps in the cloud, run your containers in standard virtual server instances and use a third-party registry instead of using the container registry and managed container service of one cloud vendor. This will require a bit more work on your end, but it will give you the freedom to move your workload to another cloud easily. It also enables cost-efficient scalability, because you are not beholden to the cost structures tied to the vendor’s managed container service. Rather, you are using only virtual server instances (and perhaps some storage to go along with them), which have much more flexible pricing on public clouds.

    Don’t Be Afraid of On-Prem

    My final recommendation, and my most important one, is to embrace on-premises infrastructure.

    Again, I say this not because I want to move backwards and return to a world where everything runs on-premises. I’m not anti-cloud.

    However, from a cost and agility perspective, the public cloud is not the best fit for every type of workload. Workloads that have very convoluted cost structures in the public cloud—or that would be difficult to run in a public cloud without sacrificing a great deal of mobility and scalability—are often a better fit for on-premises environments.

    You may be thinking that embracing on-premises means sacrificing all of the advantages of the cloud or having to forgo cloud-native workloads. Fortunately, that’s not the case. There are software vendors that offer the services of a public cloud, but on your own enterprise infrastructure using the public cloud APIs.

    Thus, you can obtain the cost and agility benefits of on-premises infrastructure (not to mention the security advantages) while still running cloud-native applications. In fact, you don’t even need to overhaul your CI/CD pipeline; you can simply deliver your cloud-native apps onto on-premises infrastructure that runs services designed to be compatible with those of the public cloud, even though they are hosted on your own servers.

    Conclusion

    Don’t move workloads to the cloud just because it seems like the thing to do or because someone told you it’s necessarily better. Some workloads work better in the cloud while others are best hosted on-premises. An all-in cloud strategy is not typically the most cost-efficient or agile architecture you can adopt.

    — Ariel Maislos

  • Kubernetes Adoption: Are You Ready?

    Kubernetes Adoption: Are You Ready?

    Enterprises are rapidly embracing a cloud-first strategy and microservices play a pivotal role in this journey. But enterprises are achieving various levels of success, measured by many factors includingmaturity of DevOps in the enterprise, ability to identify the right candidates for microservices, selecting the appropriate container management platform, adequate tooling and, finally, cultural shift in design thinking.

    As there is plenty of material around microservices adoption and strategy, this article focuses on the container management ecosystem, which plays a critical role in the success of microservices adoption. Today, Kubernetes has become the de facto platform for container orchestration. Most public cloud providers offer Kubernetes as a service in some form to abstract the complexities of managing Kubernetes as a platform.

    Currently, we see three broad patterns of how enterprises are adopting Kubernetes within their organizations.

    Pattern 1: Kubernetes as a Managed Service

    While Kubernetes makes container management somewhat simple, it is still a complex beast to understand and manage as a platform. Enterprises that have already embarked on a cloud strategy find it easy to test the unchartered waters of Kubernetes by leveraging Kubernetes-as-a-service provided by their cloud providers. It enables them to understand the impact of Kubernetes on their respective application architecture strategy and identify the gaps in their systems (such as the maturity of DevOps management, security management and release management) as well as their monitoring capabilities.

    Pattern 2: Kubernetes as a Turnkey Solution

    Certain enterprises driven by industry regulations and are technology-focused (with considerable experience in other container technology solutions), have shown interest in setting up Kubernetes as part of a private cloud or on–premises with a view to avoid vendor lock-in and limited control associated with managed Kubernetes. There are many such turnkey solutions out there to choose from.

    Pattern 3: Self-hosted Kubernetes Platform

    This category is small compared to the other two categories. However, there are a few enterprises that fully embrace the open source software development model and contribute to Kubernetes community. There are tools and frameworks that can enable the enterprises to setup and manage Kubernetes on their own.

    There are advantages and constraints in adopting any of the above approaches. The decision regarding which strategy to choose depends on the maturity of the enterprise and their business strategy.

    Challenges in Adoption

    Some of the key challenges to be considered, irrespective of the adoption pattern selected, include:

    1. Namespace management: Namespaces play a key role in managing the isolation across application domains and environments, providing controlled management of resources and user management. Bounded contexts can be linked with namespace definitions and standards. It is important to define proper naming guidelines to drive namespace management across clusters.
    2. Resource management: It is necessary to define resource utilization (resource quota) guidelines to ensure the containerized applications co-exist without being eliminated due to resource violations at runtime.
    3. Policy management: It is critical to define appropriate policies including cluster access controls, service access controls, resource utilization controls and secret access controls.
    4. Audit and compliance: It is important to audit the platform for patch levels, secret stores, compliance against the security vulnerabilities, encryption of secret stores, storage volumes, cluster policies, role binding policies and user management controls.
    5. Chaos testing your platform: It is necessary to subject the platform to chaos testing to ensure the robustness of the cluster. It also helps to test the stability of the containerized applications and the impact of crashing these containers. It will also provide vital information about how the platform behaves during high loads or when resources are unavailable for the platform.
    6. Managing the deployment manifests: Kubernetes follows declaration-based management, which means that every object or resource instruction is described through declarative manifests. This leads to versioning complexities, prone to human errors and data corruptions. It is necessary to leverage tools or create custom utilities to manage these manifests.
    7. Observability of the platform: While Kubernetes provides various mechanisms to monitor its own internal components, it does not recommend a standard monitoring approach. It is necessary to introduce well-defined health management standards while designing the microservices. Include appropriate probes for liveness and readiness probes in every containerized application deployed on Kubernetes cluster. Integrate the probe-generated metrics and platform-generated metrics with an external monitoring platform to have comprehensive observability of the cluster.
    8. Continuous deployment of services: It is not recommended to use kubectl-based deployments in a large-scale production setup. Instead, use some of the established open source frameworks specifically built for Kubernetes (such as Helm or JenkinsX) to manage seamless deployments.
    9. Archiving and backup: Kubernetes uses etcd as its internal metadata management store to manage the objects across clusters. It is necessary to define a backup strategy for etcd and any other dependent persistent stores used within the Kubernetes clusters.
    10. Container security management: Kubernetes deploys the applications by downloading the respective images from a pre-defined image repository. It is the responsibility of the repository ecosystem to ensure the image provenance of the images being deployed. Continuous security must be included as part of DevOps pipeline to ensure containers are well-managed.
    11. Service mesh support: Service mesh plays a critical role in streamlining the service to service communication. It abstracts the service level access controls and security management between services through externalized policies. It also provides routing and load balancing features. It is necessary to choose an appropriate service mesh that is compatible with the Kubernetes cluster as well as the underlying infrastructure.

    Conclusion

    Kubernetes makes the container operational aspects simpler, but it requires a methodical approach and best practices to ensure smooth maintainability, as well as seamless developer interaction. For any enterprise which are in a transition journey toward adopting Kubernetes, it is imperative to have a strategy for Kubernetes adoption to ensure success.

    — Sreekanth Nyamars

  • Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Cloud Orchestrators: Beneficial in a Multi-Cloud Environment

    Recent outages of leading cloud providers affecting thousands of business worldwide, such as the Amazon Web Services S3 outage that occurred in late February, have forced many CIOs and CTOs to think hard about their cloud strategies, including whether a multi-cloud environment would be of benefit.

    ROI and Business Impact

    During AWS’ four-hour disruption, S&P 500 companies lost $150 million to $160 million, according to analysis by Cyence, a startup that models the economic impact of cyber risk.

    Web monitoring company Apica, which watches internet performance issues worldwide, discovered that 54 out of the top 100 internet retailers were impacted with a decrease of 20 percent or greater in performance, and three websites went down completely—Express, Lululemon and One Kings Lane—resulting in a high impact in business.

    During this outage, according to Apica spokesperson, Apple and other ecommerce sites were likely spared for an easy reason: They have designed their sites to spread themselves across multiple cloud vendors, so if a problem crops up in one cloud service, it doesn’t hurt them. This is, naturally, the recommended way to use a cloud service.

    Apple, Walmart, Newegg, Best Buy, Costco and, surprisingly, Amazon/Zappos were not affected by the outage.

    Organizations have since started looking for different means to avoid data loss and downtime and to better support different applications, not to mention resilient application support, customer management and data analytics. This is where multi-cloud computing can help solve the challenges and which focuses provisioning, managing and monitoring workload across many clouds.

    Multi-Cloud Computing

    Multi-cloud computing is termed as the use of more than one cloud environment, all of the same type or a mix of types, to satisfy business requirements. An enterprise can choose which workloads can be moved to different clouds, depending upon the service offered by cloud vendors, matching the business need.

    This article discusses the need of multi cloud adoption, its benefits and challenges in managing multiple cloud environments and how multi-cloud orchestrators help solve the challenges.

    Market Trend

    According to research firm IDC, by 2020 more than 85 percent of enterprises will adapt to multi-cloud architectures encompassing a mix of public cloud services, private clouds, community clouds and hosted clouds, driving up the rate and pace of change in IT organizations.

    According to research firm MarketsandMarkets:

    Cloud Model 2016 2021
    The Multicloud management market $939.3 million $3.4 billion (compound annual growth rate of 29.6%,)
    The hybrid cloud market $25.28 billion $84.67 billion

     

    What is Driving Multi-Cloud Adoption?

    All workload and business requirement cannot be the same—this is one of the primary drivers of a multi-cloud reality.

    Unique Needs: You can run each workload where it performs best, for the lowest cost.

    Legacy Apps: You can avoid the pain of migrating legacy apps to a new platform.

    Desire to Diversify: You can avoid vendor lock-in and latency while creating redundancy.

    Benefits of Multi-Cloud Computing

    • Flexibility: Companies can deploy to public, private and hybrid clouds using a range of services.
    • Reduce the expenditure: Competitive prices and services from different cloud providers enable companies to achieve optimum cost expenditure.
    • Enhanced autonomy: Companies avoid keeping all their IT workloads in one cloud provider’s basket.
    • Customization and enhanced IT performance: Customization leverages the best-of-breed capabilities from multiple cloud vendors.
    • Migration: Containers and microservices-based applications can be migrated easily across clouds.
    • Hardware diversity: Relying on multiple locations and multiple providers significantly reduces the chances of impacting QoS.
    • Avoid data loss and downtime: Using more than one cloud services helps an organization avoid data loss and downtime attributed to a breakdown in any single component in hardware, software, storage or network.
    • Multiple Geo Availability: Companies can leverage cloud vendors’ data centers in multiple geographies, enabling to scale the business.

    Challenges of Managing Multi-Cloud Environment

    While there’s a lot of talk about moving things between clouds, the reality is it’s still fairly new. Though clouds have become smart enough to put an end to data lock-in, every vendor deployment comes with its own set of challenges, such as unique portals and processes that companies need to manage and can be put into three different categories.

    Technical challenges

    • API: No single model of integration or infrastructure automation can work, as each cloud provider will provide a different API to access different cloud services.
    • Behaviors: There are many differences in how clouds behave for common actions or under certain circumstances. For example, some clouds automatically provision storage upon launch of a server or instance, while others do not.
    • Resource sizes and types: Each cloud provider will offer different sizes and types of compute, storage and network resources; hence, the IT team must think about provisioning with optimum resource size and type needed for their workloads.
    • Operating system images: Each cloud provider will provide a unique set of operating system images, which makes it difficult to run the workload using the same image in other cloud.
    • Hypervisors: Each cloud provider leverages different, and sometimes proprietary, hypervisor options.
    • Application stacks: Some cloud providers may provide a selection of common, preconfigured application stacks (such as LAMP or Java or .NET).
    • Add-on services and features: Each cloud provider will offer extra add-on services and features above and beyond basic compute, network and storage resources. These may include load balancing, application servers, analysis tools or databases.
    • Security capabilities: The access control capabilities will vary across cloud providers, becoming more complex if different providers demand different password complexities or authentication measures.
    • Network Capabilities: Each cloud offers different ways to define subnets, security groups and network gateways, increasing difficulty in network planning.

    Operational Challenges

    • Testing: Deploying apps to multiple clouds requires platform-specific testing, which needs separate automate tests targeting multiple cloud platforms.
    • Tool diversity: DevOps tools have to keep pace with the rapid changes being made to the platforms.
    • Maintaining security and governance: Companies will need to go through rules and regulations of each service provider to adhere to security compliance.
    • Managing applications and infrastructure configurations across multiple cloud stacks: This can be difficult since the cloud platforms do not share a common API, which exposes different service definitions and billing models.
    • Technical support and expertise: Extra administrative work and research is required to to determine the best provider and whether its services are compatible.
    • Geo-availability: Expand the business into new markets can be a challenge, as not all cloud providers have global footprints and offer data centers only in limited locations.

    Business Challenges

    • Cloud brokers: Managing cloud brokers is an additional cost while using multiple clouds.
    • Billing and Pricing: Each cloud provider offers unique pricing models as well as different billing capabilities, which necessitates the need for governance and cost optimization, providing summary along with detailed cost tracking across clouds.
    • Skill sets and training: A lack of skill set and expertise in different clouds in the organization can lead to outages of workloads and increase cost/effort.
    • Planning and execution: It can be difficult to choose the services that match a company’s business needs, pricing, governance and team’s expertise.

    How a Multi-Cloud Orchestrator Helps

    Regardless of the challenges, multi-cloud environments are growing, thanks in part to multi-cloud orchestration tools, which can prove to be a right fit to address above discussed challenges.

    These orchestration tools have the capability to make multiple cloud providers look like a single provider ensuring configuration of all cloud dependencies within one configuration model. These tools enable companies to automatically deploy and manage multi-cloud environments.

    Some of the big players in this segment are RightScale, OneOps, Cloudify and IBM Cloud orchestrator, which provide a standard set of interfaces and capabilities across a multi-cloud environment.

    We have identified some parameters which current multi-cloud management platforms are well-equipped to handle:

    • Planning and Execution of an application from design to transition to deployment.
    • Installation & configuration of infrastructure packages & services in an automated way.
    • Provisioning of application environment.
    • Deployment plan and execution.
    • Cost Management: Suggestion of cost effective cloud services and single dashboard to track the cost associated with different cloud services.
    • Monitoring of entire application stack.
    • Security & Governance as to who can view, create, execute environment related activities.
    • Blue-print Templates which can be easily reused to create a new environment.
    • Reporting: View a report of instances that are consumed by your organization across multiple clouds.

    Conclusion

    Multi-cloud orchestrator tools help address some of the above  challenges to configure, provision and deploy several cloud environments, as well as integrate service management from a single, self-service interface.

    Though present multi-cloud orchestration tools offer a more time- and cost-effective solution to manage different cloud providers for organizations to focus on larger business objectives, virtually all products in this category are young—bugs and inconsistencies can and will occur. Additionally, security can be a concern for many of the popular orchestration tools. Many APIs offered are not securely encrypted by default and need to have SSL added separately.

    We can say there is still a huge scope of improvement for multi-cloud orchestration tools to build more secure, easy-to-set up standardized workflows across different cloud providers to cover the challenges which multi-cloud computing era offers.

    About the Author / Rashi Sharma

    Rashi Sharma an architect working with Technology Office in HCL Technologies. She has expertise in AWS, DevOps consulting & configuration management methodologies. She is associated with DevOps COE, working on design and Development of DevOps solutions.