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: The first silicon for Wi-Fi 7, Google’s search quality “is” failing, and what Severance tells us about The Great Resignation. (more…)
If you’re just getting into site reliability engineering (SRE) or platform engineering, you’ve probably come across a bunch of new terminologies, like SLI, SLA and SLO. These benchmarks are commonly referenced in the day-to-day life of an SRE but may seem foreign to outsiders. So, what are the differences between these abbreviations?
Well, one of the hallmarks of the SRE approach is to gauge performance and set targets for application metrics. These targets can be thought of as reliability thresholds. If a site’s latency reaches a certain point, for example, it may break the agreement the software provider has with its consumer.
SREs create and monitor service-level performance benchmarks for all sorts of metrics, such as uptime, latency, error count, mean-time-to-recovery and throughput, among others. But not all these performance goals are part of public agreements. Companies usually take a more proactive approach to setting more internal targets to stay far away from breaking external agreements and user trust. It’s become a best practice to set these baselines to retain functional, reliable systems.
As mentioned, the type of targets range from firm partner commitments to more internal goals. Below, we’ll attempt to define, in simple terms, the differences between service-level agreement (SLA), service-level objective (SLO) and service-level indicator (SLI). While these concepts share many similarities, it’s important to understand how they are applied in practice. Keep in mind that each company may have a nuanced understanding of these terms and may conceive and apply them differently.
First off, service-level indicators (SLIs) refer to the actual metrics produced by software services. This is a direct measurement of a service’s behavior. These are the real numbers that indicate overall performances, such as error rate and latency over time.
One example of SLI would be the number of successful requests out of total requests over a one-month period. Say an engineer used an application monitoring tool that ingests data from production logs. This data showed that out of one million requests made, ten requests failed. An SLI for availability would thus be 99.999% uptime.
Second, most technologists are familiar with service-level agreements (SLAs). Even if you’re not, you’ve likely agreed to many throughout your history as a digital user. SLAs are like a pact between the software provider and the software user or client. These binding commitments often note availability expectations that must be upheld. SLAs may also include responsiveness to incidents and bugs. It depends on the contract, but if an SLA is broken, some kind of penalty may be incurred such as a refund or a service subscription credit.
These days, the average business relies on many cloud-based SaaS, PaaS and IaaS. Just to initiate something as simple as an online payment might require hitting multiple remote servers. But if all these services just went offline whenever they felt like it, our digital operations would come to a grinding halt. SLAs are thus necessary for enterprise software contractual agreements to ensure both parties meet specific standards.
Once an engineer tracks SLIs and has an idea of typical behavior, they can then set an SLA that makes sense. If we take the example above, an SRE may consider guaranteeing a lower threshold than what is being actively monitored. This would ensure that application performance, at its current pace, doesn’t break any legal or contractual obligations. In this scenario, perhaps the SLA mentions an availability objective: No more than 100 requests fail per one million requests made. This would essentially equate to 99.99% uptime.
Lastly, service-level objectives (SLOs) are similar to SLAs but explicitly refer to the performance or reliability targets. An SLA may refer to specific SLOs. Or SLOs may be tracked just for internal purposes. As Google described, “the availability SLO in the SLA is normally a looser objective than the internal availability SLO.”
You don’t want the end users to be the first people clamoring about a 400%+ latency rise in your mobile web apps. Thus, SRE teams typically keep a close eye on performance to ensure they never even get close to breaking SLAs. Some do this by setting and monitoring internal baselines that are more ambitious than the SLA threshold.
If we take our example above, if an SLA guarantees a service uptime of 99.99%, the business may set an internal target of 99.995%. In other words, for every one million requests, no more than 50 should fail. If software systems aren’t hitting these marks, it’s a sign that the company must reevaluate designs and search for bottlenecks. Or, perhaps engineering teams have goals to improve the average downtime for the next quarter—an internal objective could be set at a higher standard than the currently perceived performance.
As the Google Cloud blog described, “every service should have an availability SLO—without it, your team and your stakeholders cannot make principled judgments.” It’s a good reminder to be modest in your reliability commitments, they added, as consumers will come to expect this level of performance. On the other hand, setting more ambitious internal performance targets has the benefit of delivering a better result than the agreement on paper, increasing a software service’s competitiveness.
Keep in mind that the above numbers are simply for demonstration purposes. One interesting resource for real-world figures is API.Expert, a service that queries popular APIs and posts weekly performance statistics. Since APIs are the heart of many UI-based platforms (and our digital economy at large), these benchmarks stand as a good indicator of average uptimes and latencies in the industry.
For example, at the time of writing, API.Expert’s Enterprise APIs collection ranked Microsoft Office365 and Pivotal Tracker at the top, both with a 100.00% pass rate and a 220 ms and 248 ms latency, respectively. On the other end of the spectrum, Docusign is at 99.93% with an 877 ms latency and Box is at 99.99% with 414 ms latency.
Although it may sound good to an unpracticed ear, an SLA of 99.99% still equates to 52 minutes and 36 seconds of downtime per year. That’s nearly an hour of downtime in which customers are left scratching their heads or, worse, searching for other options. For traumatic health care situations, a loss of connectivity could be a matter of life and death.
Although creating SLAs and SLOs is important to gauge system health, the reality is that it can be challenging to track and enforce them. “These agreements—generally written by people who aren’t in the tech trenches themselves—often make promises that are difficult for teams to measure,” according to the Atlassian knowledge center.
In summary, SLIs demonstrate the real behavior of software systems. These metrics inform the creation of SLAs, which must be met to ensure B2B agreements. These SLAs often reference particular service-level objectives (SLOs) that must be met, which usually give more breathing room around SLIs. Lastly, in a digital economy with accelerating digital expectations, it makes sense to monitor internal SLOs and improve baselines over time.
As an IT professional with decades of experience at every level of technology and organizations—from cell phone prototyping to banking enterprise architecture, from entry-level to CTO—I can state definitively that I have spent an inordinate amount of time dwelling on and dealing with security. And I know I’m not alone. This is a common theme. You could almost make a sitcom out of it. “What are your developers doing?” Uhhh … writing code? “That’s security!” I could go on, hitting on everything from users to cloud instances and you could fill in the “That’s security!” punchline every time.
That’s a problem. But not in the way you might think. I spent many years thinking I was somewhat unique in that I always rose to the occasion and approached security issues head-on. Most of the organizations I’ve worked for didn’t have dedicated security (I’ve probably written about that before), so some of us rose to the occasion. Nowhere near all of IT, but enough to feel like we were protected.
I now realize that I’m not all that unique; that more of us are doing the “learn security to be secure” thing than are not. I see it in modern organizations all the time. And I think that the real problem is this: Most of these people, like me, did not see themselves as security staff—but they are. Most organizations don’t recognize them as security staff—but they are.
We’ve long harped on cultivating security recruits from this pool, and I’m now going to suggest that you go even further. Make these people part of your planning. If you know that person X on the ReallyCoolApp team is ferreting out security stuff, ask them to just send an email to update InfoSec once a week. Don’t make it a huge burden, and don’t try to force them into a pure security role if they don’t show the aptitude and interest (you really don’t want unwilling security staff) but make use of their talents and drive. Certainly, if this person is doing a good job of making certain ReallyCoolApp is mostly locked down and DevSecOps tools are running against it for a secondary validation, then your limited InfoSec resources can be directed elsewhere.
Replicate this throughout the organization, and “That’s Security!” becomes a benefit rather than a hassle to try to lock down. You already do some of this—since the automation of passwords, most identity management is handled by operations staff, with security merely providing policy and being available to ops if needed. I’m simply suggesting that you expand this type of approach to include every IT department (and some non-IT departments in distributed environments). Don’t recruit everyone to be InfoSec, but recruit them to do a little bit of InfoSec in their area of specialty.
People have always said “Security is everyone’s problem,” which is true, but it’s far too vague to be useful. This is a workable intermediate. “Security is every team’s problem” and recruiting the people on each team most interested in InfoSec to formalize their involvement is a better approach.
And keep rocking it. We need security everywhere, because ne’er-do-wells have made everywhere a part of the InfoSec battleground. So recruit people everywhere without moving them from their current roles/responsibilities. Don’t let the sweet systems you’ve nursed through the years get whacked by attackers when a little recruiting and nurturing will fill the gap.
Quali has added a control plane to its Torque platform to give DevOps teams the ability to consistently provision and orchestrate infrastructure across a heterogeneous distributed computing environment.
Amir Rosenberg, vice president of product for Quali, said the control plane allows DevOps team to centrally manage the provisioning of infrastructure via reusable blueprints accessed via a self-service portal, which individual developers can access. That approach eliminates a bottleneck that occurs when DevOps teams manually provision infrastructure on behalf of development teams, he said.
The latest release of Torque also adds enhanced visibility and cost control capabilities such as the ability to set limits for maximum duration and number of concurrent environments and limits for the total cost of an environment. Also included are cost reporting tools for Kubernetes clusters and improved forecasting and resource consumption policies that can be applied to blueprints, sandboxes and spaces.
Security enhancements include new customizable role-based access to blueprints, API Token Controls and integrations with secrets management platforms.
Through its software-as-a-service (SaaS) platform, Quali makes it possible to access Torque via either a cloud account or a user interface that connects to a GitHub account where blueprints are stored. The goal is to enable DevOps teams to maintain some control over how infrastructure is provisioned without impeding developer productivity, said Rosenberg, noting at a time when more organizations than ever are launching multiple application development projects, there is more sensitivity concerning developer velocity than ever.
It’s a fact that infrastructure misconfigurations happen because developers make mistakes. It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that makes it possible to centrally apply policies that act as guardrails to prevent developers from making provisioning mistakes. An alternative to scripts created using tools such as Terraform, the blueprints can deploy complete application environments automatically. That approach also provides more visibility into how resources are being consumed.
Every minute a developer spends managing infrastructure theoretically is one less minute they could be spending writing code. As application environments become more complex, Rosenberg noted it’s becoming that much more challenging for developers to cope with managing infrastructure as code. The issue is that DevOps teams who could provision infrastructure for developers are being overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, which, Rosenberg noted, leads to more mistakes being made.
It’s not clear when or even whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t rely on developers as much, but most seem to agree that developers have far better things to do with their time.
Microsoft has teamed up with vFunction to make it easier to convert monolithic Java applications into a set of microservices that can be deployed on the Microsoft Azure cloud.
The Microsoft Services Industry Solutions group is making available the Java Refactoring Service, through which IT teams will be able to both lift and shift Java applications to the cloud and then convert them into a set of microservices using agent software and the vFunction Application Transformation Engine, which is infused with artificial intelligence (AI), to analyze Java code.
vFunction CEO Moti Rafalin said the goal is to eliminate the heavy lifting currently required to shift Java applications into the cloud. The vFunction Application Transformation Engine is required because most of the Java applications that were easy to move to the cloud have been, Rafalin noted. The remaining Java applications, he said, have levels of dependencies that make them too complex to move to the cloud without the aid of a static byte code analysis platform capable of parsing more than 10 million lines of code and thousands of Java class libraries.
Once those applications are converted into a set of microservices, it then becomes possible to achieve a level of scale that would otherwise be beyond the reach of any on-premises IT environment, he added, noting the same vFunction platform can be used also to help organizations continuously optimize microservices applications as they continue to evolve in a cloud computing environment.
Longer-term, vFunction is also looking to add support for Microsoft.Net applications that need to be migrated to the cloud, said Rafalin. Many complex Java and Microsoft.Net applications are still running in an on-premises IT environment because organizations are encountering inertia that arises from paralysis of analysis, he noted.
In general, Microsoft continues to gain momentum in its battle for cloud supremacy against Amazon Web Services (AWS). It’s not clear at what rate Java applications are being shifted to the cloud. However, most monolithic applications have components that would be easier to maintain and support as a distinct microservice. In general, organizations are embracing microservices to build applications that are more resilient. In the event a microservice becomes unavailable, requests for services are rerouted to another microservice to make sure the application degrades gracefully, rather than simply crashing altogether. The challenge, of course, is that over time the dependencies that can exist between hundreds of microservices can be more challenging to manage than those of the monolithic application being replaced.
It’s not likely that microservices-based applications with entire replace monolithic applications anytime soon, but the bulk of new applications are being built on top of a microservices-based framework. As such, many DevOps teams are now managing a broad mix of monolithic and microservices-based applications across an increasingly complex IT environment. Less clear is to what degree teams will be able to leverage existing DevOps tools and platforms to build and deploy both types of applications at the scale enterprise IT organizations require.
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: More than 100,000 tech workers leave Russia, Perforce buys Puppet, and Intel moves faster than planned. (more…)
I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.
Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’
Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.
Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.
But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”
It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.
Still don’t have DevSecOps installed? Go now. Choose a vendor.
Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.
And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.
In the past few years, organizations have seen a constant increase in cyberattacks targeting business-critical applications and the data within because that data is particularly lucrative to sell or trade. Organizations running SAP software, especially, are struggling, as SAP systems are complex and hard to patch—even worse, information security and cybersecurity teams often don’t understand SAP systems and how to secure them. Traditional security approaches aren’t enough to secure SAP systems, but DevSecOps for SAP could introduce a new approach with better results.
While traditional security often becomes a roadblock to accelerated software delivery. DevSecOps introduces a new security-first mindset that emphasizes security at every step of the software development life cycle and makes everyone in the organization responsible for security.
DevSecOps includes all departments of an organization and embeds security thinking into the entire process, from the executive board down to individual teams. To make this successful, business operators need tools and processes that support:
In the past, security was often neglected while implementing new projects or new feature releases under the assumption that security defects would be resolved later in an existing system by the information security team. This approach, however, introduced additional complexity, costs and business disruption.
If security considerations are introduced in an earlier phase of a project, security defects can be identified and remediated much more cheaply and quickly. This alone makes it far more efficient and easier to resolve a potentially exploitable vulnerability. With good tools in place, this becomes very efficient and allows organizations to identify and resolve vulnerabilities that have been introduced in earlier iterations of their change processes.
The biggest benefit, however, is that any new process or feature has been implemented with security by design, leading to a resilient environment that can more easily fend off cyberattacks.
Here’s an example: Say a new business project is started with the intent to change SAP applications or processes to introduce new functionality. Like with any project, time, budget and available resources are key elements. For DevSecOps to work, important security considerations must be made in early phases of the project. In reality, every single project is a security project. This means that business requirements and targets must not be prioritized over security concerns. Processes and tools are needed to enable development and security teams to work together to answer important questions: Will the project introduce a security impact to contained data and established processes? Similarly, is there a need for additional software and security architecture, or is a specific skill set required that needs to be onboarded to the project?
In an agile environment, once all epics and user stories have been written, the design phase can start. With a security mindset embedded into the project, this will automatically lead to a solution that is secure by design.
During the implementation phase, developers need tools to scan for potentially vulnerable source code.
Identifying vulnerabilities that allow SQL injection, cross-site scripting or missing authorization checks early on in the development process makes it easier to fix them.
The challenge here is that SAP does not provide the tools developers need to validate source code for security flaws. The SAP transport management system is vulnerable to software supply chain attacks unless appropriate security patches have been installed. For this reason, organizations need a code vulnerability analyzer that can be integrated within the SAP standard development IDE.
In addition, quality gates enabled in the SAP transport management system can be very helpful for developers to avoid source code that lacks proper security validation.
Functional issues discovered in the user acceptance test (UAT) phase must also trigger a restart of the validation cycle. Only when all security and functional requirements are met can production deployment be initiated. In this phase of the life cycle, DevSecOps for SAP focuses on monitoring to enable attack detection, regular (or better continuous) vulnerability assessments and accurate security patching.
While many organizations already make use of change management and IT service management solutions, they do not yet have all the tools needed to embark on a DevSecOps journey with SAP.
Keep in mind there are platforms available on the market with an open API that allows integration within already established SAP solutions and provides the missing link between change management and security incident management. These solutions provide a one-stop-shop to securing SAP and reduce TCO compared to individual siloed tools for code scanning and vulnerability management.
For those who doubted the digital transformation trend, it’s become clear that it’s not a marketing fad or a buzzword but is now standard operating protocol for businesses. A forecast released this week from market research firm Gartner confirms this, as the projected increase in application software, infrastructure software and managed services spending highlights that digital transformation is a CIO marathon and not a sprint.
According to Gartner, every major consumer-focused online offering and mobile application is underpinned by infrastructure-as-a-service and comprises a substantial portion of the near 10% growth in software spending that will occur this year.
Gartner said it expects digital business initiatives, such as experiential customer experience and optimization of supply chains, to push spending on enterprise applications and infrastructure software into double-digit growth next year.
Gartner’s prediction is that worldwide IT spending is projected to total $4.4 trillion in 2022, an increase of 4% from 2021.
But the technology battleground isn’t just about hardware and software, it’s also about talent. The tight IT talent pool is driving up salaries and forcing technology service providers to increase their prices. This is pushing up spending growth in analytics, cloud computing, seamless customer experiences and security
Gartner expects software spending to grow 9.8% to $674.9 billion in 2022; IT services are forecast to grow 6.8% to reach $1.3 trillion.
Cloud’s gain is traditional IT’s loss, according to a Gartner market forecast released earlier this year. Enterprise spending on public cloud computing in addressable segments will be greater than spending on traditional IT by 2025. Gartner’s ‘cloud shift’ research includes only those enterprise IT categories that can transition to cloud, within the application software, infrastructure software, business process services and system infrastructure markets. “By 2025, 51% of IT spending in these four categories will have shifted from traditional solutions to the public cloud, compared to 41% in 2022. Almost two-thirds (65.9%) of spending on application software will be directed toward cloud technologies in 2025, up from 57.7% in 2022,” Gartner predicted.
In 2022, traditional offerings will constitute 58.7% of the addressable revenue, but growth in traditional markets will be much lower than in the cloud. Demand for integration capabilities, agile work processes and composable architecture will drive a continued shift to the cloud, as long-term digital transformation and modernization initiatives are brought forward to 2022. Technology product managers should use the cloud shift as a measure of market opportunity.
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…)