devopsy.kinsta.cloud

Category: DevOps Practice

  • The State of Digital Innovation, One Year Into the Pandemic

    The State of Digital Innovation, One Year Into the Pandemic

    It’s obvious COVID–19 accelerated digital reliance for many companies. And it’s no surprise that, according to a recent study, 89% of tech leaders believe digital experiences are critical to addressing new COVID–19 challenges. In this race toward 100% digital business, agile innovation is the new elixir of life — without it, a company may face an early retirement.

    Kong just released their 2021 Digital Innovation Benchmark, which summarizes the tech priorities of 400 IT leaders. The findings stress the importance of rapid digital innovation, open source, microservices architectures, and high quality practices for scaling today’s application ecosystems. Here are the key points technology leaders need to know to remain competitive.

    Innovate or Dissipate

    The urgency to innovate is increasing. According to the survey, 84% of respondents predict a business will go under within six years if they lag behind in digital innovation. Fifty one percent of tech leaders believe their business can only survive three years.

    If digital transformation happens too slowly, it can pose an existential threat. But there are many factors that can hinder faster digital innovation; the complexity of using multiple tech stacks, reliance on legacy IT and lack of automation. Not only are there internal woes, but external danger — 62% of respondents worry about failing to keep up with competitors who innovate faster.

    It seems the urgency has increased over the last year. In last year’s report, just 37% reported they’d be out of business in three years if they didn’t keep pace with digital innovation. That figure rose to a whopping 51% in 2021.

    COVID Amplifies Digital Drive

    Virtually no one is anticipating a decreased IT budget in light of COVID–19. On the contrary, long-term digital transformation efforts are well on target at the majority of institutions, and 75% expect to see an increase in IT/developer budgets over the next 12 months.

    Interestingly, when it comes to securing the digital-only economy, European tech may have a head start. Only 40% of European tech companies have increased their security focus, compared to 51% in the U.S. This could be due to previous investment in security and stricter regulation in European countries.

    In terms of cloud adoption, 40% of tech leaders feel COVID–19 has accelerated their move to the cloud. Nearly 40% say the pandemic has encouraged the use of microservices and cloud native architecture.

    Quality Outweighs Speed

    When gauging what matters most to tech leaders, “improving operational efficiency” is still a top priority. However, this year’s report saw a spike in respondents saying application performance and reliability, as well as application security, were moving up the priority list. Though 3 in 5 (62%) respondents said they are “extremely concerned” about competition from speedier rivals, application stability outweighs the collective drive to innovate.

    These trends are likely indicative of a notable rise in cybercrime. As I’ve covered previously, to respond to emerging threats, DevSecOps practices and new security tooling are shifting left within the development cycle, automating things like vulnerability detection. Simultaneously, roles to increase application integrity, like site reliability engineers, are in high demand.

    New Technologies and Open-Source Thrills

    As mentioned earlier, IT budgets are increasing across the board. When adopting new technologies, companies place the highest emphasis on the tech that increases efficiency. A surge in automation follows a low-code movement gaining steam. Companies consider the following key factors when introducing new tech: reducing deployment risk, increasing collaboration, and increasing development. Ninety five percent of US respondents also listed the “need to integrate with existing tools” as necessary — no surprise in today’s API-driven development landscape.

    Ninety one percent of organizations use open-source software in 2021 — this is up from 82.5% in 2020. Across the board, open-source is intrinsically embedded into most software projects. We see open-source especially used in open databases, infrastructure automation, API design and testing, CI/CD tools, Docker containers, Kubernetes and service mesh. Arguably, modern DevOps would not be possible without such open source initiatives.

    Bring it on, Microservices

    If you haven’t heard of microservices yet, we would be worried. An impressive 87% of survey participants believe that microservices-based applications are the future.

    While that sounds substantial, a path toward 100% distributed microservices architecture has not been mapped within most organizations. In 2021, only 33% of companies have transitioned entirely to a distributed architecture, whereas most (53.5%) adopt a hybrid mix of microservice and monolithic styles.

    “This is strong evidence that microservices have quickly become the de-facto approach for modern application architectures that enable digital innovation,” the report said. Though more development is required, a microservices-centric future seems obvious.

    Within organizations that have already adopted a microservices approach, the average number of microservices in production is 102. And those are primarily to increase security. Ironically, the report also found maintaining security to be the top challenge of deploying a microservices system. Other drivers for microservices adoption include integrating new tech, increasing development speed and boosting flexibility.

    Kubernetes Becomes Ubiquitous

    Kubernetes has clearly emerged as the industry standard orchestration platform. Eighty six percentof all respondents report they now use Kubernetes in production, or plan to within 12 months. This is a massive jump from VMWare’s 2020 report, which put Kubernetes use at 48%.

    However, there are challenges to implementing Kubernetes in practice. Companies cite security, complexity, performance and monitoring as top setbacks when introducing Kubernetes. To say Kubernetes has a steep learning curve may be an understatement, as abstraction layers are introduced to rectify a widening knowledge gap.

    Service Mesh Prickly for Early Installs

    Interestingly, API gateway adoption and container usage, according to the survey, are both 38%. Yet, service mesh adoption is only at 20%. This could underscore the fact that service mesh is still an emerging concept — service mesh experts say the tech isn’t ready for widespread adoption. Or, it could reflect that production use cases are rare (primarily for supporting vast microservices deployments).

    Early service mesh adopters see increased service connectivity and discovery as a top benefit of the technology. This seems logical, as service mesh aims to be a common networking framework. Other common benefits include cost reduction, meeting compliances, zero-trust security in networking and traffic observability.

    Naturally, service mesh isn’t without its thorns. Complexity in deployment and ensuring performance at scale top the list of challenges faced when deploying service mesh, slowing its adoption.

    Hybrid Multicloud

    The current status of multicloud deployment sees a mix of on-premises and multiple cloud providers, with 41% of organizations using multicloud deployment strategies. While cloud adoption rates are increasing, 31% of organizations are still running on-premises servers. The saturation of cloud tooling, and the market validity of Azure and Google Cloud Platform to take on AWS, have influenced a multicloud environment. Cloud expertise is now a hot commodity to navigate multicloud modalities — so much so that some companies have introduced a new role, The Other CFO, or Cloud Economist, to balance the cloud checkbook.

    Riding out the Virtual Wave

    The pandemic has accelerated the move toward digital experiences, and in turn, quickened the pace of enterprise technological evolution across the board. As COVID–19 effects continue, there’s no indication the virtual wave will recede anytime soon.

    To summarize the current state of digital innovation:

    • Rising digital tide: The pace to innovate is rising, and those left below the new-digital-normal water line will drown.
    • IT spend is up: Most companies have increased IT budgets moderately to support new digital norms.
    • Needs for adoption: Desires for automation, speed, security and integration rank high for adopting new tech.
    • Microservices on fire: The report describes “accelerated mainstreaming of microservices.” Microservices, and the tech that supports them, are clearly the future.
    • Kubernetes everywhere: As Kubernetes rises to ubiquity, last-mile efforts center on security and developer usability.
    • Bullish on service mesh: Service mesh sees early production uses, which will likely signal more growth in this area.

    There’s nothing unexpected in these findings; instead, they affirm what most of us already know — digital innovation is going full throttle. Check out the entire 2021 Digital Innovation Benchmark here.

  • DevSecOps Implementation: SIEM

    DevSecOps Implementation: SIEM

    The world is filled with events. Our inbox floods with events that marketers really want us to pay attention to, while news feeds flood us with events they’re trying to raise above the background noise, but then, the dog barking interrupts our consumption of that information. Our family is, meanwhile, texting us about events on the family level that may be related to events on the national or world stage … meanwhile, social media is full of garbage information about events that may or may not be real, and that you may or may not care about.

    We ignore the vast majority of these inputs and move along with our day. The inputs that require our attention usually, but not always, get it. Sometimes, we fail horribly at filtering, judging importance, or both, and it has life-impacting ramifications.

    This is not too far from the state of security event management when security information and event management (SIEM) was born. Disparate feeds were coming in from all over; analysts – be they dedicated security folks or systems administrators wearing an extra hat – had to guess which of dozens, hundreds or even thousands of events were a real threat to the environment.

    The first step to gaining control of that environment was standardization and aggregation. Get the events into one place, with similar information available for similar events. That was where SIEM came from.

    Since then, the number of events coming in has continued to rise. Companies that were seeing hundreds of events a day are now seeing hundreds an hour, and SIEM vendors had to keep up. The complexity of attacks, and the ability to detect them, has gone up, and SIEM vendors have had to keep up. Tools available for feeding the SIEM and for acting on the aggregated data have evolved … and SIEM vendors had to keep up.

    At this point in time, SIEM is best characterized as a data aggregation platform with limited intelligence that aids in filtering of irrelevant events. It’s akin to turning off social media and telling those close to you to call if needed; it filters out the worst noise and elevates the most important messages.

    Other tools can analyze their own data and make their own deductions, but SIEM is where you bundle all security-related events in one place, so it is the logical place to filter the noise and raise awareness. But it requires a high-volume, adaptable datastore. Vendors have reached that plateau.

    Once volume issues were mastered, SIEM vendors turned to helping filter the insane volume of security event noise. Yes, it is a security event if Bob logged in on a new workstation, but it probably isn’t a noteworthy security event. Unless Bob’s new workstation is in a country where the company doesn’t do business, or Bob is still logged in on his own workstation, blissfully unaware of the other login.

    So, rudimentary filters were applied to the event data in the SIEM. This got rid of a huge amount of noise. Next came filtering events that, logically, looked like notable security events, but just weren’t. Something was scanning ports on the firewall. An internal firewall. Sounds bad, unless the security tools’ logs showed that an authorized user kicked off the scan. Then, it’s a simple matter of asking the user in question, “Are you scanning X?” and moving along. It’d be better for the system to lower the importance of the event based on the fact that it is an authorized user doing the scanning, with corporate-approved tools. Then, an analyst may not need to get involved at all (my security friends are cringing because, literally, they trust no one, and would point out that authorized users can misuse tools, too – so I’ll note that here).

    But the event volume kept going up, and the analysts were even more swamped. Between adding new reporting apps (HIPS alone can add thousands of reporting points to a SIEM), and increases in events on existing monitored points, it was ugly.

    Enter AI. This is when machine learning (ML) started becoming the norm in SIEM. Now, we want the system to avoid using hard-and-fast rules that must be maintained, but to use knowledge it gains by watching the flow of data and an analyst’s resolution to selectively raise/lower the priority of events. Now, the events that actually bubble up to analysts are ones that the ML engine sees as fishy, and the number is greatly reduced. False positives still occur, but not nearly at the volume they did before, as the system learns how to detect them.

    But wait! There’s more!

    All that data in one place with ML engines crawling over it was just too much temptation for data scientists and deeply knowledgeable security personnel. So, the ability to plot a course through seemingly unconnected security events and determine that this or that was actually evidence of intruder or attacker activity spread across the system came next. This is where we are now – the ability to connect the dots on events that analysts (or the system) might have filtered out to find patterns that indicate intrusions.

    But it comes with a price. It’s not cheap to set up, it’s not easy to train, and maintenance of a system that takes inputs from everywhere and tries to correlate the resulting dataset is … work. We’re not talking a little bit of data here, and, like the environment it comes from, we’re not talking a little bit of complexity. Do you need it? I would say yes. Even if you only use SIEM as a big data store, it will help you perform post mortems when (not if) you have a breach. It is worth the effort, unless you are tiny or have no Internet presence to speak of.

    Keep rocking it! SEIM is another tool to consider as you move to DevSecOps dominance, but again, just a tool that requires you to keep the org safe.

  • Overcoming Cloud Asset Management Challenges

    Overcoming Cloud Asset Management Challenges

    Twenty years ago, no one in IT could have predicted the monumental role that cloud computing would play in our everyday lives. To play off the words of Back to the Future‘s Doc Brown: “On-premises? Where we’re going, we don’t need on-premises.” As technology continues to evolve, though, security teams face greater challenges.

    Infrastructure is no longer server rooms and boxes; it is dynamic, changing constantly to support fluctuations in demand. And moving to the cloud introduces new third parties into the digital mix. Although AWS, Google, and other cloud providers have a lot at stake when it comes to protecting customer data, security responsibility is never completely out of an organization’s hands. Compliance considerations are yet another complicating factor. In many cases, regulations around data access, privacy and residence were created for an on-premises world.

    Looking to the future, companies want to maximize their investments in the cloud, while better addressing these security challenges. However, the rapidly changing nature of the cloud makes it difficult for security teams to fully understand the scope of assets they are responsible for at any given point in time, which is an absolute necessity in order for companies to truly be secure. After all, how can a company make sure it has no gaps in its cloud security if it can’t account for all cloud assets – especially when working with multiple cloud providers?

    Security teams need to inventory their entire cloud infrastructure, understand what controls are in place and find ways to detect and mitigate any vulnerabilities or misconfigurations in a timely manner.

    Understanding Cloud Workloads

    When moving assets to the cloud, it can be incredibly difficult to try to inventory devices with dynamic IP addresses, which constantly change, compared with more static devices. The mass adoption of containers and microservices, some of which exist for just seconds before disappearing, make dynamic systems even harder to track.

    One of the most important improvements that have come out of cloud growth is that everything has an API, which can be a massive advantage when inventorying assets. Because each cloud provider is self-contained, finding out when a new bucket or instance is created is certainly possible. Organizations that have advanced development capabilities can write and maintain their own applications to identify every new cloud instance for each provider – but doing this for multiple cloud providers and correlating cloud asset inventories with other security control data becomes a major investment of resources. The ability to access all resources in the cloud makes asset management a more achievable goal.

    Security Controls

    It is essential for organizations to carefully manage their assets and understand the security controls in place to know exactly what they cover. By categorizing their resources, companies not only better understand what they have, but can make informed decisions about exactly what additional security measures need to be taken. For example, vulnerability scanners may not be scanning critical workloads – or perhaps dedicated cloud workload protection platforms need to be deployed for certain cloud assets. It can be incredibly difficult for security systems to keep up; since cloud assets can be created so quickly, they need security systems tailored specifically to keeping them safe.

    A security tool can only secure devices that it knows exist. Once an organization understands the assets it has, it can expand the coverage of any existing tools to devices that were previously unknown. When that coverage is fully adopted, asset management can help the organization find gaps in its coverage to identify areas for additional protection and the right tools to secure them.

    Addressing Vulnerabilities and Misconfigurations

    Once an organization establishes a comprehensive asset inventory and visibility, the next step is to address vulnerabilities, gaps in coverage or misconfigurations that are found. With the ability to spin cloud instances up or down at will, it is inevitable that instances may be forgotten and inadvertantly left unprotected. Since cybercriminals automatically scan public cloud infrastructure to exploit these types of vulnerabilities, public-facing cloud workloads are especially at risk.

    Similarly, finding and addressing misconfigurations in cloud workloads becomes more complex. With the highly configurable nature of the cloud, mistakes happen often, and without proper security controls in place to detect these misconfigurations, attackers can easily access and steal data. Organizations must implement a process to continuously detect cloud workload misconfigurations.

    A great place to start is the Center for Internet Security (CIS) Benchmarks, which provides objective security guidelines. By comparing data from each cloud provider with the rules in the CIS Benchmarks, security teams will be able to identify assets that don’t adhere to best practices.

    The key to maintaining security in a modern cloud environment is to implement continuous discovery and interrogation, which requires automation. This includes the ability to create tailored alerts when certain conditions are met, and automatically deploy and change security controls as needed. Teams should set restrictive access controls by default so that non-approved users don’t have access to sensitive data. Any time a cloud workload deviates from policy, there should be a plan in place to automate the corrective action.

    Computing technologies continue to evolve at a staggering pace. The computing environment 20 years from now won’t resemble even the most far-fetched, futuristic ideas today. The evolution of cloud adoption from justified skepticism to ubiquity taught us an important lesson: change is constant. It is incumbent upon technology and security professionals to  constantly challenge the expectations of security solution coverage and adherence to controls to keep data and systems protected.

  • An Analytics Workload is a Critical Data Management Tool

    An Analytics Workload is a Critical Data Management Tool

    From an organizational perspective, an analytics workload is a way to gain a data-driven business advantage. Analytics workloads can serve a primary objective that translates to an actionable business impact (such as analyzing A/B testing results, understanding user retention or finding anomalies in a flow, for instance) or can serve in a supporting role for analysis (such as improving dataset quality, preparing a dataset for user consumption or adhering to a data-related regulation).

    Ideally, a workload should have a measurable ROI and should be monitored on key performance metrics such as business impact, time to deliver, cost of execution and total spend versus allocated budget. Managing workloads this way is extremely challenging for data teams. In reality, the impact of big data analytics projects – and the effort and resources spent on them – tends to be unpredictable.

    You can place workloads on a spectrum: on one end, you have workloads that are very close to their business consumers. On the other end, you have workloads that serve auxiliary and support purposes. The latter are the hardest to track, budget and measure their return on investment (ROI).

    Query vs. Workload

    When data platform teams are tasked with evaluating and implementing the infrastructure needed for an analytics workload, they tend to look at it from a technical requirements perspective. An analytics workload is a set of queries that read and write datasets; it consumes compute, storage and memory resources and has an expected level of availability, robustness and performance.

    One traditional approach for improving cost and user experience in a workload is to focus on specific queries – identifying the slow, heavy and expensive ones and optimizing them one by one. While many single queries can be made better (faster, cheaper) by rewriting and optimizing, this approach often misses the big picture, leaving money on the table.

    Knowing Which Queries to Focus On

    Stripped of workload context, queries can only be evaluated on cost or response time. But business-critical queries may not be the most expensive, nor the slowest ones. Having the full view of the workload allows for prioritizing efforts much more effectively.

    Behavior Fluctuations

    The most important query on Mondays is probably very different from the most important query on Fridays, so the effectiveness of optimizing one or both queries may be small. The workload perspective enables you to identify patterns and leverage insights for effective optimization.

    Cloud Elasticity

    Unlike legacy data platforms, the cloud enables a brute-force approach to solving performance problems by adding elastic resources on demand. While this approach can work to improve a specific query, cost quickly gets out of control when applied to all queries. Understanding the workload is key to distinguishing when a brute force solution is right, and when you need to spend the time to build a different data flow.

    Cloud Decoupling

    In legacy IT environments, where queries were competing for a limited pool of resources, optimizing a single query had significant impact. But in cloud environments where resources scale elastically, queries compete with each other on a much smaller scale, if at all. Therefore, optimizing single queries has very little impact on the overall performance of workloads.

    Measuring Performance by Looking at the Median

    The heaviest or slowest queries are in the top percentile of queries. When trying to improve the overall user experience, the median performance can matter more, but it is indirectly affected when handling the extremes, so it tends to be less effective.

    The Long Tail

    In many workloads, a few highly visible queries can paint a misleading picture. It is common to have less than ten queries responsible for 20% of the load, and thousands of undistinguished “simple” queries responsible for 80%. Therefore, when data teams are trying to reduce cost, focusing on the most expensive queries may draw attention away from lower-hanging and easier optimization opportunities in “simple” queries.

    “Big Picture” Optimization

    Actions that improve a query (such as changing the layout of a dataset) may result in unintended consequences to other queries. Only a workload perspective can help evaluate the wider impact across other queries.

    The Cluster Approach to Optimizing Big Data Analytics

    Another traditional approach to optimizing data platforms is analyzing behavior from the cluster perspective. Most data platforms offer decent cluster monitoring of technical metrics, such as CPU load and RAM usage.

    But, focusing on cluster-based KPIs will draw attention away from the elements that have the highest impact. Understanding the workload entails understanding the business logic of queries: repeating query patterns, hidden dependencies, failure modes.

    Looking at this from a cluster perspective limits you to technical parameters, such as CPU usage. Without understanding the workload, data teams will miss issues such as a repeating calculation (to be made into an ETL flow) or an inconsistent calculation flow (like having different ways to compute the same business KPI).

    In environments where clusters are shared between different workloads, data teams often encounter additional challenges:

    Workloads Have a Business Context, Clusters Don’t

    From a cluster perspective, there is no inherent prioritization between queries, and data teams find it difficult to focus only on business-critical workloads. The outcome is often reverting to focusing on specific queries, which doesn’t offer an effective solution.

    Workloads Have Different Needs

    Take, for example, an ETL workload which may require a large amount of RAM, run hours and which must be finished by 7 am. An interactive data product workload may be composed of thousands of queries that each must return in under 2 seconds. Analyzing the cluster as one unit can lead to suboptimal behaviour of both workloads. While this example can be considered simple to detect, many workloads that seem similar can have widely divergent needs.

    As data lakes gain momentum as production-grade, big data analytics architecture, data teams need to shift attention from optimizing queries to measuring, analyzing and optimizing workloads. In the early days of big data, data warehouses were isolated data platforms tasked to deliver insights for a very specific set of business questions. But as the cloud rapidly evolved, the mere migration of data warehouses to the cloud is not enough. The next stage is moving production workloads to the data lake.

    Storage is so much cheaper, and organizations want to run queries on any dataset, whenever they need it. It’s this heterogeneous collection of many different queries that requires workload-level visibility to ensure each workload can truly meet performance and budget requirements.

  • TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

    TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

    The role of DevOps is constantly evolving as new technologies and trends keep emerging and reshaping the business. It is critical for DevOps engineers to continuously learn about the latest tools, best practices and technology, and be able to adapt to change.

    There are many ways for DevOps teams to refine their skills in order to become high performers. In this TechStrong TV interview, OpsCompass Co-Founder and CTO John Grange and Engineer Amy Wall join Mitch Ashley to discuss upskilling and how to build and maintain your software, development, cloud and technology skills in the fast-paced world of cloud. John provides a look into the future and where our skills need to move next, while Amy graciously shares her journey into software development and some valuable lessons learned along the way.

    OpsCompass is a leader in Cloud Security Posture Management (CSPM) offering an enterprise SaaS product that provides security and compliance management in cloud platforms.

    The video interview is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined by two really interesting folks. We’re gonna have a great conversation, I’m looking forward to this today—Amy Wall, who is an engineer with OpsCompass, and then John Grange, CTO with OpsCompass. Welcome to you both. Good to be chatting today.

    Amy Wall: Thanks. It’s great to be here.

    John Grange: Yeah, thanks for having us, Mitch.

    Ashley: Absolutely. You bet. Let’s do this—how about if we have you both introduce yourselves. Maybe, John, if you go first, introduce yourself—tell us a little bit about OpsCompass and what the company does, too, and then hand it over to Amy and you can tell a little bit of your background.

    Grange: Excellent. Again, I’m John Grange, I’m co-founder and CTO of OpsCompass. OpsCompass is a really powerful SaaS product that does security and compliance management in the cloud. And what that really means is, you know, we’re really helping DevOps teams, CloudOps teams get the visibility, have the intelligence and the control they need to run a successful cloud operation.

    You know, my background really plays a lot into what OpsCompass does and kind of the cloud security space. I’m a career entrepreneur. I’ve co-founded a number of companies, from top five global Microsoft ASP.NET hosting provider to a health and wellness SaaS product. So, I have a lot of experience, and our team has a lot of experience in kind of the infrastructure security compliance space. The cloud, obviously, was a big game changer, because a lot of the things that we used to deliver through a variety of different software products or hosted solutions inside data centers, we can now build software to easily do it in the cloud.

    Ashley: Mm-hmm.

    Grange: So, that’s kinda how I got into the business through kind of that hosting and infrastructure space, and now here we have OpsCompass, which is leading the charge with helping customers with their security posture, their compliance—all these different aspects of running or having a well-run cloud.

    Ashley: Sure is a fun and interesting space to be in and I think we’ll get into that, too. Amy, how about you? Just a little bit of introduction, and I think we’re gonna get into more of your story, too.

    Wall: Sure, yeah. I’m Amy Wall, I’m a DevOps engineer at OpsCompass. I have the pleasure of working with John Grange, working under John Grange, and kind of forming this exciting new product, OpsCompass. And so, I’m kind of—where I’m at in my career and on my cloud journey is really in a space where I’ve kind of come to it from a software engineering perspective. I’ve been a software engineer for years now, and you know, been going through the steps and kind of getting the skills under my tool belt, upskilling on the cloud path so that I can become a full DevOps engineer for OpsCompass. So, really been learning with OpsCompass and growing with OpsCompass as they sort of kind of figure out and carve out their space in the cloud infrastructure.

    Ashley: Mm-hmm. Isn’t that nice when you work with, you find a company that’s really compatible with what your goals are and what you wanna learn with where you are in your career? That’s awesome.

    Wall: Huge. Absolutely.

    Ashley: Well, that’s a little bit of what we’re gonna talk about, the upskilling is kind of a general, I guess, tag, label for it. We’re gonna explore a little bit, and you volunteered to share your story of how you got into software and how you’ve evolved into software in the cloud and DevOps, and then maybe take a look forward, you know? We’re here in December thinking about getting through the holidays and everything else going on and thinking about the new year. Maybe John can share with us some ideas on that, too, and we’ll explore some of those things about how do we prepare ourselves for the next things that are coming.

    So, let’s start with your story. I’ll let you tell it however you’d like, but you know, maybe how did you get into software?

    Wall: Sure, yeah. I always like to joke that if I told my 12-year-old or 14-year-old self that I was a software engineer or DevOps engineer, I would not believe it, at that age.

    Ashley: [Laughter] 

    Wall: But yeah, I really didn’t have a super traditional path. You know, I was a Humanities major in college. I left college and I became a content editor and then later a project manager in the marketing space. And I really enjoyed it, but kind of along the way, I got exposure to various technologies, I got a little exposure to programming, I got some exposure to IT, and over a few years, I realized that I just loved it, and that’s what I really wanted to do. And my favorite days at work were the days where I was able to kinda solve, you know, software problems or technology problems, whatever.

    So, I did, like, a total career 180 about five years ago and took a U-turn, learned how to code, and my first job after that was at OpsCompass or a subsidiary of OpsCompass that OpsCompass then later purchased. And so, I’ve been working in software ever since as a software engineer. And it wasn’t until OpsCompass a couple of years ago, I think two or three years ago, when I was able to join that amazing team of engineers where I started to really ramp up my cloud journey. You know, I had become pretty strong in the fundamentals of software engineering, and you know, I’d become really used to kind of the experience of learning on the job. You know, that’s kinda the nature of software engineering itself, and it’s the nature of DevOps, and it’s really the nature, I think, of cloud, because there’s new technologies coming out all the time and everybody’s kind of learning a way to navigate the space a little bit better all the time.

    And so, yeah, I just kind of figured out how to learn on the job and continued learning on the job, and now I’m surrounded by world class cloud engineers and John Grange, our CTO, who have excellent mastery in this space, and it’s been a blast to kind of learn together with them and figure out how this entire ecosystem works.

    Ashley: Wow, very complimentary of the company. Be careful, John, she may have an ask.

    Wall: [Laughter] 

    Grange: Yeah, I know. This is—this is great. No, but in all seriousness, you know, just from our perspective, even, having somebody who’s a rock star at this point, like Amy, it’s hard to find cloud expertise. And you have to be able to find people that are interested in growing, willing to grow, have that interest—like, it sparks that fire, so that then you can enable that and you can grow a lot of your own expertise, and it’s a really powerful thing, but I think it’s something that a lot of companies, particularly like us, have to do today to stay around.

    Ashley: Mm-hmm. You really do have to invest in people and give them the right, whatever ways that they learn, the right opportunities. You know, there’s also the person side of it, too. One of the best things I learned in college from a Computer Sci professor was, he said, “Everything you know now is gonna be obsolete in a year, so you need to keep learning. You have to have a thirst, just a hunt, a desire for learning just to keep—keep going.” 

    And it seems like that’s consistent with what your journey’s been, Amy. Maybe talk about what the evolution from some of the technologies you started developing software in to getting into cloud—what kind of things are you doing today?

    Wall: Sure, yeah. So, I started where I think a lot of new coders start is, I started on Ruby on Rails, and I used it for years, and I actually still use it a lot of the time. But yeah, I started there, and then I worked in the consulting space for a few years where I was able to kind of bring to life a lot of customers’ ideas, clients’ ideas, and I loved that, that was really exciting.

    And so, from there, I kind of have just begun dipping my toe a little bit in all the cloud has to offer. I still have a ton to learn. But our infrastructure has a number of different resources in various clouds. You know, I get to work with AWS, I get to work with Azure, I get to work with Google Cloud Platform. So, you know, any given day, I could be working on any one of those technologies. I could be spinning up Lambda, I could be debugging something in Typescript or JavaScript, whatever it is.

    But yeah, it was definitely a journey along the process, but we have a team, like I was kinda mentioning before, we have a team that we all, I think, feel that we’re in it together a little bit. And so, there’s a great energy where I think we kind of all learn together, even the master practitioners will continue to kind of get new certifications as they come out, will continue to offer advice, and will continue to learn.

    And so, I’ve never really felt like I was the baby in the room, so to speak, [Laughter] or that I was less skilled than anybody else, per se. I kinda just felt like—okay, we’re all making ourselves better, sharpening our skills, getting better all the time, so.

    Ashley: Especially, it can be an advantage in a technology area that’s relatively new, because everybody’s learning it, right? Nobody’s been doing it for 20 years or whatever makes you an expert.

    I’m curious, too, did you find mentoring, kind of learning from peers, things like that were helpful, since everybody’s learning at such an accelerated pace moving into the cloud, whether it’s on the UI side or on the software infrastructure side?

    Wall: Hugely, absolutely, yeah. Our lead architect, Nick Allmaker, is an excellent mentor for us. You know, his knowledge never ceases to amaze me, and he’s really, really helpful. He’ll always—he’s always willing to take some time out of his day to spend a couple extra minutes on a pull request or help you figure something out.

    But, you know, even earlier on in my software engineering education, I remember having a teacher who told me, “Always T.S., try it and see.” [Laughter] And I think I mentioned this in a blog recently, but that’s been hugely helpful to me as I’ve moved into this space, because you know, for me at least, in learning cloud and in understanding the ecosystem, tutorials online can really only take you so far. Sometimes, you just have to, you know, go in there and spin up a Lambda, you know, spin up an EC2, and figure out what’s going on, play with it, move it around a little bit.

    And so, I definitely—that’s a big insight that I’ve learned is that just get in there, try it. A lot of the clouds, I think all of them, in fact, have a free trial where they give you a little bit of free canister to play with at the beginning. I used that for all of them, absolutely, and you just, you know, spin up resources. 

    And I think in addition to that, having a third party like OpsCompass where you have kind of that visibility into every single resource that you have going on in every single cloud can be super helpful to someone. Obviously, helpful for experts and helpful for people who are in the cloud security posture management space, but also helpful for people like me who are learning and who don’t really understand or who are kind of putting the pieces together of what changes do what and what resources are like others, how similar is an Azure function to an AWS Lambda, and having that kind of visibility into all of your clouds and all of your resources can be hugely helpful.

    So, you know, I kind of had that advantage at OpsCompass where, you know, I’ve definitely had a leg up, for sure, in being able to kinda learn this stuff.

    Ashley: Mm-hmm. Opportunity is everything. Sometimes it’s self-created, and sometimes it’s the situational company, et cetera. I’m curious, John, what’s your perspective on, because you’ve, you know, you’re obviously probably in a little different place in your career, but as yourself and folks you’ve worked with, what are some of the mentoring and kinda helping others advance in their careers have you seen to be really successful—either for yourself or people you’ve worked with.

    Grange: Sure. Well, you know, there’s a couple things that come to mind, and one of them Amy just mentioned, being able to go and mess with something, being able to go out into the cloud and play with the resource and have kind of both the curiosity, the time, the capability to be able to go do that is a really powerful thing. And in the cloud, when all of these services are changing and being—you know, there’s a couple hundred different ones on AWS—there’s literally something new every day.

    Ashley: Mm-hmm.

    Grange: So, I think that that’s a big part of it. The other thing that I learned early on from mentors of mine that I also try and share with the team is that when there’s these big trends—you know, cloud is an example, but then also, you know, some of what you see with big data and AI, et cetera, there’s the sort of application top layer trend that’s all of the robust sort of user applications for those technologies. 

    But for those to actually come to fruition and for that trend to really be powerful, there’s gotta be all this plumbing underneath that isn’t as—it’s not as glamorous and not everybody thinks about it, but as those spaces burgeon, it’s not just the mobile app that’s using AI to really change kind of directions in navigation, it’s the whole industry of sort of the infrastructure beneath that needs to serve those sorts of trends and applications. And those end up being great places to go and learn about. And there’s tons and tons of opportunities, sort of, in the wake of those big trends and the leading kind of applications and companies.

    So, I always like to, even in our product, you see a little bit of that, but I even try and tell, you know, folks on our team that we need to be looking at things that way, as these trends are big. What kind of plumbing do the customers need? What are the dots that need to be connected? What’s the kinda unglamorous thing underneath that everybody’s gonna need that we can learn a lot about and solve the problems around?

    Ashley: I’m curious, Amy, have you seen that? Has that been consistent with your experience, too?

    Wall: Absolutely, yeah. I think—yeah, per what John was saying, I do really think that there is kind of an ecosystem to cloud and we’re trying to always stay on top of it, in front of it, you know, figure out what’s going on with it and view it from kind of like that 30,000 foot view, so we can really understand it as a whole picture.

    So, yeah, I think there’s a great knowledge share, for sure, and I think that’s hugely important to figure out where is this going, what is going to be happening in 5 years, in 10 years? Where do we need to start working now so that we’ll still be relevant, we’ll still be making sense at that time? And it’s not always easy to guess, but definitely, there’s a lot out there in the industry that you can kind of get a feel for that.

    Ashley: I think we’re in violent agreement. [Laughter] The best developers I’ve worked with really knew it from the operating system, the whole software stack, the network—you know, not an expert in every piece of it, but knew how it all fit together and how to make it all work and kinda hum and get to the performance that you need or make the right decisions on how you want to, the architecture you want to use and what parts you do and don’t want to use.

    You know, another thought—you may have mentioned this in your article, too, Amy, and I’ll put a link to the article in the description—open source is another fantastic resource. You talked about getting free time on cloud services and using sampling software—it’s a great place to watch how software’s built, in a little bit different way, in an open way, open community, but using that as well can be super fantastic. And by the way, everybody’s using open source in their products and their IT systems, their applications. And so, the more you know about it, the more you can leverage it, right?

    Wall: Absolutely, yeah. I love—I just, I love the idea of open source. You know, I think it’s—I love the ideology of it. I think it’s fantastic, and certainly, we do use it. And I think open source is the place where a lot of people kind of go to exchange ideas in the cloud space right now. You know, we have a lot of—Twitter, for example, Tech Cloud Twitter is always really exciting and people…yeah, I think people are making some really interesting things right now with open source, and it’s an exciting place to be.

    Ashley: So, let’s kinda turn the lens from, you were talking a little bit about your background, John sharing a little bit of his as well—turn the lens to kinda thinking forward, right? Things have changed. It’s a different world in the last nine months, for sure, and a lot of organizations have accelerated digital transformation projects. We’ve got data in my analyst firm to back this up very strongly. 

    The move to the cloud is accelerated, and you know, not stopping. It’s gonna continue to move even quicker. And I know you think about a lot where you’re going as a CTO with your company and your product and your technology, John. What thoughts do you have as you think over the next 6, 12, 24 months kinda into the where we’re going and how that might influence what people might learn or maybe how they learn?

    Grange: Mm-hmm. I actually—that’s a great question, and I’d actually go back to the comment I made before about some of the different trends. And, you know, just like we’ve had the DevOps trend over the last handful of years, there’s a whole number of kind of portmanteaus, right, the CloudOps and DataOps and AIOps.

    And I think that as some of these, you know, Fortune 1000, Fortune 2000s start to become more cloud mature, you’re gonna start to see more of the need for, okay, not just general DevOps where you really understand the cloud platform and orchestrating and automating workloads and things of that nature, but you understand the details of AIOps, for instance, which is a much different challenge, it has lots of other issues with data issues and labeling and things of that nature. Similar issues with sort of DataOps engineering—lots of new problems, really important business solutions to be built there for organizations that are already pivoting their organizations to prioritize these things, particularly after the pandemic. 

    DevOps is all about efficiency, and now what companies are saying is, “Hey, you know, coming out of the pandemic, we’re gonna prioritize our most innovative projects higher and we’ve got to push to be more efficient. We can’t have the cloud spending overages, we can’t have these big breaches that are costly reputationally and financially. We’ve gotta get more efficient.

    So, I think that those are the big things that, coming out of the pandemic, I’d be thinking about. If I were kind of a DevOps practitioner out in the field but also what I’m thinking about at OpsCompass is we’re, you know, looking out, we’re looking into how can we provide more value to our users for some of these really specific use cases that are driving very significant value for companies that are implementing them.

    Ashley: Mm-hmm. I’m curious, too, then, without getting into customer details, but as you’ve worked with your customers through the pandemic, through economic challenges, recovery, that kind of thing—what changes are you seeing in the market with the customers that you’re working with? Are they emphasizing different things, stepping back and taking new directions or trying to get better at just the core things? What’s happening?

    Grange: Yeah. You know what? It’s interesting. From my perspective, it’s very much almost no new phenomenon. It’s almost all just an acceleration of things that we were already seeing.

    Ashley: Mm-hmm.

    Grange: So, in other words, a lot of our kinda strategic plans that we thought were maybe a year out all of a sudden became, you know, “We need them, like, yesterday.” So, I think that a lot of those trends around remote work were already in place. I think a lot of—you know, many of the projects that we’re seeing companies, you know, prioritize, put a higher priority on, those projects already existed. Now, they’ve just become more important.

    Unfortunately, a lot of these IT teams and cloud teams shrunk during the pandemic. So, they now have the requirement that they’re more efficient and everything else, but they have, in many situations, fewer resources to work with.

    Ashley: Mm-hmm. Well, though that’s hard, it’s almost always that growth comes through investing again, so at some point, that starts to rebuild on that efficiency.

    Grange: It’s the story of IT, right? The story of IT—being understaffed and overly important.

    Ashley: Yeah, I don’t think I’ve met an IT team that said, “You know, we just have too many people. I’m not sure what we do with all these folks.” [Laughter] 

    Grange: Yeah.

    Ashley: You know, it’s interesting—I agree with you about, it’s very much accelerating. Another trend I would share—let me see if you concur with this—is, you know, you have the fortunate, if you wanna think of it that way, situation of being in a company where your software is your product, right? So, you can connect the dots between work that Amy’s doing or someone’s doing a test or someone’s doing customer service or architecture or what you’re doing in your role, John. You can connect that to the business and why you want to invest in AI and machine learning or whatever the next thing is.

    That can be really hard to do when you’re in a bank or an insurance company or something else where there’s a lot of distance between what I’m doing in my job—especially in a Fortune 1000 company or above. With that acceleration, though, and I think because of DevOps and AsteriskOps being adopted across different functions, a lot of that is about driving that connect the dots to why we’re going and where we’re going there, and how to accelerate, right? So, the efficiency can be for financial purposes, but recovery can also require agility, very fast response. You know, markets change, our supply chain is gone. We gotta rebuild that in a totally different way—so, guess what? Software is critical. It’s not just a back office thing. Thoughts?

    Grange: Hey, I think that’s exactly right. And, you know, using the financials as an example, you know, many of these financial companies were spending an extraordinary amount of money on reducing their risk, their technology risk, their physical security data centers, really expensive software to secure it all. And you’re exactly right, one of the accelerating trends is that efficiency. That’s not efficient at all. Capital One now has moved—they’ve shut down, now, all of their data centers around the world. They’re completely in the cloud.

    Ashley: Mm-hmm.

    Grange: That’s kind of an outlier example now, they’re like, the only one. But they’re all—I can tell you, just on experience with our own customer base, the mid-market is moving very quickly that way, too. Because they just realized that—hey, we don’t have to, we now don’t have to build data centers, we don’t have to have these huge capital budgets. We can be more efficient, we can be more operational. We can—to your point, the agility that’s required with how quickly this technology’s changing, you almost don’t have a hope unless you’re in the cloud. You know, you can stand up your own container stack in your data center and set up a rack and buy hardware and do all that, or you can go turn on, you know, Amazon’s Elastic Container Service and go with it. I mean, it’s just, it’s a whole different ballgame. And, yeah, I think that that’s a good example, Mitch.

    Ashley: Excellent. I’m curious, Amy, your perspective on it, too. Will you—in your role when, kinda, you think about your career and where you’re moving as well as the company, how is the current situation influencing how you’re thinking about what you do next, what you learn, and how you can maybe help others accelerate their learning?

    Wall: Hmm. Yeah, I agree with both of you, that I think the pandemic has had a real—there’s a renewed sense of urgency because of it. And so, I think a lot of us have had a moment to kind of take a step back and think a little bit from a broader perspective about what our company is, what our company is doing, what we are doing, where our careers are going—all those kinds of things. 

    And yeah, I think people are having an opportunity to figure out—like John was kind of saying, John mentioned the infrastructure for working remotely was largely in place before the pandemic, but that wasn’t always true, and that wasn’t true for every company. And so, I think there’s a lot of catching up that’s happening right now, and yeah, there’s definitely this added urgency behind all of it because of the state that the world is in right now.

    Ashley: Yeah, it’s interesting. I was running IT for a while at a prior job, and we were at this beginning of—stopped thinking about it as we were working remotely or working remote and think of it as work anywhere. 

    And it seems like that’s totally apropos now, that’s—you know, if you think about forward, it’s not like we’re all gonna show up back in the office after we vet the vaccine or whatever, even if things are in good shape, you know, public health wise, there’s a lot of things that, you know, we’ve been doing this for a year, two years or whatever the time’s gonna be. People are gonna build on it and leverage that, at least I think. I don’t know if you all agree, but I think this is the work anywhere that we’re in now.

    Grange: Well, CFOs got a little taste of really, really small travel and entertainment budgets, and I think that, as those start to come up, I don’t think that the tolerance levels will be quite where they were before the pandemic.

    Ashley: Yeah, we’ve proven, right, what we can do.

    Grange: Yeah.

    Ashley: Also interesting, you know, folks have talked about, we’ve made decisions a lot faster, too, in some cases. You know, we were debating—do we use Team or Slack or whatever, you know, for a year and suddenly in a week, two days, we decided it. Like, why can’t we do that all the time? Well, maybe not always you do that, but we’ve shown we can accelerate a lot of things.

    Grange: Well, I think that another thing that happened is, I think that American companies in particular, I can’t comment as much internationally, but American companies, I think, got very good in this, in the 21st Century at buying software—maybe even before that. 

    But I don’t think that companies are very good at actually adopting and using software, and I think one of the things that the pandemic did is, like, everybody bought teams and bought all this stuff from these, you know, the big tech companies, and nobody really fully adopted it, fully implemented it. It was always just kind of another thing on the shelf, and I think that that’s another thing that’s happening right now.

    Ashley: Mm-hmm. Getting greater adoption. 

    Grange: Lots of the collaboration technology, lots of the things that we all kinda use are now becoming highly mission critical business processes that we care about. So, we’re, like, fully adopting them.

    Ashley: Just the essential tools in the toolkit versus, “Yeah, I’ll use it if I have to talk to that team” or something, [Laughter] that group. As you’re thinking about the technology stack, Amy, you know, John was talking about adopting software. I remember a time in my career where folks felt like they had to write all of it, right? I mean, yeah, they used a database system, or—you like to build software, so build as much of it as you can.

    Today—yeah, you write software, but you want to, is there a better container management system than Kubernetes? Well, let me go check it out. You know, I don’t necessarily want to write my own. Maybe I do wanna do it as an open source, but you’re really a software integrator, software builder as part of the whole process, not just a software developer. Is that how you view things?

    Wall: Absolutely, yeah. Yeah, I’m a big proponent—totally, yeah. I always say, “If you can avoid it, don’t reinvent the wheel.” And everyone says that, but not everyone always takes that to heart.

    Ashley: Mm-hmm.

    Wall: And I think a lot of the times, especially when you’re in a software team, you’re in a development team and you’ve kind of got your head down and you’re really working hard on code, I think it’s really easy to kind of lose sight of the broader picture.

    And, you know, just last week for example, we had this problem we were trying to solve where some customers weren’t—you know, there was a miscommunication between our software and some customers. And, you know, I kind of just was able to take a step back and—

    Wall: – you know, customers weren’t, you know, there was miscommunication between our software and some customers, and you know, I kind of just was able to take a step back and say, “You know, if we just think about this and maybe document it, write about it, you know, find some documentation online, you know, find a good article, perhaps, that we could recommend, I think we could solve this problem without writing any code at all.” And we did. And I think those kinds of solutions are happening a lot, for sure.

    I mean, and you mentioned open source earlier as well, and I think that plays into it to a huge degree as well.

    Grange: That’s what I was about to say Amy, is that that goes right back to what you were saying, Mitch, with the open source. And I think that’s why open source sort of is kind of supreme right now. Go find a library, go find a package that already does this, go find a service that we can just integrate APIs with, you know—let’s not reinvent the wheel.

    Ashley: I remember being on some panels of, you know, “Should you use open source?” and my answer was, “I can guarantee you your competitors are.” Talk about a source of innovation that you can get for little or no cost—I mean, yeah, there’s a cost with it, but you better leverage it, you know, [Laughter] in the right way for your company as well.

    Let’s talk a little bit about OpsCompass. I’d love to hear, maybe, some of the future directions you’re heading. You’re not announcing anything here today, but what are the kind of things you’re thinking about since we’ve talked about this evolution of where the cloud and technology and skills need to go? What’s happening at OpsCompass as you evolve and change and play a leadership role in the industry?

    Grange: Sure. Well, for us, the way we like to think about the product and the product strategy is, what’s going on in the cloud space, what are customers doing, and then how can we provide kind of visibility and intelligence across those different dimensions?

    So, I talked a little bit about kind of some different AI products and services that we were starting to see companies use more containers. We obviously—that’s kind of a number one use case for our customers today. So, we’re fairly strong there, but we’re gonna get much, much stronger.

    But another big part of it for us is the DevOps pipeline. We provide visibility into what the pipelines are doing today, but it’s becoming so much more critical to the full cloud processing companies. They’re becoming more DevOps mature that we are going to, you know, kind of completely blow out that kind of set of functionality in our product over the next year. So, we’re excited about that. And you know, our customers are really looking—you know, you can parse through a lot of the technical explanations for problems, but what they’re really trying to do is get control, and the definition of control is a little bit different than it was in the data center. And there’s some more subtleties and things to it, it’s got a little bit more texture, I like to say.

    And so, it requires a different approach and when we can combine, you know, the deep visibility into what they have with the intelligence and context around, you know, what’s happening and the state of things, that’s kinda how you end up getting control. And there’s processes and people involved and everything else, but kind of everything we do—and we kind of, you know, eat, breathe, and sleep that kind of mantra, and we’re constantly poking and prodding at the clouds, working with the clouds. We work with all three at the corporate partnership level. So, we’re just really—we’re having a lot of fun, and it’s sort of the key problem of the age right now is just the different teams, all these different people, different resources, different services. It’s just sort of the impact of this sort of scale and kinda chaos a little bit. So, there’s just so many great problems to solve around making sense of it all.

    Ashley: Mm-hmm. Excellent. Amy, anything from your perspective you would like to add or talk about?

    Wall: Yeah, I think John is just spot on. And I also think, from an internal company perspective, you know, what’s happening within OpsCompass is being mirrored by companies across the globe right now, which is that we are really kind of getting a feel for how to operate as a totally distributed team, like you were mentioning earlier. We have employees now all across the United States and internationally. We also work with customers and _____ abroad.

    So, we have this—I think we’re kind of learning along with our customers how to kind of interact with a more global ecosystem than we had before and how to kind of bring all of these, all of the water cooler conversations or all of the idea sessions or brainstorming sessions and whatever onto Slack, onto Teams online so that we can all engage.

    So, that’s definitely a change that I’m seeing internally and that I’m not, I don’t see going away when the pandemic is over, and I see it becoming something that goes on to the future.

    Ashley: Yeah, that’s very wise. I think it’s very sticky kinds of behavior changes and work patterns that will be with us for a long time to come.

    Well, I’ve really enjoyed, this has been a fun conversation talking with you both and it’s just—it’s so much fun to share real experiences that we’re having in our jobs and our careers and also doing it in a way that hopefully this conversation can benefit some other folks, you know, along the way who may have similar or maybe different experiences that they might pick up from what we’ve talked about.

    So, before we wrap up, to check out things at OpsCompass, John—OpsCompass.com, is that correct?

    Grange: Yep, you can go to OpsCompass.com, check out more about us. We have a free trial, really encourage people to go jump in, check out the product. Again, it’s built by a bunch of DevOps engineer cloud nerds for our sort of brethren, if you will. So, love getting feedback and let us know if there’s any, if there’s anything that we can help you with.

    Ashley: Built by DevOps people, for DevOps people, right? [Laughter] 

    Wall: Exactly.

    Ashley: Exactly. Well, Amy Wall, it’s been fantastic talking with you. Thanks for sharing your story and your insights. 

    Wall: My pleasure.

    Ashley: And John Grange—similarly, your insights as well as kinda where we’re headed and a fun conversation with you. Both the best, have a great holiday, and we’ll see you into the new year.

    Wall: Thanks a lot, Mitch.

    Grange: Thank you, Mitch. Be safe.

    Ashley: You, too.

  • Enterprise Software Development Will Break the Speed Limit in 2021

    Enterprise Software Development Will Break the Speed Limit in 2021

    For some, 2020 was the year for software development speed … but not for everyone. Startups and SMEs climbed on board the CI/CD, shift-left and agile development train en masse – and reaped the benefits of faster iterations and tighter release schedules.

    But the “big kids” got left behind. Core enterprise applications – the legacy systems with 1+ million lines of code that do the heavy lifting in many corporations – have not yet made the switch to the world of rapid release cycles. And this is natural; enterprises are rightfully more cautious by nature, and because the technology driving this evolution was not mature by enterprise standards.

    But in 2021, that’s going to change.

    Here are four speedy predictions for pushing enterprises over the speed limit in 2021, and some of the companies making it happen.

    Four Enterprise Software Development Speed Predictions

    #1: AI-based test generation will make enterprise development faster and better

    Testing automation is crucial for any software development organization trying to transition to CI/CD. But enterprise stakes are arguably high, and enterprise code is by nature inflated, often carrying significant technical debt. Preparing suitable test coverage manually is resource-heavy, to say the least. But a new generation of AI-powered testing automation tools solves this problem for you. Solutions from companies like Ponicode and Diffblue allow enterprises with large code base apps to embrace CI/CD by bridging the technical debt gap in testing while still meeting release cycles.

    #2: Test avoidance tech will make a dent in unnecessary testing

    Running tests on an entire build for one small code change is overkill – no one’s arguing that. But until recently, there wasn’t much of an alternative to ensure the ironclad quality that enterprises require. In 2021, solutions from companies like Sealights and Launchable (which counts among its investors Jenkins creator Kohsuke Kawaguchi) will help enterprise software development teams deliver quality at speed. The key is the effective use of machine learning to reduce test cycle times and run only relevant tests, not the entire test suite, to ensure faster iteration cycles.

    #3: High Performance Computing will move toward distributed computing

    Compute power will remain a bottleneck to development in 2021 – but the processing arms race will likely change. As enterprises get used to virtualizing their infrastructure, they will think twice about investing heavily in dedicated multicore build/render machines powered by next-gen processors. Instead, they will look to virtualized processing power like distributed computing, cloud bursting, and spot instances – which provide the massive scalability enterprises require at build time, while still maintaining a more reasonable price-performance ratio.

    #4: Managed CI/CD in the cloud will automate enterprise release pipelines

    Managed CI/CD, like Amazon’s CodePipeline and Azure Pipelines, help enterprises save time setting up and maintaining CI/CD infrastructure, scaling up during peak times and maintaining security. These services, while not for everyone, will continue to gain popularity in 2021. A key reason for increased adoption is that they allow companies to scale much faster: without hardware or software, development teams can push a button and suddenly gain 20 more build servers. Moreover, managed CI/CD enables faster onboarding of new teams, simpler creation of repositories and more streamlined work with multiple geolocations. Finally, pay-as-you-go models, no upfront fees and no commitments are increasingly attractive to enterprises in tough times.

    Put the Pedal to the Metal

    Newly released AI-powered products and mature hosted services from big-name cloud providers are changing the face of enterprise-level development. In 2021, we’re going to see teams supporting backbone enterprise applications increasingly moving to CI/CD, shift left and agile development methodologies. Because everyone – even enterprises – deserves to break the speed limit.

  • Measuring the Business Benefits of AIOps

    Measuring the Business Benefits of AIOps

    Staffing levels within IT operations (ITOps) departments are flat or declining, enterprise IT environments get more complex by the day and the transition to the cloud is accelerating. Meanwhile, the volume of data generated by monitoring and alerting systems is skyrocketing, and Ops teams are under pressure to respond to incidents more quickly.

    Faced with these challenges, companies are increasingly turning to AIOps – the use of machine learning and artificial intelligence to analyze large volumes of IT operations data – to help automate and optimize IT operations. But before investing in a new technology, leaders want assurances that it will bring value to end users, customers and the business at large.

    Leaders looking to measure the benefits of AIOps and build KPIs for both IT and business audiences should focus on key factors such as uptime, incident response and remediation time and predictive maintenance to prevent outages that could affect employees and customers.

    AIOps KPIs include employee productivity, customer satisfaction and web site metrics such as conversion rate or lead generation. AIOps can help companies cut IT operations costs through automation and rapid analysis; it can support revenue growth by enabling business processes to run smoothly and deliver excellent user experiences.

    Specific IT and Business Benefits

    AIOps can digest operational data and spit out actionable recommendations for keeping important systems running at peak efficiency. These are the most-cited benefits of the technology:

    • Alert management: In most cases, the first problem AIOps systems will address is reducing the volume of noise: the torrent of alerts that inundate IT operations. AIOps uses clustering and pattern matching algorithms to eliminate as much as 90% of false alarms and other redundant or irrelevant alerts, making it far easier for staffers to focus on what really matters.
    • Incident prioritization and routing: AIOps systems can learn, over time, which types of alerts should be sent to which teams, reducing redundancy and confusion when, say, networking and database teams both get the same alert related to an incident.
    • Event correlation: AIOps can correlate alerts and event data to identify the root cause of an outage or application slowdown so that IT teams can respond faster.
    • Advanced anomaly detection: AIOps systems can identify anomalies to proactively detect abnormal conditions and relate them to business impact. For example, AIOps can predict if a system will run out of disk space based on projected growth or seasonal patterns, even if the growth is non-linear. Or, if there’s a sudden increase in the number of failed server requests, the technology can determine whether the server in question is handling a mission critical task or simply performing routine backups.
    • Automation: AIOps can be used to handle routine tasks such as backups, server restarts and other low-risk maintenance activities which otherwise involve heavy manual effort.
    • Predictive analytics: A more advanced use case could involve predicting events before they happen – such as detecting when network bandwidth is reaching its limit or storage capacity is nearing threshold.

    Seven KPIs for AIOps

    These common KPIs can measure the impact of AIOps on business processes:

    1. Mean time to detect (MTTD): This KPI refers to how quickly it takes for an issue to be identified. AIOps can help companies drive down MTTD through the use of machine learning to detect patterns, block out noise and identify outages. Amid an avalanche of alerts, ITOps can better understand the importance and scope of an issue, which leads to faster identification of an incident, reduced downtime and better performance of business processes.
    2. Mean time to acknowledge (MTTA): Once an issue has been detected, IT teams need to acknowledge the issue and determine who will address it. AIOps can use machine learning to automate that decision-making process and quickly make sure that the right teams are working on the problem.
    3. Mean time to restore/resolve (MTTR): When a key business process or application goes down, speedy restoration of service is key. ITOps plays an important role in using machine learning to understand if the issue has been seen previously and, based on past experiences, to recommend the most effective way to get the service back up and running.
    4. Service Availability: Often expressed in terms of percentage of uptime over a period of time or outage minutes per period of time, AIOps can help boost service availability through the application of predictive maintenance.
    5. Percentage of automated versus manual resolution: Increasingly, organizations are leveraging intelligent automation to resolve issues without manual intervention. Machine learning systems can be trained to identify patterns, apply solutions, such as previous scripts that were executed to remedy a problem, and take the place of a human operator.
    6. User Reported versus Monitoring Detected: IT operations should be able to detect and remediate a problem before the end user is even aware of it. For example, if application performance or web site performance is slowing down, ITOps should get an alert when the issue can be measured in milliseconds; they can then fix the issue before the slowdown worsens and affects users. AIOps enables the use of dynamic thresholds to ensure that alerts are generated automatically and routed to the correct team for investigation, or automatically remediated when policies dictate.
    7. Time savings and associated cost savings: The use of AIOps, whether it’s to perform automation or more quickly identify and resolve issues, will result in both operator time savings and business time-to-value improvements. These have a direct impact on the bottom line.

    These seven AIOps KPIs can be correlated to business KPIs around user experience, application performance, customer satisfaction, improved e-commerce sales, employee productivity and increased revenue. ITOps teams need the ability to quickly connect the dots between infrastructure and business metrics so that IT is prioritizing spend and effort on real business needs. In the future, as machine learning matures, AIOps tools may even recommend ways to improve business outcomes or provide insights as to why digital programs did or did not succeed.

  • HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy Updates Data Plane API to Simplify Service Discovery

    HAProxy has updated the open source HAProxy Data Plane application programing interface (API) to include service discovery capabilities alongside native support for the Consul service mesh being developed by HashiCorp.

    Version 2.2 of the HAProxy Data Plane API also adds support for file handling, SSL certificates, map files and configuration files for its Stream Processing Offload Engine (SPOE).

    HAProxy is best known for the open source load balancing software of the same name that is widely deployed by DevOps teams. As an extension of that platform, HAProxy Data Plane makes it possible to dynamically add and configure front ends and back ends and then route application traffic between them.

    Daniel Corbett, director of product and marketing for HAProxy, said the HAProxy load balancing software coupled with the Data Plane allows IT organizations to create a gateway through which they can manage their APIs.

    Corbett said the company is currently rounding out a suite of offerings, dubbed HAProxyOne, that are extensions to its load balancing software and that add a control plane and a service mesh to its portfolio. The company has already added a Kubernetes ingress controller to its portfolio.

    At the same time, however, HAProxy Data Plane will make it simpler for DevOps teams to integrate other offerings, such as Consul, within the control plane being developed by HAProxy, Corbett says.

    Corbett said, collectively, HAProxy will provide a suite of tools through which DevOps teams will be able to more easily manage application delivery across IT environments that span multiple platforms.

    HAProxy is not the only load balancing software provider with similar ambitions. The issue that HAProxy will address is the need for a framework that can apply equally well to both monolithic applications and microservices-based applications, Corbett says.

    In 2021, a major battle is brewing for control over the infrastructure that DevOps teams use to deploy applications at scale. Alongside proxy servers and load balancing software, IT organizations are starting to use API gateways, service meshes and ingress controllers as the number of APIs through which data flows rapidly increases. In effect, these technologies provide the connectivity infrastructure required to route data between the applications that make up a distributed computing environment.

    It’s still early days, though, as advocates for competing open source projects make their cases for the hearts and minds of developers. However, given the profound impact these decisions are likely to have on IT operations, it’s likely many organizations will soon standardize on one suite of offerings to minimize complexity.

    Whatever the result, applications environments are, in fact, becoming more complex. IT organizations will soon find themselves running monolithic applications alongside a raft of microservices-based applications, all of which need to use APIs to integrate with each other. Decisions made today about how best to integrate those APIs will have a profound impact for years to come.

  • Rookout Tool now Debugs Third-Party Code

    Rookout Tool now Debugs Third-Party Code

    Rookout revealed today it has extended its eponymous debugging tools to include third-party applications.

    Shahar Fogel, Rookout’s CEO, says most organizations today are building applications that rely heavily on code or modules developed by a third party. Rookout now makes it possible to analyze and debug that code before it is incorporated within a larger application environment, Fogel said.

    That’s crucial, because many of the operational issues a DevOps team is likely to encounter can be traced to flawed code written by someone outside of the IT organization, Fogel said. This new capability will reduce the amount of time DevOps teams spend trying to deduce the root cause of an issue, he said.

    Many IT organizations erroneously assume that all the code running in their environments has passed through a continuous integration/continuous deployment (CI/CD) environment, Fogel said. In reality, it’s not uncommon for developers to deploy code directly into a production environment in the name of expediency. Not all of that code, however, may have been written by the developer. Many developers wrongly assume the code they download from a repository was properly vetted and debugged.

    Rookout now makes it possible to debug both open source code and proprietary code written by a third party or present on an application deployment platform, said Fogel. Rookout collects the local variables, function arguments, tracing data, call stack and other relevant data, and can identify issues down to specific lines of code. Support for third-party code has been extended to the call stack level to enable developers to see how code execution flows across their own and third-party code.

    As more responsibility for applications shifts left toward developers, organizations need to provide them with tools to analyze applications and the platforms they run on. Beside building applications faster, one of the primary theoretical benefits of DevOps is the notion that developers can build more resilient applications, because it’s ultimately their responsibility to remediate any issues that arise after an application is deployed in production. In practice, that’s difficult to achieve when developers have no visibility into code that they didn’t write themselves.

    Going forward, there’s going to be a lot more third-party code running in production, as developers reuse application code encapsulated in containers downloaded directly from registries, Fogel said.

    The degree of accountability developers have for their appliations’ code currently varies widely by organization. However, given the right tools, and enough time, most developers would prefer to debug both the code they write and any they have incorporated, even if it were written by someone else. That desire, however, requires more time to build and test applications. Of course, it’s worth the tradeoff if developers encounter fewer incidents that require developers to debug applications after they are deployed in a production environment.

  • 4 Ways to Scale DevOps in 2021

    4 Ways to Scale DevOps in 2021

    January is a month often dedicated to planning, setting intentions and preparing ourselves professionally and personally for a fresh year. In my own capacity as a DevOps and SRE leader, many of the clients I work with will reinvigorate internal efforts to streamline how they work in Q1.

    I often advise clients to make very concrete goals and milestones for their technology organizations to become more agile, streamlined and modernized. Setting these goals is helpful to articulate to the wider business where you want to go and how you plan to get there. Here are a few DevOps-related initiatives your team may want to tackle in the first half of this year.

    #1: Tighten Security through DevOps

    Securing your organization’s infrastructure is an evergreen priority for technology leaders. When done properly, security should be baked into all DevOps processes (sometimes called DevSecOps) from the design phase all the way to application maintenance. To be effective and not slow down development, security processes need to move at the speed of today’s fast-moving environments, which is near impossible, or, at least very challenging, unless security is well automated.

    Automated security measures can be applied to the full life cycle of product development and should make development time faster and smoother in the long run if you can catch vulnerabilities early. Identify automation tools that work for your team and experiment with what works best.

    Similarly, in fast-moving environments, it’s tempting to play fast and loose with privileged access to unblock individuals and teams. Lax policies for user rights exposes the organization to too much risk from potential hackers. Implement a solution or protocol to keep access controlled. Policy and governance are critical for well-rounded DevSecOps. Communicate policies regularly with the entire organization. Ensure that all engineers know how to comply and enforce them.

    #2: Make DevOps an Organizational Culture

    Much like security, DevOps needs to evolve from an individual role to a cross-functional, holistic, cultural approach to developing software. Organizations should foster a DevOps culture rather than identifying specific individuals in DevOps roles.

    So how do you know when this culture shift has happened? A good pulse check is to see how quickly your company can adapt to change. How mired is your team in legacy code or infrastructure? Can individual teams operate autonomously? Teams and individuals that are independent and accountable are able to continuously experiment and learn at a much faster rate.

    DevOps cultural transformation won’t happen overnight – but it can be expedited if embraced by the entire company. I typically advise companies to focus on making incremental, consistent progress that builds autonomy, trust and transparency. These are the building blocks of a thriving DevOps culture.

    #3: Simplify Your Infrastructure

    Complexity, over time, creates duplication, unnecessary systems and technical debt. All of these have a cost, and create security vulnerabilities. Create organizational goals to clean up and reduce complexity. I often suggest teams create a roadmap to move toward self-service and building platforms. As you focus on building a DevOps organizational culture, you will likely notice that teams will identify opportunities to simplify and standardize, which will also remove complexity.

    #4 Review system SLAs and SLOs

    Establishing and monitoring key metrics are a fundamental part of any SRE role. Service level agreements (SLAs) and service level objectives (SLOs) need to be defined and monitored to ensure your team is fulfilling them. System availability (uptime, latency, etc) is core to any cloud SRE team. Define what reliability means for your organization. January is a good time of year to start fresh and articulate these metrics, how they relate to your core business and what investments or changes need to be made to achieve them.