devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • Debunking 6 Stubborn Public Cloud Myths

    Debunking 6 Stubborn Public Cloud Myths

    A lot of enterprises migrate to the public cloud because they see everyone else doing it. And while you should stay up on the latest and greatest innovations—which often happen in the cloud—you need to be aware of the realities and understand different migration strategies. You need to know why you’re moving to the cloud. What’s your goal? And what outcomes are you seeking? Make sure you know what you’re getting your enterprise into before moving forward in your journey. Here are six stubborn myths that persist about the public cloud and the realities you’re facing.

    1. Cloud Technology is not a Project, it’s a Constant

    Be aware that while there is a starting point to becoming more cloud-native—the migration—there is no stopping point. The migration occurs, but the transformation, development, innovation and optimization is never over.

    There are endless applications and tools to consider; your organization will evolve over time, technology changes regularly and user preferences change even faster. Fueled by your new operating system, cloud computing puts you into continuous motion. While continuous motion is positive for outcomes, you need to be ready to ride the wave regardless of where it goes. Once you get on, success requires that you stay there.

    2. Flex-Agility is Necessary to Survival

    Flexibility + agility = flex-agility, and you need it in the cloud. Flex-agility enables enterprises to adapt to the risks and unknowns occurring in the world. The pandemic continues to highlight the need for flex-agility in business. Organizations further along in their cloud journeys were able to quickly establish remote workforces, adjust customer interactions, communicate completely and effectively and, ultimately, continue running. While the pandemic was unprecedented, more commonly, flex-agility is necessary in natural disasters like floods, hurricanes and tornadoes; after a ransomware or phishing attack; or when an employee’s device is lost, stolen or destroyed.

    3. You Still Have to Move Faster Than the Competition

    Gaining or maintaining your competitive edge in the cloud has a lot to do with speed. Whether it’s the dog-eat-dog nature of your industry, macroeconomics or a political environment, these are the things that speed up innovation. You might not have any control over these factors, but they’re shaping the way consumers interact with brands. Again, when you think about how digital transformation evolved during the pandemic, you saw winning businesses move the fastest. The cloud is an amazing opportunity to meet all the demands of your environment but if you’re not looking forward, forecasting trends and moving faster than the competition, you could fall behind.

    4. People are Riskier than Technology

    In many ways, technology is the easiest part of an enterprise cloud strategy. It’s people that introduce much of the risk involved. You may have a great strategy with clean processes and tactics, but if the execution is poor, the business can’t succeed. A recent survey revealed that 85% of organizations report deficits in cloud expertise, with the top three areas being cloud platforms, cloud-native engineering and security. While business owners acknowledge the importance of these skills, they’re still struggling to attract the caliber of talent necessary.

    In addition to partnering with cloud service experts to ensure a capable team, organizations are also reinventing their technical culture to work more like a startup. This can incentivize the cloud-capable with hybrid work environments, an emphasis on collaboration, use of the agile framework and fostering innovation.

    5. Cost-Savings is Not the Best Reason to Migrate

    Buy-in from executives is key for any enterprise transitioning to the cloud. Budget and resources are necessary to continue moving forward, but the business value of a cloud transformation isn’t entirely about cost savings. Really, it’s about repurposing dollars to achieve other things. At the end of the day, companies are focused on getting customers, keeping customers and growing customers, and that’s what the cloud helps to support.

    By innovating products and services in a cloud environment, an organization is able to give customers new experiences, sell them new things and delight them with helpful customer service and a solid user experience. The cloud isn’t a cost center, it’s a business enabler, and that’s what leadership needs to hear.

    6. Cloud Migration Isn’t Always the Right Answer

    Many enterprises believe that the process of moving to the cloud will solve all of their problems. Unfortunately, the cloud is just the most popular technology operating system platform available today. Sure, it can help you reach your goals with easy-to-use functionality, automated tools and modern business solutions, but it takes effort to use and apply those resources for success.

    For most organizations, moving to the cloud is the right answer, but it could be the wrong time. The organization might not know how it wants to use cloud functionality. Maybe outcomes haven’t been identified yet, the business strategy doesn’t have buy-in from leadership or technicians aren’t aware of the potential opportunities. Another issue stalling migration is internal expertise (or lack thereof). If your technicians aren’t cloud-savvy enough to handle all the moving parts, bring on a collaborative cloud advisor to ensure success.

  • Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL today previewed an update to its Federation platform for tracking and managing application programming interfaces (APIs) based on the GraphQL query language to give organizations more control over how APIs are reviewed and ultimately approved.

    Matt DeBergalis, founder and CTO, Apollo, said the alpha edition of the Federation 2 platform provides a unified view of distributed APIs based on GraphQL so they can be more easily governed.

    Federation is based on a unified graph created by Apollo GraphQL to initially provide more visibility into how APIs based on GraphQL are employed within an organization. That capability makes it simpler to increase collaboration among development teams that typically build APIs in isolation from one another, noted DeBergalis.

    The latest version of Federation also adds a shared ownership model that empowers teams to evolve unified graphs across smaller teams, he noted.

    In general, DeBergalis noted that Federation reduces the chances developers are going to create redundant APIs because they can more easily discover existing ones. They can then either employ those APIs as-is or modify them to suit their requirements as they increasingly compose an application using tools such as Apollo GraphQL Studio versus building every capability from the ground up themselves.

    GraphQL

    Overall, Apollo GraphQL claims that Federation is currently being downloaded more than one million times a week, with more than 30% of Fortune 500 companies such as Netflix, PayPal, Zillow, Walmart, Peloton and Priceline already using its tools.

    The company is also now making Federation and the rest of its tool portfolio available under the Elastic License 2.0 which provides the right to use, copy, distribute, make available and prepare derivative works of the software, but prevents organizations from offering a managed service, circumventing license key functionality or removing/obscuring features protected by license keys or remove or obscure any licensing, copyright or other notices.

    GraphQL, originally created by Facebook, is gaining traction as an alternative to REST APIs because it gives developers more control over how data is accessed via an API using a set of query capabilities. That capability is especially appealing when constructing digital business processes that require access by specific classes to large volumes of data. In fact, DeBergalis notes that, in many cases, it’s the existence of a rich set of APIs that enables organizations to construct digital processes that bridge the various isolated processes organizations previously had in place.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to have a significant impact on how applications are built and deployed. Many applications may wind up invoking external services via both REST and GraphQL-based APIs for many years to come.

    In the meantime, the rate at which applications are being built should substantially increase as tools such as Federation make development teams more productive. The challenge many DevOps teams will soon face is managing a large volume of deployments and associated application updates as more applications are deployed in production environments.

  • Oracle Adds AI Services to Cloud Portfolio

    Oracle Adds AI Services to Cloud Portfolio

    Oracle today unfurled Oracle Cloud Infrastructure (OCI) AI services, a collection of services that make it easier for developers to use application programming interfaces (APIs) to invoke a wide range of services based on algorithms trained by Oracle on their behalf.

    Elad Ziklik, vice president of product management for AI services and data science at Oracle, said the primary goal is to offload the data engineering tasks associated with machine learning operations (MLOps) from organizations that simply want their developers to include AI capabilities within their applications without having to necessarily hire and then retain a dedicated data science team.

    However, organizations also have the option of uploading their own data into OCI AI services to retrain the models provided by Oracle, he noted.

    Ultimate, the goal is to make OCI AI services a simple extension of DevOps workflows by making it simpler to employ AI models; these models become just another software artifact that can be stored and updated in a Git repository alongside all the other artifacts managed by a DevOps team, said Ziklik. In effect, Oracle wants to make AI ‘boring’ in the sense that these capabilities can now be readily invoked by any development team, he added.

    The OCA AI services include OCI Language, a text analysis capability that enables developers to add sentiment analysis, key-phrase extraction, text classification, named entity recognition and other similar capabilities to their applications, and OCI Speech, which converts file-based audio data containing human speech into text transcriptions.

    Oracle has also included OCI Vision for image recognition and document analysis tasks, OCI Anomaly Detection to create models that flag irregularities in processes, OCI Forecasting for tracking business metrics over time and OCI Data Labeling for creating datasets to train AI models.

    These services are designed to address the most critical AI requirements of the average enterprise rather than attempting to outperform on a set of AI benchmarks that don’t reflect the requirements of business development teams, said Ziklik.

    In addition, Ziklik noted Oracle has also made it easier to address AI compliance requirements that will eventually require organizations to document precisely how their AI models work.

    At some point soon, just about every application will be invoking AI capabilities to one degree or another. That shift creates a major workflow challenge for DevOps teams. AI models are typically created by data science teams that typically don’t successfully deploy an AI model in a production environment more than a handful of times a year. Those AI models, however, need to be integrated with applications that, in many cases, are being continuously updated via DevOps workflows.

    Oracle said that goal becomes easier to achieve using models it creates versus allowing data science teams to build out a set of custom MLOps workflows on platforms that then need to be maintained by IT professionals. Instead of having to set up, for example, a feature store to track and manage AI models, the models created using OCI AI can be stored in an existing Git repository.

    Naturally, each organization will need to determine the degree to which they will converge MLOps and DevOps best practices. Oracle, however, is betting that the simplest way to achieve that goal is via AI models surfaced via a cloud service that developers can readily invoke whenever required.

  • Newly Independent VMware to Focus on Multi-Cloud

    Newly Independent VMware to Focus on Multi-Cloud

    As an independent company once again, VMware will focus its efforts on providing management planes that span multiple cloud computing environments after officially spinning out of Dell Technologies.

    Ray O’Farrell, executive vice president for the cloud-native apps business unit at VMware, said the company now has a unique opportunity to work closely with providers of cloud services, builders of on-premises IT infrastructure and providers of telecommunications services.

    The terms of the spin-off included an $11.5 billion special cash dividend that resulted in a $27.40 per share dividend payment to all VMware stockholders. VMware claims the simplified financial structure that arises from the deal will provide it with additional operational and financial flexibility.

    Going forward, much of the development work will focus on providing management planes that not only span multiple clouds but also address specific cross-platform requirements such as security. It’s not likely there will ever be one single uber control plane for all of IT, noted O’Farrell. Rather, IT teams should expect VMware to deliver a series of well-integrated control planes to automate specific tasks in a way that breaks down IT silos, he said.

    VMware, however, under terms of its existing alliance, will also continue to work closely with Dell to create server environments that are optimized for VMware hypervisor platforms, O’Farrell said.

    Key to the strategy is a portfolio of observability tools that VMware plans to continue to expand, noted O’Farrell. VMware will also address the requirements of both traditional monolithic applications running on virtual machines as well as cloud-native applications running on distributions of Kubernetes, such as VMware Tanzu, that may be deployed on top of a hypervisor or on a bare-metal server, he added.

    Given the complex state of IT environments today, it’s all but inevitable something will go wrong, said O’Farrell. The challenge and the opportunity for VMware is to provide IT teams with the observability tools required to discover as many issues as possible before they adversely impact the business, he added. Once those issues are discovered, IT teams should be able to automate the remediation process using the rest of the portfolio of VMware management frameworks, he noted.

    Those management frameworks will also provide the foundation for unifying traditional approaches to IT service management (ITSM) with DevOps best practices that are now being used more widely, especially to manage cloud-native applications, said O’Farrell.

    When it comes to on-premises IT environments, VMware continues to dominate. Its hypervisor is, by far, the most widely used on servers in local data centers. VMware has spent much of the last two years expanding its reach into multiple clouds to enable IT organizations to standardize on a series of management frameworks. The goal is to reduce the total cost of IT by reducing reliance on what would otherwise be a hodgepodge of isolated management frameworks. The challenge VMware regularly encounters is the IT teams that manage cloud computing environments are not always the same ones that are managing on-premises IT environments. As such, many IT teams that have deployed cloud applications tend to embrace the management frameworks provided by their cloud services provider.

    VMware, however, is betting that as more organizations look to reduce the total cost of IT, the economic pressure to converge IT management using its frameworks will be simply too great to ignore.

  • GraphQL’s Greatest Strength is Also its Greatest Weakness

    GraphQL’s Greatest Strength is Also its Greatest Weakness

    Michael Scott: Why don’t I tell you what my greatest weaknesses are? I work too hard, I care too much and sometimes I can be too invested in my job.
    David Wallace: Okay. And your strengths?
    Michael Scott: Well, my weaknesses are actually strengths.
    David Wallace: Oh. Yes. Very good.

    GraphQL is a new query language that offers a simple way to interact with structured data. The best thing about GraphQL’s design is its convenient data fetching process which enables the requesting party to collect limitless data and perform multiple actions, all with a single API call. This interaction method makes it super useful and very easy to use. However, from a security perspective, its greatest strength could also be its greatest weakness.

    I recently met with Elad Koren, chief product officer, Salt Security, to understand the nuances of GraphQL security. According to Koren, GraphQL affords better usability than REST APIs, yet its bundled request model may compromise systems that don’t employ proper object-level authorization checks. Also, since developers interact with GraphQL services differently than typical web APIs, hackers could avoid detection by typical firewalls, requiring a new approach to security.

    These concerns aren’t dealbreakers for adoption; rather they are a reality check for those using GraphQL in production. Below, we’ll explore some potential weaknesses and look at some general mitigations that providers can take to improve the confidentiality of their GraphQL endpoints.

    What is GraphQL?

    GraphQL was initially developed by Facebook and open sourced in 2015. It’s a query language that makes data retrieval and manipulation with external sources very easy. Instead of programming and linking together complex calls with traditional HTTP API requests, GraphQL enables a client to bundle queries into a single request. This design pattern reduces the under- and over-fetching pattern that REST APIs typically suffer from.

    “You get exactly what you need, not more or less,” described Koren. This makes GraphQL a popular choice for modern database mechanics over REST, as it’s similar to SQL querying.

    Adoption of GraphQL is steadily growing; a 2020 RapidAPI survey found GraphQL usage had quadrupled. GraphQL is now used by 22.5% of API developers. But when it comes to overall API design patterns, REST is still the dominant architectural style used by 93.4% of APIs, found Postman’s 2020 State of API Report.

    GraphQL is promising and has a number of benefits, but remains in an early adoption phase. “It’s still a technology that early adopters are starting to look into—it’s not so widespread,” said Koren. Due to its age, GraphQL security practices are immature, exposing a few potential vulnerabilities for platforms that use GraphQL.

    Unique Security Concerns

    So, what are some unique security concerns in the GraphQL paradigm? Well, according to Koren, it begins with a lack of understanding. “Security is not necessarily top-of-mind most of the time,” he said. “When developers choose to implement GraphQL, they assume that they’re not using APIs anymore and that traditional REST API vulnerabilities do not apply.”

    In fact, the opposite may be true. GraphQL APIs can easily suffer from broken object-level authorization, OWASP’s number-one API vulnerability, just as REST APIs do. But, with greater ease of access to many underlying systems, a single GraphQL query could exfiltrate much more information than a typical API request. If the GraphQL provider does not have granular authorization checks for each particular method and resource, a GraphQL endpoint could suffer from data overexposure.

    Another issue concerns spotting malicious behavior. Typically, when hackers perform reconnaissance on an API, they brute-force it with many requests; trying different namespaces and changing user agents in the process. With REST APIs, this sort of malicious behavior is easier to catch with standard web application firewalls (WAFs) since it’s easier to notice hundreds of peculiar malformed requests. However, with GraphQL, a hacker conducting query batching could completely fly under the radar of typical thresholds.

    This could easily lead to an account takeover, said Koren, who has seen this in production. He described a production payment service that used GraphQL; callers could perform mutations and capabilities they shouldn’t have been allowed to perform, such as pulling up other users’ account information and even initiating transactions.

    It’s easier to limit this type of nefarious traffic with REST APIs by assigning access parameters to each resource and handling authorization checks once at a time. But, this playbook is thrown out the door in GraphQL. “When you’re using a single point to access the data, you may have some false sense of security,” said Koren. In practice, having a single access point requires hard work to retain its integrity. A usable GraphQL frontend may also often mask a convoluted backend made of disparate API styles, Koren explained, making it much harder to correlate user authorizations to specific resources and mutations across various microservices.

    Tips to Mitigate Weaknesses

    So, with these weaknesses in mind, how should GraphQL-based platforms respond? Koren provided the following advice to protect GraphQL APIs:

    • Adopt a security mindset in development: It’s vital to start with a security culture from the beginning. Usability shouldn’t compromise security; ideally, they should complement each other.
    • Ensure proper authorization checks are in place: Whenever an asset is provided to the user, you need to consider whether the user is authorized to access it—especially if they are hitting multiple resources at once.
    • Set a new baseline specific to GraphQL: GraphQL owners need to adapt their perimeter security systems to look for new queues. These validations should consider typical REST API security checks and nuanced thresholds that consider nested queries and batch queries.
    • Know your API inventory: Maintain a clear picture of the underlying architecture of what is beneath the GraphQL endpoint. Verify the data sources and ensure they correctly correspond to user privileges.
    • Increase visibility into API calls: If possible, increase your visibility into queries, mutations, attributes, variables and underlying specifications and how they interact with each other.

    Strengthening GraphQL Endpoints

    API attacks are rapidly increasing. Gartner estimates APIs will become a top threat vector in 2022, and Salt Labs data showcased a shocking 300% growth in malicious API traffic in mid-2021.

    “Like any other innovative tech that comes into the mainstream, it will rise in popularity, but it will not surpass REST in the foreseeable future,” says Koren. Perhaps in three to four years, GraphQL’s current 20% adoption rate will rise to 30% to 50%. While GraphQL is still a relatively niche tool, its use is growing, especially among API-first cloud-native tech companies. And with this adoption will come novel security concerns.

    According to Koren, query batching makes catching malicious attacks using ordinary firewalls tricky. Thus, training a new baseline to discover anomalies unique to GraphQL will be necessary to find and limit hackers while they are still in the reconnaissance phase. Thus, we’ll likely see future security investment go into spotting these atypical GraphQL interactions.

    In general, perhaps the best advice is to treat GraphQL with the same level of intensity you would with any other type of API—if not more. As a single doorway to many underlying systems, GraphQL requires added security forethought and careful application of user authorization.

    With that squared away, hopefully, GraphQL’s greatest strength will remain just that—a great strength.

  • Couchbase Revamps DBaaS Based on Document Database

    Couchbase Revamps DBaaS Based on Document Database

    Couchbase Inc. has unfurled a revamped database-as-a-service (DBaaS) platform dubbed Couchbase Capella hosted on the Amazon Web Services (AWS) cloud.

    Scott Anderson, senior vice president for product management for Couchbase, said that as application development continues to evolve, it’s becoming apparent more organizations prefer to have providers of databases manage those platforms on their behalf. That approach frees up database administrators (DBAs) to spend more of their time building and deploying applications, he noted.

    Couchbase Capella is based on Couchbase Server 7, which added multi-statement SQL transactions capabilities to the document database, based on a JavaScript Object Notation (JSON) format, to make it possible to also run in microseconds transaction processing applications that previously would have required a relational database to process SQL ACID transactions.

    That release of Couchbase Server 7 also added schema and table-like organizing structures, called “scopes and collections,” within the schemaless database to make it possible to add a table while transactions are running.

    As a document database Couchbase has gained traction mainly thanks to developers who have opted to employ a database they could download and deploy themselves to build applications instead of requiring a DBA to set up a relational database. However, as the number of instances of a document database proliferates, a need to manage them across fleets of servers and cloud services has emerged.

    The challenge then becomes determining whether to hire a dedicated administer or employ a DBaaS managed by a vendor. Many organizations are opting for the DBaaS approach because it eliminates the need to hire a full-time administrator. Once an organization opts for the DBaaS approach, however, it next needs to integrate that service within its DevOps workflow to build those applications.

    There is, of course, no shortage of options when it comes to DBaaS platforms. The global cloud database and DBaaS market size is expected to reach $26 billion by 2025, according to a report from Adroit Market Research. Overall, the as-a-service market reached a record $13.4 billion in the third quarter, up 55% from prior year, according to a report published by Information Services Group (ISG).

    It’s not clear to what degree organizations will ultimately wind up relying on as-a-service platforms, but since the start of the COVID-19 pandemic, the shift to this approach to consuming IT resources has increased significantly. As a result, the way internal IT teams are organized is shifting as lower-level tasks are either automated or handled by an external IT team that works for a vendor.

    Regardless of approach, the amount of data being created and analyzed within organizations is only going to grow. Organizations will need to determine to what degree it makes sense for them to manage that data versus relying on an external services provider. The challenge, of course, when relying on an external service provider isn’t just technical; it introduces a new cultural dynamic that takes some time for many IT teams to appreciate fully.

  • Sustainability No Longer Just a Buzzword for Cloud IT

    Sustainability No Longer Just a Buzzword for Cloud IT

    A recent CloudBolt survey on IT sustainability finds that sustainability is no longer just a buzzword — the market is demanding real change, and it appears that environmental concerns finally are influencing large IT investments. For example, 67% say that a cloud provider’s sustainability initiatives are important in deciding whether to do business with them. A significant portion of organizations are even willing to pay a premium to support green initiatives!

    Below, I’ll review the report to find its major takeaways. We’ll see how sustainability is directing real action in cloud IT and briefly compare how the market perceives current green initiatives among three top cloud providers: AWS, GCP and Azure.

    Sustainability Gains Real-World Traction

    In June and July 2021, CloudBolt polled 256 global CxOs and tech leaders on its Pulse platform, and found that 76% of respondents now consider climate change an existential threat. Not only are IT purchasers factoring compute and cost, but a sustainability conscience is now influencing executives to direct sweeping change. In fact, 79% of respondents indicate their IT departments are expected to help their companies achieve specific sustainability initiatives driven by the board of directors of the C-suite.

    Interestingly, other studies found that a sustainability commitment results in tangible business outcomes. For instance, 88% of the research conducted by Oxford University and Arabesque showed that solid environmental, social and governance (ESG) practices result in better operational performance of firms and higher profits. This study also noted that 80% of the time, a company’s stock price is positively influenced by sustainability practices.

    Climate Conscience Guides Cloud Choices

    Most organizations now consider a cloud vendor’s sustainability initiatives when choosing whether to do business with that provider. A full 78% of respondents agree that the public/private cloud choices they make can materially affect the environment for better or worse. New environmental cloud commitments not only attempt to minimize carbon emissions from their data centers but factor in ecological ramifications and aim to erase companies’ historical carbon footprints, as well.

    Cloud consumers also want to contribute to addressing these green initiatives. An impressive 79% of respondents indicate that they will pay a premium to work with vendors who incorporate sustainability into their business. And 41% of companies are willing to pay a premium of 11 % to 15% of their current bills. This shows that sustainability is now a vital factor within the marketplace, and companies are willing to pay the price to increase their own environmental standing.

    Though this commitment is undoubtedly growing, the report did find that operational requirements such as security, cost and agility, still rank significantly higher than sustainability when comparing cloud providers. Though IT professionals recognize climate change as an existential threat, they still have day jobs and must keep operations moving.

    AWS: King of Green Clouds

    Slightly more than half (51%) of respondents agree that the industry-wide green energy commitment is real and growing among all cloud providers. However, when comparing the top three—Amazon Web Services (AWS), Azure and Google, AWS appears to be emerging as an IT sustainability leader; 41% of respondents perceived AWS as doing the most to address green initiatives.

    AWS is on track to power its entire operations with 100% renewable energy by 2025. With their solar plant investment in April 2021, Amazon became the largest corporate buyer of renewable energy in Europe. Around the globe, AWS has invested in a combination of on-site solar, solar farms and wind farms to power their data centers and Whole Foods divisions.

    To their credit, both Microsoft and Google also committed to climate pledges that affect their cloud footprint. Azure supports a similar initiative to reach 100% renewable energy by 2025, in addition to further investments to improve water, waste disposal and surrounding local ecosystems. Google Cloud’s commitment is to operate on carbon-free energy 24 hours a day by 2030, and the company has already achieved 100% renewable every year since 2017.

    Not only does AWS appear to be doing the most to address its environmental impact, it also retains the most market traction as a cloud leader. The majority of respondents (62%) said that AWS is winning the cloud wars while only 31% said Azure and just 7% said GCP.

    Final Thoughts

    It is heartening to see that ESG standards are having a measurable impact on a company’s cloud allegiances. The market now demands real change and is willing to pay the price for more ethical and sustainable cloud hosting.

    But choosing a cloud provider is only one aspect of reducing IT’s impact. As I’ve covered before, there are many ways IT can curb its climate impact. Such actions include optimizing overall infrastructure, shuttering zombie VMs, avoiding over-provisioning resources, increasing performance visibility, refactoring code and other measures. What’s great is that most of these initiatives have the added benefit of reducing cost to the business.

    The CloudBolt Industry Insights Report, The Truth About IT Sustainability: Paying More Green to Get More Green, surveyed 256 IT leaders on their perception of cloud sustainability. For additional insights, you can pick up a copy here.

  • Dynatrace Survey Sees Continuous Delivery Challenges Ahead

    Dynatrace Survey Sees Continuous Delivery Challenges Ahead

    A global survey of 1,300 application development and DevOps leaders conducted by the research firm Coleman Parkes on behalf of Dynatrace finds, on average, organizations expect to increase the frequency of their software releases by 58% over the next two years.

    Andreas Grabner, director of strategic partnerships at Dynatrace, an observability platform provider, said that while it’s clear organizations are embracing DevOps best practices to achieve that goal, the survey also found that more than a quarter (27%) of DevOps teams’ time is spent on manual continuous integration/continuous delivery (CI/CD) tasks. Nearly a quarter (22%) admit they’re often under so much pressure to meet the demand for application deployments that they must sacrifice code quality.

    In response, nearly two-thirds of respondents (62%) are investing in automation to eliminate manual tasks, while a similar percentage are looking to automate incident response processes. Another 45% are investing in observability tools, with nearly three-quarters (74%) noting that end-to-end observability will be essential to DevOps in the future.

    A full 98% also noted that extending DevOps to more applications will play a crucial role in driving digital transformation and optimizing customer experience. A total of 71% said a unified platform that seamlessly integrates their toolchains will be critical to scaling DevOps, while 79% said extending artificial intelligence to IT operations (AIOps) into the realm of DevOps is critical for their future success.

    Survey respondents, however, also identified siloed team cultures (75%) and application complexity (70%) as the primary barriers to achieving DevOps success. Organizations, as a result, are investing in the automation of manual CI/CD tasks (62%), eliminating manual incident response (62%) and end-to-end observability (45%).

    Grabner noted that, as more organizations build and deploy next-generation applications based on microservices constructed using containers and application programming interfaces (APIs), it will only become more challenging to automate DevOps processes. As part of an effort to reduce the cost of delivering those applications, Dynatrace donated Keptn, an open source enterprise-grade control plane for automating the continuous delivery of cloud-native applications, to the Cloud Native Computing Foundation (CNCF), added Grabner. The overall goal is to reduce the total cost of implementing DevOps as part of an effort to instrument more applications, he noted.

    While most organizations that have embraced DevOps have a good handle on how to implement continuous integration, achieving the continuous delivery side of the DevOps equation has proven to be more challenging. In the absence of standardization among the platforms, each application deployed on individual IT systems is a “snowflake,” in that it is unique to that platform. That issue, in part, is why so many IT teams still rely on manual processes to deploy applications.

    It’s only a matter of time before organizations begin to more aggressively automate the deployment of applications. That may become even easier to achieve if they standardize on a Kubernetes application programming interface (API) that can be implemented across any platform.

    In the meantime, however, it’s clear that, as the pace of digital business transformation increases, one of the most limiting factors organizations will encounter is the pace at which applications can be deployed and updated.

  • How to Avoid the Most Common Online Service Costs 

    How to Avoid the Most Common Online Service Costs 

    Throughout the last year and a half, most organizations were forced to either create or develop their online service offerings at a rapid pace. Companies had to find alternate solutions to continue day-to-day operations in the transition to remote-first. Low development costs and the wide range of use cases have been primary factors in the continued rise of online services even as enterprises look to move back to the office. 

    Although the initial development costs are affordable to most global organizations, maintaining those workloads—such as internal self-service or software-as-a-service (SaaS) platforms—is a different story. Many enterprises fall victim to paying unnecessary expenses to keep their online services operating. When calculating the costs of these services, organizations often leave the costs of managing hardware out. In the event they are included, the cost breakdown is not typically accurate. 

    When transitioning to or enhancing online services, calculating the correct costs can be overwhelming. To avoid overpaying, companies need to properly assess the operational costs of their online services. Here’s how.

    Evaluate the Infrastructure

    First, determine what type of infrastructure fits best for the online offering or service. A popular trend is the “always-on” model, and with good reason. The success of online streaming services and high-availability digital workspaces encouraged enterprises to adopt this method. 

    However, it is important to note that these companies are successful with this type of business model because it fits best with their overall product and services offerings. Many organizations cannot thrive in an always-on style because they simply do not need to be always-on. After all, not every service needs to be available 24 hours a day. 

    If the online service is only needed during typical ‘office hours’ but can remain on standby after closing, the organization still needs to pay for those idle hours. These costs add up and can make for an unpleasant surprise when they show up on the monthly bill. Determine what the cost of using an always-on service will be for the organization before committing to it and weigh if it is necessary. Many times, an always-on service is not needed, and an alternate approach will do just fine. 

    Pay for What you Need

    The more users on a particular platform, the more data is used. Estimating the accurate amount of data use is a vital step in being cost-efficient. In many cases, organizations pay more than the necessary amount because of inaccurate calculations about how much data will be used. It is vital to assess data use regularly to make sure that customers have what they need without the business breaking the bank. 

    Saving money does not have to equal a poor quality of service. When paying for online services with an infrastructure-as-a-service (IaaS) provider, a business is paying for more than just a place to host its platform. IaaS providers also provide varying levels of support, allowing for organizations to take advantage of additional services at no extra cost. By partnering with an IaaS provider, an organization can experience speed, reliability and security without blowing the budget. 

    Assess if the Cloud is the Best Fit

    A common misconception is that online services are fully maintained in the cloud; however, that is not always the case. Building and testing services may require some operations take place in an on-premises location. An organization needs to evaluate whether on-premises is more cost-effective than developing its service in the cloud. Along with the potential for cost-effectiveness, on-premises solutions can sometimes prove to be more secure. Choosing on-premises or even a hybrid model for highly sensitive data may provide tighter security control. 

    Maintaining a service in the cloud can potentially transform an online business by offering flexible, scalable and cost-effective solutions. A scalable infrastructure becomes an imperative for a growing business, and with the cloud, services and consumption can grow as the business does. However, organizations need to consider their business requirements and see if their deployment decisions match the requirements for cloud or on-premises. 

    Evaluate your Total Cost

    Providers often give a basic estimate of total expenses, but it is always helpful to ask for your total cost of ownership. Looking at the total cost of ownership ensures clarity between the organization and the service provider. Overall, the most crucial best practice for avoiding unnecessary costs is to be aware of how your organization is spending money. 

    By assessing the above factors, organizations can cut unnecessary online service costs by only paying for what they need. An organization that is well-informed about its needs and use of resources is in a better position to succeed and scale their offerings—without breaking the bank. 

  • Sysdig Adds Cloud Access Controls to DevSecOps Platform

    Sysdig Adds Cloud Access Controls to DevSecOps Platform

    Sysdig announced today that it is adding a Cloud Infrastructure Entitlements Management (CIEM) capability to its Secure DevOps platform as part of an effort to better enforce least-privilege access within the context of a larger zero-trust approach to cybersecurity.

    Nick Fisher, vice president of product marketing for Sysdig, said this addition to the company’s core DevSecOps platform for securing cloud services will prevent organizations from inadvertently providing individuals with excessive permissions that result in cybercriminals gaining widespread access to applications and systems when the credentials those individuals have are compromised.

    A recent report from the Sysdig Threat Team found that nearly 80% of users have excessive entitlements due to overly permissive policies. Similarly, Gartner forecasted that 75% of security failures will result from inadequate management of identities, access and privileges by 2023, up from 50% last year.

    The CIEM offering from Sysdig enables cybersecurity and IT operations teams to resolve that issue across multiple clouds in under two minutes once installed, said Fisher. The Sysdig platform achieves that goal by making it possible to leverage templates as a set of infrastructure-as-code (IaC) tools that enable DevOps teams to integrate security within their existing workflows.

    CIEM also simplifies access control auditing by making it easier to discover who in the organization has permission to access cloud infrastructure services. As part of that capability, Sysdig also provides out-of-the-box compliance policies and access to reports that can be generated on-demand to surface a detailed audit trail of all cloud permission changes.

    Finally, CIEM will generate an alert any time someone is denied permission to access a cloud resource, noted Fisher. That capability provides cybersecurity teams with an opportunity to then review what permissions might need to be granted or whether a bad actor is attempting to compromise a cloud environment.

    Most of the cloud security issues that organizations encounter can be traced back to developers that have misconfigured one cloud resource in a way that allows cybercriminals to access, for example, a port that has been left open. CIEM extends the Sysdig platform so that, in addition to scanning for vulnerabilities and misconfigurations, it can detect and respond to attacks across containers and virtual machines deployed in a cloud environment.

    Thanks, in part, to recent high-profile breaches of software supply chains, there’s a lot more focus on cloud security as the rate at which applications are being deployed on these platforms steadily increases. While the cloud platforms themselves are fundamentally secure, the challenge most organizations are encountering is they have immature processes in place for securing the workloads running in the cloud.

    Of course, being able to limit access to those cloud resources is only the first step toward implementing a set of DevSecOps best practices to ensure the integrity of the cloud platforms being employed. Unfortunately, too many developers still tend to assume the cloud service provider is taking steps to secure workloads on their behalf. In reality, cloud service providers have adopted a shared responsibility model that, from their perspective, limits their cybersecurity responsibility to the core infrastructure they provide. It’s up to the DevOps team responsible for the workloads running on those platforms to figure out how to secure the rest of that IT environment.