devopsy.kinsta.cloud

Category: DevOps Practice

  • HashiCorp Releases Slew of Updates to Improve DevSecOps

    HashiCorp Releases Slew of Updates to Improve DevSecOps

    At a HashiDays event this week, HashiCorp launched updates to its Terraform implementation and a software-as-a-service offering, dubbed HCP Vault Secrets, that promise to simplify infrastructure security and ensure that secrets are not leaked.

    In addition, HashiCorp has added a self-hosted edition of its remote access security tool, Boundary, that can now also record SSH sessions. The company is also announcing general availability of Vault Secrets Operator, which provides a high level of abstraction for managing secrets in a Kubernetes environment and which synchronizes with the secrets management interfaces defined by the Kubernetes Technical Oversight Committee.

    Finally, HashiCorp is making available in beta a 1.16 update to the Consul service mesh for containers and virtual machines that adds a Sameness Groups capability to improve the resiliency of microservices by redirecting requests to an identical service. HashiCorp has also added a transparent proxy mode to enable failover between services along with a permissive mutual TLS (mTLS) that enables a service to be configured to accept both mTLS traffic from mesh-enabled services and non-Consul mTLS traffic from external downstream applications.

    Chris Van Wesep, senior director of product marketing for HashiCorp, said Version 1.5 of HashiCorp Terraform adds config-driven import workflow and check blocks capabilities that make it possible to declaratively use code to add existing resources into a Terraform state. Previously, the only way to update a Terraform state was to use an import command that could only be applied to one resource at a time. Terraform 1.5 also adds automatic code-generation capabilities for imported resources.

    In addition, version 1.5 of Terraform also includes a tool to validate that provisioned infrastructure is behaving as intended. That latter capability makes it possible to reduce the number of misconfigurations created by developers that might one day be exploited by cybercriminals to breach an IT environment.

    HCP Vault Secrets, meanwhile, provides a beta release of a SaaS edition of the existing Vault offering specifically designed to enable organizations to better manage application secrets that might inadvertently be exposed to cybercriminals in a production environment, said Van Wesep.

    HashiCorp is moving toward providing a portfolio of tools that enable DevOps teams to securely provision and manage hybrid cloud computing environments using a common workflow, he noted. A Forrester Consulting survey found nearly three-quarters (73%) of respondents are reporting this strategy is helping them reach their business goals, with another 19% adding they expected this strategy to help them achieve their business goals in the next year.

    It’s not clear whether organizations are fully embracing multi-cloud computing, but each additional cloud added to an enterprise IT environment increases the total cost of IT. The only way to mitigate those costs is to define a set of best practices for building and deploying applications that can be applied to any cloud computing environment.

    Unfortunately, many organizations will discover that, as they attempt to define those best practices, they have inadvertently become dependent on a set of proprietary application programming interfaces (APIs) that thwart those efforts.

  • Avoiding the Pain of a ‘Resume-Driven Architecture’

    Avoiding the Pain of a ‘Resume-Driven Architecture’

    Successful new technologies follow a predictable arc, from initial innovation to technical gold rush and, ultimately, to mass market adoption. As a consequence, they achieve strong standardization and productization. Being highly attuned to where a specific field lies on the maturity arc is how you yield the greatest benefits to a business. But what happens if your developers are not thinking about this, too? You end up with what I call a “resume-driven architecture,” and it can be highly costly to your business.

    A resume-driven architecture occurs when the interests of developers lead them to designs that no longer align with maximized impacts and outcomes for the organization. Often, the developer clings to a technology that provides them a greater level of control and, at least initially, a higher salary. Meanwhile, the organization gets an architecture that only a handful of people know how to manage and maintain, limiting the available talent pool and hindering future innovation.

    To understand why this happens and how to avoid it, it’s helpful to look at this technology arc in more detail. It’s a pattern that has played out up and down the stack, with technologies like big data platforms (now dominated by Snowflake and Databricks), Kubernetes and even the broader move to the cloud. Failing to grasp this concept of a resume-driven architecture can increase costs and hold back innovation.

    Here’s how this technology arc typically plays out, using Apache Spark as an example:

    • Stage One: A technology breakthrough like Spark emerges, providing a significant advantage to early movers.
    • Stage Two: Other companies see the benefits, and the technology receives widespread interest. Specialists are in high demand and command big salaries. Many adjacent professions naturally invest in becoming Spark experts.
    • Stage Three: The technology matures and reaches a level of standardization with an ecosystem of tools and services around it. Specialized knowledge, such as how to tune your Spark job parameters, becomes less valuable.
    • Stage Four: Mass convergence, productization and simplification occurs. As examples, Databricks becomes the primary Spark vendor and launches SQL warehouses for easier data processing. Snowflake launches Snowpark for Python as a simpler model than classic PySpark jobs. Nobody worries about tuning most parameters anymore as the underlying technology becomes part of the stack: Powerful but almost invisible.

    It’s important for businesses to take advantage of this productization stage when it comes along. There’s no sense in investing resources in a bespoke architecture if it’s not providing you with any differentiation—especially when competitors are achieving the same outcome with fewer resources.

    Moreover, getting stuck in a Stage Two mindset when the field moves on to Stage Three (or, worse, Stage Four) and cuts you off from the next wave of innovation. Subsequent technology breakthroughs often build on top of—and interoperate with—the previous technology layers. If you’re stuck with a custom architecture when the industry has moved on, you can miss out on the next wave of innovation and fall further behind competitors.

    The problem is, developers who’ve made a great career from implementing custom architectures are often reluctant to move on. After all, mastery of that previous innovation is what got them to where they are. They may not have realized that the world has progressed around them, or they may worry a standardized architecture with managed services and off-the-shelf products undermines their power and autonomy. This is how organizations fall victim to a resume-driven architecture. I’ve observed this several times when speaking with engineering leaders, and it’s become more common with the rapid innovation happening around data.

    As engineers, our value is in building things and, ideally, in solving innovative, artisanal problems. But this identity and desire can confuse what we want from our own jobs with what our team needs from us. When standard patterns and standard products emerge, we need to adopt them because that’s the way to maximize our impact and ultimately free our time and energy to move further “up stack” and have an even greater impact.

    Developers who would rather stick to a custom architecture often argue that they can squeeze out greater performance, but this is rarely a justification. You may end up with an app that’s 10% faster, but rarely does that come close to making up for the time and energy invested, the loss of flexibility and, ultimately, being held hostage by your own technology stack.

    So how does an organization avoid the trap of a resume-driven architecture? Strong leadership is key. Look critically at the business and ask which areas of your stack are truly differentiators because it’s only those areas that may—just may—justify a unique architecture. If you do go that route, it needs to provide huge benefits to the business to be worthwhile.

    For example, “data” is not in itself strategic to you; every company is now a data company, and the vast majority of things you do with it—how you source, store, process and distribute data—is no different from what everyone else is doing. What does matter are the data products that fuel your business and, most importantly, how fast you can build them.

    That’s why, as a developer or engineer, bespoke stacks are not your friend. Instead, architect your platform in a way that allows other developers to onboard quickly; that allows you to upgrade and swap out components easily over time and that doesn’t leave you held hostage to a developer whose main interest is retaining their value by sticking with an unnecessarily complex architecture.

  • Leading DevOps Transformations With AI

    Leading DevOps Transformations With AI

    In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that AI-engineered tools can help with automating repetitive tasks, improving decision-making with predictive insights and facilitating proactive issue resolution. AI can drive a higher level of quality, security and performance in the software life cycle. Leadership, the first of the nine pillars of DevOps, is the catalyst for a successful DevOps transformation using AI-engineered tools. It’s the guiding force that brings about the alignment of people, processes and technology in the pursuit of continuous delivery and operational excellence.

    How AI-Engineered Tools Assist DevOps Leaders

    Vision and Direction: Leaders define the vision and strategic direction for a DevOps transformation. They set expectations, define goals and align all stakeholders around a common purpose. By clearly articulating the benefits and objectives of the transformation, leaders can secure buy-in from the whole organization and guide their teams toward success. AI can provide data-driven insights to assist in strategic planning and decision-making. By analyzing historical data and current trends, AI can help leaders make informed predictions about the future and set the direction accordingly.

    Cultural Change: DevOps is not just about technology, it’s about changing organizational culture. Leaders are instrumental in driving this change. They model the collaborative, open and learning-focused culture that DevOps requires. They facilitate communication and collaboration across traditionally siloed teams and encourage a mindset of shared responsibility for product quality and customer satisfaction. AI tools can facilitate collaboration and knowledge sharing, helping to break down silos. These tools can enhance communication, support shared workspaces, and even analyze team dynamics and communication patterns to provide suggestions for improvement.

    Resource Allocation: Effective leaders ensure teams have the necessary resources, including tools, training and time to successfully adopt DevOps practices. They advocate for their teams and prioritize investments in areas that will maximize the benefits of DevOps, such as automation tools or cloud services. AI can assist in optimizing resource management. Predictive analytics can help leaders identify where investments will yield the greatest return, and automation can free up team members’ time to focus on high-value tasks.

    Risk Management: Leaders play a key role in managing the risks associated with a DevOps transformation. They set the pace of change, balancing the need for speed with the need to maintain stability and security. They make tough decisions about when and how to deploy new practices or tools and they are prepared to deal with setbacks or failures as opportunities for learning and improvement. AI can play a crucial role in identifying and mitigating risks. By predicting potential issues in the development and operations pipelines, leaders can take preventative action. AI can also improve incident management, speeding up the detection and resolution of issues.

    Continuous Improvement: The nature of DevOps is iterative and based on continuous feedback and improvement. Leaders need to instill this principle within their teams, emphasizing the importance of regular reflection, learning, and adaptation. Leaders can drive ongoing improvement and innovation in their DevOps practices by fostering an environment where experimentation is encouraged and failure is seen as a learning opportunity. AI can support continuous improvement by analyzing performance data and identifying bottlenecks or areas for improvement. AI-powered analytics can turn raw data into actionable insights, helping leaders understand the impact of their actions and make informed decisions about future changes.

    Risks of Not Leading With AI-Engineered Tools

    In an increasingly digital world, the use of AI-engineered tools is becoming standard practice in DevOps. While every organization must assess its own readiness and capacity to adopt AI, the risks of not doing so are significant and could impact competitiveness and operational efficiency.

    • Missed Efficiency Gains: AI offers substantial efficiency improvements through automation, prediction and analytics. Organizations not leveraging these benefits could find themselves outpaced by competitors that do.
    • Decreased Competitiveness: AI can enable faster and more reliable software delivery, quicker response to market changes and more efficient problem-solving. Without AI, organizations might struggle to keep up with competitors in terms of innovation and speed to market.
    • Inferior Decision Making: AI enhances decision-making by providing leaders with data-driven insights. Without these insights, leaders might make less informed decisions, potentially resulting in suboptimal outcomes.
    • Reduced Agility: AI can help organizations anticipate and quickly respond to changes. Not using AI may limit an organization’s ability to adapt quickly to new market trends or customer demands.
    • Increased Operational Costs: AI can significantly reduce operational costs by automating repetitive tasks, predicting system failures and optimizing resource usage. Without AI, organizations may face higher operational costs.

    Transformation Roadmap With AI-Engineered DevOps

    The successful integration of AI-engineered tools into DevOps is not a one-time project but a continuous journey of learning, experimenting and adapting. Leaders play a crucial role in guiding their organizations on this journey, and developing their own AI competencies is a key part of that.

    1. Education and Awareness: Begin with enhancing your understanding of AI fundamentals, its capabilities, limitations and implications. This can be done through formal training, online courses, seminars, workshops or self-study.
    2. Identify AI Opportunities: Leaders need to identify areas in their DevOps practices where AI can provide the most benefit. This might be where automation could save time, where predictive analytics could provide valuable insights or where machine learning could improve system performance.
    3. Start Small and Experiment: Begin by piloting AI tools in one or two areas. This provides an opportunity to learn about AI’s capabilities and challenges in a controlled, low-risk environment.
    4. Gather and Analyze Data: Data is crucial for AI. Leaders must ensure their organizations have systems in place to collect, clean and manage data. They also need to learn how to interpret the data and insights provided by AI tools.
    5. Build a Multidisciplinary Team: AI requires various skills, including data science, software engineering and domain expertise. Leaders should aim to build diverse teams and foster a culture of collaboration between these different skill sets.
    6. Scale and Integrate: Once they have seen success with initial pilot projects, leaders can start to scale their use of AI tools and integrate them more deeply into their DevOps practices.
    7. Continuously Learn and Adapt: As with any technology, the AI landscape is constantly evolving. Leaders need to commit to continuous learning and stay updated with the latest trends, tools and best practices.
    8. Develop Ethical and Responsible AI Practices: Leaders should ensure AI is used responsibly within their organization, considering aspects like data privacy, transparency and bias. They should create guidelines and practices for ethical AI use.

    Pitfalls and Challenges

    By being aware of potential pitfalls and planning for them in advance, leaders can increase the odds of a successful implementation of AI-engineered tools in their DevOps practices.

    Resistance to Change: Implementing AI tools often requires significant changes to workflows and practices. This can be met with resistance from team members. Effective change management practices can help overcome this resistance. Communicate the benefits of the change, provide ample training and support and involve team members in the process.

    Data Privacy and Security Concerns: AI tools often rely on access to sensitive data, which can raise privacy and security concerns. Develop and adhere to strict data management policies, ensuring compliance with all relevant privacy and security regulations. Use secure AI tools that offer robust data protection features.

    Skills Gaps: Implementing AI tools often requires skills that existing team members may not have. Invest in training for your team, hire new staff with the necessary skills or bring in consultants or external experts to help.

    High Expectations: AI is often perceived as a magic bullet that will solve all problems. This can lead to unrealistic expectations and eventual disappointment. Set realistic expectations about what AI can and cannot do. Communicate clearly that AI is a tool that can enhance efficiency and effectiveness, but it requires human oversight and cannot replace all human tasks.

    Choosing the Wrong Tools: With so many AI tools available, it’s easy to choose ones that aren’t a good fit for your organization’s needs. Carefully evaluate potential tools based on your specific needs and constraints. Look at factors like compatibility with existing systems, ease of use, scalability and vendor support.

    Lack of a Clear Strategy: Implementing AI tools without a clear strategy can lead to disjointed efforts and wasted resources. Develop a clear strategy and roadmap for your AI implementation. This should outline your goals, the steps to achieve them and how you will measure success.

    Summary

    Leadership plays a crucial role in the successful transformation and adoption of AI-engineered tools in DevOps practices. The journey involves educating themselves about AI, identifying suitable opportunities, experimenting with AI tools, gathering and analyzing data, building multidisciplinary teams, scaling AI usage and promoting ethical AI practices. However, challenges like resistance to change, data privacy and security concerns, skill gaps, high expectations and selecting the right tools can be encountered. These can be mitigated with effective change management, strict data policies, training and hiring strategies, setting realistic expectations, careful tool evaluation and a clear AI implementation strategy.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    LinkedIn

    Underdog.io
    New York, New York
    DevOps Engineer
    $114,000 to $206,000

    SimplyHired.com

    Verizon
    Lone Tree, Colorado
    DevOps Engineer
    $107,000 to $226,000

    Indeed.com

    Erie Insurance
    Erie, Pennsylvania
    DevOps Solutions Architect
    $104,838 to $167, 468

    Dice.com

    Nityo Infotech Corp
    Mountain View, California
    DevOps Engineer – AWS Cloud
    $100,000 to $140,000

    CareerBuilder.com

    Boston College
    Chestnut Hill, Massachusetts
    Senior DevOps Systems Administrator
    $96,000 to $120,000

  • Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk to Add ASPM Platform via Enso Security Acquisition

    Snyk this week announced it plans to acquire Enso Security, a provider of an application security posture management (ASPM) solution that tracks events and analyzes metadata collected from DevOps and security tools.

    At the same time, Snyk revealed it has added a DeepCode AI Fix tool that creates validated fixes for code written by either humans or machines and an Insights tool that helps organizations better prioritize remediation efforts based on the risk to the business. DeepCode AI Fix extends the capabilities of a generative artificial intelligence (AI) capability based on large language models (LLMs) that Snyk gained with the acquisition of DeepCode in 2020.

    Manoj Nair, chief product officer for Snyk, said all of these initiatives represent an effort to extend the reach of Snyk’s portfolio to address a wider range of issues within the context of a larger DevSecOps workflow as well as give developers tools that enable them to write more secure code.

    The acquisition of Enso Security is expected to close this quarter. The company has been making a case for an ASPM platform that eliminates the need to manually collect cybersecurity data from the various tools and platforms that a DevOps team may be using.

    Despite innumerable cybersecurity concerns, the rate at which applications are being deployed and updated continues to accelerate. The Enso platform makes it possible for cybersecurity teams to keep pace with those projects by discovering issues before an application is deployed in a production environment.

    The challenge, of course, is that most development teams are not going to be able to address every issue before an application needs to be deployed. In addition to knowing who is developing what application code, cybersecurity teams need to also prioritize potential issues versus rather than just sharing a list of potential issues that have been discovered. Enso Security’s ASPM platform provides visibility into events so that it’s simpler for cybersecurity teams to trace issues back to individual developers or the AI platform that generated them.

    That latter issue is becoming more significant as more development teams rely on general-purpose generative AI platforms to write code, noted Nair. Those platforms are writing that code based on samples collected across the internet, many of which are deeply flawed from a cybersecurity perspective, he added.

    The Enso platform is intended to enable cybersecurity teams to have the most impact on an application development project without being forced to interrogate every developer to determine what’s occurring in any application environment. In fact, one of the reasons developers resent those conversations is they know all the relevant data has already been entered into a system—cybersecurity professionals just need to access it.

    There’s still a lot of work to be done when it comes to bridging the historic divide between cybersecurity professionals and application developers. However, the more data that can be seamlessly shared between these teams, the simpler it becomes for organizations to embrace DevSecOps best practices.

  • The API Life Cycle Mixer’s Manual: What Goes Into a Single Source of Truth?

    The API Life Cycle Mixer’s Manual: What Goes Into a Single Source of Truth?

    In bartending, the mixer’s manual is a trusted source of information. These books can contain hundreds of recipes for classic cocktails, some of which might be 100 years old, while others might be for drinks that only recently arrived on the scene. Mixer’s manuals also can be great sources of inspiration for new, yet-to-be-tested recipes for exciting additions to a bar’s or restaurant’s offerings. This balancing act of preserving the old while encouraging exploration into the new can provide a valuable lesson for API development in the software world. An API’s “single source of truth” is, in many ways, the software organization’s own mixer’s manual. This is especially true when the right approach is taken to ensure that software remains functional and performant and serves up experiences that delight customers and keep them coming back for more.

    The Rise of APIs and Mixology

    While we might think of mixology and the mixologists who practice this craft as relatively new terms, the first recorded use of the word “mixologist” dates back to 1852 and “mixology” followed shortly after.

    Just how similar are the work, mindsets and passions of mixologists and API developers and designers? Check out this definition of a mixologist and count the similarities for yourself:

    “The term ‘mixologist’ refers to someone who studies the history of mixed drinks, has a rich appreciation of the ingredients and techniques used and regularly creates new and innovative mixed drinks … their job title implies that they do a significant portion of their job behind the scenes, creating new craft cocktails and putting their signature twist on existing favorites.”

    The best API developers, designers and architects of the world should recognize a lot of the above in their own work. They have deep respect for their craft and are always honing it further. They seek to understand the tastes and palates of their consumers. They factor in other stakeholders’ inputs, they test, iterate and test their creations again before “serving” those APIs to production.

    Like mixologists and bartenders (if you see them as two different roles), every professional along the API life cycle should understand the needs of consumers, customers and the business–and then design and develop their APIs accordingly. An essential part of this process is continuous validation and adaptation to market requirements.

    Maintaining Confidence in Ever-Changing Recipes

    Changes to APIs, even minor ones, can have significant downstream effects. And the same can be said for tweaks made to an age-old cocktail recipe, where adding or removing a single dash of this or that can completely change the flavor of a drink … as well as people’s interest in it.

    While there’s no “standard” rate of change to APIs to plan for, you can expect changes to be needed with each new software release. This could mean changes are being made (and need to be tested against and validated) every few weeks, every month or even every day, depending on your release cadence. There also can be as-needed, ad-hoc changes.

    What’s crucial for teams to ensure is that these changes do not disrupt an API’s functionality or performance. To make this possible, teams are increasingly leveraging API contract testing to provide a safety net of sorts. This comes in the form of testing that validates changes against a “contract” that details an API’s original, agreed upon and, therefore, required functionality.

    The ability to foresee the impacts of changes to APIs can depend on the maturity of an engineering team and its ability to collaborate across departments, time zones and varying levels of technical expertise. Tools and guidelines that promote standardization and collaboration can prevent mishaps from overlooking or being blind to negative downstream effects.

    Documentation is Key

    Whether we’re talking about being able to trust a single source of truth for the most up-to-date version of a published API or the latest edition of a mixer’s manual for tried-and-true drink recipes, clear and concise documentation is key. But it’s also not enough for this documentation to simply exist.

    It seems like common sense—although you’ve probably worked somewhere where it wasn’t—that your API documentation also needs to be easily accessible, understandable and usable. Ensuring all of these things leads to smoother onboarding and a positive developer experience and, ultimately, to wider adoption of a functional, performant API that meets or even exceeds expectations.

    API documentation is often the first point of contact a developer has with an API. It serves as a guide, walking developers through the API’s features, endpoints, request/response models and error messages. It also provides insight into the underlying business logic and unique characteristics of an API.

    Good API documentation follows the principle of a single source of truth, meaning that it should be comprehensive, up-to-date, and consistent. It should always mirror the actual behavior of the API, reducing the guesswork for developers and minimizing the potential for misunderstandings and errors.

    Just as a mixologist relies on a detailed and accurate cocktail recipe to deliver a pleasing experience to a patron, API developers depend on good documentation to create and deliver useful, value-add APIs and powerful applications.

    Continuous Improvement = Continuous Education

    Like a mixologist who meticulously adjusts the ingredients of a cocktail or who creates new cocktails to meet the evolving tastes of customers, developers must constantly adapt their APIs to meet changing market demands, business needs and industry standards.

    This is achieved through a potent blend of market research, collaboration, adherence to standards and governance and meticulous testing. However, as software development, testing and deployment technologies and processes continue to evolve, the tech industry must continue educating itself and refining its practices.

    With a mindset focused on constant learning and continuous improvement and a dependable single source of truth as their guide, development teams can confidently serve up exceptional API experiences in every release. In the end, the aim is to create APIs that are reliable and easy to consume and that meet the unique needs of the moment–much like a mixologist’s perfect beverage.

  • Technical Debt? No Sweat!

    Technical Debt? No Sweat!

    As a product manager, I dread the moment a developer says, “Wait a minute; I need to refactor …” (I wish it was just a minute). Something that should take two days starts taking three days and then a week. Over an application’s lifetime, the app starts accumulating technical debt. At that point, innovations become a smaller and smaller percentage of the work due to the vast efforts invested in the extra time required to support new developments.

    It is okay and natural to get into technical debt. As in finance, some people will take out loans to invest in something because they know that later they will be able to sell it for a higher price and pay off the loan with ease. Same with code. You take on technical debt because you want to develop the application faster and get the product or updates out as soon as possible. But in the end, the technical debt has to get paid. This creates friction between R&D and product, and although we both understand at some point that modernization is needed, it is difficult for the team to quantify. Due to all the long cycles, the complex QA, the increasing number of bugs and security issues, engineers start to feel frustrated. And as a product manager, I also feel frustrated when dealing with missed deadlines and inflated estimations.

    It’s not that we don’t want the developers to be happy and to invest in the code (and, let’s face it, in their own mental health, too), but we never know how much time and money is actually spent on technical debt versus how much is reallocated to innovation. For me, that was always a big question, but I never managed to move the conversation from, “I have a feeling,” or “The code looks ugly …” to “For every $1.00 I invest, X% is dedicated to maintenance.” How do we stop guessing and feeling we are in debt and actually start measuring it? And once we make technical debt tangible, when and where do we start modernizing?

    Every application’s innovation cost is affected by its level of technical debt. It’s important to determine how much money invested in the application is put toward innovation and how much is used to repay technical debt. In addition, there are classes of debt that add more complexity and risk overall.

    The newest versions of a monolithic application’s framework can be tagged as modern, aging or unknown (if the jar file isn’t found). This adds another layer of information when deciding what a modernization effort would entail and helps you focus first on aging frameworks that pose the greatest risk to enterprises due to the accumulation of technical debt and security concerns.

    Complexity, Risk and Debt

    The complexity of an application is determined by the degree to which class dependencies are entangled, reducing the level of modularity. A code risk relates to the length of the dependencies: How might a change in the application affect some of its seemingly unrelated components?

    These two metrics affect the architects’ ability to decouple functionality and create independent, isolated microservices in the future. At the end of the day, that is what forms the overall technical debt. Using the average of these three metrics, we can further prioritize applications in the portfolio. This provides insights into immediately actionable areas, such as our next metric.

    The process of modernizing takes time and money and, unfortunately, is a high-risk and often unsuccessful project. To make this process successful, it is first necessary to understand the cost of innovation, the complexity of the application and the risks involved. With these metrics at their disposal, R&D and product are well positioned for a comprehensive, data-driven conversation about modernization.

  • Report Surfaces DevOps Challenges for Mobile Applications

    Report Surfaces DevOps Challenges for Mobile Applications

    An assessment of 1,600 DevOps teams involved in building and deploying mobile applications found that 62% were adversely impacted by manual processes that slowed the rate at which these applications were deployed and updated.

    Based on the Mobile DevOps Assessment (MODAS) created by Bitrise, a provider of a continuous integration/continuous delivery (CI/CD) platform for building and deploying mobile applications, the metric measured the creation, testing, deployment, monitoring and collaboration phases of building and deploying applications.

    The survey also found (44%) of respondents reported their release approval process is mostly or entirely manual, with only 9% having fully automated application releases. Only 22% of teams said they’ve been able to complete internal release processes in less than an hour.

    The survey also found that nearly two-thirds of organizations (66%) have deployed applications that can’t be opened in two seconds or less, which is widely considered the accepted level of performance required.

    In addition, three-quarters of organizations (75%) required more than two days to address bug fixes. Only 21% of teams said that they had implemented some form of app performance monitoring to keep track of bugs, the report found.

    Daniel Balla, chief strategy officer for Bitrise, said MODAS applies many of the concepts from the DevOps Research and Assessment (DORA) metrics that Google now oversees. Those metrics, however, are not specifically designed to assess mobile application development initiatives, he noted.

    It’s not clear what percentage of applications DevOps teams are building today are deployed on mobile devices. But given the emphasis on digital business transformation initiatives, many of these applications are increasingly mission-critical to organizations. The general expectation among mobile application end users is that apps will be regularly updated with new functionality. However, if release processes are largely manual, regularly improving the user experience can become problematic. In addition to the increased likelihood that mistakes will be made, manual processes are often the reason why a vulnerability was introduced into an application environment.

    DevOps teams will also need to also consider the level of scale that will be required to support mobile app development, noted Balla. Many of the tools that developers rely on today to build applications were not necessarily designed to enable developers to build and deploy mobile applications at scale, he added.

    Finally, most enterprise applications need to run on multiple devices, so the tools used to create these applications can’t focus on applications that can only run on one platform, said Balla.

    Regardless of the approach to building and deploying mobile applications, the amount of focus on them within most organizations is high; any issues that arise are likely to be noticed by the highest echelons of an organization. That level of attention can easily put pressure on DevOps teams that frequently work on multiple projects. The challenge and the opportunity now is to create a set of DevOps workflows optimized for mobile applications that almost by definition require much more frequent updates than any other type of application.

  • Coming Soon: AutoOps

    Coming Soon: AutoOps

    I’ve spent a lot of time looking at products in the DevOps toolchain and paying attention to where they are going, what they are doing that is new and how they are differentiated. That has led me to one inescapable conclusion: AutoOps is on the way.

    What is AutoOps?

    AutoOps is full robotic automation; the continuing progression of what has been building for the last couple of years. We have DevOps, GitOps, DevSecOps, IaC, CloudOps, AIOps … and the list is still growing. But they all move toward one thing: AutoOps.

    Now that development has been fully integrated into DevOps, the market is moving to do the same for operations. It is harder with operations because DevOps had Agile, but it is coming. And it is coming to your org.

    That is a good thing, in my opinion. Compliance almost demands it; what we currently call AI enables it and staffing in hard macroeconomic times will make it appealing.

    The questions that you should start asking now are what does the organization need to enable rapid deployment, management and upgrades while leaving humans in control for the majority of decisions?

    Some of you are living this. I have a friend that is in a GitOps shop with automated CloudOps where they are implementing AIOps to handle minor day-to-day things and monitoring for drift … but they’re the exception; most of us are nowhere near there.

    Knowing that is where we are heading means you can plan – and it is glaringly obvious this is where we are heading. Vendors are branching from their current subset of XOps to take us there and eventually, we will have a full end-to-end vendor that can do everything from GitOps to fully automated rollout, green/blue deployment, monitoring and drift correction with human intervention only where the organization wants it. Some vendors are already very close to this environment and I expect that several will get there in the next year or two via acquisitions or partnerships.

    We just don’t think of the overall DevOps/concept to retirement SDLC process in the absolute terms that AutoOps requires, but we’re going to want to because the environment is changing. The changes are for the better, but they will be massive and cause disruptions. However, they’ll make everything better in the end by eliminating error-producing bits while leaving us in control of the flow and process.

    Start Planning for AutoOps

    So start planning, understand what your organization wants and needs from the coming full-robotic automation I call AutoOps, and keep kicking rear. Eventually, we’ll have systems that can do a lot of Dev and Ops work, but that day is a ways off, and will require people to manage the systems that manage the systems… Funny but true.

    *I’ve never seen AutoOps used anywhere with regards to IT, I just thought it describes where we’re headed pretty well. Let me know if you’ve seen a better term coined by a smarter person. Or a not-smarter person that has a cooler name for it.