devopsy.kinsta.cloud

Category: DevOps Practice

  • 3 Steps to Jumpstart Your App Modernization Journey

    3 Steps to Jumpstart Your App Modernization Journey

    Like organizing your garage, modernizing your applications can seem daunting before you start, but you know it will pay off once done. So, instead of thinking about this project as a technical challenge, let’s look at it in the wider context of the business. Just as getting rid of old junk in your garage frees up the space you need for things you actually use, modernizing your apps helps your business run more efficiently and scale more easily. Based on my experience with many application modernization projects, here’s how developers can best approach app modernization, including what you’ll need from your team and technology, six key ways to tackle the task and how to prioritize.

    Start With a Business Assessment

    Before you can make any changes to your applications themselves, you need to lay out a plan based on your company’s needs. That means assessing every application in your portfolio, not just as individual properties but in the way they interconnect.

    Like most developers and engineers, when you have a technical background, it’s tempting to build a strategy around the most exciting technical opportunities. But the purpose of all the applications your company uses is to enhance the business. For example, your organization is likely considering an app modernization initiative to better serve customers and clients; to increase revenue or cut costs.

    That means when you approach modernization from a business perspective, you should prioritize apps based on business value. Large modernization projects can get complicated, so you won’t necessarily be able to complete this process for every app.

    When it comes to large-scale, complex applications, the effort required to modernize every piece is significant. So, it’s important to decide what applications are of the highest value and plan your modernization efforts starting there.

    There are several business-focused questions to consider, such as:

    • What are the business’ needs now and in the future?
    • Which problems are we trying to solve as an organization and as a department?
    • What capabilities does the business need to add in order to grow?
    • What does the business need to do to better support customers?

    Smaller organizations may be able to modernize every app and component. But if you’re in a large business or an enterprise, you will have to choose the apps and components that are most critical to the business goals. Of course, if you’re successful with the first crop of applications, it’s more likely you’ll get the go-ahead to move on to other apps and components.

    It’s important to stress how important this kind of assessment and planning process is. You need to get that business buy-in for that ultimate alignment and for delivering the most value for your business in the shortest amount of time.

    Choose Your Application Modernization Program

    Different applications require different modernization approaches, some of which are more labor-intensive than others. Here are six methods (the six Rs) used to modernize an app and how to assess which one is right in each case:

    • Retain: If an application is working as well as it possibly can in its current environment, leave it alone. This is rare, but it does happen.
    • Rehost: In the case of apps that already work well, you’re more likely to want to move them to a new platform than leave them completely untouched.
    • Retire: If an app no longer serves a useful purpose, is outdated or runs on technology that no longer exists, retire it.
    • Repurchase: Switching apps from perpetual licenses to software-as-a-service (SaaS), subscription-style models means less hardware maintenance, easier access to updates and cloud storage for all users.
    • Replatform: Transfer an app from a hardware-based option to the cloud, with a few small changes.
    • Refactor: The most work-intensive option—and the most interesting! This is the coding equivalent of a movie remake, in which you update the code to improve performance, availability, security and more.

    Follow App Modernization Best Practices

    All right. You’ve got leadership buy-in and you’ve categorized all your business’ apps according to the six Rs we mentioned above. Now, the real work begins. There are app modernization best practices to follow as you continue on this journey. Most importantly, remember that the effectiveness of your modernization efforts comes down to two key components: Your team and your tech. Here’s what you need from both for a successful mission.

    Deploy the Most Advanced Technology

    The underlying purpose of application modernization is to bring your apps up-to-date with the latest cloud technology. For the best results, you need to use the best available tech. There are a few elements of modern cloud technology you should consider. Serverless infrastructure is one. With serverless, you can make large-scale changes in real-time without having to maintain servers.

    Data management is another area where you should employ cutting-edge tech. You can use purpose-built databases that best suit different types of data for faster and more efficient processes.

    Autoscaling is also a key benefit of moving to the cloud. Be sure to factor in the need to scale from the start of your modernization project to avoid bottlenecks further down the line.

    Hire an Agile Team

    The most advanced tools in the world are useless if the people using them aren’t sufficiently trained or skilled. When hiring a team, look for agility. Application modernization processes are a lot of work. You need a team that moves quickly in order to hit your deadlines.

    Culture and responsibility, as well as ownership are also important. A demanding work environment requires open communication and people who will take responsibility for their part in the system. Consistency is another crucial factor. Involve the people who will be responsible for managing the apps from the start of the modernization process. This makes it easier for them to continue the work once the app is ready.

    Summary

    Getting the most out of your application modernization project requires the right tools, personnel and services. And while taking your first steps into the cloud can seem intimidating, by following tried-and-true best practices, you can stay on the right path toward a big payoff in the cloud.

  • What We Don’t Know is Dangerous

    What We Don’t Know is Dangerous

    Pop quiz: How many database management systems (be they RDBMS or NoSQL or even flat file) do you have running in your overall organization? Not actual databases, but management systems?

    How many containers do you have that are exposed to the internet, directly or indirectly? Not container management systems, because you’re only running a couple of those and they’re all relatively new, but actual containers?

    The questions could go on and on. Not too long ago, because there was an identifiable cost associated with it, cloud inventory management became a popular thing – finding and removing cloud instances, services and storage that were no longer necessary became a part of normal operations for organizations that had even a mid-sized cloud presence.

    But now, we have sprawl all over the place. So let’s extend inventory management to all software, and get rid of what isn’t needed on a regular basis … because it does indeed build up quickly.

    Yes, there are a few companies out there trying to do just this, and I encourage you to check them out. I have not, because our inventory at Ingrained Tech is manageable without that level of overhead. Our development and ops time is limited, so we keep a tight rein on what is out there and the maintenance it requires.

    But for larger organizations, the more you have out there, the larger attack surface and potential data sieves you have in place. So make sure if it isn’t needed, it’s gone. In the age of containers, this actually requires a fair amount of investigation; first, a list of all containers part of an ongoing project (and in even a mid-sized company, “They’re all together for each app,” won’t create this list because random containers are out there, too). And then a list of all containers not associated with a known project that can be gone through and usage determined.

    It’s not glamorous. It’s a bit of a slog. It’s in the organization’s best interests, though, and the slog should motivate your teams to put a policy in place to manage container life cycles. Like notes in Docker files that say when the container is no longer needed, or what it is needed for, so future you can easily get rid of it without stress.

    If you are in a containerized environment, this problem is growing almost by the day. Seriously. On our last project, we had 12 active containers before we pared it down to the five we needed long-term. The others were R&D along the way or tools we were using before focusing on a different method of achieving the same goals. Since we’re a small team, we just cleaned up when the project was coming into focus, but a larger org needs to be more focused on cleaning things up as they go.

    Meanwhile, those assets are letting customers get to your org, and allowing employees to manage the systems. Keep rocking it, and just remember to pick up, particularly after cutting-edge new projects, but also occasionally as just a normal cleanup step.

  • Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    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: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

  • GitLab Allies With Rezilion to Add Workload Analysis Tool

    GitLab Allies With Rezilion to Add Workload Analysis Tool

    Rezilion has integrated its workload analysis tool with the continuous integration (CI) framework provided by GitLab. The move is part of an effort to make it simpler for developers to discover issues such as vulnerabilities before they upload code into a repository.

    Sam White, a senior product manager for GitLab, said this integration will provide developers with an instant feedback loop that will enable them to address a wide range of issues before their code is ever reviewed. Rather than experiencing the shame of, for example, missing a vulnerability, the Rezilion platform enables developers to quickly write code while relying on a code analytics tool to surface common mistakes that they can remediate as they see fit, he added.

    Rezilion CEO Liran Tancman added that the proprietary workload composition analysis engine, dubbed Unison, on which the Rezilion platform is based makes it feasible to shift more responsibility for application security further left without requiring developers to become cybersecurity experts.

    Unison automatically creates a model of all the applications that include the underlying infrastructure and runtime environments. It reverse-engineers and maps that environment in memory to dynamically track the inventory, provenance, runtime execution, exposure and interdependencies between each piece of code and can generate a software bill of materials (SBOM).

    The code that is most in need of immediate attention is also surfaced directly with the GitLab user interface, said Tancman. That capability can reduce remediation time of the vulnerability backlog an organization might be working through by as much as 70% over time, he added. Rezilion enables organizations to achieve that goal because non-exploitable vulnerabilities are marked as “false positives” that shouldn’t hold back a release.

    Tancman said that without this level of automation it would be extremely challenging for an organization to implement a set of DevSecOps best practices. It might take developers years to attain the level of cybersecurity training that would be required in the absence of the automation enabled by the Unison engine, he noted.

    Historically, the relationship between application developers and cybersecurity teams has been tense. Cybersecurity teams tend to put off code review until it’s about to be deployed in a production environment. It’s not uncommon for an application to be pulled at the last minute because of a vulnerability discovered by a cybersecurity team. In some instances, that vulnerability is a legitimate concern but in others, it turns out to be a false positive because the flagged piece of code isn’t actually included in the application.

    By providing developers with a workload composition analysis tool within the context of a CI framework, GitLab is trying to reduce the level of friction that the process tends to create between developers and cybersecurity teams.

    It may be some time before most organizations fully master DevSecOps, but it’s clear that merely telling developers they will be held accountable for application security without providing the appropriate tools isn’t going to make applications any more secure.

  • Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software has added support for the IBM I platform as part of its relaunch of a DevOps platform that also runs on IBM mainframes.

    Chris Wey, president of the data modernization business unit at Rocket Software, said the Rocket DevOps continuous integration/continuous delivery (CI/CD) platform will make it possible for organizations that employ both IBM I midrange platforms and mainframes to modernize application development and deployment using a common framework.

    Modernization of application development on mainframes has been occurring for some time. A survey of more than 500 U.S. IT professionals conducted by Rocket Software found 44% of respondents employ multiple DevOps tools, but slightly less than a quarter (24%) have a comprehensive DevOps platform in place.

    Rocket Software is expanding its DevOps reach to include the IBM I platform because organizations that rely on this platform have the same pressing need as other organizations to more quickly build applications, said Wey.

    It’s not clear to what degree organizations are still building new applications for what have become venerable IBM platforms. A Rocket Software survey found that while 82% of respondents are migrating workloads to the cloud, only 4% reported they are migrating completely to the cloud. The bulk of most mission-critical applications running on mainframes are online transaction processing (OLTP) applications that require a level of processing capability that still can’t be easily matched using any other platform. There are plenty of instances where certain classes of workloads have been migrated off the mainframe to run on lower-cost platforms. However, there are still many enterprise applications that continue to run faster on mainframes than they could on any other platform.

    In most cases, Wey noted, organizations will be deploying and updating applications across hybrid cloud computing environments for years to come. The immediate challenge they face is a lack of DevOps skills among the IT teams that manage IBM I systems and mainframes, he added.

    Rocket Software also provides access to a set of application development tools for building modern applications on IBM platforms. Most recently, the company added support for an open source Python software development (SDK) that IBM created for the Python programming language to the Rocket Open AppDev for Z framework for building mainframe applications.

    The overarching goal is to make IBM platforms more accessible to a wider range of application developers and DevOps professionals that today mainly work on distributed computing platforms, noted Wey.

    One way or another, the divide that has existed between legacy platforms and distributed computing systems is continuing to narrow. Many organizations are trying to lower the total cost of IT by centralizing management of both these classes of systems versus continuing to hire and retain separate IT teams.

    The IBM I platform traces its lineage back to AS/400 systems that were first launched in 1988 as an integrated midrange minicomputer rival to VAX/VMS systems from Digital Equipment Corporation (DEC). Fast-forward more than 30 years later and there still are many IBM I platforms running long after VAX/VMS systems have all but disappeared.

  • Bringing Development Environments Into the Modern Age

    Bringing Development Environments Into the Modern Age

    It’s time to rethink how we deliver distributed access to software development environments.

    We know how to write code. And there are plenty of well-established tools, techniques and processes for doing so.

    We know what kind of code to write: Functional, scalable and efficient code that’s inherently secure and that we can readily modify whenever and however we need to modify it.

    We know why we write code. We write it to enhance the value we offer customers, to expand our market reach, outperform the competition, cut costs, minimize risks and otherwise engage in what we call “digital transformation.”

    We know who writes code—or, more accurately, the various “whos” who write it. We need developers with a diverse range of skills. And as our needs keep changing, we keep adjusting the mix of in-house and contract developers accordingly.

    We also know when to write code—which is now and for the foreseeable future.

    The one thing we still struggle with is where to write code. Not ‘where’ in the physical sense; we’re way past that. We know that for development teams to be optimally productive, we have to enable everyone to work from any physical location at any time. COVID-19 has dramatically reinforced this principle.

    The ‘where’ we struggle with is the virtual ‘where’ of the developer workspace. Yes, we already provide developers with remote access to development resources. Sort of. But there are a lot—a lot—of problems with the way we do that. These problems adversely impact development every day by, among other things,

    • Bogging developers down in annoying technical problems that hamper their ability to set up their environments.
    • Forcing developers to wrestle with the maddening complexity of configuring and managing the multiple dependencies associated with each project.
    • Trapping developers in an endless cycle of building, terminating and recreating environments as projects begin, end and are resurrected for updates and enhancements.

    Unfortunately, we’ve become so accustomed to these problems that we tend to accept them as normal. But we cannot afford to accept them any longer. Here’s why.

    Development Environments: Insecurity, Lost Productivity and Technical Debt

    One big problem for both developers and the enterprise is that developer workspaces aren’t fully portable. The methods we use to give developers remote access to their environments invariably come with unacceptable insecurity. There’s also the issue of onboarding. When a developer joins a team—whether as a new hire, temporary contractor or current employee switching to another project—it can take days for them to get them fully up to speed with access to all the project-specific resources they need. That ramp-up time invariably frustrates developers.

    On the other hand, offboarding developers can be a security and compliance issue. Piecemeal provisioning of the multiple resources developers need inherently results in the piecemeal deactivation of those same resources. So when a developer quits or is fired—or when a contractor’s contract is up—we can’t be 100% certain that all their permissions have been revoked.

    Moreover, what happens when a developer needs to go back into a project that no one has touched in months or even years? How does a developer recreate the full workspace associated with that project and have high confidence that they’re doing it right?

    The answer is that we can’t. Instead, some unfortunate developer inevitably has to spin their wheels trying to piece together a long-dormant project. All your aging code is thus guaranteed to become “legacy” (which is just another name for ‘code no one is quite sure how to work on’), thereby guaranteeing that your organization will forever be burdened with an ever-growing mountain of resource-draining technical debt.

    The Shoemaker’s Children

    So how can we re-engineer the delivery of remote workspaces so we make life easier for developers while also fulfilling the security and compliance requirements of the enterprise?

    Here are a few ideas to consider:

    • Host developer workspaces in the cloud. Developers provide everybody else with a wealth of cloud resources, yet rarely take full advantage of the cloud themselves. Some resources they need may reside in the cloud, but the complete workspaces they require to be fully productive do not.
    • But why not? Everything a developer needs for every project should exist as a complete, unified, project-specific workspace that’s available to them anywhere—just like all the other SaaS solutions developers build for end-users every day.
    • And given the sophistication of today’s browsers, cloud-based workspaces can be made available to developers without requiring them to install a desktop client. The cloud also enables workspaces to be hosted anywhere to avoid latency delays.
    • Nothing should leave your secure workspace repository. Ever. To ensure the security of all developer work-product, no actual code or data should ever leave the hosting environment.
    • Only screen pixels and keystrokes should move across the network. This remote-access model makes developers’ workspaces fully secure and fully portable. It also provides the best protection against data exfiltration.
    • Simplify the definition and administration of project-specific workspaces. You don’t want developers looking around for tasks in progress, relevant datasets or process workflows. Instead, administrators should be able to configure workspaces that give developers access to all the resources they need for each project via a single sign-on (SSO).
    • Leverage containerization into your workspace hosting. Better, safer enterprise development isn’t just about re-engineering remote workspace access. It’s also about making those workspaces easier to manage on the back end. The best way to do this is containerization, which allows you to flexibly mix-and-match workspace elements. That way, you don’t have to build every workspace from scratch.

    And those workspaces don’t exist as monolithic, “all or nothing” environments that you pray you’ve gotten right. Instead, with containerization, you can build project-specific workspaces more quickly, at less cost and with less risk.

    Effective hosting of fully portable developer workspaces requires other important functionality as well: Inactivity time-outs, cloud cost/utilization controls, etc. Before addressing these details, however, development leaders must first come to terms with the fact that developers need a much better way to work remotely—and that every remote workspace must be a secure one.

  • What Donuts Teach Us About DevOps and Delivery Risk

    What Donuts Teach Us About DevOps and Delivery Risk

    Today, most DevOps teams do not think too much about their approach to risk. Usually, the typical attitude focuses on what to add to reduce risk further. In other words, “Can we add more tests? Can we deploy more carefully?” More tests, more processes and less risk are all obviously good things. Or are they?

    As a programmer, I’ve seen a lot of projects where there are so many tests and so many processes that they actually become counterproductive. Those ‘overheads’ presumably do reduce risk, but nobody knows by how much. I call this attitude ‘blind risk avoidance.’ This line of avoidant thinking usually builds up over time as we react to failures. It’s a very natural reaction.

    But when risk avoidance becomes your standard modus operandi, your delivery cycle gets slower and slower over time. Your team starts to feel they are trapped in molasses but, as time goes on, they not only gradually train themselves to tolerate this but to actively justify that it’s a good thing. In the meantime, nobody pays attention to the fact that your software is losing a competitive edge and that you’re being out-innovated and out-executed by others. Nobody pays enough attention to engineering team attrition; losing people as they drop off, one-by-one to move to more modern software development teams with less baggage. The ultimate conundrum lies here: If you move too fast, you break things. But if you move too slowly, your business and your team are doomed.

    So what is the optimal approach for DevOps teams to take when it comes to risk? The truth is, neither extreme is desirable. Blind risk avoidance leads to a failure of value delivery. On the other hand, blindly ignoring risk means crashing and burning.

    The ideal balance lies in not avoiding risk entirely or ignoring the reality of risk. Instead, a sensible middle ground can be found in taming risk.

    Moving forward, DevOps teams and developers must focus on taming risk to deliver software confidently with data-driven actions, speed and quality. 

    Automation Can Reduce Operational Overhead

    Taming risk should become a larger part of DevOps culture. One of the most famous ways this approach has been adopted is by Google’s site reliability engineering (SRE) team. 

    Google’s SRE team embraces two key principles when it comes to taming risk: Automation for reduced operational overhead and structured and rational decision-making for better, data-driven choices.

    To explore this mindset of risk-taming at Google, let’s dive into how the SREs use automation to slash waste, save time and reduce repetitious, low-value tasks and tests. 

    At Google, SREs are software engineers with an extremely low tolerance for repetitive, reactive work. (Aren’t we all?) But here’s the difference at Google: Thanks to a workplace culture of taming risk, operations that do not add value to a service are avoided or automated away.

    The vast majority of DevOps teams hold the same beliefs as Google: That automation cuts down on waste and saves everyone time.

    We all know automation allows for lower operational overhead, frees up software engineers to proactively assess and improve the services they support and boosts team morale. No one wants to spend their time or energy on repetitive, low-value tasks. Automation frees up DevOps teams to expend their energy on what matters most: Continuous quality.

    Bottom line? Automation is integral to the idea of taming risk. Automation of repetitive, low-value tasks is the perfect way to embrace a mindset of taming, not avoiding or ignoring risk entirely.

    Data-Driven Decisions

    Another way that Google’s SRE team tames risk is through structured and rational decision-making based on data. 

    Data-driven decisions are crucial to the success of any software engineering team, project or mission. Without proper data and feedback, there’s no way for software engineers to make the best, most calculated decisions and mitigate risks. 

    A data-driven decision methodology can—and should—be applied to DevOps testing cycles. 

    Another key aspect of data-driven decisions that speaks directly to the concept of taming risk? Service level objectives (SLOs).

    A service level objective is an element of a service level agreement that measures the performance of the service provider. SLOs are created (and agreed upon) between the service provider and the customer and help to mitigate disputes between providers and customers.

    Now, let’s take the concept of SLOs and apply them to engineering and QA teams.

    In traditional organizations, engineering and QA are forced to interact intentionally with a healthy amount of tension. One team produces software and the other team tears this software down. While this kind of necessary and healthy conflict between teams can lead to better results, the inherent push and pull between engineering and QA can create an excess of interorganizational infighting.

    Engineering teams will always advocate for more velocity or blind ignorance of risk, above all else. On the flip side, QA will always advocate for quality, or blind avoidance of risk, above all else.

    Of course, neither side is entirely correct (nor incorrect).

    Instead, the solution to this tension lies somewhere in the middle: The taming of risk, not ignorance or avoidance of risk. This is where an SLO, or the numeric target that represents ‘somewhere in the middle,’ comes into play. For engineering teams focused on velocity and QA teams focused on quality, creating an SLO—a happy medium to work toward with regard to risk—will create a more balanced workplace culture. In short, this approach can be considered a taming of risk.

    ‘Donut’ Slow Velocity

    Now, we’re finally going to get to the donuts. To demonstrate how embracing a mindset of taming, not avoiding, risk can create better, happier and faster DevOps teams, let’s take a look at Krispy Kreme Donuts.

    Krispy Kreme churns out millions of delicious, hot, glazed donuts every single day. However, during production, it’s inevitable that one or more of those donuts will be flawed. (I know, you’re asking, “Is there really such a thing as a flawed donut?!” For the purposes of this analogy, let’s say yes, there is.)

    One common donut defect occurs when the donuts bunch up on the production line and clog it.  Now, let’s assume this common error is caused by the speed of the line. If the Krispy Kreme team attempts to solve this problem by pushing the line even faster, tolerance gets smaller and the risk of even more smashed, defective donuts only rises. That’s certainly not a solution to this issue.

    On the other hand, if the Krispy Kreme team slows down the donut production line speed, there will be a smoother—albeit slower—operation.

    Is Krispy Kreme better served by slowing down its entire production line and sacrificing its velocity to eliminate the risk of a potential defective donut? Of course not! 

    If that’s not true, then is Krispy Kreme better served by cranking up their production line speed to go as fast as possible, regardless of the risk of defective donuts? Again, of course not!

    For sweet success, Krispy Kreme must embrace a mindset of taming risk. By baking careful measurement and an iterative feedback loop into their donut production process, Krispy Kreme is better able to create delicious, high-quality donuts at an optimal speed, producing some flawed donuts. This balance of speed with quality creates the best economic outcome and the mindset and measurement allow for a constant evolution to risk-taming in the future. As the production line changes, the optimal speed also needs to evolve.

    DevOps teams should take this same approach. Tame the risk without sacrificing speed and quality. ‘Donut’ slow velocity to fix a few minor issues!

    If you’re still not convinced, here’s another way to think about taming risk that is decidedly less delicious than warm, glazed donuts: Taxes. 

    The IRS balances velocity and accuracy during tax season as they process millions of tax reviews. While suspect returns are flagged for audits, the IRS simply cannot catch every single flawed tax return. It’s not economical or even possible to run detailed audits on every single problematic tax return, every single year.

    So, instead, the IRS tames its risk with automation and data-driven decisions. The IRS focuses on creating and using methods to detect patterns that correlate with flawed tax returns. Then, once these data-driven problem returns are detected by automation, experts can devote their precious time and mental energy to tackle the biggest of the problematic returns. 

    Again, this approach to taming risk creates an inherent balance between quality and speed and allows for an evolution of the process as economic activities and laws evolve.

    Whether you love eating donuts or doing your taxes, the bottom line is clear. Most organizations need to balance potential risks with maintaining speed, quality and team morale. DevOps teams are no different. 

    How to Tame Risk in DevOps Teams

    So how can we, as DevOps teams, tame the risk?

    The basic idea here is to do smarter testing, not just more testing. The good news is that if you have a reasonable level of automation, the data coming out of your existing automation can make your testing smarter. Approaches like predictive test selection can let you spend your computer hours more meaningfully, allowing you to improve speed and quality at the same time. Approaches like flaky test insights can let your precious engineering resources focus on the most impactful effort to improve the quality of tests.

    The Power of Taming Risk

    What is the right balance between speed and quality? This is the constant question DevOps teams face. But, here’s how I answer this riddle: Taking calculated risk is the most logical and rational approach in the workplace.

    It’s easy to avoid risk. Anyone can skirt around potential pitfalls by avoiding new solutions and sticking to the same old methodologies. But it’s so much more satisfying to take a calculated risk rather than ignore or avoid the risk outright. 

    If you want to improve the velocity and the happiness of your DevOps team, it’s time to embrace a new mindset: Tame the risk, gain control.

  • Why Your Business Needs DevOps

    Why Your Business Needs DevOps

    One of the biggest headaches IT leaders face today is managing cross-functional teams to develop and deploy high-quality software faster. Not only does their work have to be continuous to stay productive, but there’s the need to save the business money, time and improve end user and customer satisfaction while fixing a seemingly endless parade of bugs.

    Without a robust DevOps process in place that benefits the entire organization, IT management and tech leaders often feel like they are chasing the impossible.   

    What is DevOps?

    DevOps is a set of practices that help you plan how both development (Dev) and operations (Ops) teams can work cohesively to deliver your company’s products and services, meet customer needs and stay ahead of your competitors. In short, it is a set of tools that leverages people, processes and technology to enable safer, faster handling of any IT software delivery initiative.  

    Yet, according to Gartner, as of the beginning of 2022, 75% of DevOps initiatives have not met these expectations because of inefficient collaboration, lack of buy-in from employees, trying to do too much too quickly and unrealistic expectations. For a methodology that is so critical to businesses today, it’s still surrounded by uncertainty and doubt. Let’s look at how you can make DevOps work for you and why it’s so important that you do so.

    Addressing Bugs

    Because detecting and addressing software bugs is a major priority of any IT department, disruptions need to be handled quickly and efficiently. This can only be done through immediate action and a tried-and-testing workflow in which all departments involved can act fast. The beauty of DevOps is that the process can be continuous rather than reactive and thus improve the quality of your software when deploying new features, as DevOps allows you to make changes rapidly. 

    Without DevOps, productivity is slowed or even brought to a halt which leads to an often-damaging customer experience.  

     Improving Customer Satisfaction

    A significant benefit of adopting DevOps practices is that it lowers the failure rate of new features while improving recovery time. The continuous deployment, testing and feedback loops ensure faster service delivery and happier customers. The development team can focus on creating superior products by automating the software pipeline while the operations team can improve business delivery. 

    Faster delivery of your products and services should not be a pipe dream. Those who understand and implement DevOps should feel confident they can stay ahead of the competition. 

    Improving the Security of Your Software

    DevSecOps builds on the DevOps pipeline to integrate security from the very beginning of the development cycle rather than at the deployment stage when flaws and vulnerabilities are more difficult and costlier to fix. Combining development, security and operations across your products and services will improve quality, security and your ability to meet client expectations. Building security into your pipeline seamlessly means bugs and other issues can be addressed more easily and remain almost unnoticed to the end users.

    DevOps and DevSecOps make this possible so that outdated security practices are not integrated into your software and don’t interfere with customer demand. So, if increasing customer satisfaction and positively impacting your bottom line by delivering high-quality, secure and effective software is on your business priority list, then implementing a DevOps process can not only save IT headaches but deliver better business outcomes.

  • How DevOps is Revolutionizing Embedded Development

    How DevOps is Revolutionizing Embedded Development

    There’s something curious happening on the desktops of embedded developers around the world. From home offices to cubes to labs, in lamp-lit rooms late at night and sun-lit rooms early in the morning, developers are doing something different. They’re beginning to implement DevOps practices in their embedded development.

    Something quite serendipitous has occurred to make this possible: The parallel rise of cloud-native computing and the explosion of internet of things (IoT) devices and edge technologies. A world with billions of embedded devices connected to the internet all the time, every minute of every day, requires a new way of designing, testing, deploying and maintaining these devices. At the same time, cloud-native computing has introduced continuous delivery (CD) and continuous integration (CI), among other methods, to enable automated software builds that are reproducible. This is creating a revolution in the embedded world.

    Until now, embedded software was written and deployed and then remained static in perpetuity because it was isolated. Not anymore.

    The Slog, Security Demand New Thinking

    Embedded software developers have traditionally faced a monumental slog to build projects. Typically, embedded developers have had to build an entire platform to build new software, including the kernel, the distribution and more. And all of that software would need to get (re)built anew every single time something changed. Everything had to be checked in. Everything had to be rolled out. There was a version control infrastructure team, a CI team, a QA team—and they all had to work together and be aligned to meet the production schedule.

    This approach to developing was incredibly slow, costly and clumsy and in no way architected for today’s world of connected devices, IoT and the edge. Consumer product makers (home appliances, for example) simply don’t have the resources to provide frequent updates. Additionally, consumers are not used to frequent updates on consumer devices that are not their phones or laptops. With the rise of modern applications, it is just no longer acceptable to build static software that is never changed or updated.

    With billions of devices connected to an always-on network, large-scale security vulnerabilities have never been a bigger concern or consideration among companies that have millions of nodes on a network. Today, companies need to be continuously connected to all of their nodes and devices to properly maintain and secure them.

    Enter DevOps and Embedded Innovation

    DevOps has already transformed the way cloud-native applications are developed. Software gets built often, but it also gets deployed often. That’s why web apps are constantly being upgraded. Now, embedded is poised to take advantage of this software version control system that automates software builds and that is reproducible. Bringing DevOps to the embedded software ecosystem is about providing a set of tools or a platform that does the version control, CI and CD all in a single package—a platform to simplify the workflows for companies that typically have to build all of this themselves now can deliver opportunities for tremendous efficiencies and innovation.

    Consider the airline industry as it was 60+ years ago. At that time, the airlines built their own planes from start to finish. Today, Boeing and Airbus build all airlines’ planes. Of course, each airline can customize their fleet from the overall flying experience to the interior branding, but everybody is leveraging the same core technology because airframes are really hard to build and the differentiation happens on top of that foundation.

    Similarly, embedded software developers can focus on the customization of their product, not the time-consuming build that provides no differentiation. This is the concept behind the cultural shift we see in embedded software: Buy the airframe and customize it rather than build it yourself. Also inherent in the DevOps model is a distributed development practice, where different team members in different roles can be anywhere in the world and still work together seamlessly.

    The pandemic certainly created more demand for this model, but distributed teams aren’t going away and are more prevalent than ever in technology development. Many embedded software developers are still working in the same way they were in the 1980s and 1990s. With DevOps practices and platforms in place today, embedded software developers can focus on the value-add of their application. By taking all the complexity out of building it yourself, companies today can simply leverage easily consumable and reusable tools to achieve what cloud developers have been doing for years.

  • Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness Acquires ChaosNative to Meld Chaos Engineering, DevOps

    Harness this week announced it acquired ChaosNative as part of a plan to more deeply integrate chaos engineering with DevOps workflows.

    At the same time, the company added a Harness Service Reliability Management (SRM) and Harness Security Testing Orchestration capability to its continuous integration/continuous delivery (CI/CD) platform.

    Chaos engineering, as a discipline, refers to experiments on a software system that test its resiliency in the face of an unplanned outage. The goal is to deliberately make resources unavailable to see how the application environment either adjusts or whether it fails.

    ChaosNative’s LitmusChaos platform, which manages these chaos engineering tasks, was donated to the Cloud Native Computing Foundation earlier this year.

    Scott Sanchez, chief marketing officer for Harness. said the company plans to shift chaos engineering further left as part of an effort to enable developers to test the resiliency of their applications before they are deployed in a production environment.

    It’s still early days where adoption of chaos engineering within DevOps workflows is concerned. Many IT leaders’ performance is measured based on the stability of application environments. The idea that they should deliberately break something as part of an effort to make an application more resilient requires a shift in mindset, noted Sanchez.

    However, once IT leaders start to appreciate how chaos engineering actually improves the availability of applications it’s only a matter of time before the practice becomes more widely implemented, he added.

    In the meantime, Harness is looking to automate more of the lower-level tasks that today’s DevOps teams often manually manage. Harness SRM enables DevOps teams to automatically track service level objectives (SLOs) that are attached to specific pipelines within the Harness CI/CD platform.

    The Harness STO module, meanwhile, makes it simpler to orchestrate security testing across multiple pipelines.

    In general, there is now more focus on the productivity of DevOps teams as the number of applications that are being built simultaneously increases. The challenge, however, is not just the number of applications but also the dependencies that exist between them.

    Harness is making a case for a CI/CD platform that automates DevOps tasks by employing, for example, machine learning algorithms to identify which applications are most likely to fail before a build is completed. The goal is to reduce the amount of time DevOps teams waste waiting for builds to complete only to discover that the application almost immediately failed.

    The time, effort and cost of maintaining a DevOps platform will naturally vary as the overall environment becomes more complex. However, as DevOps processes become more automated, the platforms themselves become more accessible to a wider range of organizations. Today, the effort required by a DevOps to set up and then support a CI/CD environment is often considerable.

    Nevertheless, as more organizations rely on custom applications to drive digital business processes, it’s only a question of when and to what degree DevOps best practices will be more widely adopted. After all, the total cost of application downtime is only going to rise in the age of digital transformation.