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: No remedy for banned Facebook users, new ARM-based VMs on Microsoft Azure, and The Great Resignation will still be a Thing for the foreseeable. (more…)
Like organizing your garage, modernizing your applications can seem daunting before you start, but you know it will pay off once done. So, instead of thinking about this project as a technical challenge, let’s look at it in the wider context of the business. Just as getting rid of old junk in your garage frees up the space you need for things you actually use, modernizing your apps helps your business run more efficiently and scale more easily. Based on my experience with many application modernization projects, here’s how developers can best approach app modernization, including what you’ll need from your team and technology, six key ways to tackle the task and how to prioritize.
Before you can make any changes to your applications themselves, you need to lay out a plan based on your company’s needs. That means assessing every application in your portfolio, not just as individual properties but in the way they interconnect.
Like most developers and engineers, when you have a technical background, it’s tempting to build a strategy around the most exciting technical opportunities. But the purpose of all the applications your company uses is to enhance the business. For example, your organization is likely considering an app modernization initiative to better serve customers and clients; to increase revenue or cut costs.
That means when you approach modernization from a business perspective, you should prioritize apps based on business value. Large modernization projects can get complicated, so you won’t necessarily be able to complete this process for every app.
When it comes to large-scale, complex applications, the effort required to modernize every piece is significant. So, it’s important to decide what applications are of the highest value and plan your modernization efforts starting there.
There are several business-focused questions to consider, such as:
Smaller organizations may be able to modernize every app and component. But if you’re in a large business or an enterprise, you will have to choose the apps and components that are most critical to the business goals. Of course, if you’re successful with the first crop of applications, it’s more likely you’ll get the go-ahead to move on to other apps and components.
It’s important to stress how important this kind of assessment and planning process is. You need to get that business buy-in for that ultimate alignment and for delivering the most value for your business in the shortest amount of time.
Different applications require different modernization approaches, some of which are more labor-intensive than others. Here are six methods (the six Rs) used to modernize an app and how to assess which one is right in each case:
All right. You’ve got leadership buy-in and you’ve categorized all your business’ apps according to the six Rs we mentioned above. Now, the real work begins. There are app modernization best practices to follow as you continue on this journey. Most importantly, remember that the effectiveness of your modernization efforts comes down to two key components: Your team and your tech. Here’s what you need from both for a successful mission.
The underlying purpose of application modernization is to bring your apps up-to-date with the latest cloud technology. For the best results, you need to use the best available tech. There are a few elements of modern cloud technology you should consider. Serverless infrastructure is one. With serverless, you can make large-scale changes in real-time without having to maintain servers.
Data management is another area where you should employ cutting-edge tech. You can use purpose-built databases that best suit different types of data for faster and more efficient processes.
Autoscaling is also a key benefit of moving to the cloud. Be sure to factor in the need to scale from the start of your modernization project to avoid bottlenecks further down the line.
The most advanced tools in the world are useless if the people using them aren’t sufficiently trained or skilled. When hiring a team, look for agility. Application modernization processes are a lot of work. You need a team that moves quickly in order to hit your deadlines.
Culture and responsibility, as well as ownership are also important. A demanding work environment requires open communication and people who will take responsibility for their part in the system. Consistency is another crucial factor. Involve the people who will be responsible for managing the apps from the start of the modernization process. This makes it easier for them to continue the work once the app is ready.
Getting the most out of your application modernization project requires the right tools, personnel and services. And while taking your first steps into the cloud can seem intimidating, by following tried-and-true best practices, you can stay on the right path toward a big payoff in the cloud.
Competing in the gaming industry is becoming increasingly costly. To attract new players, millions of dollars are spent in user acquisition (UA), development and cloud infrastructure. As the space becomes more expensive, revenue and cost optimizations can become a matter of survival.
The cost to businesses because of server outages, game response lag or generally poor performance can equate to billions of market cap of gaming companies. The value of observability in modern games is about ensuring that revenue opportunity is not missed in a costly operating landscape. Observability assures that all investment spent on user acquisition is protected and that gaming user experience (UX) is maximized. And user experience depends not only on how the game’s UI is performing but also on the entire gaming environment performance and reliability.
A modern gaming environment is usually highly distributed—a lot of pieces have to come together. The engineering team develops code for the gaming application, which can consist of many microservices, containers, managed cloud services, third-party APIs and serverless functions. Game designers create game levels, the art team produces visual effects and animations and the audio department creates game audio. Once these moving parts are packaged together, the game service has to be deployed on cloud infrastructure and the game itself shipped as executables for consoles, mobile devices and laptops.
All these elements generate massive amounts of observability data, particularly if a game is popular and played by millions of users. Thus, making sure that all gaming elements are working as expected means that gaming companies have to implement efficient ways of collecting and analyzing the massive amounts of that data. That data comes from gaming services, consoles and other sources in real-time. For instance, it is not uncommon to deal with hundreds of terabytes of ingested log data per day. As a result, improving the gaming experience can be quite challenging for gaming companies with large-scale operations. The companies’ success depends on how efficiently they can harness all the data generated by gaming environments.
This is where observability comes in. Observability provides critical insights into what is—or what may be—wrong with the game, all its moving parts and user experience. Powerful observability capabilities are essential, including processing vast amounts of data (logs, metrics, traces, etc.) in real-time, managing fluctuating observability data from variable user loads and running concurrent real-time queries on a massive scale.
So, what, exactly, needs to be measured for a great gaming user experience?
Gaming companies are under continuous financial pressure to deliver new features that attract and retain new users in order to offset mounting operating expenses. Attracting new users is a balancing act from the gaming companies’ perspective. If they move too slowly, they will lose gamers. If they move too quickly, the gaming user experience can deteriorate due to newly introduced bugs. Gamers can be very vocal on social networks, especially if their intent is to express their dissatisfaction with compromised gaming quality. As a result, companies are forced to balance the rate of feature introduction with user satisfaction. That’s why they need to measure user experience continuously.
To improve gaming user experience, gaming organizations must establish measurable key performance indicators (KPIs), which can drive improvements and overall quality. KPIs include, but are not limited to:
Gaming applications are often bursty when it comes to user load, especially during the introduction of new games or new features. One of the critical indicators to monitor is service latency to manage fluctuating user demand during those times.
DevOps teams and SREs need to collect logs at a massive scale to analyze the performance of services, infrastructure and individual host utilization metrics such as high CPU utilization. This information gives engineers clues about the sources of bottlenecks and potential deterioration related to service latency. And logging tools need to be able to deal with this fluctuating demand, too. This level of insight into the state of the gaming application helps engineers troubleshoot issues before gamers face increased service latency that can impact their gaming experience.
Game developers can create custom logs and metrics and combine those with observability data from the gaming engines. Both must be analyzed to assure a high-quality user experience. Some of the common gaming data parameters available for analysis are:
The more data collected, the better the chances to understand any issues that can turn players away from the game. Observability data management should evolve in parallel with game development. As new features are added, the code should be instrumented with KPIs to ensure the quality of the newly introduced code in the long run.
To store time-sensitive gaming data, DevOps teams must use fast databases. The database performance and how fast the game’s properties are retrieved from a database directly impact user satisfaction. Slow database performance negatively affects the gaming user experience. For DevOps teams to avoid any service issues, it is a must to measure key database performance indicators such as response times metrics, out-of-memory error logs and others.
Fast databases could be expensive in the extremely competitive market where gaming companies are always looking for cost optimization to survive in the business. It’s non-trivial for DevOps teams to monitor user experience related to database performance and, at the same time, to look for ways to optimize the cost of fast databases.
For a large-scale video game, new code is often pushed many times per day. Builds can be significant and deployed across many gaming consoles and end devices. Continuous build pipeline and delivery monitoring are crucial for frequent and commonly large software deployments.
With large builds deployed daily over the network to thousands of gaming platforms—where each platform receives a massive amount of data—monitoring of build deployments should be automated. Errors from log data should trigger alerts and drive redeployments. QA automation is necessary to reduce the burden of QA efforts and make build deliveries less error-prone and less tedious.
Insights into user behavior are as important as monitoring possible issues affecting user experience. Observability tools can provide key insights into the overall engagement of all game users. High engagement then drives more excitement. Higher user excitement may increase the success of ad campaigns and accelerate in-game purchases.
When thinking about observability tools that can be instrumental in driving continuous improvement of user experience in the gaming industry, the following functionalities are important:
Observability is key to protecting gaming revenue opportunities and assuring the success of video games, as long as you know what to look for in observability tools that are used to gather data from gaming environments.
Harness this week announced it acquired ChaosNative as part of a plan to more deeply integrate chaos engineering with DevOps workflows.
At the same time, the company added a Harness Service Reliability Management (SRM) and Harness Security Testing Orchestration capability to its continuous integration/continuous delivery (CI/CD) platform.
Chaos engineering, as a discipline, refers to experiments on a software system that test its resiliency in the face of an unplanned outage. The goal is to deliberately make resources unavailable to see how the application environment either adjusts or whether it fails.
ChaosNative’s LitmusChaos platform, which manages these chaos engineering tasks, was donated to the Cloud Native Computing Foundation earlier this year.
Scott Sanchez, chief marketing officer for Harness. said the company plans to shift chaos engineering further left as part of an effort to enable developers to test the resiliency of their applications before they are deployed in a production environment.
It’s still early days where adoption of chaos engineering within DevOps workflows is concerned. Many IT leaders’ performance is measured based on the stability of application environments. The idea that they should deliberately break something as part of an effort to make an application more resilient requires a shift in mindset, noted Sanchez.
However, once IT leaders start to appreciate how chaos engineering actually improves the availability of applications it’s only a matter of time before the practice becomes more widely implemented, he added.
In the meantime, Harness is looking to automate more of the lower-level tasks that today’s DevOps teams often manually manage. Harness SRM enables DevOps teams to automatically track service level objectives (SLOs) that are attached to specific pipelines within the Harness CI/CD platform.
The Harness STO module, meanwhile, makes it simpler to orchestrate security testing across multiple pipelines.
In general, there is now more focus on the productivity of DevOps teams as the number of applications that are being built simultaneously increases. The challenge, however, is not just the number of applications but also the dependencies that exist between them.
Harness is making a case for a CI/CD platform that automates DevOps tasks by employing, for example, machine learning algorithms to identify which applications are most likely to fail before a build is completed. The goal is to reduce the amount of time DevOps teams waste waiting for builds to complete only to discover that the application almost immediately failed.
The time, effort and cost of maintaining a DevOps platform will naturally vary as the overall environment becomes more complex. However, as DevOps processes become more automated, the platforms themselves become more accessible to a wider range of organizations. Today, the effort required by a DevOps to set up and then support a CI/CD environment is often considerable.
Nevertheless, as more organizations rely on custom applications to drive digital business processes, it’s only a question of when and to what degree DevOps best practices will be more widely adopted. After all, the total cost of application downtime is only going to rise in the age of digital transformation.
A survey of 900 application testing professionals conducted by PractiTest, a provider of a platform for managing testing tools, suggested the number of organizations that have dedicated testing teams is declining at a steady rate.
The survey found a 15% decrease in organizations with dedicated testing teams that have six or more members. At the same time, however, the survey found only 18% of respondents reported that all testing is done by individuals that are not part of a dedicated testing team.
Joel Montvelisky, test specialist and chief solution architect at PractiTest, said that shift indicates that more organizations are steadily incorporating testing within DevOps workflows. In fact, more than 60% of respondents said DevOps and Agile processes led to teams being more organized and stable, with two-thirds (66%) reporting that development teams were releasing features more frequently with more functionality.
However, only 38% of respondents said they were active participants in a continuous integration/continuous delivery (CI/CD) workflow. A full 90% said they needed to coach or train other members within the team and just over half (54%) reported that estimations of the time required for development and testing were accurate.
Two-thirds also said collaboration with developers is also improved when applying DevOps processes, with more than half reporting fewer serious bugs made it into production. More than half also said they monitor software in production and deployment environments. The number of testers who defined themselves as engineers has gone up by 14% year-over-year. However, only 44% report that automation has replaced 50% or more of their manual testing efforts.
A full 95% or more of survey respondents identified application programming interface (API) testing, Agile methodologies, functional testing and scripting as high on their list of priorities. In contrast, big data testing, internet of things (IoT) testing and machine learning/artificial intelligence (AI) testing were cited as important or very important by only 60% of respondents.
Finally, about a third of survey respondents noted that non-testers are now involved in testing activities.
Montvelisky said the PractiTest survey makes it clear that while developers are a little more involved in testing than they were a few years ago, organizations still relied on testing specialists that are becoming more integrated into DevOps workflows. This is especially important as more organizations launch digital business transformation initiatives that require them to build software using the same types of DevOps processes that independent software vendors (ISVs) employ.
It’s still too early to say just how far testing might shift left toward developers, but as testing becomes more automated—thanks, in part, to increased reliance on AI—the types of tests that will be conducted by a dedicated testing team will evolve. In fact, it’s unlikely automation will eliminate the need for those teams any time soon. Rather, testers will be augmented by AI technologies that will help them to keep pace with the accelerated rate of application development enabled by wider adoption of DevOps best practices within organizations both large and small.
The rise of remote workforces, cryptocurrencies and super-sized data centers brings to the forefront a concern in tech development that doesn’t get enough attention: The impact of computing and advanced technologies on the environment.
About six months into the pandemic, people began to notice cleaner air, clearer water and an overall calming effect on the environment in the reduced presence of industry. Memes were created and widely circulated that suggested maybe we were the problem after all.
That lasted for about six weeks before cabin fever set in, and we became impatient and ready to get back to business as usual.
In the time between the last quarter of 2020 and the sudden waxing and waning of NFTs, a few timid voices again raised concerns about the impact of super-computing and other technologies on the environment. Those concerns eventually became muffled amidst socioeconomic and political turmoil, fears about inflation, staff shortages and logistical issues surrounding supply chain disruption.
App development tried to fill some of those gaps and new data centers appeared as we struggled to find our footing again in a post-pandemic world.
While environmental issues have been a matter of growing concern for decades, the past few years have put a particularly intense focus on the issue, with entire industries growing up around everything from climate-friendly investing to carbon offsets, and more. The environmental impact of technology has become an issue yet unresolved in spite of a growing focus on sustainability.
The typical DevOps journey focuses mainly on how app development will impact an organization. Rarely does it address how development impacts the environment.
In addition to factors like improving time-to-market, reducing human error, debugging and making financial resource management more efficient, part of your DevOps strategy should include ways to reduce your carbon footprint and impact on the planet.
First, it helps to understand exactly how technology affects the climate and depletes natural resources so you can incorporate sustainable development into your plan in a meaningful way.
Even relatively passive use of technology, like video streaming and remote collaboration, for example, has the potential to consume more power than entire countries. Add up all of the hours of Netflix, Zoom meetings and other remote activities and ponder the implications.
To become part of the solution, it’s important to do more than just invest in green businesses. Here are some steps you can take to clean up your DevOps process and become part of the solution rather than contributing to the problem.
Software engineering and DevOps are increasingly embracing new territory and emphasizing sustainable engineering. The first step in the right direction is to become aware of how power and resources are consumed during your development cycle.
Consider:
In the realm of sustainable engineering, the process can be broken down into three categories: Technical, operational and environmental. The goal is to balance these aspects to monitor and optimize the development process and do the least amount of damage possible.
Once you’ve identified areas of risk and set goals for sustainable software engineering, use the results to create and enforce a set of development best practices that better support environmentally responsible design and production. If you need some help or ideas, you can model your own initiatives after these emerging standardization principles.
In 2021, more than 200 countries signed the Glasgow Climate Pact, solidifying their commitment to reducing their carbon footprint and resultant environmental damage from tech development and use. The conference brought together stakeholders from businesses, government agencies and others to share information and create standards and best practices for sustainable computing and tech development.
Tech giants like Google, Amazon, and Microsoft are creating tools to help DevOps and IT monitor and measure the environmental impact of everything from cloud computing to app development. Seek out and incorporate these tools into your own set of best practices or work on creating your own solutions.
Tech development is intended to improve our quality of life and reshape how we conduct business. There’s no reason that intention shouldn’t extend to the world in which we live and engage in commerce.
The first step toward combating climate change without negatively impacting development is understanding how technology affects our environment. Then, we can make informed decisions that support responsible, sustainable DevOps.
Today’s software systems are, essentially, controlled chaos—and lightly controlled chaos, at that. This makes it exceptionally challenging to model the behavior of those systems. Our systems are quickly becoming larger and larger, with more and more moving parts. It is not uncommon for enterprises to have over 1,000 microservices and millions of containers running thousands of applications containing many thousands of open source libraries.
Why are things growing more complex? Because from microservices to CI/CD pipelines, from service meshes to blue/green deployments, all these new practices and new technologies help us make our applications and infrastructure more resilient and scalable. The downside is the ever-increasing complexity, which is actually accelerating.
In addition, software has officially taken over every layer of the networking and hardware stack (which sounds like an oxymoron, but it’s containers and virtualization turtles all the way down until you hit bare metal). Software is, by definition, easy to rewrite. Thus, the ease of changing software has further increased the number of changes we make to systems. Which adds still more complexity. In fact, software only ever increases in complexity; never decreases in complexity. Software is always trying to do more and encompass more. For that reason, even when you try to simplify software, you just move the complexity around rather than eliminating it.
Here is how Netflix, the organization that pioneered chaos engineering, defines the practice: “Chaos engineering is the discipline of experimenting on a distributed system to build confidence in the system’s ability to withstand turbulent conditions.” Turbulence is the opposite of order, but it’s where all systems end up.
In the beginning of a system’s life cycle, there is always an orderly plan for deployment and operations. You always have a clean diagram of your resources, code repositories, containers and always a nice 3D diagram of AWS instances you will deploy to and the network topology.
In reality, our systems are never this simple. After the system goes live, that is when we start learning about how it actually operates through unforeseen events like when marketing asks to refactor the pricing module or an outage to the payments API forces you to hardcode a token or a DNS outage—well, you know about DNS outages. In the span of a year or two, you go from 300 to 800 microservices and you have to add Kubernetes clusters and a container network interface (CNI) to properly secure the networking of those clusters. And so on and so on. The bottom line? Almost all production systems evolve into a state that we do not understand and cannot easily map back to our original systems diagram.
Chaos engineering is a mechanism for dealing with this growing level of complexity. The basic idea behind chaos engineering is asking the computer or application or network (or any other environmental element) a series of questions. Consider a legacy system like a mainframe. How did our legacy systems become so stable? They are well-documented. Engineers feel confident in how the system operates. The question is, was the system always that way? Is the system the same one that they originally designed? The answer is “No.”
Legacy systems actually went through a trial-by-fire; a constant parade of unforeseen surprises. These surprises were, effectively, questions. Through these surprises, engineers learned how the system would actually operate (or wouldn’t operate) in the face of chaotic and unforeseen events. This process created iterative feedback that helped the engineers learn how to make the system continuously more stable.
The point of chaos engineering is to generate this same type of feedback loop without the pain, stress and repercussions of unforeseen (and generally unwanted) events. Thus, chaos engineering is a proactive way of introducing adverse conditions to ensure that the system can still do what it’s supposed to do when unforeseen events transpire. Because everything today is software and change is constant, the questioning must also be constant.
For example, chances are that in the time since we originally designed any given system, it has changed a lot. This means some or all the mitigation and resilience we programmed in—retry logic, failovers, circuit breakers—are old news, designed for an older system. When triggers for those conditions actually occur, those mechanisms of resilience we designed may not perform as we had intended.
Chaos engineers proactively ask the question, “Under the conditions in which you are designed to perform, do you do what you are supposed to?” We introduce the conditions themselves in a controlled manner with a limited blast radius to put the system to the test and verify that our assumptions line up with the intended reality. The practice of chaos engineering is intended to be performed on live, running systems without the risk of taking down critical production assets or ambushing unsuspecting applications and their associated DevOps and development teams. This helps engineering teams reduce uncertainty by building confidence in their understanding of their systems by providing them with enhanced context. It turns out that, when engineers are presented with better context, it considerably improves their ability to make smarter, well-informed decisions where resilience is concerned.
Cybersecurity is a context-dependent discipline, dependent on how well you understand the systems you are protecting. Software engineers are constantly changing the system. And they must have the flexibility to change it because their primary task is to constantly move towards business value. Yet to effectively apply cybersecurity practices, we must know what we are trying to secure. From that knowledge, we then can know what we most need to secure and how to do it on a given system in its most current state.
Before an engineer can understand how to build robust security measures that provide effective cybersecurity, the engineer must first understand the system. This reliance on the “system first” is a foundational driver for why our security systems and controls—even the immutable and ephemeral ones—experience considerable engineering drift over time. We are continuously burdened by the dependence on a stateful understanding of the system.
Without having some sort of testing or instrumentation feedback loop in our post-deployment world, we don’t know there is a problem with our security until there is an actual problem. Finding out that the room is on fire after the house has been burning for hours is too late. The result is the self-defeating series of reactive incident fire drills, war rooms and outages that we find ourselves in today. If we do not change this reactive crisis loop of chasing the tiger’s tail, it inevitably leaves us taking two steps back for every step we take forward with engineering teams.
When this drift goes undetected, we are left with our wounds exposed and attackers salivating at the meal to come. Engineers always prefer to find evidence and sources of drift through some internal engineering failure or controlled test rather than experiencing a successful real-world attack. Over time, there is a constant drift between the system and security; engineers are constantly changing the system. As a result, there is frequently a lack of recalibration between systems and the security designed to protect them. The way to achieve this recalibration is through continuous testing or experimentation.
Testing is not chaos engineering. Testing is a verification and validation of something you know as either true or false. This could be vulnerability to a specific CVE or exposure to an attack pattern. In experimentation, you are trying to derive new information and explore the unknown unknowns. From this exploration, you seek to create a better understanding of how a system reacts and then share that with the people who are designing the system.
Live security incidents are not effective measures of detection because, by then, it is already too late in the life cycle to effectively address the problem. Worse, incidents cause stress, fear and irrational behaviors. People freak out. Not surprisingly, a security incident is not a good learning environment. Yet security incidents serve the same purpose: Asking questions about a system or systems and helping teams see how to improve them. Chaos engineering offers a better way to create these questions under conditions where it is easier to learn and observe system behaviors, providing clues to improving security. In other words, the purpose of security chaos engineering is to help us proactively understand our systems and where the security gaps are before an adversary has a chance to take advantage of them.
There are multiple use cases for security chaos engineering including:
A team I headed wrote an open source application, ChaoSlingr, designed to generate chaos engineering events for security experiments. The application consisted of three serverless functions to generate the experiment, apply it to infrastructure and then monitor the resulting impact on the system.
One example of how we used ChaoSlingr was an exercise where we induced an open port. Enterprises and engineers inadvertently open ports in firewalls all the time. Sometimes this is a result of misconfiguration. It may also be the result of a software upgrade after which the developer or AppSec engineer forgot to reset the port to the proper security settings. In theory, firewalls should automatically detect an unauthorized open port.
For the experiment, we selected a set of resources that had opted-in to our experiments, selected a security group and opened the port. At the time we were relatively new to Amazon Web Services. We were surprised to find that the firewall only detected an unauthorized port opening 60% of the time. We discovered clear evidence of configuration and security tool drift.
We also noticed that a cloud-native configuration and management tool we had deployed was identifying and alerting the unauthorized port opening almost 100% of the time. We then realized that correlating and responding to incident events of an unauthorized port opening was complicated; it was hard to map the incident back to the log data describing how our systems responded to the event. We added a metadata pointer to each alert, allowing us to more easily correlate the information and save valuable time finding the affected security group and port.
In short, the exercise gave us excellent context on where our systems were drifting and failing to keep up, which of our systems were the most reliable and whether we could quickly and easily respond to these incidents by chasing down the right log files.
In any environment where we are managing complex systems, trust is critical. You must trust that your systems will handle unforeseen events gracefully and not cost your company money or reputational currency. You must trust that the people designing and building your systems are constantly trying to improve them. You must trust that the security teams protecting your systems are up to the task. As systems grow more and more complex, the number of unknown unknowns multiplies. As humans, with our limited processing capacity, we cannot solve for unknown unknowns at scale, continuously. This is the task of security chaos engineering and the processes around it: To create a programmatic way to experiment against and find answers to unknown unknowns. Your systems, developers, customers and your CEO will thank you for it.
About Secure Software Summit
The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.
https://go.shiftleft.io/secure-software-summit-2022-replay
It appears that, in many IT environments, observability is becoming too much of a good thing. A global survey of more than 315 IT executives, cloud application architects, DevOps professionals and site reliability engineers (SRE) conducted by Dimensional Research on behalf of log data management platform provider Era Software, found 96% are witnessing an explosion of log data.
The survey also found 79% of respondents reported the overall cost of observability and log management will skyrocket in 2022 if current tools don’t evolve.
More than three-quarters of respondents (78%) also noted attempts to manage volumes of log data have had mixed or unwanted results such as an inability to access data. Nearly two-thirds (65%) are also evaluating their observability options while the other 41% are considering it.
Stela Udovicic, senior vice president of marketing for Era Software, said the survey makes it clear that as organizations rely more on logs to analyze IT events, the cost of storing all that log data is becoming a significant challenge. Overall, the survey finds usage of observability tools and platforms has jumped by 180% as IT teams struggle to manage increasingly complex IT environments.
On the plus side, more business users are benefiting from log data. A full 83% of respondents report that business stakeholders outside of IT use insights from log data, with 96% reporting log data is being used to solve business problems.
Observability has always been a core tenet of DevOps best practices, but achieving it has always been a challenge. Monitoring tools are designed to consume predefined metrics to identify when a specific platform or application is performing within expectations. The metrics tracked generally focus on, for example, resource utilization. However, whenever there is an issue, it can still take days, sometimes weeks, to discover the root cause of an issue through what amounts to a process of elimination.
In contrast, observability combines metrics, logs and traces—a specialized form of logging—to instrument applications in a way that makes it simpler to troubleshot issues without relying solely on a limited set of metrics that have been predefined to monitor a specific process or function. DevOps teams can employ queries to interrogate data in a way that makes it easier to discover the root cause of an issue. Observability platforms correlate events in a way that makes it easier for analytics tools to identify anomalous behavior indicative of an IT issue.
The issue that arises is that IT teams need to find a way to store all the data generated by the logs they need to analyze. Each IT team can, of course, could reduce the amount of log data they retain. However, there is always a concern that in the event of an incident critical log data won’t be available.
Udovicic said most IT organizations have historically viewed storing log data as a necessary evil. The primary issue most of them encounter is the simple fact that log data is not easy to work with, she noted.
Regardless of how organizations view log data, the amount of it that needs to be managed will only increase as DevOps workflows become more mature. The issue IT teams need to come to terms with now is finding a way to minimize the cost of storing it all.
A recent cloud observability survey found nearly two-thirds (64%) of respondents reported the adoption of public clouds has made it more difficult to achieve observability. Nearly half of respondents (48%) said they now consider providing real-time insights into application/infrastructure environments to be a top priority.
The survey polled 357 IT professionals and was conducted by Enterprise Strategy Group (ESG) on behalf of Yotascale, a provider of cost optimization tools for cloud computing environments.
Yotascale CEO Asim Razzaq said that attaining and maintaining observability becomes more challenging with each new cloud platform adopted. The survey found that 71% of organizations now rely on more than three cloud infrastructure providers.
A full 84% of survey respondents also noted that tracking costs and cloud cost allocation is burdensome and time-consuming, and 61% admitted they lacked sufficient visibility into which teams own what cloud resources. Nearly a quarter (24%) are considering making changes to their monitoring and observability practices as infrastructure costs rise.
Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate events with costs as part of an effort to rein in the costs of IT, said Razzaq.
In the immediate aftermath of the COVID-19 pandemic, the number of workloads being deployed on public clouds increased sharply. In theory, many organizations signed enterprise licenses that reduce cloud costs if they consistently consume a certain level of infrastructure resources. In practice, however, individual developer teams are showing a preference for one cloud platform over another based on the attributes of their workloads. As a result, however, it becomes more challenging to not only consistently observe diverse platforms but also to control costs.
It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of pre-defined but often conflicting metrics. Observability platforms unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.
The rate at which DevOps teams will embrace observability will naturally vary. In 2022, the biggest obstacle might not be the technology as much as it is simply understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs. Regardless of approach, however, the ability to manage complex IT environments in the months and years ahead will continue to steadily improve.
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: ByteDance restricts TikTok in Russia, Unified Patents escalates the fight against trolls, and Google Chrome beats the magic 300.
First up this week: Russian TikTok users won’t be able to view or upload new content. For users in Russia, TikTok has frozen its catalog of cringe.
Putin’s vague new “fake news” law is concentrating minds in Beijing’s ByteDance. Is your organization exposed too? To protect its employees—and perhaps its users, too—it’s hitting the Safe Mode button.
Dan Milmo: TikTok restricts service in Russia
Chinese-owned TikTok said it would block livestreaming and uploading of new content in Russia after the Kremlin criminalised the spreading of what it deems to be fake news about its invasion of Ukraine. … The BBC, CNN and other global media outlets have temporarily suspended reporting in Russia to protect their journalists.
…
TikTok spokesperson Hilary McQuaide said the app in Russia now appears in “view-only” mode and won’t let people post or see new videos or livestreams. They can still see older videos, but not if they came from outside the country.
…
She said, “The safety of employees is our top priority,” … adding that the video-sharing service—part of China-based tech company ByteDance—did not want to put either its Russian employees or users at risk of severe criminal penalties.
With more on that head-scratching law, here’s Aimee Chanthadavong:
Russian President Vladimir Putin signed a new law on Friday that bans what the country calls “fake” news about the military. This law will target any statements referring to the invasion of Ukraine as an “invasion”, any attempt to discredit the armed forces, or calls for sanctions on Russia. Those found to be spreading so-called fake news could face up to 15 years in prison.
…
TikTok’s in-app messaging service will not be affected. … “We will continue to evaluate the evolving circumstances in Russia to determine when we might fully resume our services with safety as our top priority,” TikTok added.
And Scott Nover thinks about the effects on Russian citizens:
Russia’s fake news law is a severe step for a country whose government is already antagonistic to … a free press. … The country has blocked Facebook, Twitter, and YouTube proactively, but TikTok beat Russia to the punch. The result is the same, however: The people of Russia … will be locked out from another window into the real-life consequences of Putin’s war.
“Patent assertion entities,” also known as “non-practicing entities,” are organizations that don’t produce anything, but simply acquire and hoard patents—later asserting them against unsuspecting organizations. The aim is to extort money from those they claim are infringing.
The problem? Many of those patent claims are as weak as a sickly kitten.
You might think you’re safe, but trolls also go after the users of the disputed technology. Examples include podcasting, JPEG images, order-confirmation emails, geo-locating a car and even caching data.
Steven Vaughan-Nichols: Open Source Zone grinds away at patent trolls
Patent trolls, aka Patent Assertion Entities (PAEs), have plagued … software for ages. … The attacks keep mounting up. The reason is simple: It’s profitable.
…
[But] Unified Patents, an international organization of over 200 businesses … brings the fight to the trolls. It deters patent trolls from attacking its members by making it too expensive for the troll to win. … With United Patents’ high success rate in knocking out bad patents, slowly but surely the patent trolls are being driven back.
…
For example, an Accelerated Memory Tech patent 6,513,062, was used by the troll IP Investments Group to claim … Redis, which manages cache resources on the cloud, violated the patent. [The troll] went after Hulu, Citrix Systems, Barracuda Networks, Kemp Technologies, and F5 Networks for their use of Redis software. IP Investments Group gave up rather than fighting it out. Everyone who uses Redis wins.
Ban software patents? Beware of throwing out the baby with that bathwater, thinks WierdUncle:
Patents themselves are a good idea: … Inventive people should be rewarded for their contributions to the economy.
…
[But] patent trolls are parasites who contribute nothing to the prosperity of citizens. … The patent troll business plan is unfortunately quite viable. You don’t invent anything, or fund new developments. You have sufficient funds to clobber anybody who challenges you, by having better lawyers.
The underlying issue is weak patents. Here’s nzkbuk:
Start suing the patent office for damages against wrongly issued patients. It would then be in their best interest to set up this sort of thing as an alternative where the patient can be investigated first.
Google Chrome on macOS boasts a better benchmark score than Safari on an M1 MacBook Pro. Hilariously, this is using Apple’s own Speedometer benchmark tool.
Great PR, and popcorn-worthy Cupertino trolling. But aren’t there better optimizations Google could be making?
Frederic Lardinois: Chrome on macOS is now faster than Safari
Version 99 of Chrome on macOS manages to score 300 points on the Speedometer benchmark, which was originally developed by Apple’s WebKit team. This, Google points out, is the fastest performance of any browser.
…
It’s been a while since competition in the browser market focused on speed. … When a new chip comes along, though, there’s always room for optimization. Originally, Chrome on Apple’s M1 chips had passable performance, but … Chrome now runs 43% faster on them.
…
Speedometer 2.0 tests for responsiveness, which makes it a good proxy for user experience. … It doesn’t take much to make software feel more responsive, so the 43% on M1 Macs will surely make you feel more productive.
How? Try not to gloat, Max Christoff:
Building on many performance changes over the last year, we enabled ThinLTO in M99, a build optimization technique that inlines speed-critical parts of the code base, even when they span multiple files or libraries. … Two of the other recent major contributors to Chrome’s speed are the V8 Sparkplug compiler and short builtin calls. Sparkplug is a new mid-tier JavaScript compiler. … Short builtin calls are used by the V8 JavaScript engine to optimize the placement of generated code inside the device’s memory [which] boosts performance by avoiding indirect jumps when calling functions.
…
We know that benchmarks are just one of many ways of measuring the speed of a browser. [But] combined with recent graphics optimizations (namely, pass-through decoder and out-of-process rasterization) … Chrome is now 43% faster than … 17 months ago.
Benchmarks/schmenchmarks, thinks codedokode:
Browser developers are optimizing the wrong thing. … Optimizing for speed usually causes increased memory consumption, and this increases the chance of invoking swapping. If the system starts swapping, it becomes orders of magnitude slower.
…
If the browser could use [half the] memory while using twice amount of CPU time, that would be perfect. Just think how many laptops with 2 or 4 GB of RAM would become usable again.
You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.
Image: Rostislav Artov (via Unsplash; leveled and cropped)