devopsy.kinsta.cloud

Category: DevOps in the Cloud

  • What’s Ahead for the Future of Data Streaming?

    What’s Ahead for the Future of Data Streaming?

    Data is everywhere. It’s being produced by almost everyone and everything around us. For businesses to be competitive, they need to build resilient, scalable systems that can efficiently tap into and react to this ever-increasing volume of data. Companies are meeting this need by moving to real-time data streaming to develop new solutions and improve their businesses and customer experience.

    This category of data streaming has been growing. And, driven by the rise of real-time digital experiences like ride-sharing, fraud detection, inventory management and more, the growth has accelerated.

    So what’s next for data streaming?

    Data as a Product Grows in Popularity

    The concept of data as a product will become more mainstream. Across many industries, data streaming is becoming central to how businesses operate and disseminate information within their companies. However, there is still a need for broader education about key data principles and best practices, like those outlined through data mesh.

    Data as a product is foundational to rethinking how data produced in one part of a business can be reliably used in another. Data products with formalized ownership and responsibilities, combined with a platform for discoverability and accessibility, result in significantly fewer barriers and a much easier data access experience for all. Schemas, the Kafka API and maturing specification standards like ASyncAPI can be a part of this evolution.

    As more folks embrace this mindset, I expect to see companies shift from using ad-hoc data pipelines to ones based on data products, driving a centralized system that can power both better analytical insights and operational execution.

    Growth of Self-Service Solutions

    With the rise of cloud-based offerings, I expect to see more companies offering more accessible, pay-as-you-go, self-service solutions. We’ve already seen this shift over the past few years; cloud-based offerings are making it easier for companies to try out a data product based on their usage (or lack thereof). Given the current market conditions, these offerings will be more appealing to organizations that aren’t ready to sign a multi-year contract for a product offering or focus solely on a single technology.

    Increase in Cloud Migrations and the Continued Rise of SaaS

    Cloud is here to stay. We’ve proven that it works, that it’s safe and secure, and for many folks, it just makes sense. This should come as no surprise to anyone, but expect the trend of cloud migrations to continue.

    In the context of Apache Kafka, building out a Kafka-based data streaming solution used to mean hosting and managing your own Kafka cluster. If you’ve ever been in that position, you know that usually means more DevOps work and less focus on building applications to get the most out of your data. Not only do cloud-based Kafka offerings eliminate much of the DevOps headaches that come with a Kafka cluster, but they also make it much easier and faster to hit the ground running and begin streaming your data.

    I’m personally excited by what the cloud and SaaS can do to make Kafka and data streaming more accessible. In my visits to developers and companies around the globe, I see this enthusiasm shared by so many. Entire geographic regions and industries are taking the opportunity to move to the cloud and dive headfirst into data streaming.

    KRaft Leads to Rise in Kafka Adoption

    As of Apache Kafka 3.3, the KRaft consensus protocol has replaced Zookeeper and is production-ready. Cluster metadata can now be maintained and managed from within the cluster, meaning there’s one less thing to worry about when deploying Kafka instances.

    While there are many options for cloud-based Kafka-as-a-Service, improvements such as KRaft in open source Kafka make self-hosting even easier. This, along with the work done to make it simpler to run managed Kafka services on local machines and test environments, means that Kafka no longer has to be synonymous with complexity. With the difficulty of managing and maintaining a Kafka instance no longer preventing folks from making use of data streaming, I predict that the adoption of Kafka will increase even more.

    Data streaming will continue to mature as a transformational technology for companies of all sizes, serving as a critical infrastructure that most organizations will need to run their business.

    If you haven’t yet explored what data streaming has to offer you, maybe this will be your year to check it out!

  • Microsoft Outage Outrage: Was it BGP or DNS?

    Microsoft Outage Outrage: Was it BGP or DNS?

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

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

  • The Database of the Future: Seven Key Principles

    The Database of the Future: Seven Key Principles

    The database of the future will be more than just a database. Instead, it will be a platform that focuses on the user experience and abstracts the technology. Looking at the evolution of application development, an enormous amount of effort has made it easier to build and deploy applications. Similarly, databases need to evolve for ease of use with a delightful developer experience and an exemplary user interface that surfaces features and functionalities that engineers will actually use.

    Here are seven principal features needed to chart the development of the future database.

    1. Serverless by Default

    Serverless is unquestionably the most significant paradigm shift in software engineering in the last five years and the one that’s been realized the least. There aren’t that many people at this point that are all in on serverless. It’s the shift away from buying a server to a service that does what you need and scales with your growth.

    Serverless by default is the only way to ensure the database of the future will be easy to operate while being consistently reliable. Serverless is evolving from running functions in the cloud to becoming the standard for fast-paced development teams that don’t want to worry about vCPUs or node pools but focus on outcomes.

    The companies that are doing it the best still deploy servers, but they are leveraging products that scale independently, regardless of how many servers they have. Their component vendors can increase the number of resources allotted to them, and they only pay for what they use, and the architecture of the solution scales in that way. They’re not buying a single server and pushing it as hard as they can. They’re telling one platform, ‘here’s my code,’ they’re telling another, ‘here’s my data,’ and then that scales up based on usage much, much farther than buying a single server.

    When people think serverless, they think JavaScript and Lambda, but there’s serverless PHP out there, too. It’s not just the JavaScript community. Other software paradigms are going for this. We will see more and more people pulling this out when they need to do some quick code and they want to ship to production as quickly as possible and scale as quickly as possible.

    2. Easy to Operate

    The most significant advancements in DevOps have been freeing developers from complex operations that overwhelm their day-to-day operations. Engineering teams today are organized around product and business goals, not maintenance and servicing. But databases have yet to catch up. Product teams still rely on experts to perform overly complicated database operations tasks.

    The database of the future must fit into everyone’s DevOps workflows. It must be usable for any developer and leveraged by every team within a technical organization. The database needs to be operable by everyone and no longer require database admins to manage backups and capacity planning or worry about disaster recovery.

    Developer-centric features like database branching, database developer environments, autoscaling and usage-based billing will be commonplace.

    3. Reliable

    Reliable simply means it’s harder to hit the scaling limits. Not only does it mean that the database is there, but that you get the right information when something is going wrong, and you can collaboratively help scale.

    Nothing scales infinitely. There are not enough computers in the world to scale something to infinity. You’ll always be able to query a database and pull too much information out of it too fast. No matter how many cars you get or how much horsepower you have, you can’t go a million miles an hour. A good database must let you know when you’re hitting those limitations and help you move past them, whether at a small scale, medium scale or large scale.

    4. Interoperable

    Future databases will be accessible to every imaginable client–from smart refrigerators to fleets of autonomous delivery vehicles. But this client-agnostic approach requires planning for many more transactions and connections than most current databases could ever manage simultaneously.

    In the future, databases can handle unlimited connections through smart connection pooling, query replication and intelligent query routing. Databases will also need to serve a wide set of connections and clients. Although we are already seeing many databases offering web APIs and new connection types, as these get tested at scale, we will begin to see them adopted and used to power the next generation of applications.

    5. Globally Distributed, Locally Available

    Today, most businesses and applications don’t need a global database, which often introduces unnecessary complexity and operating costs. However, there are many reasons the future database will need to be globally distributed, as they must be located where you need them the most.

    The key to this is knowing what your requirements are. Many people look at multi-region and think it’s faster reads, failover, scaling and breaking the speed of light. Ultimately, it’s all a series of tradeoffs. For example, when you read from a local replica, you trade off consistency because you have asynchronous replication. But this is really leveraging the global internet to deliver a better outcome where it’s necessary.

    Being compliance-ready with regionally stored data enables you to scale rapidly to a new region and provides a great user experience by quickly serving locally available data. High-transaction, low-latency applications such as mobile games already need this capability.

    But there’s one caveat: Global data distribution cannot break principle number two—being easy to operate. Tools will need to be elegant and have straightforward interfaces as their main goal is to make operations easier, not harder.

    6. Intelligent

    The future database is intended to be used by people and will be able to tell them how it needs to be used and how to make it better. All the tools you buy today can only give you the data you need to make some educated guesses. The future database will replace that with concrete recommendations, then self-healing actions.

    This starts with basic data collection and observability and moves to, “let’s record every query that someone makes and use some decision engines and some AI and recommend how they can shard automatically.” It will be able to say, “I’ve recorded your database use for the last 30 days; this is how you should shard for optimal performance. Click the button, and we’ll do it.”

    The future database will say, “You’re scaling too far for the single machine at a per-user level. You must break it down into two or break it down into four, and we figured out how to do it for you, so you don’t have to figure that out. We’ve sharded your data on your behalf.”

    7. Linearly Horizontally Scalable

    Future databases will also need to be designed for future scale. Only a handful of companies on the planet have hit a scale that tests the limits of current technologies, but as information grows, more companies will get there. The next databases will do that by automatically scaling both vertically and horizontally within seconds. Many existing databases require a maintenance window, replication and a failover before they can be scaled up or out. But downtime is unacceptable, and scale should not come at the cost of performance. And it doesn’t have to. The database of the future will scale intelligently and without a blip on the status page.

    In short, the consumer should be able to get what they need when they need it, with no risks. It should be easy to say, “I’ve doubled the number of servers, I’ve doubled the amount of throughput. I’ve quadrupled the number of servers and the amount of throughput.” This is what sharding provides. Good sharding happens automatically at a super high scale, and you’ll only pay for what you use as you go along. The future database will do all of this without users having to turn a knob.

    In conclusion

    It will take the entire database industry to agree on these principal features, adopt a user-focused approach and build future database platforms designed to make engineers more successful by delivering superior products and services to their customers. I envision a day where every company no longer worries about its infrastructure and can simply focus on its business. I want development teams to take back control over their development workflow. Using a database should be as easy as writing code.

  • Deploying a Service Mesh: Challenges and Solutions

    Deploying a Service Mesh: Challenges and Solutions

    A service mesh is a dedicated infrastructure layer that enables communication between microservices in a distributed application. It helps to abstract the underlying communication infrastructure, such as network protocols and load balancing and provides a consistent interface for microservices to communicate with each other.

    In a service mesh, each microservice in the application is represented as a “service” within the mesh, and the mesh acts as a proxy between the services, routing requests and responses between them. It also includes a control plane, which manages and configures the proxy instances and provides observability and monitoring capabilities for the services.

    Some of the benefits include:

    • Improved observability: A service mesh provides visibility into the communication between microservices, which can be helpful for debugging and monitoring the performance of the application.
    • Resilience: It can help to make microservices more resilient by providing features such as retries, timeouts and circuit breakers, which can help to prevent cascading failures.
    • Security: A service mesh can help to secure communication between microservices by providing features such as mutual TLS (mTLS) and rate limiting.
    • Ease of use: It provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications.

    Why is a Service Mesh Important?

    A service mesh is important because it helps to abstract the underlying communication infrastructure for microservices-based applications, which can make it easier for DevOps teams to build and manage these types of applications.

    One of the main benefits is that it provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications. For example, a service mesh can provide features such as load balancing, retries and timeouts, which can be useful for ensuring the resilience and reliability of the application.

    It can also help to improve observability for microservices-based applications by providing visibility into the communication between the microservices. This can be helpful for debugging and monitoring the performance of the application, which can, in turn, make it easier for DevOps teams to identify and resolve issues more quickly.

    What are the Main Deployment Challenges?

    There are several key challenges that a DevOps organization may face:

    • Complexity: Service meshes can be complex to set up and manage, especially in large, distributed applications. This can make it challenging for organizations to implement and ensure that it is configured correctly.
    • Operational overhead: Service meshes can add a layer of complexity to the application stack, which can increase the operational overhead of managing the application. This can be especially challenging for organizations that are not used to operating one.
    • Cost: While service mesh software is typically open source, the need to run a sidecar container alongside every container can increase the compute capacity needed to run a Kubernetes cluster.
    • Integration with existing systems: They can be difficult to integrate with existing systems and processes, especially if the organization has not previously used a service mesh. This can make it challenging to get the full benefits.
    • Lack of expertise: Service meshes are relatively new technologies, and there may be a lack of expertise within the organization. This can make it challenging for organizations to get started and ensure it is used effectively.
    • Performance overhead: Service meshes can add a performance overhead to the application as they introduce an additional layer of proxying between microservices. This can make it challenging to ensure that the application is performant and scalable.

    Best Practices to Ease Service Mesh Pain

    Here are a few best practices that can turn service mesh deployments from a pain to a pleasure.

    Use Configuration-as-Code in a GitOps Approach

    Using configuration as code in a GitOps approach is a best practice to improve reliability and maintainability.

    GitOps is a way of managing infrastructure and applications using Git as the single source of truth. In a GitOps approach, all configuration and deployment information is stored in Git, and changes to the infrastructure and applications are made by committing code changes to Git.

    Using configuration-as-code in a GitOps approach can help to improve the reliability and maintainability of the service mesh in several ways:

    • Version control: Storing configuration-as-code in Git allows you to track changes to the service mesh configuration and roll back changes if necessary. This can help improve the service mesh’s reliability by making it easier to identify and fix issues.
    • Collaboration: Git allows multiple people to work on configuration at the same time, which can make it easier to collaborate on changes and ensure that the service mesh is properly maintained.
    • Automation: GitOps approaches often use automation tools, such as continuous integration and delivery (CI/CD) pipelines, to automatically deploy changes to the service mesh when code is committed to Git. This can make it easier to manage and maintain and can help to improve its reliability by reducing the risk of errors.

    Focus On Developer Experience

    Ensuring a positive developer experience is a best practice because it can help to improve the productivity and effectiveness of the development team. A positive developer experience means that developers can easily understand and use the service mesh, and that it does not introduce unnecessary complexity or frustration into their workflow.

    Here are some ways to improve the developer experience:

    • Provide clear documentation: It is important to provide clear and comprehensive documentation on how to use the service mesh, including examples and tutorials. This will make it easier for developers to understand and use.
    • Integrate with existing tools and processes: The service mesh should integrate seamlessly with the existing tools and processes that the development team is already using. This will help to minimize disruptions to the team’s workflow and make it easier for them to work with.
    • Provide support and training: It is important to provide support and training to help developers understand and use the service mesh effectively. This can include online resources, in-person training, and support from the vendor.

    Reduce Costs With Low-Cost Cloud CPUs

    A service mesh increases the cost of an entire containerized deployment because it requires deploying a sidecar container alongside all workloads. When running on Amazon Web Services (AWS), the AWS Graviton processor can ease deployment by reducing the cost of running service mesh infrastructure.

    The AWS Graviton processor is a custom ARM-based processor designed specifically for use in Amazon Web Services (AWS) environments. It is optimized for running workloads commonly found in the cloud, such as microservices and containerized applications.

    Using the AWS Graviton processor can help to reduce the compute costs of a service mesh because it is generally less expensive than other processors, such as Intel Xeon processors. The AWS Graviton processor is also designed to be highly efficient, which can help reduce the service mesh’s overall resource utilization. This can help to reduce the cost.

    Choose the Right Control Plane

    Choosing the right control plane is a best practice because it can impact the performance, reliability and maintainability of the service mesh. The control plane is the central component that manages the proxy servers and enables you to configure and monitor the communication between microservices.

    Here are some considerations for choosing a good control plane:

    • Compatibility: It is important to choose a control plane that is compatible with the rest of the service mesh infrastructure, as well as with the application and its dependencies. This will ensure that the control plane can operate effectively and support the needs of the application.
    • Performance: The control plane should be able to handle the traffic and data volumes of the application without experiencing performance degradation. It should also be able to scale up or down as needed to meet changing demand.
    • Reliability: The control plane should be reliable and able to withstand failures without interruption. It should also provide features such as circuit breaking, retries and timeouts to help improve the resiliency of the service mesh.
    • Ease of use: The control plane should be easy to use and understand, with clear documentation and a user-friendly interface. This will make it easier for the DevOps team to manage and maintain the service mesh.
    • Integration with other tools: It is important to consider how the control plane integrates with other tools and systems, such as monitoring and logging tools, and how it can be integrated into the overall workflow of the organization.

    Conclusion

    In conclusion, deploying a service mesh can be a complex and challenging process, but it can also provide significant benefits in terms of improving the reliability, scalability and security of a cloud-native application. 

    Some of the key challenges include complexity, operational overhead, integration with existing systems, lack of expertise and performance overhead. 

    To overcome these challenges, it is important to choose the right service mesh, use configuration-as-code in a GitOps approach, choose the right control plane and ensure a positive developer experience. By addressing these challenges and following best practices, organizations can successfully deploy a service mesh and reap the many benefits it has to offer.

    Image Source 

     

  • Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration

    Optimizing Cloud Costs for DevOps With AI-Assisted Orchestration

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

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

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

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

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

    Kubernetes Landscape

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

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

    Cloud Cost Use Cases for DevOps, DevSecOps and SRE

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

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

    Sources of Waste and Potential Savings

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

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

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

    Complexities Impacting Ability to Optimize

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

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

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

    Opportunity for an AI-Assisted Kubernetes Orchestrator

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

    What This Means

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

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

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

  • Devs Increasingly Rely on IaC to Manage Multiple Clouds

    Devs Increasingly Rely on IaC to Manage Multiple Clouds

    A survey of more than 300 DevOps professionals conducted by Firefly, a provider of a platform for automating cloud provisioning, found that more than a third of organizations (36%) have allocated the equivalent of two or more full-time engineers per month to writing infrastructure-as-code (IaC) templates.

    A full 82% are also deploying the templates within the context of a DevOps pipeline, with 68% reporting more than half of their cloud instances are now managed using IaC tools, according to the survey. A total of 27% reported they are now managing every aspect of IT as code.

    The challenge is that 61% of respondents also admitted they can’t automatically detect configuration drift over time, with more than a third (35%) spending days or weeks remediating IaC templates. Well over half of respondents (56%) said they are also retrofitting existing cloud instances using IaC tools.

    Cindy Blake, vice president of marketing for Firefly, said this issue is likely to become more challenging to address as the number of clouds in use continues to increase. The survey found 44% of respondents already use multiple cloud providers. Overall, 42% reported having more than 10 cloud accounts.

    The top IaC benefits identified by survey respondents are improved efficiency (75%), increased reliability (55%) and easier compliance (52%) and simpler troubleshooting (49%).

    Not surprisingly, the survey identified knowledge (46%) followed closely by complexity (43%) as the top challenges organizations face when using code to manage cloud infrastructure. Factors increasing complexity included cost and complexity (70%), followed by security (61%).

    In addition, only 14% of respondents reported that all their engineers are IaC literate. More than a third (36%) said they only have one IaC-literate engineer. As a result, many organizations are now attempting to navigate IaC bottleneck issues that could be alleviated if they relied more on automation that can be integrated within a continuous integration/continuous delivery (CI/CD) platform, noted Blake. She added that many organizations are already allocating too much engineering time to manually writing IaC templates.

    Those manual efforts often result in misconfigurations that are easily exploited by cybercriminals, added Blake. Many developers using IaC tools such as Terraform have had little to no cybersecurity training, so the odds they will make a mistake are high.

    At a time when more organizations are focused on the productivity of DevOps teams and ensuring the integrity of software supply chains, there is a clear need to automate processes that increasingly span multiple clouds. More organizations than ever are employing multiple clouds to ensure application availability in the wake of a series of outages over the past few years, Blake said.

    Regardless of the motivation, multi-cloud computing is here to stay. Developers opt for different clouds based on the performance capabilities they can provide for various classes of workloads. There may be one cloud platform that runs the bulk of the workloads, but the number of organizations that have standardized on a single cloud are comparatively few. The issue is finding the best way to manage multiple clouds that doesn’t require as much manual effort so organizations can reduce the total cost of managing IT environments.

  • Cloudflare Adds Digital Experience Monitoring to CDN Portfolio

    Cloudflare Adds Digital Experience Monitoring to CDN Portfolio

    At an online CIO Week event, Cloudflare today added a digital experience monitoring capability to a portfolio of services layered on top of its core content delivery network (CDN).

    Corey Mahan, director of product management for Cloudflare, said the Cloudflare Digital Experience Monitoring service extends a Cloudflare Zero Trust platform based on agent software dubbed Cloudflare WARP. The solutions delivers a wide range of software-as-a-service (SaaS) offerings spanning everything from data loss prevention (DLP) to email security.

    He added that the overall goal is to reduce the total cost of IT by delivering SaaS application services more efficiently using a single agent rather than having to deploy multiple agents for each service.

    The Cloudflare Digital Experience Monitoring service, available as a private beta, will enable IT teams to leverage the Cloudflare CDN to measure and analyze controlled data flows to public or private resources by emulating traffic flows using synthetic data. Via integration with the Cloudflare Zero Trust platform, IT teams can also access real-time data visualizations highlighting anomalies in connectivity or performance that might, for example, be indicative of a security breach, noted Mahan.

    While there’s no doubt IT organizations are looking to streamline the number of IT vendors they need to manage, it’s not clear what the center of gravity will be for achieving that goal. Cloudflare is making a case for using the same global CDN that many organizations already rely on for networking services.

    The Cloudflare Digital Experience Monitoring service leverages the company’s CDN to make it simpler to understand, for example, why users in one geography experience sub-optimal application experiences compared to another, said Mahan. That’s especially critical when more organizations than ever have employees working from home across multiple geographies, he added.

    In the longer term, more networking and security functions will be consumed as a service. The challenge then becomes integrating those services into the DevOps workflows that are employed to deploy applications across a highly distributed computing environment. In many cases, what might initially appear to be an application performance issue winds up being a network connectivity problem that is more easily solved.

    One way or another, the management of IT services in the months and years ahead will continue to converge. Organizations of all sizes will need to determine whether it makes economic sense to acquire platforms they need to manage versus consuming a service that is managed on their behalf. Most of the time, a service will be easier to consume and free up resources that can be applied to other IT functions, such as application development.

    Of course, organizations will also need to take care to avoid locking themselves into a specific services provider. Ultimately, however, the question is whether managing a specific IT function provides enough differentiated value to be worth the time and effort when there is so much more to do.

  • How DevOps Helps Banks Optimize Their Services

    How DevOps Helps Banks Optimize Their Services

    A world-renowned bank’s CEO was recently quoted as saying that while there are thousands of manual banks now, the future will see only a handful of digital banks. Along with the rest of the world’s critical business sectors, an overwhelming number of banks are also shifting to virtual platforms. This migration is being orchestrated by some of the best DevOps resources that the global FinTech sector has to offer.

    The convenience of personalized services that are always on-demand has incentivized the banking sector’s reliance on DevOps workflows. When the COVID-19 pandemic struck and limited physical banking services, the migration of enterprise banking systems onto the cloud had been in full swing. Most bank employees had to shift to a work-from-home setup, accelerating the use of virtual service delivery.

    As per an estimate by the IBM Institute for Business Value, about 59% of the companies surveyed are in various phases of their digital migration and the banking sector is naturally following suit. DevOps teams are tasked with writing software extensions for connecting digital banking services to the end customer in an agile manner.

    This article explores why DevOps is slowly becoming an essential foundation for any successful banking institution. We will also discuss how traditional institutions cope with these changes and what benefits they can look forward to once they make the leap to DevOps.

    Agile Processes Facilitate Digital Transformation

    Most banks these days have been adopting agile processes to stay ahead of the competitive curve. The main motive behind this is to keep up with frequent business requirements that come with efforts to improve clients’ banking experiences. Fine-tuning the project planning and execution processes that drive this improvement are what the DevOps teams would be mainly doing.

    Under the Agile methodology, banking applications would be created in small, controllable steps known as sprints. Each step is tested meticulously before it can be considered executable or complete. Before continuing to build on the delivered component, proper channels are followed for real-time feedback and course correction. The end goal is that the customer must get a product that is of value in a much shorter timeframe than is possible through any other development process.

    More than even the process and the rules governing it, the DevOps teams involved and their collaboration is a top priority as well as the eventual outcomes. Agile projects behind the most optimal banking services and products must involve continuous planning, testing and integration of finished components.

    Faster Success for DevOps Teams in Banking

    To successfully drive new digital banking services, large banks need billions in assets and need to gain millions of new customers along the way. It all boils down to shifting their processes to a more granular process and continuously improving upon it.

    In situations like these where DevOps practices need to be adopted proactively, the client’s line of business (LOB) teams move to Agile planning strategies fairly quickly. They use a variety of tools to implement Agile and DevOps practices to tackle growing customer demands for their improved digital banking services.

    But for this to work seamlessly, the developer experience for both the LOB and IT teams needs to be streamlined. The LOB and IT teams’ efforts can be integrated if the DevOps platform is automated with built-in Agile capabilities and bi-directional integration. This ensures seamless collaboration, faster DevOps implementation and the speedy delivery of banking services and products.

    Focused Insights and Better Predictability

    Large banks can standardize the internal IT development team on an engineering life cycle management platform, simultaneously providing support to the LOB team via the Agile issue tracking dashboard. Agile life cycle management tools extend an integrated solution for banks. Using these tools, the DevOps teams can be provided with full transparency and traceability of developer data.

    Developer-specific capabilities such as source code management, build automation, continuous integration and delivery and Agile planning are more accessible this way. The IT developer community considers Agile workflow management platforms as the benchmark for efficient and continuous business flow. Workflow management platforms and issue tracking portals are the places where most of the Agile planning takes place.

    Agile life cycle integration adaptors then link the LOB-defined Agile stories with specific developer tasks in easy-to-manage packets. The developer changes to the application code are tracked within the workforce management tool to draw useful and quantifiable insights from the data. The speed of application delivery is accelerated further because of the connections established between the projects, teams and tools.

    Minimizing Service Delivery Mishaps

    Using workflow management tools, the team can provide continuous build and integration functionalities. They can deploy automated integration builds on dedicated cloud or on-premises environments which minimizes errors in service delivery. A software bill of materials (SBOM) is generated for each build in the final audit trail which lets developers resolve errors retroactively as well.

    A broad picture is created of which new tasks and pieces of code went into the build and what software assets were created. DevOps implementation ensures continuous delivery of the banking application across test and production environments. Errors are reduced throughout the production life cycles of each banking service or product. This reduces the time taken from development to production. A fully automated and auditable delivery pipeline is created to make future deployments even faster.

    Reduce Banking Product Release Cycles

    DevOps provides a very robust and reiterable foundational environment for the bank’s business to thrive while reducing release cycle time with every iteration. This means every time a new banking service is delivered, the development life cycle is improved bit by bit. In some cases, the release cycle can be reduced by more than half the original time taken.

    While service delivery is improved, this also frees up release engineers for urgent tasks crucial to the deployment window. More deployments occur while still keeping the bank or financial institution in accordance with regulatory guidelines.

  • Survey Sheds Light On Cloud, API Expertise Skills Gap

    Survey Sheds Light On Cloud, API Expertise Skills Gap

    Enterprise IT faces a three-pronged onslaught: Digital transformation, open APIs and security threats. First, most organizations are still navigating ongoing digital transformations and cloud migrations. Second, development teams continue to increase their use of open APIs, leading to sprawl concerns. And third, we’ve witnessed a slew of cybersecurity threats that appear to be growing in sophistication. Tech leaders are attempting to govern this influx of new tools and risks, yet it can be challenging to innovate quickly while ensuring that sensitive data is always protected.

    The Axway 2022 Open Everything Survey shed light on some of the above challenges and attitudes of those invested in API development and API-enabled managed file transfer (MFT). Most notably, the survey found that 86% of respondents feared an expertise gap in the coming years, in which their organization won’t have the skilled software and IT infrastructure talent they needed to innovate. Below, we’ll review other findings from the survey, focusing on the responses from those who indicated they’re invested in API development.

    Cloud Migrations Are Still Underway

    Digital transformations are still underway in the vast majority of organizations. Only 12% reported being wholly digital and leading innovation. The rest were either just beginning transformations, were midway through or were still largely brick-and-mortar. More than one-third (38%) also said their company’s digital makeup is a hybrid of old and new technology.

    The most-adopted computing environment is the public AWS cloud, at 47%. Yet other options trailed close behind, including hybrid (37%), managed cloud services (32%), Azure (28%), private (25%) and Google Cloud Platform (18%). Other reports substantiated how modern IT is becoming increasingly hybrid and multi-cloud. As digital journeys continue to shift and evolve, some organizations are embracing multiple fit-for-purpose clouds.

    Although multi-cloud offers unparalleled flexibility, the primary drawback is security. Just over half (55%) of respondents said that tracking and controlling the flow of personal data into and through the cloud is a key hurdle to a multi-cloud strategy. And 53% reported that dealing with different security requirements for regional instances of cloud infrastructure was a top challenge. This concern is warranted, as companies doing business internationally must carefully navigate many specific regional data regulations.

    Open Data Strategies Abound

    As the Open Everything name indicates, many different sectors are becoming more “open.” The report highlighted the adoption habits of APIs within supply chains, where they are most often used to configure applications, operate and monitor applications and integrate internal data sources. Popular use cases here included payment and tracking systems. APIs also have a significant role to play in the financial world—41% of those working in finance said open banking is an opportunity to discover new business models. But nowhere is the need for more open data more crucial than in health care, which was found to be the area most in need of digital transformation.

    We’d like to think of the API revolution as being driven by API-first startups and SaaS services. While these trends get attention, it’s not the most common use case for APIs. In fact, 44% of the time APIs are used to support IT consulting and system integration requirements. This is followed by providing cloud applications for customers (35%), developing a partner network (35%) and offering cloud services for customers or partners (34%). Although there are certainly business use cases for generating revenue through APIs, they are most often adopted to supplement existing platforms or to glue together internal services and data.

    Most Technology Leaders Fear API Sprawl

    Security is an encompassing concern for all walks of IT, but is especially top-of-mind when opening up data. Respondents said security is the most important concern when creating APIs (30%). This concern is warranted, as attacks on APIs have increased exponentially in recent years. Other top concerns are API adoption or consumption (15%), customer experience (14%), ease of API management (14%) and design and development (11%).

    As APIs and microservices become more abundant within an organization, it’s easier for sprawl to set in. Unbridled technology sprawl can have a deteriorating effect on design standards and lead to unknown shadow APIs that may pose a security vulnerability. As a result, over two-thirds of respondents said the prospect of API sprawl worries them.

    To mitigate sprawl and address other concerns, most companies are investing in tools to help manage the growing number of APIs. The majority (83%) said their budget for API management has either increased or stayed the same over the last two years. For 18%, this budget has risen by over 25%. Operationalizing API life cycle management capabilities can have benefits such as standardizing design style and increasing the discoverability of internal services.

    API Security Must Still Mature

    In a perfect world, we could share data without fear of misuse. But in reality, APIs are a common target for hackers. Publicly exposed endpoints with broken access control or missing object-level authorization can be easily abused for things like privilege escalation and data exfiltration. And although these risks persist, many APIs don’t adopt industry best practices regarding API security.

    Although most APIs use authentication and token schemes, under half (43%) implemented OAuth. Furthermore, only 30% implemented policies with an API gateway. OAuth 2.0 and gateways have become best practices in serving APIs, as there are too many vulnerabilities to rely solely on HTTP Basic Authentication and API keys. As such, we will likely see these adoption rates increase as API security matures.

    As with other cybersecurity endeavors, it’s really about taking a holistic perspective and applying defense-in-depth. Thankfully, most technology professionals understand this point—developing a more holistic approach to security was ranked as the top strategy for protecting personal data. Other strategies, like data encryption, advanced multifactor authentication, data loss prevention tools and highly-secured data transactions will also be necessary to protect cloud-native assets.

    Final Thoughts

    The Axway 2022 Open Everything Survey asked 1,000 IT leaders, architects and developers about their top concerns. Above, we focused on results from technology leaders engrossed in cloud and API development. For more insights and the findings from those using managed file transfer (MFT), readers can pick up a copy behind an email gate here.

  • Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

    Southwest Airlines: ‘Shameful’ Technical Debt Bites Back

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

    20 Years of Neglect Led to ‘Meltdown’

    Last month’s débâcle of canceled flights was caused by decades of technical debt. That’s the analysis of Columbia University professor Zeynep Tufekci. (more…)