devopsy.kinsta.cloud

Tag: operations

  • The Importance of Incorporating DesignOps Into DevOps

    The Importance of Incorporating DesignOps Into DevOps

    Design is a critical software project element that often goes unnoticed by those writing code. After all, coders and implementers tend to take the design process for granted and leave the look and feel of applications to the designers. In the days of waterfall based development, design was one of the first steps in the development sequence of creating a new application. However, with Agile and DevOps development practices, design became disconnected from the overall process.

    “If you look at the full spectrum of AppDev, it becomes obvious that there are many elements that should be part of DevOps. Take, for example, cyber – today, there is a movement to integrate cyber into the DevOps pipeline, which the industry has started to call DevSecOps,” said Mark Troester, VP of strategy at Progress, a software company offering tools for developers and IT. “To make design a part of the iterative process of DevOps, teams need to think about including designers during the complete development process, something along the lines of how cyber has become part of the iterative process. In other words, teams should be embracing the concept of DesignOps,” Troester said.

    To understand the challenges this creates for those looking to include design as part of the DevOps process, one only needs to look at how design, specifically user experience/customer experience (UX/CX) design, was done in the past. Designers would use tools such as InVision Studio, Axure, Proto.IO, Adobe XD, or one of the many other tools available, to prototype the look and feel of an application, or, more specifically, the end-user experience. The term DesignOps was coined to encapsulate the processes around design. However, DesignOps solely focused on the process of design, such as design workflows, design tools, design governance, team management, budgets and so on. 

    The ultimate goal of DesignOps was design creation; that design was then passed on to those who would write the code and develop the logic to bring that design to fruition in the form of an application. DesignOps worked rather well when an organization was adhering to waterfall development methodologies, where each step was clearly defined and the goal was to deliver a complete, finalized application to those requesting it.

    “Larger organizations were able to field large design teams and could afford to implement a complete design system. When you have 50 or more designers, a complete design system becomes critical to manage design,” said Troester. “However, as AppDev has evolved into a more agile process, especially under DevOps, the disconnect between design and development became a significant problem.”

    What Troester is alluding to is the reiterative development cycle used by DevOps teams, where applications are delivered in pieces and then further modified based on user feedback or business operational changes. Businesses today are embracing agile concepts, so they can react much faster to changing market conditions. This, in turn, means modifying applications as quickly as possible to maintain a competitive advantage. Currently, design remains somewhat siloed, and can become a bottleneck for implementing changes if the UX/CX must be modified to address those needed changes. 

    “With the rise of DevOps, teams need to start thinking of reiterative processes, where DesignOps integrates with the DevOps team, so there is collaboration between the designers and the developers, allowing design changes to happen quickly,” Troester said. “Yet, there are still remaining challenges – some created by the COVID-19 crisis – where designers and developers may not even be in the same building, much less the same time zone,” he said.

    To Troester’s point, the COVID-19 crisis has forced businesses to evolve in ways that were once thought impossible. Developers, designers and even operations teams and individuals may no longer be sharing office space, and might be distributed across multiple locations. That complication will drive the need for better collaboration tools that bring design into the DevOps cycle.

    “DevOps teams, as well as DesignOps teams, should be looking into technologies that can bridge the designer/developer divide. It will be critical in the near future to facilitate collaboration between design and development,” Troester said. “Perhaps, the answer lies with building some type of bi-directional API into design systems, which can play a key role in the implementation and support of design-first experiences,” he added.

    Existing solutions to the current divide seem to be few and far between. But, that does not mean DesignOps and DevOps teams should not be currently looking for a solution to what will become a major problem as DevOps accelerates in the enterprise.                  

  • Operations Model: DevOps, NoOps, AIOps or None of the Above Ops?

    Operations Model: DevOps, NoOps, AIOps or None of the Above Ops?

    Within an organization, an operations model must be fit-for-purpose and be able to adapt as business needs change. At the same time, changing technology necessitates an advancement in how an organization operates. Small and medium-sized enterprises are faced with the difficult choice of how much to invest in operations and which approach to choose. In light of the numerous possibilities, companies need to identify the right upgrades for their needs. For instance, should a company now using a traditional operations model invest significantly to reach DevOps? Or would AIOps better fit customers’ needs? Is NoOps an option?

    There is no “correct” answer. Each option comes with pros and cons and important budget considerations. That is why every business needs to evaluate the appropriate system for its products and its customers with three concepts in mind: cost, goals and experimentation.

    Operations Models

    Traditional IT operations (ITOps) is the process of designing, developing, deploying and maintaining the infrastructure and software components of a specific product or application. It also ensures the customer experience is delivered through traditional means of support such as tickets and escalated paths for resolutions.

    DevOps is a process for accelerating the delivery of features to the application or product infrastructure in a consistent model with less human intervention, while also providing a better quality product through automation in the software development life cycle.

    An AIOps process introduces data science into the operating model by learning the behavior of the systems, scaling according to the needs of a platform (both infrastructure and customer usage of the platform). It expands the horizon of DevOps through the introduction of machine learning, focusing on data generated from the hardware and software systems, and allows organizations to grow organically based on demand.

    NoOps, although the name suggests otherwise, is an advanced approach to managing IT operations through the mindset that everything is derived as development. This model is best applied with startups and companies with high technological maturity.

    Typically, these companies have advanced skill levels to deliver the best experience by adapting to the new industry trends of both software and hardware maintenance practices. NoOps is at the opposite end of the spectrum from traditional operations, and it’s largely a theoretical concept at this point.

    NoOps is a fully automated, cloud-based approach that eliminates the operations team, aside from an integrated team focused on life cycle. The self-managed system requires resiliency and a high level of maturity with fail points that have already been addressed. NoOps, or high maturity structures, will also provide quick learning on drawbacks, customer and product needs. However, moving toward a self-maintained system requires upkeep for advances and innovation.

    Invest in an Operations Model to Reach Higher Levels of Maturity

    The first factor to consider in evaluating an operational approach is cost. Each level of IT maturation is gradual, incremental and expensive. Costs vary depending on the size of the company and the type and number of products. A small company that seeks to move from a level 2 to 4 maturity would need to make a significant financial investment.

    Some questions to consider when looking at operations model upgrades include:

    • Does this make sense for the business?
    • Will the investment allow for scaling?
    • Will it increase customer loyalty and trust in the brand?

    Next, it’s important to consider overarching goals and brand identity. The appropriate level of maturity might depend on the company’s value proposition. If, in the company’s vision, technology is at the heart of its journey, the company needs to invest, at a minimum, in a DevOps operating model to have the competitive edge to grow the business and meet its needs. If the company’s vision is to retain existing business and gain customers through continued investment in innovation based on the trend analysis of their core business, then AIOps will have the best ROI. If the company’s vision, culture and mission are intertwined with technology, adapting to NoOps is the right move.

    Know the Product, Customer and When to Halt

    Still, it’s important not to overreach with an operations model that might not fit the customer. To make a sound decision for the organization, it is important to understand the model, the product, customer base and when to halt an operational model and invest in a new one. The leadership team needs to ask how adaptable its end users are before implementing changes. Take, for instance, the poor consumer response to replacing live customer service representatives with automated features. Some end users were not prepared to adapt to the massive change in the platform or service offerings this move entailed.

    Product-driven businesses often don’t see investing in new operations models as worthwhile. This mindset can result in continual churn that creates a backlog and increased operating costs for maintaining systems and services. Another important consideration in deciding which operating model meets the company’s needs comes through experimentation. That is because finding the right operating model for an enterprise can’t be done with a cookie-cutter approach. The point is to maintain the existing quality and productivity while investing in outcomes that will garner more trust and confidence in the company. If you do this right, the end user will appreciate the changes, and the company will outperform the competition.

    Allow for Operations Failure

    Enterprises should expect failures during experimentation with different models and plan to pressure-test an advancing model for the cracks that will emerge. It is important to invest in failure to understand why and how the model did not perform to expectations. Those failures provide valuable insight and important data, result in significant learning about products and customers and help you know what to improve or modify going forward.

    An operations model serves as the backbone for any business that wants to grow. Smart operations investments will ensure adaptability, competitive advantage and customer loyalty. But there’s no one-size-fits-all, easy-to-follow recipe for each enterprise. Whether the investment results in AIOps, NoOps, DevOps or traditional operations is unique to each organization and needs to be calculated with the brand, customer and end goal in mind.

  • How Impact Mapping Can Align Remote Teams for Success

    How Impact Mapping Can Align Remote Teams for Success

    Impact mapping is ideal for creating effective cross-functional groups in a remote work environment

    Around the globe, teams have been adjusting to the current remote work environment. Those adopting a DevOps way of thinking may have had an easier time adapting to the rapidly changing situation.

    Yet, even for organizations used to remote work, there’s often a natural disconnect that crops up between teams that can hamper initiative planning and product launches. While teams within organizations may be conducting daily standups and adhering to agile ceremony cadences, communications pipelines tend to be more fragmented.

    As such, without a proactive and concerted communications and planning effort in place, it can be challenging for everyone to have a clear understanding of their organization’s objectives, let alone visibility into the work being done by their colleagues. Without this understanding, they run the risk of duplicating work or overlooking key performance metrics, and not delivering products that drive value for their customers.

    At a time where organizations are planning 2021 initiatives, impact mapping can help. This graphical strategic planning practice can be leveraged at any level of an organization that is looking to identify clear goals, build better lines of communication and map out the resources it will take to meet corporate initiatives.

    So how can organizations and teams take advantage of impact mapping?

    The 4 Elements of an Impact Map

    The goal or initiative: This should be specific and measurable. For example, “Increase customer satisfaction by 20% over the next 12 months.”

    The actor: The people or things that influence the eventual outcome. An actor can be a team member, but it can also be a piece of software or a group of people (e.g.: customer service).

    The impact: An assessment of behavioral changes necessary to achieve the goal. For example, a behavior change could be a decrease in the number of units a customer returns to the business.

    The deliverable: Any changes (or work items), platform updates and/or product features that will need to be created or improved to achieve the goal. In this case, reach the desired impact and increase customer satisfaction ratings by 20% over the next 12 months.

    To create an impact map, a facilitator and business owner gathers a team of sponsors across the business. This could include product teams, operations, finance and sales. Over the course of several hours (or, sometimes, weeks) the initiatives are brainstormed and prioritized. Utilizing a digital whiteboard, such as Coggle or Google Jamboard, all team members are invited to be engaged and to contribute.

    The net effect is that all team members can be on the same page when it comes to the overall strategic goal behind the initiative and their unique roles in the process. When the prioritizing is complete, they can go forward and continue to work together to deliver the right features to align with the objective.

    Before that happens, there are additional steps that take place during the impact mapping process that play a vital part in the ultimate success of an initiative. Let’s take a closer look at a few of those steps.

    Building a Team

    As the goals, actors, impacts and deliverables become clear, so, too, will the resources that an organization will need to make the ultimate outcome a reality. Those resources may include individuals from various parts of the organization.

    For example, it may be determined that one of the best ways to increase customer satisfaction is to significantly decrease the number of bugs in a product. That might necessitate a higher level of involvement from security teams in the development and planning process. Getting these teams involved early will save time and reduce risk as their input is incorporated into the design from the very beginning, helping to create a compliant, bug-free product that will better deliver on customers’ expectations.

    The number and type of team members will vary based on the product and the goal. In some cases, teams may include members versed in user experience strategies, while in others it may be DevSecOps team members. Whatever the use case, once the team and roles have been established, everyone involved in the product will have a clear view of what they’re expected to do, and how their work aligns with the rest of the team and drives toward achieving the goal.

    Improving the Development Process

    Impact mapping can also be useful for identifying areas of improvement in the development process. It sheds light on areas that teams may not otherwise realize need work. For instance, perhaps team members will discover they need to implement higher quality tools or make changes to their integration testing processes. Or, their developers need better training on Kubernetes Operators so they can automate and expedite the deployment of applications.

    These deficiencies and others can be discovered before they end up impeding development. By creating more transparency in these areas, teams can focus on addressing them prior to delivery, resulting in a secure and more stable product that meets its objectives.

    Facilitating Better Communication and Collaboration

    The impact mapping process encourages collaboration and the sharing of ideas that can, in turn, spur other ideas. Through collaboration, team members can help each other solve problems and find new ways to address the impact and deliverable phases of the process.

    Closer collaboration also allows team members to help each other become more comfortable with any changes that might be necessitated by the impact mapping process. This could include the adoption of new technologies that the team may not initially be comfortable using.

    Consider if the development process calls for the team to adopt new technologies that will change their workflow processes. Such a move could take many people out of their comfort zones. But if everyone understands the reasons behind the change and a willingness to test it out, the change becomes more palatable. By working together, they can collaboratively troubleshoot issues and adopt new best practices for using the technology.

    A Good Solution for a Remote Environment

    While impact mapping sessions have been delivered in conference rooms or large meeting spaces with sticky notes and markers, the practice can also enable alignment when used in a remote environment. Being on-screen instead of in-person can actually bring out participation among members who might otherwise be shy or reluctant to volunteer ideas in a room full of their colleagues or managers, where they may be hesitant to speak their opinions. Team members may feel more anonymous in a remote environment and feel more comfortable speaking freely.

    In short, impact mapping is ideal for creating effective cross-functional groups in a remote work environment. No matter where they are located, everyone will have a better understanding of what they need to do—both individually and collectively—to create applications that deliver value to their businesses.

  • Antipatterns That Hurt DevOps Implementations

    Antipatterns That Hurt DevOps Implementations

    Avoiding these DevOps antipatterns can help organizations reap the benefits of implementations faster

    It’s a given that all organizations at some point will suffer from poor development practices when trying to find the perfect balance between software development and IT operations. The good news, however, is that implementing DevOps can help you improve these processes and get them synchronized and working together in harmony.

    However, understanding and mapping out the core issues and the common DevOps “antipatterns” that are holding you back from successful DevOps implementation is essential. This article will focus on the most common DevOps antipatterns that organizations tend to fall into and how to avoid or overcome them.

    What Are DevOps Antipatterns?

    At first glance, DevOps may sound like a pretty straightforward concept. At its core, DevOps is about bringing together separate but functional areas and bridges the gap between software development (Dev) and IT operations (Ops) with the ultimate goal of delivering software faster and with better stability.

    That said, DevOps antipatterns can best be defined as ideas that are counterproductive to the DevOps culture. They include:

    • Blame culture: In this kind of culture, blaming and punishing people is the norm when mistakes are done. It can happen at an individual or organizational level.
    • Root cause analysis (RCA): RCA is a process that involves identifying the “root” cause of a problem or an event, as well as the appropriate actions to take to avoid a recurrence. It’s an iterative and continuous process that must be performed until data is exhausted or all organizational factors have been identified.
    • Human error: Human error is often cited as a root cause in RCA. This is also common in “blame culture” and someone has to be held accountable for mishaps and mistakes.
    • Silos: An organizational or departmental silo defines the mentality of teams that don’t share their knowledge with other teams within the same company.

    4 DevOps Antipatterns and How to Break Them

    Wrong Perception of Your DevOps Team

    The perception you have of your DevOps team matters. It’s essential to consider the team as part of the entire process. Neglecting to provide them with structure, resources, and a positive working environment can increase your chances of DevOps failing. Furthermore, making DevOps teams more productive requires proper implementation of processes and tools.

    How to Break It

    A successful DevOps implementation requires more than just bringing people together. Structuring the team correctly and adding processes is vital if they are to succeed. Providing the necessary resources, technology and information security they need will get the best results.

    Practices such as continuous integration (CI) and continuous delivery (CD) are both concerted processes that can be used to bring development teams together in alignment so software products are delivered quickly, operations are more simple to manage and no downtime is present during deployments that are detectable to the end user.

    Poor Choice of Technology

    Technology plays a significant role in IT; however, the rapid development of new technologies has made it challenging to separate essential and overhyped tech trends. For instance, DevOps itself is a powerful digital transformation tool as it plays a critical role in new software development and problem-solving. Nevertheless, many of the latest IT trends should not be worth your attention unless you and your team are willing to implement it correctly.

    How to Break It

    This antipattern can be broken by top-level and project managers who make the decisions regarding technology choices. Asking questions such as, “What does the organization need?” or, “How well will this technology work for us?” will help when choosing what tech is right for your organization. With thousands of tools and technologies available, you need such a mindset to make the right decisions.

    Unclear Responsibilities in Teams

    You may have come across this problem in many other non-IT projects. However, in both IT and DevOps teams, the consequences can be severe if solutions aren’t implemented quickly. If team members aren’t clear on their roles and responsibilities, this can lead to poor decision-making and unnecessary interference in other people’s positions.

    How to Break It

    First of all, you need to clearly define roles and responsibilities for everyone in the team. A clear definition of roles boosts productivity. For example, having a data scientist in your DevOps team can play a huge role in business success due to their very specific data analytics skills, techniques and tools. In fact, 89% of business managers agree that hiring a data professional will help to improve success at their respective organizations. There just needs to be active and consistent communication between team members for everyone to conduct their own roles and responsibilities efficiently.

    Every team member should follow the strategies and plans in place so timelines can be monitored and effective top management decisions can be made. When implementing complex DevOps architectures that require teams and software to work together, poor decision-making will be an issue if roles are left unassigned.

    Wrong or No Code Deployment

    To put it bluntly, there’s no DevOps without code deployment. With this being the ultimate result, DevOps makes no sense if it fails. This is quite a challenge for several organizations, as having Dev and Ops teams working in harmony can seem impossible.

    How to Break It

    As mentioned above, code deployment is often a challenging task for DevOps teams. However, organizations can break the resultant antipattern by integrating the units correctly to enable a collaborative environment, a great strategy for successful DevOps implementation.

    Such an environment will also make code deployment easier by reducing the need for a series of meetings and reviews, which ultimately delay teams from getting code to deployment.

    NoSQL’s Key Role in Database DevOps

    DevOps processes need to work in a synchronized manner to be successful. Issues with the database can cause it to slow down and affect the delivery of database changes. However, NoSQL’s unique approach is designed to simplify the process of DevOps implementation in the following ways:

    Faster scalability

    Many small companies fail to maintain peak performance with greater workloads. A more significant workload calls for better tools that can help maintain peak performance, subsequently making it easier for organizations to scale out.

    More efficient technical support

    Having technical support that doesn’t hold you back is key to DevOps success. The right NoSQL solution enables you to solve problems before they become full-fledged, expensive and time-consuming.

    Faster adaptability

    The changes that new codes bring for databases can be challenging. NoSQL makes it easier to deliver solutions to client requests, as it organizes them using dynamic indexing. Therefore, it verifies all queries before answering them with the appropriate index.

    Platform testing

    Testing is one of the critical steps you need to go through before actual implementation. Databases should be flexible enough to allow you to test queries without interfering with the real data. Testing helps to determine how new changes will impact the development process.

    Conclusion

    As you can see, there are many ways to implement DevOps systems in your business to deliver products faster, offer more technical support and automate essential tasks.

    All of the requirements we have covered are necessary if a business is to scale and grow. Businesses need to ensure the correct strategies are in place, roles in the company have been clearly defined and common antipatterns have been identified and eliminated.

  • 7 Things to Make DevSecOps a Reality

    7 Things to Make DevSecOps a Reality

    While talking about DevSecOps has become a hot trend, it is clear that many organizations claiming to follow such methodologies are actually mired in traditional waterfall development. Let’s figure out if you’re really ready to implement DevSecOps.

    In a world that relies heavily on distributed computing and third-party services, security is paramount for those who want to remain competitive. From open source applications to operating systems developed, deploying, delivering and correcting application vulnerabilities must occur rapidly before breaches or compromises occur.

    Here’s the good news: If your company practices authentic agile development and uses highly modular design patterns such as service-oriented architecture, you are well-positioned to achieve DevSecOps success. Why? Because you are already using key strategies that provide solid foundations for secure computing solutions, so you can immediately start experiencing the benefits that come from doing DevSecOps right.

    Follow the Exact Recipe: Don’t Cherry-Pick Ingredients

    DevSecOps emerged from people realizing that DevOps did not adequately highlight security concerns and security should be shifted farther left in the software development life cycle. You should think of DevSecOps as sweetening the existing “recipe” of DevOps by baking security in from the beginning without slowing down the development and release cycles. It may sound obvious, but increasing velocity while reducing risks will guarantee the release of better products because they are built with potential risks in mind (for instance, more and better error handling). This approach results in happier customers and repeat business, which will positively impact your bottom line.

    DevSecOps Requires a Shift in Culture and Mindset

    Let’s face it, the days of successfully deploying applications designed to meet business demands without embedding security controls early in the development life cycle are gone. Effective DevSecOps spans culture, practices and tools that break down silos, orchestrate integrated processes with automated tasks and simplifies security by bringing it out into the open. Instead of “security through obscurity,” boundaries and channels are clearly defined and narrowly focused.

    The benefits of DevSecOps are many and include:

    • Automating security review and application testing.
    • Increasing the speed of delivery enhances product quality.
    • Enhancing compliance with continuous monitoring and auditing.
    • Fostering transparent and open cultures.
    • Reducing costs, development church and application attacks.
    • Delivering increased security and confidence.

    A methodology that uses communication and collaboration to allow for dynamic development and deployment is crucial for responding to change and needs rapidly. When done right, this new mindset will make everyone in your organization accountable for security with a simultaneous mind and talent shift.

    Putting DevSecOps Into Practice: A Checklist

    An efficient DevSecOps program will require continuous management and developer education and process improvement through open collaboration, proactive monitoring and informed feedback. Here’s a short checklist to ensure you’re on the right path.

    1. Build an Environment Conducive to DevSecOps: Engage leaders with a new mentality that makes it incumbent on leadership to understand engineering practices, so they know when things need shorting up. Deeply integrate management, so they support the necessary investments in tools and training while encouraging teams throughout the entire development life cycle.
    2. Ensure Open Communication and Active Training: Promote collaboration and ongoing learning that leads to continuous improvement across the organization. Do this well by providing developers with the training and tools they need. Enable failing fast, early and often so you learn from it and create something useful.
    3. Adopt a Security-Conscious Culture: The driving force behind DevSecOps requires security to be defined at the beginning of a project for repeatable, consistent use. This practice will help you respond to security needs and changes quickly while increasing team collaboration.
    4. Implement Infrastructure as Code (IaC): Without relying on manual processes, IaC helps manage and provision infrastructure automatically. This approach allows code to automatically be rolled out in a repeatable and consistent manner through a version-control system instead of relying on installation gurus and “component owners.”
    5. Use Genuine Agile: Instead of cherry-picking from the agile approach and using your own form of agile-flavored waterfall—focus on practicing “Pure Agile.” This method includes detailed and frequent stakeholder involvement, “fail fast” practices and processes, a “meet the requirements” values and principles mindset and technical excellence.
    6. Adhere to Modular Design Patterns Closely: While object-oriented design (OOD) and service-oriented architecture (SOA) mean different things to different people, the commonly understood key is decomposing large business problems into small business problems that can be addressed by discrete services through boundaryless information-flow sharing.  When done correctly, OOD and SOA will help your applications scale quickly while decreasing costs.
    7. Favor Resource Management over Pride of Ownership:  There is a now-famous analogy about thinking of software components more like cattle than like pets.  While grim, the point is a salient one: When something fails, you should be able to quickly replace it with a new or improved component instead of trying to nurse the ailing component back to health. This mindset better promotes modularity and discreteness of purpose, which, in turn, leads to faster fix and restoration times.

    As virtual environments and cloud usage grow, the need for DevSecOps to be done “the right way” is growing right along with it. But the sense of urgency to implement DevSecOps practices “the right way” hasn’t quite caught up yet. The challenge is to embrace all aspects of DevSecOps day in and day out, instead of just going through the motions of the select practices you adopted.

    The call to action is clear: Now is the time for organizations to move the speed of delivery and secure code out of the textbooks and manifestos into the mainstream.

  • ServiceNow Acquires Sweagle to Advance DevOps Agenda

    ServiceNow Acquires Sweagle to Advance DevOps Agenda

    ServiceNow has acquired Sweagle, a provider of a repository for collecting configuration data that makes it easier to manage IT environments at scale.

    RJ Jainendra, vice president and general manager of DevOps and IT business management at ServiceNow, said Sweagle advances the DevOps initiative his company launched last year by providing a way for IT teams to more easily share configurations created by a variety of tools within a single repository. Those configurations can then be vetted to make sure DevOps teams are not reusing configuration that might be propagating a cybersecurity vulnerability, he said.

    Sweagle is essentially a modern implementation of a configuration management database (CMDB). It will be revamped to have the same look and feel of a ServiceNow application once the deal formally closes in the early part of the third quarter, Jainendra added.

    ServiceNow also plans to integrate Sweagle with its Service Graph, which enables teams to visually track metrics across a service spanning multiple platforms.

    Jainendra said as IT teams deploy applications it’s not uncommon for them to track more than 50,000 data configurations. Sweagle provides an opportunity to bring some order to what historically is a set of IT processes that are becoming more complex as organizations embrace microservices based on containers and serverless computing frameworks.

    Sweagle complements a DevOps initiative ServiceNow launched late last year through which the company is providing increased visibility into DevOps processes to IT service desk staff. ServiceNow DevOps collects metrics from various DevOps platforms that can be analyzed alongside the metrics ServiceNow surfaces using an ITIL-based framework accessed via a software-as-a-service (SaaS) platform.

    Ultimately, ServiceNow doesn’t anticipate DevOps replacing ITIL as much as it sees both approaches creating a need for IT teams to strike a balance across disparate styles of managing IT, each of which places different levels of emphasis on agility and stability, Jainendra noted.

    Naturally, each IT organization will need to determine how best to balance those conflicting goals. In many cases, organizations will decide to manage applications very differently from the underlying IT infrastructure on which they are deployed.

    Regardless of approach, IT organizations have never been under more pressure. In the wake of the COVID-19 pandemic more applications are moving into the cloud to achieve flexibility and resiliency. At the same time, more application code is being pushed out to the network edge. As IT becomes complicated, many organizations are mixing and matching best ITIL and DevOps practices as they best see fit.

    As is the case with any philosophy, there are proponents of DevOps and ITIL frameworks that are not given to compromise. However, most IT organizations tend to gravitate to the middle ground. In the wake of the current economic downturn, it’s probable there will be an even larger inclination toward compromise. After all, the rate at which applications are moving into the cloud is accelerating. However, most of those applications are now being accessed by devices that are more distributed than ever now that more people are working from home.

  • Using Automation Tools to Drive Collaboration, Innovation

    Using Automation Tools to Drive Collaboration, Innovation

    How automation can help business move past the walls of confusion between dev and ops

    In the current state of things, businesses are leaning more than ever on the collective intelligence of their tech teams to drive innovation within their respective organizations. These teams are always comprised of developers and operations professionals. With the foray into automation and the desire for companies to do more with less, it has never been more critical that all individuals, regardless of team, come together to do amazing things. Of all of the services available, Chef is a great example of a suite of tools that want to empower teams to do just that: come together and innovate. It is all about bridging gaps, which can range from simply redefining how teams think about each other to more complex things such as knowledge gaps.

    The first gap that almost always seems to come up when bringing teams together and driving business value is the duties gap. For too long we have sat on opposite sides of the coin. In operations in particular, too often we see ourselves as the ones that have to deal with the aftermath of unfortunate problems within code. But the fact is, we should all care about our systems, we should all care about our code and we should all be ensuring the longevity of both.

    Once you’ve moved past the first hurdle, then comes the gap in knowledge.  Scripting has become pretty common as companies press for automation, but in some instances, it becomes necessary to build up existing team members. Using enterprise automation tools such as Chef, entire teams and entire companies can begin caring about a shared thing: the configuration, health and state of their infrastructure and applications. In doing so, those same teams can begin speaking a shared language. Once this knowledge and shared language are in place, developers no longer view the ops team as an “other,” but rather as collaborators. They can each use their various areas of expertise and speak the same language without having actually having to speak the same language.

    The third common gap is the process gap. Process can represent all of those past processes that a company is reluctant to let go of, which can hinder the ability of the developers and operations humans when they’re attempting to collaborate. The process gap can become particularly difficult to move past without leadership buy-in; as such, it is critical to involve business decision-makers in this transformation. While nearly the entire industry is beginning to move toward more collaborative environments, the entire leadership team must be onboard with the requirements to make changes happen. With the use of automation tools in particular, though, processes can begin to shift more toward collaboration-friendly policies and you can then make the case for further expansion with proof that it can aid in your transformation.

    Empathy is the final gap that must be overcome. The great part about the other gaps is that they work hand in hand to solve each other’s problems. By promoting collaboration, resolving these gaps are also facilitating collaboration. The empathy gap is largely caused by silos of the past that have led to the commonly talked-about “wall of confusion.” Closing the knowledge and duties gap, developers and operations humans can now communicate and understand the same language and processes each is following. This allows the wall to be broken down and operations humans and developers alike can care about both code and stability.

    It’s easy to start getting dev and ops teams working together and on a more even playing field once these gaps have been eradicated. This becomes a big driver for innovation and is, in many cases, a true recipe for success within the company. During my career, I’ve both watched and been involved in these transformations. Working with solutions such as Chef has allowed me to cross the bridge myself, and likewise, be able to share with others how that can be scaled out to entire organizations.

    — Brittany Woods

  • Dev and Ops: Not from Different Planets

    Dev and Ops: Not from Different Planets

    At a conference, I heard a speaker remark that “Dev people are from Mars while Ops people are from Venus.” That’s catchy and captures what a fair number of managers believe instinctively. But is it really true? I’m not convinced.

    We all know that DevOps enables us to deliver software faster, with fewer bugs and much less downtime than traditional approaches. But DevOps is new, complex and often challenging for teams to embrace. Developers often guard their tools and operations shake their head each time they hear about some new asset bundling package they have to support. I think the first few meetings of Dev and Ops probably do a lot to build the notion that they are from different planets.

    In my experience, however, the opposite is true. To borrow a different popular catchphrase, they are more “brothers (or sisters) from a different mother.” When you examine the makeup of Dev and Ops people, you find more similarities than differences. Here are some examples of their common ground:

    • Consistency and Standards. Both Dev and Ops are technical endeavors that place a huge premium on things being “precisely” correct. Whether coding a service or setting up an AWS instance, “in the ballpark” doesn’t cut it. For this reason, both camps try to establish standards for how they work. Whether keeping Dev teams all using the same environment or Ops trying to keep Dev, testing and products all running the same, both need to benefit from building consistent environments.
    • Coding Skills. Whether coding or scripting, Devs and modern Ops teams need to be comfortable in a variety of highly technical tools. Build scripts, deployment, automated testing and reporting all require some coding skill.
    • Common Tools. If you look at the DevOps ecosystem, you’ll increasingly see tools that are intended for both Dev and Ops tasks. Dev people, for example, use Git for reusable code; Ops uses Git as well for configuration of things such as Docker. Also, Dev uses Jira to track bugs while Ops uses Jira to track tasks.
    • Shared Metrics. While their focus may be different (code versus pipeline), both Dev and Ops share many metrics of success—consistent delivery, fewer errors, responsiveness to customers and uptime, to name a few.
    • Test-Driven. Dev and Ops both embrace the “fail fast” mantra. They want to know if a change will break anything as soon as possible, long before it ever impacts a customer. Both often start with automated tests, which are run on Dev or local instances, to verify the changes are non-breaking.
    • Love of Automation. Neither Dev nor Ops enjoy manual, error-prone work. Both gravitate to tools that automate routine tasks, reducing variances and errors.
    • Star Wars. Finally, both groups are avid “Star Wars” fans. Just watch how they open automatic doors using the force or name servers or other things with sly “Star Wars” references (such as “Secret Rebel Base”). In fact, next time you’re in a DevOps meeting and somebody is wondering if Dev and Ops can get along, bring up Jar Jar Binks and marvel at the immediate—there will be a completely concordant reaction from both sides.

    So, are Dev and Ops from different planets? I don’t think so. I see Dev and Ops as being like those twins separated at birth, who, when reunited decades later, laugh the same, have the same twitches and both married spouses with the same first name. And in the best DevOps shops I have seen, that’s a really good thing.

    — Joshua Platt

  • IoT, Not People, Now the Weakest Link in Security

    IoT, Not People, Now the Weakest Link in Security

    Do a quick search on “people weakest link” and you’ll see a raft of articles in which cybersecurity experts and computer scientists point to employees or end users as the biggest vulnerability. No doubt, people do silly (or outright abusive) stuff and open the door for a variety of enterprise security problems. Spoiler alert: There’s this technology called the Internet of Things (IoT) and it’s a bigger security risk than people ever were. The new theme of this rapidly changing IoT security story is data integrity.

    Increased cybersecurity risk is due in part to the variety of environments IoT applications touch. Most at-scale IoT deployments use some form of a three-tier architecture, with edge, gateway and cloud components.

    • Edge devices are those connected sensors and actuators touching the real world. They are usually small, low-power devices often running a wireless protocol such as Bluetooth, Thread, ZigBee, Z-Wave, sub-GHz, low power wide area (LPWA) networks, cellular IoT technology, Wi-Fi or other protocol.
    • Gateway devices are hubs that groups of sensors connect with. One big role of the gateway is to translate the various protocols from edge devices into Internet Protocol (IP) for transmission into an enterprise network. Gateways also perform a key role in provisioning edge devices securely. Smartphones running Android or iOS often serve as a gateway for consumer IoT devices. For industrial IoT devices, multiprotocol gateways typically are built on a small form factor computer running a real-time operating system or Linux. Edge computing or fog computing architectures use enhanced gateways for more algorithm processing.
    • Cloud platforms are very familiar to most enterprise developers. In IoT apps, data from the edge arrives for processing, storage and presentation. Algorithms can run on a server cluster or in a distributed computing framework such as Hadoop or Apache Spark. Business intelligence and predictive and prescriptive analytics also reside in the cloud.

    In our practice, we see many IoT cybersecurity issues that can be mitigated with proper attention to two areas. The first is shutting down simplistic endpoint attacks by using basic connected device security measures. Avoid edge devices that ship with a well-known default password or PIN—compromising those defaults can be as easy as a battery pull and a factory reset. If a device uses encryption, make sure it doesn’t use a hardcoded key that, if cracked, compromises an entire family. Look for edge devices using over-the-air (OTA) programming allowing for security updates over a long life cycle. As more device developers gain IoT security experience and provide the right features, closing these basic weakest links is easy.

    Now, for the more startling weakest link. When the IoT application runs, is the data any good? According to a just-released survey of 950 IT and business decision-makers, only about 48 percent of companies are confident they can detect an IoT security breach. (BTW, don’t get me started on blockchain; it’s one tool, not a panacea.) A lot can happen before your people get involved. By then, it may be too late.

    Data integrity needs constant monitoring during at-scale IoT deployment, not just during pilot. An easy way into an unprotected IoT network is to add an unauthorized edge device at a gateway, then use it to access other devices. Gaps in end-to-end encryption are also easy exploits. Untrustworthy public cloud elements are also bad news—a big reason we recommend hybrid cloud architecture. A private cloud layer gives you more control over algorithm performance and data stream security. Presentation and archiving can be left to a public cloud layer.

    Bad data can come from either a compromised or faulty device. It propagates quickly across a system, and when an unwitting user at the presentation layer runs a business intelligence tool on it, the bad data could cause issues. How do teams hunt down vulnerabilities and faults that lead to corrupted data and results?

    • Hire a penetration tester, preferably a contractor removed from your day-to-day development who can objectively assess your architecture during pilot and reassess it during deployment.
    • Ensure your architecture can tolerate edge device or gateway failures without ripple effects in algorithms; in other words, protect the application from prolonged operation on bad data streams.
    • Before turning AI loose on automated decision-making, consider an AI-based IoT security analytics tool to spot anomalies and quickly bring people into the loop.
    • Retarget at least part of your cybersecurity experts to ongoing data integrity efforts and help them stay abreast of IoT technology and trends.

    This all sounds like a good job for DevOps, doesn’t it? You know what to do about people; now you’ll need to work magic with devices. The long-held security axiom that people are the weakest link is no longer true when IoT applications run unattended all the way to presentation. There are a few exceptions when people have more interaction at the edge, particularly in the medical device arena. Generally, we’ll see bigger and bigger IoT applications with more data, more processing and less interaction with people.

    If someone on the IoT says there’s a security hole you can drive a truck through, they may mean it literally. Data integrity measures will be critical for DevOps teams moving forward. Do you agree? What types of data integrity issues are you seeing in IoT applications?

    — Don Dingee

  • Using Continuous Backup to Keep Pace in an Increasingly DevOps World

    Using Continuous Backup to Keep Pace in an Increasingly DevOps World

    How continuous backup can help DevOps teams keep working with the right data

    The world of software engineering has changed; in fact it’s constantly changing. We’re moving on from the days of waterfall when big-budget releases with multiple features per version were the norm. Now, to compete, organizations have to implement agile development, with shorter release cycles and fewer improved or new features at a time. Modern software development has evolved to a practice of continuous development to the point that each new release feels like a simple patch rather than a dramatic overhaul.

    This has completely upended the testing process. Release cycles are a fraction of the time they used to be and the previous QA methods don’t stand a chance to keep pace. The latest model combines developers, operations, testing and security into close-knit teams. Development cycles are shortened and testing and deployment are automated from the source. All of this blending of teams and processes has been dubbed DevOps.

    This new paradigm for operations and development has been made possible by the flexibility ushered in by virtualization and the snapshots that can be made for a point-in-time failback. Yet, limitations remain that can keep technology from supporting the advanced needs of DevOps teams. More is still needed to keep environments up to date because once a snapshot is deleted, the data that it represented is gone.

    New tools have emerged including Docker, Kubernetes and Puppet to help on the operations side, but development teams can still be expensive if they aren’t used efficiently and effectively. Any amount of downtime or idle waiting for a database to be refreshed from production or for any sort of regression testing environments to be instantiated is burning money. DevOps processes can do this, but they aren’t effective if they don’t have a continuous stream of recovery points.

    The Quality of Code

    Development can only be as good as the copies of production data that a developer has to work with. The challenge is to get a current copy of production data in a reasonable amount of time. If it uses simulated test data designed to mimic production, results can be shoddy and defects can occur more frequently.

    A continuous backup solution with search and recovery across data, files or VMs from any point in time can make development and testing easy. Spinning up a clone of production environments is simple if you have multiple copies of data in different locations in a one-to-many configuration. Production data can then be replicated to DR facilities for protection, but also to development, test and QA environments to assure that developers and testers are working on the same, latest version of production data.

    Production replicas along with the simultaneous use of a proper API can allow the orchestration of test builds and deployments without manual intervention. This is essential because being able to perform tests on good, reliable data can significantly reduce the amount of code defects deployed into production.

    Confidence in Changes

    Because you can spin up real-time replicas of production workloads with ease, developers don’t have to guess what might happen when they push a new code update into production. Instead, the can reproduce an exact replica of production that has the latest data to an isolated area where it can’t affect production users. In this environment, they can observe the results without any risk.

    — Gijsbert Janssen van Doorn