devopsy.kinsta.cloud

Category: Enterprise DevOps

  • 4 Challenges OEMs Face When Implementing New Technology

    4 Challenges OEMs Face When Implementing New Technology

    Like many others, the manufacturing industry is moving to a subscription-based business model. This new way of doing business is being referred to as servitization and it is forcing manufacturers to no longer strictly sell new products, but instead sell access to and the outcome those products deliver. This is fundamentally changing the way manufacturers have traditionally done business and is not only encouraging a shift to subscription-based pricing models, but also Products-as-a-Service.

    As manufacturers implement the processes and resources necessary to make servitization a reality, implementing new technology will be key to success–laying the foundation for success today and in the future. More specifically, machine learning and predictive analytics will become especially important for predictive maintenance, process optimization and supply chain management. While there are opportunities to capture a significant competitive edge using these technologies, there are also significant challenges specific to the manufacturing industry. Some of these noteworthy challenges include:

    Efficient and Secure Data Connectivity

    Complex, capital equipment (think construction equipment, agricultural equipment or industrial machinery) is built and designed to last, on average, 30 to 40 years. As a result, these machines must be very reliable. Today, however, the majority of equipment in service has upwards of 20 to 30 years remaining in its lifespan. However, almost none of these products were built or designed for IoT connectivity–creating the challenge of retroactively fitting existing equipment with IoT-enabled parts.

    In addition, a majority of this equipment operates in some of the harshest and most rugged environments in the world. Whether it’s an electro-submersible pump 3,000 feet below the surface of the ocean or a mining truck in a remote mine with little to no cellular connectivity, efficiently connecting this type of equipment to collect relevant data is a difficult challenge and oftentimes cost prohibitive.

    Even if manufacturers manage to connect this equipment, there is an added challenge of doing it in a way that ensures cybersecurity. Rogue elements that could gain malicious access to this equipment could have serious safety and economic consequences–and could even implicate national security in some instances.

    Sparse Data

    Newer machine learning algorithms, such as Deep Learning and Recurrent Neural Nets, have been groundbreaking for capabilities like image and voice recognition. However, these algorithms are also very data hungry, requiring millions–if not billions–of similar data points from millions of users.

    Because complex industrial equipment is intended to last for decades, failures are generally rare. Think about it: There have been just a handful of actual engine failures during flights for the entire global commercial fleet, which amounts to nearly 30,000 aircraft. Assuming an average of 2.5 engines per plane, the global commercial aircraft engine fleet is less than 100,000. While certainly a large number by itself, it is relatively small when considering these engines vary greatly in design and thus any single engine type that could be modeled together would be even smaller.

    Manufacturers of industrial equipment or durable goods also tend to be reluctant to share data, especially if their competition could potentially benefit from it. The challenges of efficient connectivity, rare failures and relatively small numbers of similar equipment in a fleet leads to the sparse data problems in the Industrial IoT (IIoT) realm.

    Domain Expertise

    While domain expertise to successfully apply machine learning and predictive analytics is required in the consumer world, in the manufacturing space, it is much more critical. Machines and processes are designed using physics and engineering principles. And, the context in which machines operate and behave is very important for accurate training models and analyzing results. Without appropriate context, there becomes a “garbage in, garbage out” problem as sensor data and machines alone do not capture or provide any context. This is where domain experts who can make sense of historical data for accurate model training as well as interpreting results are critical.

    The impact of making an incorrect decision can have expensive–and sometimes catastrophic–results that aren’t seen in the consumer-facing domain. For example, re-routing an aircraft mid-flight could cost millions of dollars for an airline. If that decision is made because of bad data and an incorrect prediction, it would be a very costly mistake. For us as consumers, we have some aspect of domain expertise for problems in the consumer world, whereas a trained pool of engineers with the relevant design, operational and maintenance expertise is a very small pool. And this, combined with the problem of baby-boomer retirement where expertise is lost at a significant rate, there is a real challenge to capture the knowledge and best practices required to deliver value.

    Data Ownership

    Currently in the manufacturing sector, there aren’t industry standards for data security, ownership or accessibility. Currently, many manufacturers are wrestling with who owns and has access to the data. Is it the manufacturer who designs and builds the equipment? Or, is it the third-party entity that rents and operates it? Or, is it the financial entity that may be the legal owner? What about the supplier that provides a component that is part of a larger piece of equipment (e.g. an aircraft engine that works in conjunction with the aircraft, with each component manufactured by a different entity)?

    Manufacturers being risk-averse in nature, are being very conservative in interpreting and applying the myriad patchwork of regulations being brought in other industries, including data security standards. This is limiting them in adopting more connected processes and strategies. The industry must accelerate efforts to establish industry-wide standards as well as regulatory frameworks for data ownership, data-sharing, interoperability and testing of systems and end-to-end security to overcome the roadblocks for faster adoption of these technologies and realize the promised benefits.

    The shift to servitization will require manufacturers to completely re-think how they operate–new organization structures and skilled resources, new incentive models, new KPIs to measure success and new processes. They will have to become data-driven organizations investing in technologies to connect and track products, collect data and efficiently analyze massive amounts of operational and service data, using technologies like IoT, machine learning and predictive analytics. This will strain manufacturers’ existing organizations and IT infrastructures, necessitating investment in highly scalable, cloud-based solutions to lay the foundation for a successful future. Manufacturers that embrace these changes will be the winners, while others will struggle to stay relevant. In fact, the ones that can successfully adapt to these paradigm shifts will be able to gain significant competitive advantage and market share.

    — Vivek Shah

  • 5 Tips to Eliminate Knowledge Gaps in Dev and QA

    5 Tips to Eliminate Knowledge Gaps in Dev and QA

    To create and release high-quality software, the software development lifecycle (SDLC) was established using different roles and processes designed to work seamlessly together. This approach is of critical importance because it spans the initial planning phase, all the way through production release and monitoring.

    Roles vary within projects but typically include designers, business analysts (BA), developers, testers, scrum masters, project managers, product owners (PO) and technical architects (TA). Each one brings different expertise and skills to a project but ultimately, they are meant to collaborate and determine how to implement different aspects of the software.

    The amount of processes can also vary for projects based on team size, release schedules, availability of resources and the complexity of the software.

    What is the Knowledge Gap?

    Without a distinction of responsibilities or a roadmap that identifies who owns each task in the SDLC, everyone assumes someone else will complete the tasks. The result is that the majority of these important steps remain incomplete or undone.

    The reason this happens is because a knowledge gap exists among the team. This is especially true when teams are a mix of entry-, mid- and expert-level individuals. Sometimes, assumptions are made regarding the skill set, experience and domain knowledge that each individual brings to the project. Knowledge gaps can also develop at a more granular level, with teams using the same tools but in different ways. As an example, developers and testers might be using a single testing platform quite differently.

    As teams begin collaboration on features for the software, they may encounter the following situations:

    • Each team member has a different interpretation of the project requirements
    • Developers assume testers have their same level of technical expertise
    • A lack of ownership and assigned responsibilities among the team
    • A PO has a feature idea and each team member has different ideas for how that feature should work
    • The TA explains how a feature should be implemented using technical jargon that designers, POs, BAs and testers don’t understand
    • A tester is not allowed appropriate time to complete testing due to tight release schedules

    Identifying Knowledge Gaps

    Knowledge gaps not only negatively impact the release of high quality software, but also team morale, productivity, job satisfaction and empowerment. The first step to finding acceptable solutions is to identify exactly where a knowledge gap exists. Some questions to help teams do this include:

    • What are the common problems that occur in each phase of the SDLC?
    • What processes are in place during the requirements, design, development, testing, acceptance and release phases of the SDLC?
    • How effective is the communication between different roles in the team?
    • Are the responsibilities of each team member clearly identified?
    • How visible is the status of the project at any given time?
    • How often are release cycles pushed to accommodate for more development and testing?
    • Are the teams aware of what kind of customers are going to use the product?
    • Is the velocity of the team stable? How often does it fluctuate and by how much?

    Bridging Knowledge Gaps

    Finding gaps in a team’s knowledge is the first step. The next step is determining how to narrow the divide. The following key factors help bridge the knowledge gap in teams:

    Training

    Sufficient training and tools should be provided to help teams do their jobs better. Proper training has a domino effect on the success of the project. It helps designers understand how to design mockups so developers can effectively implement the feature; testers can attend code reviews without intimidation and use tools more effectively; developers will understand why the testability of a feature is important and understand which tools can aid the development testing effort; the scrum master can better manage project tasks; the project managers can ensure the team collaborates to meet release schedules and deadlines; and finally, stakeholders can have an overview of the project through reports that are generated using various tools.

    Visibility

    For teams to work seamlessly together, we need to ensure the results of everyone’s efforts are visible to the entire team. It is important to understand how each contribution maps to the overall goals of the project. To increase visibility, teams can consider using the following:

    1. Checklists: a list of items to be completed during each phase of the SDLC. If the items in the list are marked as done, then there is no ambiguity about which tasks need attention.
    2. Visual Dashboards: give a high-level overview of the project’s health and status. These can be created on whiteboards, easel boards or in software and during daily meetings, teams can address the dashboard to ensure everyone, including business stakeholders, are aware of the high-level project status.

    Clear Definition of Roles and Responsibilities

    Each person needs to understand his/her role on the team, as well as the tasks they must accomplish on a daily, weekly, monthly or quarterly basis. Goals, objectives and expectations for each team member should be defined and discussed with respective peers and/or managers. This eliminates confusion and increases productivity and task completion.

    Empowerment

    In an age where individuals are increasingly more technical and skilled, what they still lack in their job functions is empowerment and autonomy. Contrary to the conventional wisdom that a project needs a single leader, the leadership responsibility can be effectively divided within each role on the team. Having one point of contact each from the design, development and testing teams means each can help to lead their respective sub-teams and help to ensure everyone within the project is working toward the same goals and objectives. By operating within this structure, the whole team becomes empowered.

    Experimentation

    Once sprints are completed and knowledge gaps have been identified, the whole team should come together to discuss solutions to existing problems. Based on this discussion, the team can start experimenting with different solutions to determine what works well or doesn’t. This constant experimentation and feedback loop helps to make the team more creative and empowers them to come up with solutions that work for their organization.

    In summary, the knowledge gap has been a major obstacle for development teams in reaching their fullest potential. By identifying and reducing these gaps, teams can be more efficient and achieve faster release cycles with higher quality software.

    — Raj Subramanian

  • Best Practices for Software Change Assessment

    Best Practices for Software Change Assessment

    Business spending on enterprise software has been on a constant rise over the past decade with 64% of businesses spending more on IT operations in 2018. It is estimated that in 2019, the number will reach $462 billion worldwide. This not only includes the procurement or development of new software and digital innovations, but also investments in modifications and upgrades.

    However, implementing software changes is no easy feat. It involves serious financial investments and staffing resources, which is why it is critical to get it right. A well-implemented change assessment is a key component of every software change project. This gives decision-makers an accurate and complete understanding of the impact of the software changes and identifies potential disruptions to specific departments, functions and processes.

    There are many ways to approach and implement software change assessment. These best practices can ensure a glitch-free software change rollout.

    Use a Comprehensive Discovery and Dependency Mapping Technology

     One of the disadvantages of the modern workplace across all industries is the emergence of information silos. They can hamper growth and efficiency and cause other problems, including redundancy of effort, stalled collaboration and other missed opportunities.

    In order to break these silos, efficient application discovery and dependency mapping is a crucial step in every software change project. Unfortunately, most businesses are failing miserably in this department. A Forrester survey revealed 56% of IT managers “do not have a complete view of dependencies between applications or between applications and infrastructure.”

    The same survey revealed 30% of the IT managers think that having a complete inventory of all enterprise hardware and software in use at their organizations is critical for IT efficiency. Ironically, 42% do not collect the necessary software data, while 39% are maintaining their inventory manually.

    The disadvantages of inadequate discovery and inefficient dependency mapping include low productivity, project delays, increased overhead costs and poor team morale, among others. A key step in solving this predicament is investing in the right discovery and dependency mapping technology, which can support a solid foundation for a software change initiative or any IT project for that matter.

    A reliable, agile software solution should provide both macro and micro views. The more granular, the better. Additionally, it should be able to give IT decision-makers a consolidated view of their application stack across multiple message queues, APIs, databases, unifying codes and languages.

    Use the Seven R’s of Change Management

    One thing IT managers should realize when assessing software change is, they’re not pioneering the process. Many organizations have done it and made mistakes along the way. Experts have used these mistakes and learnings to create roadmaps for others.

    One of the most well-established resources for IT change management is the Seven R’s of Change Management conceptualized by Information Technology Infrastructure Library–a set of detailed practices for IT service management. The seven Rs represent the following questions designed to help businesses make educated decisions on how to proceed with change requests.

    1. Who raised the change?
    2. What is the reason for the change?
    3. What return will the change deliver?
    4. What risks are there if we do or do not carry out the change?
    5. What resources will be required to perform this change?
    6. Who is responsible for this change being performed?
    7. What relationships are there between this and other changes?

    While these concepts are not exclusive to software change assessment, they provide a solid framework for businesses to identify noteworthy software change projects. This is especially helpful for organizations creating their software change assessment protocols from scratch.

    Never Skip Impact Analysis

    This is especially important for software vendors who are operating on tight budgets and strict deadlines. Software change impact analysis encompasses five major areas:

    • Identifying the impact of the change request on the software development project or on a business’ IT infrastructure.
    • Determining all software resources that need to be modified to implement the requested change.
    • Calculating the cost and manpower capital needed to perform the change request.
    • Ensuring the requested change complies with internal and external regulations.
    • Eliminating or minimizing any security risks associated with the change.

    To make sure businesses covers all the bases for any software change initiative, it’s best to use a checklist or template sourced either from the technology vendor or one their IT team put together, tailored to their needs.

    Not All Changes Are Created Equal

    Today’s ever-changing business landscape dictates business technology must evolve to keep up with an organization’s shifting needs. Software changes, when implemented strategically, can help businesses achieve new heights in productivity, efficiency and profitability.

    To ensure software changes serve this purpose, IT project managers need to implement an airtight software change assessment system. With the help of technology, checklists and well-established industry best practices, organizations can quickly outline a process that yields beneficial results in the end.

    — Aditya Sharma

  • Measuring Success in DevOps: Top Four DevOps KPIs

    Measuring Success in DevOps: Top Four DevOps KPIs

    There is no news in DevOps concept. Many companies have integrated DevOps to improve and accelerate software development and help drive their digital transformation, and that number continues to grow exponentially. There are now entire tool ecosystems, methodologies and transformation models—as well as endless resources—available to guide companies along the DevOps journey.

    But DevOps success can be difficult to measure. DevOps isn’t a formal framework; it’s more of a culture and a set of practices, and there is limited guidance available to ensure you’re doing it properly or accurately measuring your successes and failures. DevOps also looks different in every organization—no two DevOps shops will be the same.

    However, despite the nebulous definition of what a DevOps organization looks like, there are some core key performance indicators (KPIs) that should be common to all DevOps environments: asset management, monitoring, continuous integration/continuous deployment and continuous security.

    Asset Management

    In this context, asset management means measuring what is automated and how effectively it is controlled. It doesn’t matter if you are using tools such as Puppet, Chef, Ansible or Terraform; what matters is how effectively you use them. These tools allow you to automatically provision bare-metal or cloud assets, as well as join a load balancer and receive traffic. However, you can achieve similar results from Kubernetes or chaining lambda functions. Automation is really about controlling assets to achieve your business goals.

    Whether you’re using on-premises virtualization or cloud workloads, taking the time to streamline your processing cycles down to the minimum hardware required can significantly reduce monthly costs. The higher the percent of your servers, containers, services, etc. are automated, the less time you’ll spend fixing and maintaining your infrastructure. Some of your applications may be uniquely configured to your particular organization, and therefore cannot be automated. However, if applications cannot be automated, it might be time to retire them and build next-generation applications.

    Monitoring

    Should you be monitoring all of your resources? Yes. Should you also filter out the noise? Absolutely. Monitoring agents should be deployed to all of your servers, and if your PaaS tools and other providers have integrations, you should be using them and parsing out unneeded data. The only thing worse than not monitoring anything is monitoring everything without proper filtering.

    Good monitoring should always be coupled with utilizing the information acquired. Capturing logs, parsing them and using tools such as ELK, Datadog or Sumo Logic, for example, give you a large kit that can not only capture and glean useful information from a tremendous amount of data, but can also make decisions and perform predictive analyses. You might learn your stack is operating inefficiently, or not scaling fast enough during peak utilization periods.

    Disparate systems should be aggregated into a common tool, lest you spend valuable time combining information across systems or pulling information from data warehouses to get your insight. Let the tools do that work for you. You should also be using tools such as Logstash to pull and understand application, database and other logs in your stack for meaningful data. If not, you’re limiting your insight into the service’s health.

    Continuous Integration/Continuous Deployment

    Continuous integration and continuous deployment (CI/CD) is the difference between releasing software once a quarter (or year) and performing dozens of releases to production within a day.

    But it’s one of the most difficult indicators to measure, since every environment is different. It is important to understand how many code commits don’t make it past your integration environment. These blockages could be the result of poor programming practices, poor code quality or poor testing. However, if features stay in dev or integration for too long, there is surely an underlying issue. In most cases, it centers around automated testing.

    So, how do you measure good testing? This is one of the most difficult questions enterprises face, especially when automated testing is added after monolithic applications are already written. Essentially, good testing is about creating good business logic and integrating testing that meets most use cases, while covering each function and class. Immediate feedback on failed or successful tests expedites the automation process. The less automated testing is built, the more QA has to test by hand. Failing to integrate good business and integration testing slows down the entire CD part of the pipeline significantly. Also remember shooting for 100% test coverage is unrealistic—over 80% should be sufficient.

    It’s also important to remember applications that are not in a pipeline and must be manually tested will never keep up with the pace of cloud-born innovation. If you are dealing with a giant, monolithic legacy app, it’s time to design its replacement (starting with testing). Pipelines should also have notifications built into them, with chaining logic to react to failures. Tools such as Jenkins, CircleCI, TravisCI and most code repository solutions, such as GitLab, offer rich feature sets to aid in pipeline creation and management.

    Continuous Security

    The easiest way to ensure security compliance is to shift left and resolve security issues in the development stage. Too often, security is applied at production, which means it’s not part of the environment’s end-to-end process. Securing applications and networks at the development level will give you more confidence that applications will interoperate properly at the production level.

    After shifting left, make sure you continuously deploy and monitor your clusters, nodes and pods in a secure manner. Ideally, you have a tool that provides a real-time summary of your cluster’s compliance and security status by looking at workload security and governance checks, cluster worker node CIS Kubernetes Benchmark checks, cluster Ingress controller security best practices and istio security checks.

    DevOps Success Never Ends

    Success in measuring your core DevOps KPIs is not about getting to full automation immediately—it’s about understanding your biggest issues, continuously securing them and improving them over time. DevOps has no end; success requires continuously measuring your progress and improving your environment with the most effective and up-to-date tools. Take control, implement thorough and meaningful monitoring, deliver with confidence and do it securely.

    — Gadi Naor

  • The Barriers to Robotic Process Automation, Part 1

    The Barriers to Robotic Process Automation, Part 1

    It sounds alluring enough: Intelligent bots step up and do the menial tasks humans would rather (probably) not be doing–or employers would rather they not, in order to slash costs. But streamlining business processes with robotic process automation (RPA) isn’t as easy as setting and forgetting a software bot as if it was an automated rotisserie.

    Still, many enterprises forge ahead as if that’s the case. This rush forward is likely one of the top reasons, as consultancy Ernst & Young found, as many as 30% to 50% of initial RPA projects fail.

    This isn’t a reflection of RPA technology or its capabilities. It’s generally the result of organizations rushing forward without doing the right upfront work necessary to prepare for heightened software autonomy and automation. To find answers, we reached out to experts to get their thoughts on the most common barriers to the effective enterprise deployment of intelligent automation.

    “The number one success factor for intelligent automation is visible sponsorship,” said Jesse Tutt CEO at mattress company Gotta Sleep. Tutt claimed having visible sponsorship is essential because the biggest barrier to RPA success is often resistance from both management and staff.

    “Management often have little capacity to allocate time to improvement and secondly resist intelligent automation as they have a perception it may negatively impact staff satisfaction,” said Tutt.

    Tutt said the second barrier is the lack of staff with broad skillsets in data, analytics, software development and RPA necessary to succeed. Good data is necessary to support the analytics that will drive the automation.

    In addition to data and analytics skills, automation teams also need to be good software developers. Typically, most automation projects are accomplished through direct database or API interaction, Tutt explained.

    “Lastly, in cases where systems are antiquated, are only accessible published applications, or which require mouse or keystroke interactions, robotic process automation skills are required,” said Tutt.

    Salvatore Stolfo, founder and CTO at Allure Security adds another barrier: the elusiveness of the AI-powered minimum viable product (MVP). Stolfo said, like any complex application, the difficulty is driven predominately by the complexity of the problem, business considerations and computational constraints.

    “To achieve an MVP, the performance of the machine learning engine must achieve accuracy levels that make the application work well enough for the intended market solution. There is no magic bullet,” said Stolfo.

    Niraj Patel, managing director, artificial intelligence practice at enterprise technology consultancy DMI, said enterprises are floundering when it comes to RPA because they spend insufficient time understanding the customer experience and therefore the ultimate value derived from automation; they lack clean data sources which gets in the way of generating the intelligence; and legacy applications that don’t lend to plug-play of newer modules such as RPA and machine language components; and unrealistic expectations when it comes to robotic software processes.

    In part 2 of this story, we will tackle how organizations can beat the barriers to robotic process automation.

    — George V. Hulme

  • Bringing 5G-Enabled Digital Services to Life Calls for Cloud-Native Operations

    Bringing 5G-Enabled Digital Services to Life Calls for Cloud-Native Operations

    Spotify, Netflix, IoT connectivity and cloud storage are a few examples of the digital services providing new options for fun and function to consumers and businesses alike, while representing a growing boon for communications service providers (CSPs).

    Gartner predicts by 2020, nearly one quarter (23%) of CSPs’ large enterprise business communication revenues will be driven by digital services—up a staggering 10 percentage points from 13% of revenues in 2017. This gain should come as no shock to developers who favor building in the cloud or using tools such as Microsoft Teams to collaborate, or who stream video from HBO Go or skim stories in Apple News during their commutes. Today’s customers (consumers or businesses) expect value-driven, digitally enabled services that inspire personalized and meaningful experiences with their brands of choice.

    The good news is companies are eager to meet demand: CSPs want to deploy services in the cloud to address the challenges of web-scale companies. In fact, 85% of companies surveyed say launching new digital services is critical to their business strategy.

    What’s the catch? To do it, they’ll need to be agile. Although telecom is not an industry known for its agility, and is often thought of as the opposite, it has been transforming—like many industries—through adopting more agile approaches in business strategy. CSPs are striving to maximize resources and reduce inefficiencies, while at the same time sparking innovation. Nothing has been more of a stimulus for agility than the cloud, especially for the web-scale companies whose services pose the greatest threat to the telco industry.

    A key requirement will be cloud-native applications that improve the agility of network functions. However, being cloud-native involves a lot more than just shoehorning code into a container previously ported from an appliance to a virtual machine.

    Rather, at Oracle, cloud-native means faster development and deployment through DevOps and continuous integration and continuous delivery (CI/CD) pipeline. CSPs can only achieve an agile cloud with an environment enabling developers to innovate true cloud-native solutions if they implement an operational framework that embraces a key set of principles. Specifically, we at Oracle have identified the principles for successful cloud-native operations.

    System Immutability

    Everything, including software and configuration, is code. All changes are made through CI/CD, where they are deployed as immutable artifacts. No manual configurations or customizations are allowed. This makes it easier to implement the principle of least privilege as there is no need to run scripts in the production environment. Also, any changes not coming though the delivery pipeline can be considered malicious.

    Automate Everything

    All aspects of build, test, verification and deployment are automated. This includes activities such as backup, recovery, password/key rotation, etc. Fully automating the DevOps pipeline, including verification and testing, removes much of the potential for human error. This automation also allows changes to be applied to the environment with confidence and provides for rapid repair.

    Disposability

    All services are transient and treated as short-lived. Instead of focusing on never failing, services are designed to go up and down quickly without service interruption. Regular repaving (re-deployment) of the environment ensures failed or failing services are removed and new ones deployed.

    Externalized Configuration

    Configuration (including passwords, credentials, location of backing stores, etc.) is decoupled from the software image, and like software, can be treated as a build artifact in a controlled and versioned manner. Versioned configuration enables development and production parity as an artifact and can eliminate costly operational errors.

    Logs as Event Streams and Constant Telemetry

    Everything needed to debug or diagnose any functional, operational or security issue is found in logs, traces or metrics data. These are treated as a stream of time-ordered events and stored in a centralized collector outside the system, enabling better threat monitoring, forensics and diagnostics through event correlation or analyzing the aggregated and holistic view. Constant telemetry is fundamentally enabled through logs as event streams and, thus, the two should always be considered together.

    Delegated Governance

    Some shared aspects of the environment are centrally managed like networking, identity management or infrastructure, but in a true DevOps fashion, teams delivering a service are responsible for operating the service. This is allowed only with strict governance, enforced through checks in the continuous delivery pipelines, giving greater control over rate of change. Business agility is improved as applications have better visibility into the operations of their service with tighter feedback loops that ultimately improve quality.

    Independent Lifecycle

    Independently upgrading, scaling and deploying each microservice is paramount for supporting other cloud-native principles as well as minimizing the amount of change in the system at a given time. Furthermore, such decoupling makes other principles, such as repaving, easier and promotes easier isolation of issues.

    As 5G introduces increased connectivity and speed, along with the need for more security and reliability, service providers will need the agility, flexibility and security of the cloud and cloud-native principles. These principles are enablers for better cloud operations. Together, they provide the ideal context in which to implement a broader view of the Cloud Native Computing Foundation (CNCF) landscape, giving developers a robust Platform-as-a-Service of backing services beyond just containers.

    As 5G moves from a fabled future to a reality, the market for digital services that reap its benefits is likely to continue to grow. By leveraging these principles, along with DevOps and the CI/CD pipeline, organizations will be able to evolve and prepare for 5G’s promise for innovative business models and new revenue streams—be they digital services or beyond.

    — Shirin Esfandiari

  • Autonomous Security in Containers

    Autonomous Security in Containers

    With the advent of DevOps, the development world has quickly moved to agile development practices and containerized applications. At Forum Systems, we have responded to this trend by putting our API security software, Forum Sentry, into virtual form factors such as Amazon Machine Image, Azure Image, VMware Image, Linux, Windows and Docker.

    Why do we feel it’s necessary to containerize API security in this way, and what benefits does it deliver over traditional software or even hardware-based API security?

    What Is API Security?

    Before we explain why we containerized our API security software, it is first necessary to define exactly what we mean by API security. As a result of the major IT trends of the last decade–in particular cloud, mobile and IoT–more people and applications are connecting to IT assets than ever before.

    What’s more, the majority of these interactions are from untrusted entities outside the organization’s network perimeter (and as you will read below, across container boundaries). Securing your organization’s systems, data and business-critical processes is harder than ever.

    Almost every interaction relies on an API to communicate to an application or system somewhere in the world. The simplicity of APIs makes it easy for developers to connect their projects to other systems to enhance their functionality, with data being easily shared between a myriad of external partners, cloud providers, virtualized data centers and on-premise applications.

    As a result, APIs have become the primary channel for business transactions and the traditional boundaries of data exchanges have become blurred. APIs provide many benefits but also present risks, as wherever there is innovation, there is also the dark side of threat and attack, and always someone who will aim to exploit weaknesses.

    In many environments, APIs and their underlying technologies are designed primarily to share data; they are not designed to thwart threat and attack. This is where API security gateways are necessary to validate both the data and the identity of users, systems and devices interacting with the API.

    API security goes far beyond just access control, it requires specialized technology to perform dynamic data security to inspect and ensure the specific and unique characteristics of each API communication are correct. The API security policies are designed to prevent intrusion, data leakage and other forms of data loss as a seamless and transparent part of the technology architecture.

    API security gateways differ greatly from API gateways; the key word “security” immediately distinguishes this technology from simple API gateways, which serve only to provide proxy and simplified access control points. API security gateways are purpose-built to protect against API threats, and the dynamic data security capabilities they offer provide centralized protection of bi-directional API communications. API security gateway technology provides essential risk mitigation at each layer of the API architecture, and as rising adoption of containers and micro-service architectures arise, it provide zero-trust concepts within and across the container boundaries to protect the assets and technologies therein.

    Why Containerize API Security?

    Container technology such as Docker has become a popular means to deploy API micro-services, a collection of loosely coupled services which are fine-grained and lightweight. The move toward virtual and cloud was initially driven by fully virtualized images with their own operating system, but the adoption of lightweight services and on-demand environments has led to widespread adoption of container technologies run on a shared operating system. These container architectures provide flexibility and ease of deployment, but come with the same set of API risks.

    The concept of containers also brings into focus the trust model that needs to be considered for communication among technology components within and across containers. Containers become a new API boundary layer and thus represent the same type of risk paradigms, where a rogue container application can gain access or otherwise wreak havoc if the proper security controls are not put into place (commonly known as an insider attack).

    By deploying API security directly into a container, organizations can automate their API security into their existing workflows and provide zero-trust security capability that ensures real-time enforcement and protection of container-based APIs. This means API security becomes autonomous and baked into the architecture, rather than tacked on at a later stage.

    As mentioned earlier, dynamic data security is essential wherever information is traversing. The traditional cyber umbrella approach no longer applies in the interconnected API world. It’s like using an umbrella in a water park, it may stop the water from the top, but not from the sides. By having automated API security at the container and virtual layers, the ability to visualize, connect and secure information becomes an integral (and necessary) aspect of the container security strategy and a fundamental baseline for secure API enablement and trusted data exchanges.

    API security gateways deployed as container nodes allow DevOps teams to harness the power of virtualization, cloud computing and containers while at the same time protecting the organization against API threats from both the inside and the outside. With API security baked into the container, developers are free to focus their time on building the best functionality in their apps.

    — Jason Macy

  • Successful Transformation: Challenge the Status Quo

    Successful Transformation: Challenge the Status Quo

    If enterprises are going to succeed in their digital transformations, they need to be able to shake-up and challenge the status quo within their organizations. In fact, not being able to challenge the status quo is one of the biggest barriers to successful digital transformations. Yet, challenging the status quo is always a risky move for individuals and small groups within organizations.

    “Many large organizations are intrinsically unable to challenge the status quo and execute a large scale successful digital transformation,” said Mads Hennelund, advisor at consultancy Nextwork. “There are good reasons for this, since established bureaucratic organizations are built in order to handle complex procedures.”

    “Most CIOs, CTOs, and enterprise technology leaders want to challenge the status quo, but doing so can be dangerous because there’s no room for error,” said Laura Stringer, principal at strategic consultancy Ninth Fourth LLC. “IT leaders are under intense pressure to deliver continuity and multiple competing projects on an insufficient budget.”

    But it’s even more than just budget. It’s human nature’s near-ubiquitous aversion to change and inability to endure a number of losses on the road to find big wins. Stringer and other experts we questioned about challenging the status quo all agreed senior business and IT leadership must acknowledge the risks inherent with experimentation, while also providing a comfort level so teams can execute on transformational initiatives.

    Some initiatives will certainly fail and some will succeed. Ideally, like a portfolio of investments, while some investments will fall short, the winners will more than make up for the losses.

    “The organization needs a shift in culture to encourage all employees to become more open to changes in their daily processes and tools–digital transformation is largely about creating a culture of constant learning. Without the pressure to provide perfect continuity in current technologies, IT leaders can become more comfortable trying new things,” said Stringer.

    “This is one of the reasons why it’s common to see large organizations collaborate with smaller companies for projects,” said Hennelund. “In the financial sector we see a flourishing fintech and insurtech market around established banks and insurance companies. Companies successful in challenging their status quo are those that can navigate between these collaborations or even small in-house sub-divisions that develop new digital IT-based projects,” added Hennelund. “Putting into place a quick decision-making process is also critical.”

    This could include making it possible for stakeholders to hold meetings and move forward with their consensus without always having to get board approval.

    Such shifts in behavior require culture change. So, how do organizations and IT leaders get there?

    First, leaderships needs to make the staff feel safe taking risks and, even potentially, failing. “This only happens in an environment where current practices can be freely challenged without repercussions from upper management,” said Nabil Freij, CEO and GlobalVision International, Inc.“This means that upper management needs to be on board with digital transformation.”

    Only then is the right culture, one that can safely challenge the status quo, possible. “The right company culture is extremely important. One that embraces adopting technology, taking calculated risks, thinking outside the box, rocking the boat, challenging status quo, rejecting complacency, empowering employees to lead and overcome challenges…is the essence of enabling digital transformation,” said Freij.

    The ability to challenge the status quo all begins with building the right culture. A culture that encourages fresh thinking and intellectual risk taking. “Thirty-eight percent of CIOs think their digital strategy would fail without an innovative and experimental culture,” said Joe Garber, global head of strategy and solutions at Micro Focus.

    If so, it’s essential for organizations to build and maintain such culture.

    — George V. Hulme

  • Three Insights from the World’s Leading IT Organizations

    Three Insights from the World’s Leading IT Organizations

    IT is in a state of change on a consistent basis, but never more so than now. With the increasing importance of the digital customer experience across all industries, technology is at a new inflection point in how it can fundamentally impact executive priorities. And while nobody can speak for the direction of IT as a whole, there are a few resources so comprehensive that they’re worth reviewing when they’re released.

    Take, for example, the 2019 Harvey Nash/KPMG CIO Survey. It’s the largest global survey of CIOs with data from 3,645 respondents across 108 countries. IT leaders who participated in the survey controlled a whopping $250+ billion in annual IT budgets. The CIO survey examines how board priorities, technology adoption, skills gaps and IT leadership is changing in the age of digital business.

    Here are three insights that explain the tectonic shifts occurring in enterprise IT teams today.

    Digital Leadership: Three Steps to Becoming a Digital Native

    The 2019 Harvey Nash/KPMG CIO Survey shows only 30% of IT organizations are digital leaders. These organizations are unusually adept at “using digital technologies to advance their business strategy,” and can launch innovative solutions that generate new revenue streams, enable faster time to market and cut down operational costs. Here are three defining characteristics of what it takes to be a digital leader in 2019:

    • It’s All About Data. Data management and analytics is a core competency of leading IT organizations. Digital leaders are in a strong position to maximize the value of their organizational data by extracting, aggregating and curating the right information. This data is then used to train machine learning models, create high-value assets and deliver customer value on an ongoing basis.
    • Speed of Execution. Digital leaders are willing to either quickly double down on successful experiments or pull the plug on products that don’t deliver expected value. They are also more likely to leverage agile and DevOps practices to increase software release velocity and iterate rapidly on solutions using fast feedback loops.
    • Expansive Mindset. Digital leaders have transitioned from project thinking to product-centric innovation for creating enduring value from their software investments. They also build cross-functional teams across their business and IT silos for better collaboration and faster decision making for digital transformation initiatives.  

    What Does This Mean? CIOs will need to embrace big data analytics, agile delivery models and product-centric teams to create the right foundations for digital business. Without proper foundational investments, IT leaders will struggle to meet business demands, gain customer trust and withstand competitive pressures in the face of escalating customer expectations.

    Business-Managed IT: How Shadow IT Finally Became Respectable

    In the last decade, the adoption of cloud services led to the phenomenon of shadow IT where business units would directly buy cloud solutions without consulting IT teams. CIOs resented their growing irrelevance and tried their best to bring shadow IT under their control.

    The 2019 CIO survey confirms 64% of enterprises have made peace with business-managed IT investments. In fact, 10% of IT leaders actively endorse this approach. What factors have led IT teams to change their mind on shadow IT?

    The survey shows organizations with business-led IT scored better on key metrics than organizations without any mandate for business-managed technology spend. Business-led IT organizations delivered “better customer experiences and faster time to market for new products (52% more likely) as well as positive employee experiences (38% more likely).”

    For business-managed IT spending to be truly successful, CIOs will require the right guardrails in the form of central IT oversight. The 2019 CIO survey makes the case that organizations without IT team involvement are twice as likely to have multiple security issues and are also less likely to build customer trust with their technology investments.

    What Does This Mean? Instead of actively opposing shadow IT investments, CIOs should partner with their business counterparts to create effective governance and operating models for business-managed IT spending. Central IT oversight will ensure the right support for digital business initiatives, reduce the risk of unauthorized breaches and minimize wasted spend.

    Influencing Without Authority: What It Takes to Be an Effective Technology Leader

    Board membership for CIOs dropped this year, with only 58% of IT leaders being part of the executive team in 2019 as compared to 71% in 2017. Does this mean CIOs no longer have executive backing for orchestrating and executing digital business strategies in their enterprise?

    The 2019 CIO Survey indicates board membership, headcount or annual budgets are not the right indicators of the power and influence of technology leaders. Instead, CIOs should focus on building trust across organizational boundaries, creating partnerships with the right executive stakeholders and ensuring the success of critical initiatives. CIOs working for digital leaders are comfortable exerting influence without authority and are driving organizational growth, by being “three times more likely to collaborate strongly with business leaders.”

    What Does This Mean? Formal board membership or the size of the IT team is not the best way to assess CIO influence. The best technology leaders ensure successful enterprise transformation by garnering strong commitment from the board, building digital capabilities with cross-functional teams and creating a sense of urgency for rapid innovation.

    — Deepak Jannu

  • The Impact of DevOps on Database Monitoring and Management

    The Impact of DevOps on Database Monitoring and Management

    The rise of DevOps has broken down silos and brought database administrators (DBAs) and application developers closer together to deliver software faster and in a more agile manner. This near-constant change driven by DevOps is reflected in the results of the Redgate 2019 State of SQL Server Monitoring Report.

    It reveals that 73% of organizations now deploy database changes multiple times per month, and 15% deploy multiple times per day, driven by DevOps. Yet, this is just one of the challenges DBAs face today. The research also identified the size of database estates is growing–45% said they will have more to manage over the next year, with 43% remaining the same.

    Additionally, they are increasingly looking to migrate their databases to the cloud (cited as their biggest challenge by 22%) and are seeking to solve performance issues. Perhaps unsurprisingly, given these greater workloads and more frequent changes, human error is the largest cause of issues (22%), ahead of capacity problems and bad deployments.

    Managing in a DevOps World

    The database is now a core part of DevOps for many organizations and DBAs need to work more closely with their developer colleagues, adopting new technologies and tools to ensure business success.

    This essentially involves DBAs focusing on the following distinct areas.

    Standardizing Approaches Across DevOps Processes

    The monitoring report highlighted human error as the biggest cause of problems for DBAs–and with larger DBA and developer teams now working on databases together, adopting standardized processes is vital to flagging issues early and preventing later problems. Otherwise, what starts as a minor issue can swiftly escalate to become a significant business crisis.

    As well as standardizing processes, organizations should look at rolling out industry-standard coding tools across the entire team. This will ensure a consistent approach, not matter who is writing, reviewing or editing code. Introducing a team style for database code, rather than having the code written in many different ways, for example, will make the code base consistent and clear and minimize the confusion that lead to errors. At the same time, merging code early and often with version control tools will ensure you have a known, shared codebase on which to work, and provide a single source of truth that can always be relied on.

    Automating for Speed and Consistency

    Developers who have adopted DevOps already see the value automated processes such as continuous integration, continuous delivery and continuous deployment provide. Automation not only speeds up development, avoids manual errors and reduces laborious work, but also provides a full audit trail for regulatory compliance.

    Extending this to the database can deliver major benefits for hard-pressed DBAs. Every time a change is committed to version control, for example, a continuous integration process can be triggered to test the change and flag up any errors in the database code. The errors can be fixed immediately and tested again, before the change is then passed along to a release management tool where it can be reviewed before being deployed to production.

    Overall, automation dramatically brings down time to market, but organizations need to ensure they have the right tools and processes in place if it is to be truly effective.

    Stepping Up Monitoring to Drive Continual Improvement

    One of the mantras of DevOps is continual improvement, and that applies equally to database DevOps. Monitoring is a key part of this. On one level, monitoring tools highlight potentially disruptive performance issues (cited by DBAs in the research as a major challenge), enabling them to be fixed quickly.

    Beyond this, they also deliver the insights and trends companies need to improve, helping them optimize operations moving forward. Thanks to a combination of DevOps and the growing importance of the database to business success, many organizations are already sharing this information. For example, 40% give developers access to their monitoring data, according to the research, which helps to enhance performance by highlighting opportunities for improvement.

    Guarding Personal Data and Ensuring Regulatory Compliance

    We’ve all seen the spread of data privacy regulations across the globe. Over 60% of the world’s population is likely to be covered by more stringent legislation in the near future, with California joining the EU in enforcing new regulations from January 2020. Organizations need to realize they are now data guardians, not data owners, when it comes to personal information.

    At the same time, developers like to have realistic information in order to successfully create and test new code. That means organizations need to adopt tools for data masking and anonymization that can protect confidential and personal information, while still providing realistic and usable data for development and testing. This also gives a full audit trail for regulatory requirements, balancing speed and compliance.

    DevOps has broken down the traditional silos between DBAs and developers and the importance of information has put the database center stage. As the latest Redgate research shows, DBA workloads are increasing, meaning they need to adopt new technology and collaborate more closely with developers if they are to successfully manage in a DevOps world.

    — Matt Hilbert