devopsy.kinsta.cloud

Tag: Cloud Computing

  • AWS Outage and App Resiliency: Did a Roomba Replace the Canary?

    AWS Outage and App Resiliency: Did a Roomba Replace the Canary?

    Canaries were once sent into coal mines as an early warning sign against danger—for me, it was my Roomba failing to automatically search out dog hair and clean the floor under my sons’ dining room chairs. Cloud-enabled apps also were acting “weird”. Some were down, while others were just slow—although, in my view, slow may as well be down; who has the tolerance to wait for an application to load?

    What caused this headache felt across the internet? An AWS disruption.

    In the days since the December 7 outage, I’ve had a number of conversations with CIOs, colleagues and other industry analysts and many of our shared concerns remain unanswered. Here are a few quick thoughts on the latest us-east-1 outage.

    Understanding AWS SLAs

    It’s important to remember that AWS requires instances/apps be deployed across two or more regions for redundancy and resiliency. And an SLA is not only a way for service consumers to gauge the value they’re getting for their money, it’s also the contractual agreement between a cloud service provider (CSP) and a customer. It outlines the uptime, availability and performance standards to which a cloud service will adhere. It may also specify that the service provider’s helpdesk will respond to an outage within a set amount of time. Amazon has very clear SLAs. If a customer receives less than 99.99% uptime in a given month, the company will provide credits to their account.

    However, there are three things to keep in mind:

    A 99.99% uptime agreement still means you are willing to tolerate services being down for almost four and a half minutes per month (53 minutes per year), and you must architect your AWS instances and applications in a way that meets the AWS SLAs. The third point is that, in AWS’s view, the outage wasn’t their fault.

    Outages Don’t Just Impact Startups and Organizations With Poor Planning Practices

    The cloud allows organizations to regularly make budget versus resiliency decisions. However, the recent AWS outage didn’t just impact born-on-the-web startups. Mature businesses like Disney, McDonald’s and Amazon itself were impacted by the outage. These technology-first companies aren’t sacrificing budget over resiliency. They understand that they are technology companies—they have large IT budgets that represent this priority and were still blindsided.

    The recurring question is why all these organizations were crippled by a single Amazon region going down? Was it poor architecture? Did these AWS customers not fully understand AWS’ SLAs? Did they choose budget over resiliency? 

    Amazon as an Enterprise Platform

    Adam Selipsky’s keynote and industry analyst Q&A at re:Invent 2021 made it clear that AWS is completely focused on the enterprise. Amazon understands the needs of the DevOps community, but they are still working on developing their approach to the enterprise. Google Cloud recognized the same shortcomings in its own organization and brought Thomas Kurian from Oracle to build up the company’s enterprise and IT industry persona.

    Everyone in the technology industry understands that outages and slow performance happen, but they expect service providers to provide best practices and avoid downtime. In response to Selipsky’s re:Invent keynote, Linda Jojo, executive vice president of technology and chief digital officer for United Airlines, said that the airline settled on a “one cloud” approach. Surely United Airlines can’t tolerate regular downtime.

    My View

    December 7, 2021 won’t live in infamy for AWS; we have seen plenty of other outages.

    Application resiliency is still an emerging area of focus. In the past, the focus was on platform and data center uptime; however, in many cases, developers have no control over the infrastructure. Therefore, teams need to focus on the resiliency of an application and assume that the underlying IaaS (cloud infrastructure) will fail for one reason or another.

    In addition, Amazon needs to offer more opinionated offerings. Disaster recovery and failover should be built into every level of AWS. Software companies shouldn’t be forced to sign up for multi-region deployments, but AWS should at least be prescriptive with best practices that advise such a practice.

  • NetApp Survey Shows Hybrid Cloud is Maturing

    NetApp Survey Shows Hybrid Cloud is Maturing

    A small survey of 79 midsized to large enterprises conducted by NetApp suggests enterprise IT organizations might finally be embracing hybrid cloud computing beyond use cases involving backup and recovery.

    The survey finds 20% of respondents are currently employing both on-premises and cloud resources to support the same workload in a production environment, with another 17% planning to do so within 24 months.

    Darnell Fatigati, senior product marketing manager for hybrid cloud at NetApp, noted that a hybrid approach to cloud computing will dominate with more than three-quarters of respondents reporting their organization plans to operate a hybrid cloud environment for the foreseeable future. Only 17% expect their organization to eventually migrate all their IT environments to the cloud.

    A major factor in the decision to not migrate all workloads to the cloud is the amount of data gravity that legacy applications running in on-premises IT environments exert, noted Fatigati. The amount of effort required to successfully migrate terabytes and even petabytes of data into the cloud is simply too great, he added.

    The primary benefits of hybrid cloud computing cited by survey respondents are faster innovation (26%), increased responsiveness (25%) and increased collaboration (22%). Survey respondents also noted they are looking to improve infrastructure flexibility and scale (27%), optimize costs (21%) and improve data accessibility (13%). Data protection involving disaster recovery, backup and archiving remains the most widely employed use case for hybrid cloud, with 29% either employing it today or planning to do so in the next 24 months.

    Most hybrid cloud computing environments today consist of multiple clouds and on-premises IT environments that are managed in isolation from one another. The fact that more organizations are now starting to deploy the same workload across both a cloud service and an on-premises IT environment has significant implications for DevOps teams that will be required to manage those workloads. Most DevOps workflows today do not span multiple platforms. However, as more organizations become impacted by the occasional cloud outage, the level of resiliency enabled by hybrid cloud computing is becoming a higher priority.

    In many cases, the shift to hybrid cloud computing was accelerated by the COVID-19 pandemic that drove many organizations to increase the number of workloads deployed in the cloud. Now, heading into 2022, those same organizations are looking to reduce IT costs by centralizing IT management as much as possible, noted Fatigati. Each time an IT organization adds a new platform, the tooling and personnel required to manage that platform increase the total cost of IT for any organization. Much of the shift to hybrid cloud is being driven by C-level executives looking to reduce those costs.

    It may be a while before most enterprise IT organizations are able to deploy workloads across multiple platforms. However, as both cloud and on-premises IT environments continue to evolve and as more platforms deployed in local data centers are increasingly managed using a cloud operating model, the way those platforms are accessed on demand will continue to converge. In fact, there may come a day when the term cloud computing itself disappears from the IT lexicon as every IT platform, by default, leverages one type of cloud or another.

  • What Developers Need to Know About Edge Computing

    What Developers Need to Know About Edge Computing

    More and more companies are living “on the edge” as they move from “I’ll think about edge computing” to “I don’t think our business can optimally grow and compete without edge computing.” Developers will play a key role in helping organizations use the edge, but their effectiveness will depend on having edge-aligned processes, products and people in place.

    Edge computing takes place near the physical location of either the user or a data source. It’s one way that organizations can use and distribute a common pool of resources across multiple locations. The edge model provides users with faster, more reliable services while expanding the potential of hybrid cloud computing for organizations. Customers and businesses alike will benefit from the way in which edge computing optimizes the use and application of artificial intelligence and machine learning by running data-intensive applications closer to the data source.

    While it is in many ways a question of architecture, applications are key to effectively exploiting the edge. Here are some of the things developers—and their organizations—need to know.

    Edge computing and cloud computing are not mutually exclusive. The best solutions will leverage both platforms. For example, centralized computing might be used for storage and compute-intensive workloads, while edge computing would be used to exploit data at the source, in near-real-time. Infrastructure and company culture need to be in place to support this, but developers must be thinking in terms of building applications that can cross and bridge computing platforms.

    Consistent tooling is essential. Developing for legacy IoT was very specific and required specialized tools and skills. The modern edge, in contrast, is part of a technology continuum, and developers need tools that they can use across that continuum, including:

    • Provider/enterprise core: The “non-edge” tiers, owned and operated by public cloud providers, telco service providers or large enterprises.
    • Service provider edge: Tiers are located between the core or regional data centers and the last mile access.
    • End user premises edge: Tiers on the end-user side of the last mile access can include the enterprise or the consumer edge.
    • Device edge: Standalone (non-clustered) systems that directly connect sensors/actuators via non-internet protocols. This represents the far edge of the network.

    Containerization enables flexibility, scale: Linux container technology wasn’t built for the edge, but the model fits perfectly with edge requirements for modularity, segregation and immutability. 

    Keep an “open” mind. Open APIs open up new opportunities. Developers using open APIs can access real-time data programmatically, making it possible to build applications that can leverage data as it’s “born.” Likewise, a focus on open source development tools and platforms will help to ensure that organizations can continue to leverage the edge as the model evolves. 

    What’s different is the devices. Developing for the edge is just like developing for any other platform–except that developers must write consistent and secure code that can be seamlessly copied to all device types. 

    Edge computing may not start with developers, but developers will play a huge role in organizations’ ability to leverage the edge. A focus on flexibility, openness and the future will help ensure that developers build applications that fully exploit and expand the edge advantage. 

  • Edge Computing: Tech’s Next Trillion-Dollar Opportunity 

    Edge Computing: Tech’s Next Trillion-Dollar Opportunity 

    Even as technology continues to move into the cloud, a simultaneous shift is already underway in the opposite direction as computing increasingly moves to the edge. One key reason: by 2025, the number of connected devices in use is expected to exceed 56 billion units, according to IDC. Edge computing is not a successor to the cloud, but another expansion of technology’s reach that represents an exceptional opportunity for investment and growth.

    As edge-device and computing adoption continues to skyrocket, organizations need to process the proliferating data from these devices locally so they can act on it in real-time. This will require investments in edge-adapted infrastructure and related tools and platforms. Enterprise technology is about to be transformed yet again — the need to process and analyze some data at the point where it is both created and consumed is becoming a business requirement as mandatory as moving other parts of the technology stack into central locations in the cloud.

    Organizations already must deliver compelling customer experiences with edge devices based on data that must be continuously refreshed. The alternative—uploading and downloading data to and from a cloud service or local data center—often takes too long. Whether the data is on a consumer’s smartphone or a manufacturing floor, organizations need to process and analyze data as near as possible to the point where a real-time data-driven response is required.

    The competition to provide these capabilities is already intense. Many vendors—ranging from cloud service providers to telecommunications carriers to longtime providers of server and storage infrastructure—view edge computing as their next trillion-dollar opportunity.

    Why We Compute at the Edge

    Edge computing has been around for decades in various forms. There are countless examples of standalone software being deployed on, for example, devices used on factory floors that automate various aspects of a manufacturing process. In recent years, many of those systems have been connected to the Internet to enable organizations to collect and share data more easily. The challenge now is that the amount of data being generated at the edge often exceeds the point where it is practical to transfer that volume of raw data across a wide area network (WAN). Platforms that can process and analyze large amounts of data at the network edge are required. The aggregated results of data processed on an edge platform can then be shared more efficiently with other applications running in the cloud, in an on-premises IT environment or even on the network itself.

    Low-latency requirements are today’s biggest challenge. In many scenarios, an application running on a gateway at the edge of a telecommunications network needs to be able to respond in a fraction of a second to a mobile computing application’s request for data. In other circumstances, an edge application is driving an automated factory operation that needs to dynamically adjust to analytics processed at the edge of an extended enterprise.

    There are even more advanced use cases, some of which are described below. These include in-car computers that process computer-vision data in real-time for driverless vehicles and robotics applications that promise to transform manufacturing.

    Hardware Advances Enable Edge Computing

    The often competing demands of low-latency network connections, high-power computing and large storage requirements are driving innovations in edge hardware.  Electric carmaker Tesla, for example, has added custom-made devices to its processors capable of pre-processing massive amounts of data, performing machine learning inference to make quick driving decisions and predictions and even do some deep learning model training on the vehicle itself–before sending a subset of the data to central systems to do even more training.

    Earlier this year, Tesla unveiled a processor with six billion transistors. According to the company, its device boosts performance by 21 times compared to the Nvidia GPU it replaced in its Tesla Model S, Model 3 and Model X models. These powerful devices are used in addition to CPUs from traditional providers such as AMD and Intel for workhorse applications like infotainment.
    With this computing power at the edge, a Tesla car can process sensor data that allow it to recognize and self-pilot around pedestrians, other cars on the road, emergency roadside signage and potentially hazardous moving objects. This sensor data is also processed with pre-loaded mapping data and GPS connectivity. Additionally, Tesla’s in-car computers relay information over Tesla’s network to massive storage facilities where the data is analyzed to improve Tesla vehicles’ self-driving and other functions. Improvements to the vehicle’s software stack are then downloaded to it over the network.

    Healthcare is an example of a sector with similar needs for advanced machine learning-taught devices and software. Images from MRI and other scanning devices with inference-computing capabilities deployed at numerous locations would also require computing power and network infrastructure similar to that which Tesla’s cars need. Most hospitals, however, don’t have the interest or wherewithal to build their own powerful edge computing hardware and will need to consume this capability from technology vendors.

    As advances in semiconductor circuits approach seven nanometers and smaller, the ability to run applications at the edge in an energy-efficient manner becomes more realistic for a wider range of organizations. With each new iteration of processors, the total cost of edge platforms will continue to decline while the amount of horsepower available to run applications steadily increases.

    Networking at the Edge

    Regardless of how much data is processed and analyzed at the edge, the sheer volume of data creates more demand for network bandwidth and, consequently, the potential for bottlenecks. One main bottleneck is at the backhaul—the stretch between the edge towers and central servers and network. Whether tomorrow’s edge network infrastructure will consist of 5G, more ultra-powerful WiFi connections and devices, low-latency daisy chain systems, fiber systems such as those that Google is developing, satellite connectivity, yet-to-be-created technology or a combination of these is still unclear–but one thing is certain: Data volumes are increasing faster than network bandwidth.

    Today, organizations have a choice of connecting edge platforms among several available wired and wireless network alternatives. The number of use cases involving edge computing is expanding in part because wireless 5G networks make it possible to share data across multiple interconnected edge platforms. For example, manufacturing employees wearing augmented reality headsets that can share data and analytics in near-real-time not only with their coworkers on the floor but with colleagues hundreds of miles away.

    As telecom carriers continue to virtualize the network infrastructure they employ to deliver 5G services, the cost of delivering them should steadily decline across a widening range of geographic areas. Today, a 4G network can support roughly 4,000 devices per square mile. A 5G network could pack up to three million devices in the same area.

    It’s still early days as far as 5G is concerned. A Capgemini survey of 1,000 industrial organizations that plan to incorporate 5G into their operations finds less than a third (30%) have progressed to trials and real-world implementations. Yet, carriers are already at work defining the next generation of 6G wireless standards that promise to deliver another giant leap for wireless networks in another decade.

    Regardless of the network employed, organizations will still need to strike a balance between how much data needs to be processed, stored and eventually disposed of at the edge versus the amount of aggregated data that needs to be transferred over a WAN and incorporated within various other platforms that process data centrally or function as systems of record.

    Factoring in Security

    Arguably, the biggest obstacle to edge computing is security. Each time an organization deploys an edge platform, the attack surface they need to defend grows. Many of these edge platforms are also managed by operational technology (OT) teams that don’t have as much cybersecurity expertise as does, say, the data center security team at Google. Most organizations are trying to meld their OT and traditional information technology (IT) teams in an effort to deploy, manage and secure edge platforms. However, the cultures of these two teams are significantly different. It takes time for organizations to harmonize the efforts of these two groups.

    More challenging still, cybersecurity expertise is hard to find and retain. Cybercriminals have discovered how vulnerable OT environments are. Attackers affiliated with various nation-states have already demonstrated that industrial control systems controlling electricity grids and other critical infrastructure systems are primary targets should war erupt. From their perspective, each edge computing platform connected to a network is yet another vehicle through which malware can be introduced into an IT environment. It only takes a few minutes for malware to propagate laterally across an entire platform.

    Ultimately, organizations will soon spend billions of dollars securing edge platforms. Once the edge systems are locked down and secure, edge processing can improve overall cyberdefense—processing more data at the edge without moving it around as much can dramatically reduce the attack surface.

    How the Edge Computing Ecosystem is Evolving

    Once the right level of infrastructure is in place, the next challenge is building applications. The widespread adoption of container technologies has allowed developers to build applications using artifacts that require much less memory and storage. Most container environments today, like those based on Docker and Kubernetes, are decentralized, in a sense, but are run in centralized environments like data centers. But work is progressing on even smaller container formats that make it even easier to deploy application software on, for example, an oil rig hundreds of miles from any server or gateway.

    Lighter-weight instances of the open source Kubernetes container orchestration engine are starting to gain traction. Kubernetes, by surfacing a consistent set of application programming interfaces (APIs) regardless of what platform it is deployed on, provides an opportunity to centralize the deployment and management of modern microservices-based applications across highly distributed computing environments.

    Industry API specifications and frameworks are also beginning to emerge for machine learning, data science and other technologies that empower edge computing. An example is oneAPI, supported by Intel and others, which provides a framework for developing edge applications.

    Providers of development platforms are also racing to create frameworks that make it simpler to build applications within edge architectures that seamlessly invoke backend application services running in the cloud. Distributed event-streaming platforms like Apache Airflow and Kafka can play a role in allowing edge computing platforms to share data with those backend platforms at scale. Some organizations will also invoke the services of content delivery networks (CDNs) to improve the performance of applications deployed across a global network of points-of-presence (PoPs) that have already been constructed.

    Finally, stateful applications deployed at the edge can require local databases that provide access to persistent forms of data. The bulk of container applications deployed today are stateless—they store data on an external storage system. Building stateful applications that access data in containers on a local Kubernetes cluster is more challenging.

    There are already millions of developers familiar with container platforms who are standing by until improved hardware and software simplifies and secures deployment of highly portable applications as far out on the edge as possible.

    The Coming AI and Data Management Challenge

    The most exciting edge innovations ahead will likely be driven by the rise of machine learning and AI. Today, AI models are typically trained within centrally located cloud computing platforms. An AI and machine learning inference engine can then be created and deployed in a production environment, where a trained AI engine deduces what actions to take as new data is discovered.

    Over time, those inference engines are subject to drift as the amount of new data collected exceeds the parameters on which the original AI model was based. Data science teams working in collaboration with IT and OT teams then need to train a new AI model to replace the inference engines at the edge. Advances in new AI and machine learning capabilities, in conjunction with lower-power and higher-performance processors and other components to help lower costs, can improve the accuracy and performance of prediction systems, but typically doesn’t reduce the degree to which this drift happens.

    If AI models can be at least partially retrained at the edge, this can help to reduce prediction accuracy drift. However the software and hardware infrastructure required to retrain an AI model efficiently within an edge platform is still very early-stage. That said, as the cost of increasingly high-powered hardware declines and edge machine learning software systems improve, the ability to train at the edge will become more feasible.

    The Economic Impact and Investment Opportunity

    The global edge computing market was valued at approximately $3.6 billion in 2020 by Markets and Markets. The research firm forecasts this market will reach $15.7 billion by 2025, representing an astounding 34.1% compound annual growth rate (CAGR).
    McKinsey forecasts that the economic value generated by use cases involving internet of things (IoT) applications alone will be somewhere between $3.9 trillion and $11.1 trillion per year by 2025. Add in all the other use cases for edge platforms and the potential for positive economic impact becomes enormous.

    Increased computing at the edge will be a huge technology market in its own right and will also drive increased demand for centralized cloud computing. Gartner notes that by year-end 2023, 20% of installed edge computing platforms will be delivered and managed by hyperscale cloud providers. The other 80% of this massive emerging market opportunity is up for grabs.

    Lonne Jaffe co-authored this article.

  • What It Will Take To Bring Cloud Gaming to Fruition?

    What It Will Take To Bring Cloud Gaming to Fruition?

    The gaming industry is booming. There are 211 million people gaming in the U.S., and it’s one of the fastest-growing forms of entertainment on the planet. In the age of Twitch streaming, gaming has even upstaged traditional sports viewership. On average, young gamers between the ages of 18 and 25 spend a full hour more watching online gaming than watching traditional sports.

    Gaming has also become a way of connecting with others—65% of players say they play with others online or in person. Some software development teams even encourage gaming in the workplace to increase productivity. For this reason, there has been a massive shift toward online cooperative games, RPGs and sandboxes like Minecraft. Also, games are becoming more cloud-based, with purchases, downloads and game saves occurring in the cloud. Still, many people lack the hardware necessary to run complex games locally. All these factors are harbingers of a coming shift away from PC and console-based processing.

    I recently met with Noam Salinger, product manager, Granulate, to learn about the future of gaming and how software teams in the gaming industry can prepare. To Salinger, “cloud gaming is the next step.” The move away from consoles and toward cloud-based, remote processing will have huge ripple effects. Lowering the barrier to gaming could introduce millions of more players into the ecosystem and further balloon the industry. However, cloud gaming presents significant hurdles. The transition will require a substantial reduction in latency, 5G networking and highly efficient computing optimizations.

    Roadblocks to Cloud Gaming

    “Cloud is an integral part of any gaming company,” says Salinger. More and more functionality associated with gaming is being pushed online. There are already online game marketplaces, cloud-based account management and remote game saves. This is especially prevalent with mobile gaming. But, what about the actual processing for computationally-intensive games—could these workloads also move to the cloud soon?

    This kind of cloud-based gaming could soon come to fruition. Yet, Salinger foresees some major roadblocks to cloud gaming:

    1. The Software Components

    A complete jump to cloud gaming will require having the proper software infrastructure in place and getting vendors on board to support it. This is perhaps the biggest obstacle to cloud gaming in the software industry, said Salinger, “It’s still not mature enough.”

    2. The Business Components

    Furthermore, gaming platform companies might refrain from cloud gaming due to fears of it cannibalizing their existing hardware sales channels. On the other hand, cloud gaming presents a big opportunity to take on more of a subscription-based model, such as allowing a user to play any game they want from an extensive suite of games. Akin to streaming services like Netflix, Hulu or Peacock, we could see similar platform styles emerging in gaming. “They will have no choice but to participate at some point,” said Salinger.

    3. The Network Components

    As most gamers can attest, online games can easily suffer from network issues that negatively affect gameplay. Salinger predicts that the ubiquity of 5G networks will be necessary to propel the cloud gaming market forward. 5G could be a universal method to enable real-time connections for a broader base of end-user gamers.

    Even if software developers optimize game processing speeds, a poor network could add enough latency to data throughput to cancel out those gains. 5G could expedite this process, but it’s taking a lot longer than expected. Some estimates place 5G finally arriving at full throttle sometime in 2023, after more antennas are constructed and pre-existing physical infrastructure is upgraded.

    4. The Latency Components

    Another significant roadblock to cloud gaming is figuring out real-time remote computing on the game vendor side. “This is where the latency aspect of things really comes into play,” said Salinger. Since game clients will be making many remote calls, optimizing cloud CPU utilization will be vital to reducing the response time to requests.

    Cloud gaming will require parallel running processes that anticipate user action. Similar to the way modern web applications simultaneously trigger multiple backend requests for authentication, geolocation, user databases and so on, real-time cloud games will require many different processes running in parallel. Servers could allocate resources before requests come in, using predictive analysis of usage patterns to trigger components in advance of user behaviors.

    To enable intelligent resource allocation, Salinger describes how an OS-agnostic kernel module could be in charge of resource allocation, continuously adapting to changes in the application workload. Low-level resource allocation at the CPU level, the allocation memory, I/O, and the sequence of execution must be optimal for each specific application, he described.

    This sort of process is already being applied in production by some ad tech companies to enable real-time ad bidding. For example, by optimizing cloud CPU utilization, Perion is able to perform faster, process more responses and use fewer machines to perform the same task—thereby reducing the roundtrip time for each request. Similar principles could be used to advance cloud gaming.

    Rendering sophisticated virtual environments is highly resource-intensive, and high-performance graphics cards are expensive. Video games are set to only increase in complexity with new AR/VR modes. Cloud gaming could help respond to rising computational needs and replace the need for local computing hardware. In the process, this move could bring in more gamers, disrupt the console wars, and nullify age-old PC-versus-Mac compatibility issues.

    Moving to a cloud-based approach is also arguably more aligned with today’s fast-paced software release cadences. Pushing more frequent patches can help resolve bugs faster. But it also could aid in retaining engagement by introducing new levels and objectives continually.

    The rise of the gaming ecosystem can’t be ignored. But as it stands now, there are still significant challenges to wider penetration of cloud gaming. Cloud computing optimizations to reduce latency, mainstream adoption of 5G and significant re-platforming of software infrastructure are just some of the many issues that will need to be tackled before truly cloud-based gaming experiences advance to the next level.

  • No-Nonsense Guide to Distributed Databases

    No-Nonsense Guide to Distributed Databases

    I got my first DBA job 15 years ago, and quite a few things have changed since then. The amount of data exploded, we saw the rise of NoSQL, and business logic moved away from being stored in relational databases to applications.

    To this day, the three pillars of reliability, scalability, and maintainability are the banes of a DBA’s existence. To spice things up, your monthly cloud bill for managed databases just made your CTO lose the will to live.

    So, now you have two extra things to worry about in addition to these three pillars: cost efficiency and vendor-agnosticism.

    In this article, I’ll (try to) run an open source, new-generation database, benchmark it and touch on some of the challenges of being cloud-neutral.

    TL;DR

    • Solving the SQL vs. NoSQL dilemma in the Kubernetes world
    • How to leverage a distributed SQL database in a multi-cloud world
    • Taming performance – single cloud versus multi-cloud
    • Running TPC-C as a transactional benchmark
    • Taming the costs – the question of egress costs

    New Packaging For a New Age

    Just five years ago, people were like, “Containerizing stateless microservices? Sure! No problem.”

    But when you actually containerize a database, your persistence layer is asking for trouble.

    Over time, containers grew on us. Now, it’s the default way of packaging and shipping software. Heck, even AWS Lambda caved and started running container images. Databases just couldn’t resist.

    Once a database is containerized – say, a PostgreSQL database – Kubernetes takes over dealing with some of the more painful aspects of reliability and maintainability (with the help of middleware-specific operators).

    Containers decouple data from the runtime, so upgrades and configuration are easier through infrastructure-as-code (YAML). Hardware failure and maintenance windows are covered by Kubernetes’ built-in capability to reschedule pending pods on surviving nodes. Full scheduled backups or point-in-time recovery are in the hands of the operator’s automation.

    But what about scalability?

    Kubernetes’ vertical pod autoscaler can adjust container resources, deleting and recreating pods with new resource settings. As a traditional relational database, PostgreSQL can have only one primary replica that writes data. This means that you’ll be facing a  short downtime while the new pod comes online. The majority of workloads are about five times oversized, so while sizing is painful, it’s better than no sizing at all (please, have mercy on your CTO’s budget).

    NoSQL has none of these limitations. Databases like Cassandra were built for scaling horizontally without downtime.

    Enter Distributed SQL

    What if we could blend Google Spanner’s ability to operate at distances with strong ACID consistency, Cassandra’s scaling and PostgreSQL compatibility?

    This is where YugabyteDB helps.

    YugabyteDB is an open source, relational, distributed SQL database management system. It was designed to handle large amounts of data across multiple availability zones and geographic regions, all the while delivering single-digit latency, high availability and no single point of failure.

    I hate when the new kid on the block brings their own syntax language because, you know, their case is so very special – just like everybody else’s.

    Yugabyte doesn’t do that. They have a wicked-smart storage layer (inspired by Google Spanner) that reuses the PostgreSQL query engine. This means no mental strain on the development team – you get to use the time-tested, marketable and incredibly powerful PostgreSQL language-level features that many are already comfortable with.

    If Google Spanner is so inspiring, why is it not taking over the world of distributed SQL? Well, it’s available only as SaaS, and heavily depends on the specifics of Google Cloud hardware like atomic clocks (trueTime) and Google’s backbone network. If your private data center or favorite cloud provider is not GCP – well, no Spanner for you, my friend. Personally, I’d be hesitant to marry into the ultimate vendor lock-in. Yugabyte doesn’t have any dependencies and would happily run on any cloud, private data center, VM or bare metal – and if your coffee machine runs Docker containers, you can run Yugabyte there, as well.

    If Yugabyte is robust, scalable and easily maintainable, you have the top three pillars covered. But what about the other two pillars your CTO is nagging you about (cost efficiency and a vendor-agnostic approach)?

    How to Make Your Database Vendor-Agnostic

    Being vendor-agnostic means being able to switch between major cloud providers at any point without depending on prohibitively expensive services like DynamoDB. This approach also allows you to leverage inefficiencies in cloud pricing so you can look for new opportunities to reduce cost and dynamically shift resources between cloud providers online.

    This is something CAST AI can do.

    The CAST AI platform acts as a cloud abstraction and makes the whole multi-cloud, vendor-agnostic requirement quite trivial.

    Developers just interact with standard Kubernetes (no CRDs), and the complexity of several clouds is abstracted. A Kubernetes cluster in CAST AI can span across several cloud providers at the same time, bringing some unique cost optimization opportunities.

    What if spot/preemptible instance interruption wasn’t totally random anymore, but something you could actually predict? You could be proactive and—by operating in several compute bidding markets at the same time—reduce the risk of running out of capacity.

    Why not slash your monthly cloud bill radically by running some of the database containers on spot/preemptible nodes?

    Highly Available Stateful Application on Multi-Cloud

    Yugabyte on a multi-cloud CAST AI Kubernetes cluster is a robust design without a single point of failure.

    Active/Passive solutions are so ’90s—failovers cause brief downtime, and DBAs tend to leave the failover to be manually initiated due to occasional short-lived network blips. Active/Passive solutions constantly require testing and validation. Will your disaster recovery work on darker days? Because these tests cause downtime, nobody does them regularly.

    The best highly available solutions are active-active, don’t require user failover, and don’t rot if not tested regularly.

    CAST AI has a tutorial in place that takes you through every step of building the above solution in about 10 minutes, from scratch.

    Go ahead, open your cloud provider’s console and release your inner chaos monkey by killing Yugabyte, business app pods or whole Kubernetes nodes.

    CAST AI, Yugabyte, and Kubernetes were built with a core tenet that nothing is guaranteed; nothing should be shared. But keep in mind, consensus algorithms work when there’s still a majority left to vote N/2 + 1.

    You may be asking, what’s the performance impact of increasing resiliency when going multi-cloud with a distributed database?

    Let’s find out.

    Let’s benchmark a distributed Yugabyte database on top of CAST AI Kubernetes spanning AWS and GCP. These cloud providers are arbitrary choices here; Azure or DigitalOcean can be used in the mix, as well. We picked GCP and AWS because their VMs boot up a bit faster.

    Mono-Cloud Vs. Dual-Cloud Network Benchmark Results

    Let’s compare a Yugabyte containerized database on Kubernetes in a single-cloud scenario versus a distributed database working in two different clouds.

    Setup

    We took the OSS Yugabyte HELM chart with the image version “2.5.1.0” with the replication factor of 3.

    Role

    YB-Master

    YB-Tserver

    Description

    Control plane, consensus

    Serves data

    CPU

    3 CPUs

    7 CPUs

    RAM

    3 GiB

    14 GiB

    Storage

    50 GiB

    300 GiB

    Remote Network Block storage:

    • EBS gp2 (300 IOPs)
    • Standard persistent disk (R225/W450 IOps)

    Nine pods, each on a separate VM to ensure plenty of resources:

    Mono Cloud

    Regional GKE k8s cluster with 9x GCE N2d-standard-8 distributed in three availability zones. Casual VPC network in Google’s US-East4 region.

    Dual Cloud

    AWS EC2 3x c5a.2xlarge

    GCP GCE 6x n2d-standard-8

    A network between cloud providers set up with a Wireguard-based full mesh VPN that encrypts traffic end-to-end (also inside the same VPC).

    To minimize noise from compute and local storage efficiency, we didn’t optimize for cost but wanted to isolate and better understand how distributed databases would work in situations where database nodes are distributed single-digit milliseconds away (in this example, less than 9 ms).

    Nine milliseconds of network round trip latency means a lot of flexibility in choosing between data center providers distributed within a few hundred miles.

    The majority of cloud provider regions lack imagination and are clustered in the geographic vicinity of a densely populated metropolis. California, northern Virginia, Montreal, São Paulo, London, Frankfurt, Amsterdam, Mumbai, Tokyo, Singapore, Sydney, etc.

    So, what are your options in, say, Frankfurt? AWS, Azure, GCP, DigitalOcean, Oracle, Alibaba, IBM Cloud, Hetzner, Linode—not to mention the white-label providers.

    We carried out tests on U.S. East (Ashburn) and Europe Central (Frankfurt) with similar results.

    How We Measured It

    If we want to test relational database performance – the gold standard ruler to date is a synthetic TPC-C benchmark.

    Why did we choose that? Because it’s the most mature OLTP benchmarking test suite that has stood the test of time. As stated here:

    “While the benchmark portrays the activity of a wholesale supplier, TPC-C is not limited to the activity of any particular business segment, but, rather represents any industry that must manage, sell, or distribute a product or service.”

    We loaded an identical Yugabyte configuration in both scenarios with 300 warehouses worth of data and then ran benchmarks several times.

    Each test took half an hour, and the output was the single most important metric: transactions per minute. The test also provided different outputs per type of transaction, average and 99th percentile duration in milliseconds.

    Results

    This table shows a comparison of TPC-C results with the average duration for a single cloud on Google and AWS + Google in the same region, US-East.

    300 warehouses

    Mono Cloud

    Dual Cloud

    Num New Order transactions per 1800 s

    113,071

    113,247

    TPM-C

    3,769

    3,774

    Efficiency

    97.6%

    97.8%

    NewOrder Latency avg msec

    580.2

    498.8

    Payment Latency avg msec

    30.8

    46.7

    OrderStatus Latency avg msec

    33.8

    32.4

    Delivery Latency avg msec

    123.1

    174.9

    StockLevel Latency avg msec

    239.4

    465

    And comparing the 99th percentile:

    300 warehouses

    Mono Cloud

    Dual Cloud

    NewOrder Latency  p99 msec

    6985.6

    5498.7

    Payment Latency p99 msec

    110.5

    157.5

    OrderStatus Latency p99 msec

    146.3

    185.1

    Delivery Latency p99 msec

    331.5

    696.8

    StockLevel Latency p99 msec

    712.3

    1083.3

    As you can see, the difference between the mono cloud and dual cloud scenarios is quite small.

    Some operations, like OrderStatus, are plain read operations. The nearest server can quickly respond with data to the client—usually, a microservice running on the same K8s cluster.

    Yugabyte’s lowest isolation level is a snapshot. This means that those reads are protected from the undesirable effect of the “dirty read.”

    What about writes?

    Writes are a bit more expensive. Raft consensus, hybrid logical clocks and lockless multi-version concurrency control (MVCC) algorithm magic—all of this means a lot more chatter and replication between nodes to get write committed.

    We see that, in payment and delivery operations duration (30ms vs. 46ms and 123ms vs. 174ms, respectively) the geographic distances start to be noticeable.

    The actual network latency between nodes in different availability zones in the mono cloud scenario without network overlay and encryption is, on average, about 0.6ms. Network latency between two clouds with overlay (VXLAN) and encryption (Wireguard) is about 5ms.

    The laws of physics aren’t going away anytime soon. But as we can see, the results are much better than expected.

    YMMV, but industry accepted norm is that the majority of IO operations will be reads, at 70%; only remaining 30% writes, reducing the impact of speed of light even further.

    Having said that, the gold standard for measuring OLTP database performance for the last two decades says that performance results are identical (TPM-C 3’769 vs. 3’774).

    Data Gravity and Egress Costs

    Data gravity refers to a scenario where compute gravitates closer to data.

    For example, if you have a hybrid cloud or multi-cloud strategy but your data stays in a single location like an on-premises data center. Most of the compute with stateless services will tend to stay in the same data center, closer to data.

    The whole point of multi-cloud and a high-performing distributed database was to get rid of data gravity. If we have the same data on two or more clouds, then the data gravity effect disappears.

    If all your data is replicated to several locations, what about network traffic costs?

    All cloud providers allow unlimited incoming (ingress) data. It doesn’t matter where data is coming from—if it’s your on-premises data center, a different cloud provider, the dark web or most cloud-native services. All the incoming data is free.

    “You can bring as much data as you want to us. But if you want to take your data back – sorry, you need to pay.” This is universal between all cloud providers. All the outgoing (egress) traffic from your availability zone is paid! Some cloud providers, like Oracle Cloud, are very generous with egress costs, and companies like Zoom saved a ton of money when they moved some of Zoom’s infrastructure to Oracle Cloud.

    DigitalOcean gives a generous egress monthly allowance per Droplet (VM), depending on size and how long you run it. But, at a minimum, it starts at Terabyte per smallest Droplet. The monthly egress allowance is aggregated in your account, and you pay only for the combined extra.

    All clouds have some minimal free tier—but in general, egress costs start at around 10 cents per GB of data sent outside VPC, and, on average, 2 cents for data between availability zones in the same VPC (I bet you didn’t know that you pay 1cnt/GB in AWS and Azure for incoming traffic coming from same VPC/Vnet from another AZ).

    If you send more traffic, your cost per GB falls. The first drop is at 10TB and generally flattens at around 5 cents at ~150TB.

    How does it make you feel when cloud providers charge an eye-watering 97% margin on that egress traffic? It’s like we’re back in 1995 with dial-up modems, right?

    There is a more cost-effective alternative. But first, let’s answer the ‘Will it Blend?’ question. Let’s add Direct Connect, Express Route, Cloud Interconnect and Layer 2 or Layer 3 providers like Equinix or Megaport. Yes, you get a Dedicated Fiber Link smoothie out of the blender.

    Dedicated fiber link slashes costs to a mere 2 cents per GB. And if you have more egress traffic than 7TB, it’s more cost-effective than relying on the weird discount models from cloud providers.

    You might be thinking, “2 cents for every GB?! That’s way too much! I’m using RDS—yes, I have vendor lock-in and data gravity—but at least I have none of the problems with egress cost, resilience, scalability and overall affordability of the service, right?”

    That’s just the result of an opaque billing design.

    https://twitter.com/QuinnyPig/status/1372598432095891458

    All the traffic between Availability Zones in all clouds is paid at 2 cents per GB of egress+ingress. The only place where you pay for ingress is between Availability Zones in the same region (AWS/Azure). Some managed services offer free replication, but they charge double on compute costs, etc.

    Through the ServiceTopology feature, Kubernetes can keep your application pod’s traffic inside the same cloud service provider Availability Zone and cloud, to avoid round robin, random calls between clouds. This means that you get the best latency and pay no traffic premium.

    Most of the database activity is reads (70/30, YMMV) and are effectively free, egress-wise (coming from the local AZ due to the Kubernetes topology awareness). So, the only thing you replicate and subject to egress costs is your database change delta rate per month.

    Now you can see that the issue of egress costs is an incredibly overstated problem.

    The overwhelming push to the public cloud over the last decade brought on new challenges like vendor lock-in, data gravity and eye-watering monthly infrastructure bills.

    During that time, innovation in non-traditional RDBMS, containerization and workload scheduling removed some of the old barriers.

    Running a hands-free, strongly consistent, highly available and scalable database in heterogeneous data centers on a budget was a monumental task a decade ago. Today, it has become an affordable best practice for running our business applications.

  • IBM Unifies Cloud Services to Simplify App Dev

    IBM Unifies Cloud Services to Simplify App Dev

    IBM announced today that an IBM Cloud Code Engine service that unifies the cloud platforms on which applications are built and deployed is now generally available.

    Built on top of a serverless computing platform, IBM Cloud Code Engine is a managed service that unifies access to a platform-as-a-service (PaaS) environment, a container-as-a-service (CaaS) environment and batch workloads, that run on traditional virtual machines, to a single platform.

    At the core of that managed service is an instance of Kubernetes running Knative middleware for invoking an open source serverless computing framework, the Istio service mesh and Tekton pipelines for building DevOps workflows.

    Jason McGee, CTO and vice president for IBM Cloud Platform, said the goal is to eliminate the artificial constructs that developers are forced to navigate in the cloud today that can each trace their lineage to a different era of software development. The IBM Cloud Code Engine unifies the developer experience in a way that makes it simpler to build and deploy applications on the type of cloud service that best makes sense for a specific application workload, McGee said. Developers no longer need to configure code for a specific type of infrastructure; they can simply describe how they want source code or a container image to behave, and IBM Cloud Code Engine automates deployments accordingly.

    The serverless computing framework that IBM Cloud Code Engine is built on also makes it possible for IBM to only charge organizations when code is actually running, versus requiring them to commit to a specific amount of infrastructure to run a set of virtual machines, McGee added. Charges are based on the memory and vCPU consumed and incoming HTTP calls. That approach will, over time, substantially reduce the total cost of cloud computing, said McGee.

    It should also accelerate the rate at which applications are migrating to the cloud, added McGee. Today roughly 20% of application workloads run in the cloud. Getting the next 40% of workloads shifted into the cloud will require providing a simplified application developer experience, noted McGee.

    The challenge organizations are wrestling with today is that they are deploying a mix of monolithic and microservices-based applications in the cloud that, to varying degrees, rely on batch-oriented and real-time platforms. IBM Cloud Code Engine represents an effort to provide a layer of abstraction over a wide range of cloud services that they can flexibly invoke via an event-driven platform, as required.

    The DevOps implications of IBM Cloud Code Engine are potentially profound. DevOps teams today spend an inordinate amount of time provisioning cloud infrastructure on behalf of developers. IBM is now making a case for a platform that automates that process in few seconds. In effect, control over cloud infrastructure will shift even further left to application developers. DevOps teams, in theory, will spend more of their time optimizing cloud environments after an application has been deployed.

    It’s not clear to what degree platforms such as IBM Cloud Code Engine might force cloud service providers to consolidate distinct cloud services they provide to developers today based on the type of application being built. However, it’s already apparent that the writing on the wall heralding that consolidation have now been indelibly inscribed.

  • What Amazon’s New CEO Means for IT’s Future

    What Amazon’s New CEO Means for IT’s Future

    Amazon is placing its bets on the future of cloud. The announcement that CEO Jeff Bezos will be stepping down and passing the torch to Amazon Web Services (AWS) leader Andy Jassy at the start of Q3 2021 signals a major shift in the future of technology – and not only for organizations specializing in IT, storage and web hosting. Rather, the growth of AWS signals a multi-industry-wide demand for cloud services as the new normal for conducting business – and those that continue to rely on legacy technologies could soon see their businesses falter in the shadows of competitors in the near future. However, every company’s individual systems are entirely unique, and modernization doesn’t happen with a one-size-fits-all approach. So why should organizations invest in new technologies – and how?

    Setting Sights on the Cloud

    The pandemic has made painfully clear the need for organizations to get away from their aging legacy systems and to embrace the cloud for a variety of reasons. First, COVID-19 has forced almost all businesses, across all industries, to embrace more distributed networks – requiring business-critical systems and functions to be accessed from countless different sources at any given moment. This can prove a major pain point for organizations with IT infrastructures that are prone to difficulties and outages. These shortcomings can have a detrimental impact on customers and citizens, as well. In light of major IT outages in states like New Jersey, California and Oregon, it’s clear that pursuing a more modern approach to IT systems is no longer just an option – it should be the only option. This is because, in addition to the benefits for users and enhanced business function, there are added benefits for the company itself and the world at large.

    Shifting systems away from data centers requires significantly less energy to power – and as data centers are responsible for as much greenhouse gas emissions as the airline industry, the environmental impact coupled with operational cost savings enable businesses to meet customer demands for greener practices while reducing overall operational costs. What’s more, this change to cloud services will allow for horizontal scalability within organizations, ensuring that businesses are able to meet demands for their offerings in real-time.

    The Sky is the Limit: Strategies for Improving IT Infrastructure

    If your organization is relying on a mainframe, it won’t be able to reap the many benefits that cloud infrastructure has to offer – and organizations that shy away from making these vital updates run the risk of running their business offline entirely. As a result, the time to act is now – but in the rush to get IT departments in order, it’s vital that organizations choose a modernization strategy that is best suited to their unique business. For most organizations, a modernization journey begins with one of the four following approaches:

    • System Replacement: Sometimes, organizations aim to expedite their modernization journeys by doing away with their aging legacy systems entirely. Through a system replacement, organizations purchase off-the-shelf solutions from third-party vendors and conduct business via the new software while their existing infrastructure and applications are taken out of service. While this approach enables a speedier shift toward the cloud, it should be noted that these solutions aren’t tailored to a specific company’s needs or functions, and that these solutions can be especially costly.
    • Rewriting: In an effort to retain key legacy knowledge while enabling better business function, some organizations pursue a rewrite of their existing systems within a more modern environment. Through this approach, a team of professional developers work to manually recreate the system and its applications – which often results in an extended timeline for modernization, exorbitant costs and an especially high risk of complete project failure.
    • Automated Refactoring: Through looping in a team of IT experts, this strategy enables an organization to migrate their legacy system’s procedural code bases into object-oriented languages within modern environments that are more appropriate for today’s business demands. Using specialized and automated tools designed for the project at hand, this modernization strategy ensures that an organization has a system designed for its unique business cases and an immediate pathway to the cloud.
    • Rehosting: To help companies maintain their legacy information, many organizations pursue rehosting as part of their modernization strategy. In this approach, a company’s existing legacy codebase is transferred away from their mainframe and their unchanged procedural code bases, data and other core functions into a new computing environment that is more suitable for current needs. This fast-paced process helps to set organizations on track toward the cloud as quickly as possible.

    Aiming for the Cloud(s)

    Amazon’s shift in leadership is a testament to the growth potential and overall importance of the cloud – not only for companies that manage web services, but for all industries around the world. However, by proactively taking the steps to move away from legacy systems and pursue a cloud-first approach to business, organizations will be better positioned to maintain their revenue streams, improve scalability, drive customer satisfaction, reduce operational costs and even protect themselves from potential disasters down the line. By setting and sticking to a set strategy and timeline for modernization, companies can ensure the success of their most mission-critical applications and functions to ensure their continued success and survival in a world or rapidly changing business demands.

    The sky is the limit – are you ready to aim for the cloud(s)?

  • Cloud Growth and Other 2020 Trends

    Cloud Growth and Other 2020 Trends

    Growth continued this year as even the COVID pandemic could not slow down the cloud

    The rise of COVID-19 defined 2020 for nearly every industry. Cloud computing is no exception, though growth in the sector continued this year. Gartner estimates that $257.9 billion will be spent on public cloud services in 2020, up 6.3% from 2019. IDC reports that almost half of IT spending is cloud-based, “reaching 60% of all IT infrastructure and 60% to 70% of all software, services and technology spending in 2020.” These projections came in mid-2020, which proves that cloud adoption and spending were not greatly impacted by the pandemic.

    You can make the argument that cloud computing itself is the trend of 2020. Blockchain, quantum computing, machine learning and AI all deservedly earn a lot of headlines in the tech press. But at a more basic level, cloud computing is changing the way we do business. Whether it is the way they store their data, improvements to agility and go-to-market for faster release of new products and services, or how they develop and operate services remotely in today’s “locked-down world,” cloud computing is benefitting all businesses in every sector.

    In short, cloud computing had a strong year in 2020 despite COVID-19 and appears to have a very bright future. Several key trends, perhaps overshadowed by the pandemic, helped define a dynamic year for the sector. These include the following:

    • Continued Dominance of ‘The Big Four’ – All of the big four cloud providers—AWS, Azure, Google Cloud and Alibaba Cloud—reported strong growth and collectively grew 40% in Q320. Together they still account for 63% of the entire cloud sector.
    • Rise of Managed Services – The global cloud managed services market, in particular, is growing rapidly and is expected to reach $116 billion by 2025, growing from $62.4 billion in 2020, according to a study conducted by Markets and Markets.
    • Serverless and Containers – There used to be some talk about serverless and containers replacing the use of traditional virtual machines (VM). But I mostly see customers realizing that VM infrastructure is not going to disappear anytime soon, though container use certainly rose over the last 12 months.
    • Automation – The push toward greater automation continued in 2020. I noticed users accepting greater automation in their infrastructure environments, and there was simply more demand for it across the board. This is great news as one of the major advantages of a DevOps approach is automating away the manual tasks that bog down critical projects.
    • Growth in home use – This may seem an obvious one, but with the COVID-19 pandemic leading companies across the globe to new “work from home” policies, virtual desk infrastructure (VDI) usage exploded.
    • Security – Especially with a remote workforce, cloud security faced new challenges this year. One example of this playing out is in Snowflake’s massive IPO.

    Other trends of note this year included the continued growth of hybrid and multi-cloud and desktop as a service (DaaS). So, while COVID-19 truly defined 2020 for most people, the cloud sector was busy with the trends discussed above. It will certainly be interesting to see how these trends play out in the year ahead. Whatever new trends arise, it seems likely that cloud computing will continue to transform the way we all do business.

  • How to Avoid Cloud Overspend

    How to Avoid Cloud Overspend

    Cloud overspend can have a major impact on a company’s bottom line. Here’s what organizations need to know

    Cloud technology has reached the stage of mainstream adoption across multiple industries, be it finance, health care, manufacturing or retail. According to a Research and Markets report, the global cloud computing market is expected to grow further to $832.1 billion by 2025, at a compound annual growth rate of 17.5% during the forecast period. However, with the expected increase in cloud usage, cloud waste is bound to increase. According to a report by Gartner, cloud waste is forecasted to reach $21 billion by 2021.

    Companies that are not aware of the factors that lead to cloud overspend will end up wasting a lot of money without even realizing it. This article discusses some of the reasons for cloud overspend and potential ways to optimize cloud usage and expenditure.

    1. Understand cloud better: One of the most prevalent reasons organizations overshoot their anticipated cloud usage is a general lack of understanding of cloud technologies. They often fail to make well-informed choices at the beginning of their journey to the cloud. Without truly understanding their business needs and the trends in their industry, they will opt for a one-size-fits-all approach, which frequently does not work. Gartner estimates that 70% of the global cloud overspend can be attributed to companies that do not have a defined plan for cloud cost management. An activity as simple as organizing data before a cloud migration can help organizations optimize cloud usage.
    2. Define a policy around cloud usage and associated expenditure: Organizations that do not have a defined strategy to navigate their cloud journey frequently end up with misaligned priorities that can lead to overspend. This lack of strategy manifests with different people and/or departments managing disconnected cloud initiatives that frequently are not aligned with the overall business goals or bound by governing policies, the result of which is typically out of control cloud sprawl. To avoid overspend due to a lack of governance and oversight, organizations should at the very least define these three controls at the start of their cloud journey:
      • Financial controls at multiple levels of the organization.
      • A project lead who coordinates, controls and manages cloud resources across the organization.
      • Resource quota policies to help prevent unanticipated spikes in usage.
    1. Control overprovisioned resources: According to a report by RightScale, approximately 40% of cloud instances are larger than needed for their workloads. The widespread perception that cloud technology is economical and affordable makes companies worry less about controlling the expansion of cloud instances. This often leads to the creation of unnecessary or oversized instances, resulting in shockingly large bills.
    2. Decommission idle and orphan resources: Continuous and thorough assessments help to identify and eliminate assets that are no longer used or required. The right assessment helps identify unattached volumes and orphaned assets that can be deleted. Investing in cloud cost optimization tools can assist with these assessments and reviews. Without a regular review of cloud resources, companies will continue to pay for resources that are no longer needed.
    3. Track vendor contracts regularly: Keeping a close watch on your vendor contracts governing licensing and subscription services is a complicated but necessary step to reduce cloud overspend. This becomes more critical for companies dealing with multiple vendors for different cloud services. Vendor contracts should be re-negotiated and fine-tuned at regular intervals to reduce subscription costs. These savings could be substantial in the long run.

    One of the most important steps on your journey to the cloud is finding the right partner that can assist you at every stage. Choose a technology partner that can help with not just implementation but also the management of your cloud instance. A strategic partner will help you leverage the cloud to drive business growth as well as scale your cloud usage and spend to suit your ever-changing business needs.