devopsy.kinsta.cloud

Category: DevOps Practice

  • Rethinking Data Management in a DevOps Environment

    Rethinking Data Management in a DevOps Environment

    You often hear data is the new oil. This valuable, ever-changing commodity has begun to play a starring role in many cloud-native applications. Yet, according to a number of DevOps teams, data issues continue to plague their efforts to continuously integrate, test and deploy frequent software releases. More specifically, issues with persistent data (and its underlying database engine) often appear to be the culprit.

    Your organization might be pursuing emerging IoT applications that incorporate and analyze sensor data from multiple sources. Or, your DevOps team may be trying to develop applications that extract further actionable insight about customers. Whatever the use case, there’s no doubt back-end database architectures have gained growing importance to the success of such projects. Yet, in many cases, such database systems appear to be having difficulty just keeping up with the pace of today’s DevOps pipelines.

    According to one report on the state of database deployments in 2019, 46% of DevOps teams on an accelerated release schedule (with weekly, or even daily, releases) found it “extremely or very difficult” to speed their database release cycles accordingly. In a related Redgate report on the 2019 State of Database DevOps, 20% of respondents cited slow development and release cycles as one of the biggest drawbacks to “traditional siloed database development practices.” Another 23% saw a higher risk of deployment failure and extra downtime when database changes were introduced in a traditional database environment.

    Getting to the Heart of the Data Problem

    Are such database issues the result of the wrong choice of underlying database technology–such as the use of an RDBMS, NoSQL or even a NewSQL system? Possibly.

    Maybe database issues are also caused by poor (or non-existent) cross-communication between database experts and their developer counterparts? Undoubtedly, this is true as well.

    Would you be surprised to learn both situations (wrong technology and poor communication) are often to blame? Also, to blame is the urge to solve new data problems in the same old way organizations approached their earlier, legacy use cases.

    Ultimately, as with many things DevOps-related, the answer to the data problem is likely to require change along three, separate fronts: People, process and technology. It will also require a fundamental shift in how such issues are approached at the start.

    Starting with People and Process

    Instead of worrying about database slowdowns, what if you began again with how DevOps teams first approach the many facets of the underlying data layer? This means:

    1. From the start of a project, include DBAs as part of the cross-functional DevOps team. This will help promote healthy cross-communication. They will also positively influence the development of appropriate underlying data layers and infrastructure that support your emerging use cases. In larger organizations that manage many data sets, these may be specialized database administrators (DBAs). In smaller companies, these may be more full-stack engineers who also have high-quality expertise in database operations.
    2. Identify early the different data types, domains, boundaries and optimal cloud-native patterns associated with your data. Once these are established, the team can gain a better understanding about the different ways to develop applications and data architectures for each new use case.

    In effect, organizations need to make a concerted effort to shift left with their overall data architecture discussions. This shift allows more of the right questions about data to be asked, answered and incorporated early on in the design of the overall application.

    Asking the Right Questions About Data

    Part of this early collaborative work may involve asking key questions about data. These include the best ways for an application and its users to interact with the underlying data, such as:

    • How will data be ingested and from where?
    • How will we access the data?
    • How and where will we store it?
    • How do we update and/or maintain legacy databases as we build for new use cases?
    • What types of data will we have? How will the types change or be increased over time?
    • How will we query from it? And what are the most common queries users will want to run?
    • How will we manage and scale the data in use?
    • How will we protect the data from data loss, disaster or corruption?
    • How will we secure the data?

    If these questions sound a lot like features in a data lifecycle, you’re right. But, such basic questions about data are often overlooked in the rush to deliver, integrate, test and deploy application code. So often, what happens instead is an application team creates a design, then hands it off saying, “Okay, now create a data architecture to support the application.”

    This fundamental miss with data and collaboration at the start often leads to poor database architecture decisions later. It can also cause DevOps teams to resort to workarounds to accommodate such wrong architecture choices made at the start–which may cause some development teams to choose to circumvent DBA involvement altogether. In this case, they might even find themselves opting to use public cloud services instead (or some other types of data management) to support their application.

    Instead, application teams should choose the path of early collaboration between developers and all functions of IT (including DBAs). This approach can offer better DevOps outcomes. It also helps move organizations toward a future where data architects provide an effective bridge between all parties critical to the application’s success: From the needs of developers to the platforms provided by DBAs and the underlying infrastructures needed to enable them.

    Changing Skillsets, Changing Mindsets

    As with most things DevOps-related, success at the data layer has as much to do with changing the education, mindset and culture toward database architectures and database deployment methods as it does with the specific steps in the DevOps pipeline.

    For example, if most DBAs in your organization are narrowly focused in one area (such as an Oracle DBA or SQL Server admins), your organization may benefit from investing in education to close skill gaps. Such investment can help expand the knowledge and exposure of that workforce to DevOps practices or emerging database approaches to cloud-native application patterns.

    It can also help some organizations to first identify those individuals in the organization who want to transform, innovate and learn about new tools, methods and practices.

    Hiring those with that expertise already in place is another option. When you hire new skillsets, however, the answer may not be just to hire several NoSQL administrators. This tactic will not necessarily solve your data problem, either. It may be just as beneficial (or more so) to hire someone with little specific NoSQL skills but who is good at thinking about data in a different way.

    Business First, Technology Second

    In our practice, we are often asked to weigh in on technology choices to support DevOps efforts in emerging areas such as IoT, Big Data and advanced analytics. Organizations ask us about using traditional relational databases (SQL Server, Oracle, etc.) versus NoSQL databases (MongoDB, Cassandra, etc.). They ask about the merits of one NoSQL iteration over another. They ask about how to manage persistent data in container environments. They even ask about workarounds when the data choices they’ve made cause other unexpected problems.

    We do our best to answer these questions. But, whenever possible, we also tell organizations to back up a few steps and start, instead, from their business objectives:

    • What are you trying to accomplish?
    • What are your business drivers?
    • How do you hope data will be used in these contexts?

    Answers to these questions can help you make better choices about the best data architecture to support your growing applications.

    Ultimately, new tools and technologies can enable a lot of impressive data architectures. But, just throwing tools at the data problem is not enough. Early effort and investment in people, process and cross-departmental communication is just as important to a successful data outcome for any project.

    Many of the discussions we have now are trying to take everyone back to the steps they skipped. This harks back to the fundamentals of software engineering: Addressing things early so you don’t have problems later.

    Unfortunately, data is the one component in the technology stack that you can’t easily undo once you’ve chosen a specific path with your application’s data architecture. When it comes to planning for data, it really is a pay now or pay later equation.

    Isn’t it best to take the time and choose your data path wisely rather than paying later for slowdowns or other issues with deployment and performance?

    — Jeff Bozic

  • What is so Special About AIOps for Mission Critical Workloads?

    What is so Special About AIOps for Mission Critical Workloads?

    As the wave of digitization sweeps more enterprises with each passing day, the threats posed to organizations, particularly IT organizations, have never been more complex and pressing. With cybercrime statistics, including those for more targeted crimes (such as phishing) pointing towards an alarming frequency of attacks, the stakes for securing enterprises have been higher.

    However, many IT organizations have been unable to smoothly transition into pushing the digitization of their organizations forward. This inability to support and drive digital transformation isn’t a result of a lack of effort on behalf of these organizations. Instead, it has everything to do with the unavailability of the proper management tools needed.

    Unfortunately, many IT organizations lack the tactics and tools needed to overlook the smooth shift to digitization on such a grand scale, which often leads to the degradation of critical business applications, along with IT slowdowns and outages. Luckily, however, artificial intelligence for IT operations (AIOps) arrives like a beacon of hope for revolutionizing IT application, along with increasing business agility.

    The Failure of Enterprise in Tackling the Burgeoning Complexity of IT Infrastructure

    A primary reason behind the ever-present issue of IT slowdowns in enterprises and organizations that is frequently overlooked is the fact that the customer-facing side of IT (applications) is growing increasingly complex with each passing day.

    As the increasing number of applications continue to occupy more and more space, the IT infrastructure grows into a vast and hybrid structure which often spans across multiple clouds on a grand scale.

    Although the vastness of the IT infrastructure is a byproduct of the digitization drive taking enterprises by storm, it is still worlds away from the security infrastructure of yesterday, which was much easier to manage and analyze.

    From the Internet of Things (IoT) connecting thousands of devices onto an organization’s network to complex issues such as bottlenecks, application slowdowns and outages, along with performance latency and the ever-present threat of phishing attacks via a free host website (000webhostapp, being the most commonly used host), organizations are just setting their systems up for failure at some time in the foreseeable future.

    Owing to the flourishing complexity of the IT infrastructure, an organization’s system fails to cope with new, dynamic workloads for any multitude of reasons. Usually, the system is utilizing extra resources or is under the influence of a recent addition to the system.

    In instances of outages or IT slowdowns, the pressure to fix the IT infrastructure falls on the IT team, who are tasked with the immense responsibility of analyzing and diagnosing the issues as they occur in real-time, along with coming up with a solution that satisfies customers and prioritizes the business aspect of an organization as well.

    Unfortunately, however, without access to the proper tools and techniques, the IT team can only conjure security patches that resolve the problem for the moment but fail to withhold security in the long run. Also, without the ability to effectively predict a pattern for the ever-present security threats, the IT team is operating on a whim rather than basing their solutions on the rationale.

    How Can AIOps Help the Situation?

    To leave the momentous challenge of perfecting an organization’s IT infrastructure solely on the IT team is not only outdated, but it is also impractical. Taking into consideration the complexity of the threats facing enterprises, a solution that arches above each aspect of cybersecurity in an organization should be implemented.

    Today, that solution arises in the shape of AIOps. The hybrid IT infrastructure has become too complex to be handled through traditional tools and tactics, which is why AI, along with machine learning and automation, has to step in to bridge the gap.

    Unlike other security strategies, AIOps integrates a wholly modern and unique approach, which allows for the AI to view systems in terms of business outcomes. Simply put, rather than analyzing and diagnosing identities, infrastructure and applications independently, the AIOps platform follows the path taken by the user into the complex IT infrastructure and back out of it.

    Ideally, AIOps platforms run automated investigations that derive the root cause of existing and recent issues on a regular basis. When it comes to managing a business-critical application, an AIOps platform can detect an unusual response within the system, whether it’s an anomaly in a workload profile or variant response to critical workload.

    Other benefits to incorporating AIOps as a security tool include tapping into the truly unique set of capabilities offered, including predictive capacity management and forecasting/predictive abilities. The predictive ability of AIOps allows for the AI to smartly notify IT teams about any attack or potential outage, or slow down, before they actually happen so they may act accordingly.

    By taking a different approach to the pressing issues faced by enterprises today, AIOps manages to do what several security strategies have failed to accomplish—provide organizations with an end-to-end, app-centric approach to security, which also takes into consideration the context at hand.

    Moreover, AIOps will push organizations to shift their focus from reactive problem solving and cause them to optimize their IT infrastructure on a more proactive basis. Fundamentally, AIOps provides IT teams with the necessary tools to diagnose and combat both internal and external threats to an organization’s security infrastructure.

    After the integration of AIOps within an organization’s infrastructure, enterprises can turn their attention into optimizing the balance of critical workloads, along with prioritizing business functions and improving applications, rather than worrying about security.

    What Hurdles Can Enterprises Expect with AIOps?

    Despite the countless benefits AIOps brings to the table, certain obstacles arise when it comes to the implementation of the security model into organizations.

    Perhaps the most apparent obstruction organizations have to deal with is the extensive amount of time investment AIOps requires. Like every other security tool centered around an AI or machine learning technology, time is absolutely pivotal for the learning to actually take place. A simple way to smoothen the transition, AIOps must be fed with data, statistics and analytics originating from multiple data centers.

    Another common issue that arises, mainly because of a lack of research, is when an AIOps platform fails to perform as per the specific requirements of an enterprise. Keeping this in mind, CIOs must voice their concerns about fine-tuning AIOps before committing to a vendor.

    AIOps abilities in performing an in-depth analysis into the IT and security infrastructure—within the context of the applications it performs—gives the unique chance to stay ahead of the threats they face.

    — Rebecca James

  • Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    Building Hybrid and Multi-Cloud Architectures for Analytics and AI

    We are in the early stage of the data revolution. Today’s conventional wisdom states that hybrid latency prevents you from running analytic and machine learning workloads in the cloud with the data on-prem. As a result, most companies either do not burst their workloads into the cloud or have to copy their data into a cloud environment and maintain that duplicate data—and even this can take days or weeks.

    Counter to conventional wisdom, you can create a high performance hybrid/multi-cloud data platform for analytics and machine learning by using data orchestration technology. Container orchestration technology (e.g. Kubernetes) enables containers to run in any environment agnostic to the hardware that is running the application, similarly data orchestration technology enables active working sets and data to be orchestrated on demand. This enables enterprises to create a compute agnostic, storage agnostic and cloud agnostic stack to serve all their data driven workloads, including analytics (e.g. Apache Spark, Presto, Apache Hive) and AI (e.g. Tensorflow, PyTorch).

    An enterprise hybrid cloud analytics strategy should burst compute that spans on-prem and cloud data stores. By bringing the hot data to the analytics and machine learning applications, the performance is the same as having the data co-located in the cloud. Also, the on-prem data stores will have offloaded the computation and minimized the additional I/O overhead.

    Specifically, a data orchestration system should:

    • Abstract data access across storage systems. Today, data is siloed in various storage systems and deployments. For example, lots of on-premise data is stored in systems such as Apache HDFS, Ceph, EMC Isilon and IBM Cleversafe, and data in the cloud is stored in systems such as AWS S3, GCP Store, Alibaba OSS, etc. Historically, there have been many attempts to unify all data into a single storage deployment with limited success. As a result, we’ve seen more of a trend around embracing these data silos by abstracting the data in various storage systems/deployments. To do this, the data orchestration system needs to abstract and virtualize across various storage deployments/deployments by server side API translation, which enables users to run existing applications without modifying any code. The system also needs to provide a single global namespace to enable apps and users to access all the data in their environments without the need to understand which storage the data is stored in.
    • Bring data locality in a separated compute and storage environment. While cloud vendors and leading companies in data-heavy industries have adopted a decoupled compute and storage architecture, it can still be very challenging to implement this type of architecture, especially when it comes to bursting on-premises data into the public cloud. A data orchestration system resolves this challenge by providing caching functionality that enables the system to automatically orchestrate the hot data to be closer to compute while at the same time keeping cold data in a cheap storage. Because each workload may have a different usage pattern, the system must have a policy that enables customized policies best suited for those specific workloads. Moving forward, it is also very critical to have policies across various clouds to enable a multi-cloud environment.
    • Provide security for data in motion and at rest with secure access methods. A data orchestration system plays a critical role in the success of an organization’s data strategy. While open source software is important and can help in avoiding potential vendor lock-in, it is also critical to provide necessary security features in this environment given the system touches a lot of data in the organization.

    Besides empowering data driven application developers, a data orchestration system also brings value to data and infrastructure engineers. It de-risks vendor lock-in by providing organizations with flexibility at the infrastructure level. Transitioning to different storage systems (including cloud storage), adopting another application framework, or even having a hybrid or multi-cloud environment are all possible without the need for many different technologies or incurring large development costs.

    — Haoyuan Li

  • Why Mobile App Security is Like a Rubik’s Cube

    Why Mobile App Security is Like a Rubik’s Cube

    Now more than ever, mobile applications are driving modern business, and developing and launching them are top priorities for companies across industries.

    As of 2018, more than 194 billion applications had been downloaded from app stores, according to Credence Research. The global mobile app market was valued at $109.67 billion in 2018 and, at the time of the report, was set to see a 15.60% compound annual growth rate during the forecast period (2019-2027), according to the firm.

    Although only a small fraction of mobile applications will be used in the enterprise, the tidal wave of mobile apps off-the-shelf, corporate-developed and sponsored creates substantial new challenges. For DevOps teams, it means they must make their internal processes more agile and efficient. That’s a good thing. But it also means they face a critical step securing those apps, which can add weeks to development times and cycles.

    One problem is mobile apps run outside of the confines of corporate networks and can access services across the public internet. This makes mobile applications a huge security vulnerability point–especially if they aren’t architected properly and configured with proper security and access controls.

    A report by WhiteHat Security offers a stark reminder that mobile apps are riddled with security flaws, many of which go unremedied. Based on 17 million application security scans carried out in 2018, the firm found a 20% increase in vulnerabilities in the applications organizations tested for security flaws. Complicating matters, most enterprises face the risks presented by the use of personal mobile devices by their employees.

    It is not uncommon for enterprise users to have 15 to more than 80 enterprise applications on their devices. Enterprise must have control over the app and the data in the app before permitting widespread deployment.

    “That simply visiting a website can lead to your iPhone being hacked silently by some unknown party is worrying enough,” said Thomas Brewster, a cybersecurity reporter for Forbes, in reference to a recent, successful hack of an iPhone. “But given that, according to Google researchers, it’s possible for the hackers to access encrypted messages on WhatsApp, iMessage, Telegram and others, the attacks undermine the security promised by those apps.”

    Challenges of Securing Mobile Apps

    Why is app security such a challenge? For one thing, securing apps before release doesn’t happen just once; every time an app or OS is updated, whether pre- or post-release, it must be secured again.

    Today, it takes an average of five weeks to secure a mobile app before launch.

    What’s more, when third-party libraries used by the app are updated, the app must be secured again. DevOps teams need to ask themselves: “How much of the time during which this app is in production will it be vulnerable to a security breach?”

    But integrating security into mobile apps gets even more complex. Here’s why: Integrating app security by manual coding is hugely time-consuming and error-prone, given that implementing cybersecurity isn’t everyone’s cup of tea. For example, a developer may not implement the data security APIs everywhere in the app, resulting in some data being written unprotected.

    And another factor tangential to security–device adoption–enters the picture. Employees expect corporate-authorized and distributed mobile apps to provide the same user friendliness as any consumer app they are accustomed to. If an app is not easy to use they will shun it, and enterprises won’t derive the business and process benefits they expect from mobility. Enterprises that attempt to secure their mobile apps may resort to forcing employees to use a managed, corporate-supplied device in order to use the app, or introduce a cumbersome VPN/login experience that will allow employees to access key data on remote servers from within the app.

    In short, such security practices, while they may secure data, make the mobile app inconvenient, cumbersome and difficult to adopt and use.

    What Can Be Done?

    Today, many of enterprises’ mobile security protocols and practices are rooted in manual methods, and DevOps and security teams struggle to place security-hardened devices and apps in production. But two practices remove virtually 100% of the issues that plague enterprise teams today.

    1. No-Code Security Integration: A no-code security integration solution can embed military-grade data encryption into apps and deliver the enterprise-level security controls that organizations need to ensure that corporate data is always safe, even when the device isn’t under enterprise controls.
    2. Securing the App, Not the Device: Securing mobile apps–not the endpoint devices or device-resident containers they run in–decomplicates security while significantly reducing security risks. This practice enables developers to automatically embed the security controls into the organization’s apps, and it enables employees to use those apps without having to deal with device security restrictions.

    What’s more, when an app or the OS behind it changes, it’s a trivial matter to re-secure the app.

    Smart users of mobile devices take precautions to safeguard their data from hackers. While that’s a prudent move, the real job starts with the DevOps and security folks to solve the security-integration Rubik’s Cube once and for all.

    — Nikfar Khaleeli

  • Kubernetes and Service Mesh With StackRox

    Kubernetes and Service Mesh With StackRox

    DevOps and Kubernetes enable organizations to “go with security,” adding security to the code instead of on top of it. In other words, security is built-in rather than bolted on.

    This is one of the aspects of security in the DevOps world with a Kubernetes system that Ali Golshan, co-founder and CTO of StackRox, explained during this exclusive interview with Alan Shimel, Media Ops CEO and editor in chief. The other aspect is security has become continuous instead of snapshots, which provides “a lot more visibility into various stages, various deployments, as well as running environments,” he said.

    During the interview, he explored containers, orchestrations, Kubernetes and service mesh.

    “Leveraging this cloud-native infrastructure, Kube and service mesh the right way reduces your dependency on third-party tools, allows you to hand off things you typically handed off to vendors and does that inside your infrastructure, which makes it actually more secure and highly scalable,” said Golshan. “You can automate that and reduce your lock-in and your sort of dependency.”

    Check out the interview below to learn more about the best and emerging practices in Kubernetes, service mesh and the security feedback loop.

    — Veronica Haggar

  • How Enterprise IT Teams Can Win the Hearts of DevOps

    How Enterprise IT Teams Can Win the Hearts of DevOps

    Take your average IT team in a young enterprise in the midst of skyrocketing growth. There’s a good chance the workflows they’ve used since the outset can’t keep up with the ever-increasing volume of requests from the business. In the minds of some DevOps and app development teams in particular, the IT department of the scrappy startup has gradually become the department of slowing things down.

    As a result, tasks that once took hours, such as provisioning resources (e.g., virtual machines, workloads, XaaS), can now take days. For agile DevOps teams, this is essentially a showstopper: They need access to resources when they need them–not when you deem them worthy. Anything else feels like a drag on development and the business.

    Giving DevOps What They Want

    IT needs to make access to resources as seamless as possible for DevOps teams. The ultimate goal is self-service. DevOps should be able to instantly gain the access they need to the resources they need, without the back and forth of ticketing systems, or the complexity of provisioning resources on totally unfamiliar systems. And with a user interface that only serves up the resources relevant to the requesting team, DevOps can easily manage and provision resources on demand.

    Maintaining the Controls the Enterprise Needs

    Of course, it’s not about just giving DevOps access to whatever they want when they want it. You need real controls in place.

    For example, without the right guardrails, DevOps teams can easily spin up more virtual machines than they need and let them run without limit. To give you an example of how bad it can get, Gartner estimates shadow IT accounts for 30-40% of IT spend, from idle resources consuming costs by the minute.

    Through blueprints, repeatable ways to orchestrate and automate provisioning of resources, this self-service nirvana to eliminate shadow IT can be a reality for admins. Since blueprints contain set rules and builds sanctioned by IT, they’ll always be able to accurately and securely deliver the right resources, without users going rogue and out of compliance with taking provisioning into their own hands.

    For instance, IT can determine who can order servers, workloads and XaaS—along with quotas set for spend and resource usage—to who can approve fulfillment of those orders. This way, resources are never over-provisioned and a real tally is kept as to exactly who is using which resources across the business. By automating routine approval processes and applying the proper conditions to user requests, the errors and time associated with manual provisioning are eliminated and users can get what they need without going at it alone.

    Control Doesn’t Have to Come at the Cost of Delight

    In the absence of the right tools and the right processes, IT can start to seem like a slow-moving gatekeeper to DevOps teams, who need resources fast. Consuming resources needs to be easy and quick for agile developers who need to ship products to market fast. In this sense, the self-service IT model plays greatly to agility: By presenting only the resources needed for DevOps teams, and orchestrating automated processes, resources are provisioned in seconds versus the days involved with an IT ticket. Additionally, with built-in, automated permissions and role-based controls, IT teams can still protect the enterprise, as they should, but at the same time delight users.

    Take for example an organization as big as Home Depot, with over 385,000 employees: By rolling out a self-service approach to provisioning resources, they were able to completely reign in VM sprawl and at the same time make their developers’ lives easier with a provisioning time decreased from two weeks to just under 20 minutes.

    Indeed, IT admins can win the hearts of DevOps and at the same time win back their role as an enabler of enterprise-wide innovation. By empowering users with intuitive self-service to quickly get resources when they need them, IT becomes the heroes that enterprises–and their DevOps teams—need.

    — Brian J. Kelly

  • Achieving Application Health Through Integrated APM

    Achieving Application Health Through Integrated APM

    Performance and availability mean everything to application users at both the enterprise and consumer level. Think about how much we rely on technology for our everyday communication—when Slack suffered from an outage this summer, it affected thousands of business professionals across the globe who use Slack to communicate, organize tasks and share information. In a sense, we are only as efficient and effective as the technology we use.

    With this in mind, it’s clear achieving and maintaining application health is paramount to overall business success. In part one of this series, we explored how creating and maintaining a healthy app involves not only ensuring it’s performing well via lifecycle APM, but also making sure it’s available when needed—making a log management solution that monitors availability, enables proactivity and reacts quickly to overcome problems is crucial.

    In order to help ensure a healthy application, we must first consider a few defining characteristics.

    Understanding a Healthy Application

    Even for humans, health is more than just being alive—if we’re not performing optimally, we’re not having the best experience possible. Optimum health for an app or website doesn’t mean it’s just up, but that it’s also performing in the way the market demands. For this, organizations need to implement an integrated APM solution to ensure top performance and continuous availability.

    However, achieving application health is easier said than done. Issues that arise for teams working in silos can lead to digital war rooms and blame storming. Organizational structure can get in the way of disparate teams working together to achieve performance and availability. How can organizations overcome this issue?

    Optimizing Performance and Availability

    As we know, each piece of the APM puzzle must be incorporated to achieve full-stack visibility and ultimately top performance: user experience, metrics, traces and logs. Following a few key best practices can help achieve overall application health.

    • Early Adoption: Implement application performance and logging tooling as early in the application development lifecycle as possible. Without integrating these tools from the beginning, organizations run the risk of having errors in availability and performance when they deploy the app. This is because one of the key benefits of a full-stack APM solution is the ability to analyze the performance characteristics of the application code and logic itself. If an application isn’t properly written, it can be so inefficient that no amount of resource in production can assure appropriate service delivery.
      Another critical benefit of early lifecycle APM adoption is the knowledge it delivers about app performance can be reviewed with business stakeholders to ensure complete alignment against shared goals—before going live in full production.
    • Integrated Solution: As mentioned above, the biggest challenge to achieving availability and performance is typically organizational structure. For most organizations of a reasonable size, separate teams monitor performance and availability; in some cases there may even be multiple teams monitoring performance and availability, specifically aligned with the individual technologies (e.g. compute, storage, network, web, cloud, etc.) underpinning each application. To get around the obstacles this creates, it’s key to have an integrated solution where every team is looking at the same set of information—the so called single pane of glass. The ability to share information proactively with management across teams is paramount to overall success and avoiding digital war rooms, or at least minimizing time spent in them.
    • Implement High-Value and Appropriately Priced Solutions: Powerful, easy-to-use solutions that will achieve integrated application performance and availability management for any type of organization operating either on-premises and/or cloud-based applications are key. Traditional APM solutions were either so complex to deploy or so expensive that ubiquitous adoption was not operationally or fiscally possible—depriving much of the organization and its applications the benefits of APM by restricting its application to only the most important subset. As a result, quick-to-value and affordable solutions are needed to enable tech pros who may be working in the organizational performance silo to get running quickly and show success to the organization.

    Conclusion

    Although apps serve their own unique purpose—whether that’s for consumer use enabling us to watch TV and movies on-the-go or at the business level to streamline work and communication—they’re all connected by a universal need: performance and availability. Companies must therefore prioritize application health, and in turn creating and delivering an exceptional user experience.

    — David Wagner

  • Applying Secrets Management to DevOps

    Applying Secrets Management to DevOps

    DevOps has changed the way enterprises operate, allowing for quick and efficient product development. In order for companies to keep up with market competition, many companies that are not structurally prepared to implement DevOps will still put together a team just to meet demand, which in turn creates vulnerabilities and gaps within their security posture.

    Today, only 46% of IT professionals are confronting security risks during the initial phases of development. With security as an afterthought, DevOps teams may overlook even the most basic security practices. What’s more, in an environment that relies heavily on code, we’ve seen time and time again careless developers leaking confidential information through APIs or cryptographic keys on sites such as GitHub. As a mecca for code, it’s the primary place cybercriminals turn to gain access to the credentials developers have stored in its platform and forgotten to remove before production.

    While GitHub breaches continue to put a spotlight on DevOps security, most organizations are still missing the big picture. The reality is security hygiene remains critical, and DevOps can put their organizations at risk by neglecting basic security practices such as monitoring access and embedded secrets, such as passwords, keys and APIs.

    Where Should DevOps Teams Begin?

    The solution is simple: separate highly valuable secrets from the developer. Luckily, the key to streamlining secrets doesn’t have to be time-consuming or costly. In fact, secrets management is, at its core, an extension of privileged access management (PAM), which many enterprises already have in place.

    As an essential approach to safeguarding an organization against bad actors, one of the fastest ways to mitigate the risk of DevOps-related data is to remediate weak security practices related to PAM.

    The following are some of the most important security protocols DevOps team should apply to their delivery pipelines:

    Inventorying Privileged Accounts and Access

    Large enterprises running networks with thousands of servers and network devices often lack an accurate inventory of assets. Most organizations create a security gap by not understanding the credentials within their systems due to inadequate deprovisioning processes. A DevOps environment’s use of automation and scripts makes it even more complicated to manage privileged accounts and access.

    To ensure DevOps practices are secure beyond the initial provisioning phase, security professionals must understand where automation is stored and what embedded credentials are stored within that automation. By understanding the entire embedded privileged credential process, adamantly keeping track of each DevOps team member’s access and leveraging automation, enterprises can instantly update a user’s access when their role changes to ensure they have the right access to do their job and nothing more.

    Secrets Management Integration

    A significant challenge for DevOps teams in managing privileged credentials is finding a solution that can be seamlessly integrated into existing development toolsets.

    Many DevOps teams rely on several different tools for different phases of the development process, and simply can’t afford to use secrets management solutions and processes that don’t integrate with and address all of them. For example, if an enterprise has invested in AWS and has an Azure-specific secrets management solution, tedious steps could be added to the process. In an environment that’s focused on rapid development, developers are likely to find ways to work around these inconveniences which can put the enterprise at risk.

    To ensure an effective secrets management strategy is put in place, enterprises need to understand that it must work with every tool in the DevOps workflow. By integrating security systems with tools developers know and use, enterprises can ensure no shortcuts are putting its sensitive information at risk.

    Understanding the DevOps Pipeline

    Traditionally, enterprises think the only way to obtain a secret is to log into a server, but in DevOps that’s not the case. In DevOps, when a user with privilege inputs a piece of code, it goes through a pipeline and many enterprises are oblivious to what happens within that pipeline. This blind spot could pose serious cyber risk to the organization. For example, if three developers are working on a project and they check in code that requires privileged access, such as copying credit card information, a developer could inadvertently interject dangerous code into that project and the security team is none the wiser.

    For an environment that’s focused on individualized actions, applying secrets management and thinking twice about who has access to build within this pipeline environment is critical. By not understanding how the pipeline functions and not knowing who has access to specific data, enterprises increase their risk of an internal breach or data leak.

    The reality is managing DevOps security has nothing to do with the actual DevOps process. By integrating basic privileged management protocols, enterprises can ensure security is at the forefront–and not the backend–of the development process.

    — Tyler Reese

  • Quality Engineering Has DevOps and Agile in the Driving Seat

    Quality Engineering Has DevOps and Agile in the Driving Seat

    As opposed to the traditional software development lifecycle (aka waterfall), today’s Agile and DevOps-based software development process is more outcome-oriented. The unrelenting pace of the changing market landscape has made the hybrid, Agile plus DevOps way of software development absolutely critical in addressing customer demands and staying competitive.

    The focus on Agile and DevOps is necessary due to the high failure rates of traditional software development methodologies. These failure rates are mainly attributed to the glitch-infested, low-quality applications churned out by following legacy methodologies.

    The failure rates had left many companies to bite the dust and brought the key role played by quality in ensuring customer satisfaction and ROI for the business into sharp focus. Also, the IT landscape is witnessing developments such as mergers and acquisitions, increased focus on risk and compliance, data and analytics, the fast rollout of apps and mobile commerce, among others. These have necessitated the software development process to become increasingly agile, streamlined, collaborative and flexible. The reshaping of customer expectations is letting organizations to go beyond shift-left testing or DevOps testing by transforming the QA process into one driven by quality engineering.

    What Is Quality Engineering?

    To meet the growing demand for quality software applications in double quick time, a mere tweaking of the software development process is not enough. What is needed is the adoption of software quality engineering process comprising optimal quality assurance, predictive analytics and monitoring of QA elements to reduce glitches to negligible levels. The process would involve a continuous cycle of feedback and quality improvement based on the same. The quality engineering process offers maximum test coverage in the shift-left scheme of things and ensures outcomes like functionality, security, accessibility, usability, performance and reliability of the software application. It complements Agile and DevOps methodologies and ensures their outcomes to remain consistent with the desired business objectives. Quality engineering, instead of identifying the inherent glitches in the SDLC, focuses more on preventing them altogether.

    Shift Left and Strengthen Right

    Quality engineering services cover the entire spectrum of the SDLC thereby yielding the maximum test coverage and delivering the best quality product. With DevOps testing shifting left, the quality determinants are incorporated right into the product build during the development phase. At the same time, DevOps-based QA focuses on the shift-right approach to ensure the last stage of the SDLC i.e., delivery goes on unhindered and customer feedback is taken in right way and worked upon. The ultimate aim of both shift-left and right is to create and deliver a glitch-free product that meets the requirements of the end-users. Here, since end-users are the ones who ultimately assess quality of a software product based on parameters such as usability, functionality and performance, among others, the feedback mechanism should be responsive enough to understand the issues faced by the end-users and remedy them at the earliest.

    Quality Engineering as an Aid

    Quality engineering (QE) helps to bridge the gap between development and deployment processes, which can arise due to the lack of agility. It harps on the successful strategy of “test early, test often,” to pre-empt challenges that businesses face when testing a software product. Quality engineering ensures the quality of a software application throughout the SDLC–right from the designing stage to its final delivery. QE can be incorporated into the development process by using methods such as Behavior-Driven Development (BDD), Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) respectively.

    Let’s find out what these methods are all about:

    • BDD: In this software development method, the behavior of both the software and business outcomes are taken into consideration. Here, the right sets of tests are automated, leading to an increased collaboration among developers, testers and other business stakeholders.
    • TDD: In this software development process, the QA team writes unit level tests before the development stage. This results in getting an early feedback and helps the development team to refactor its requisites.
    • ATDD: This software development process focuses on writing an acceptance test even before the development phase. This helps the software to meet the acceptance criteria beforehand.

    Quality Engineering and DevOps

    QE, being an end-to-end testing methodology, can offer optimum solutions to businesses struggling with their legacy IT infrastructure. The solutions in terms of continuous testing and integration as mandated by DevOps, can be arrived at by integrating the QA process with the DevOps pipeline. This results in executing processes such as build, test, deploy and deliver in a seamless manner. QE complements DevOps and Agile by detecting glitches right at the beginning of the development process.

    Moreover, QE’s focus on end-to-end testing helps the product to be developed and tested simultaneously. This approach adds teeth to the DevOps’s requirement for continuous integration (CI) and continuous delivery (CD). No wonder, the successful implementation of quality engineering is underpinned on fulfilling the requirements of DevOps and Agile. It further consolidates the benefits achieved from implementing DevOps testing services and Agile testing services.

    QE riding on DevOps and Agile can help businesses to scale up their operations without investing much resources and time. By implementing DevOps test automation and Agile test automation using a test automation software such as Selenium, Robitium etc., businesses can boost their SDLC. QE can help businesses to develop and deploy glitch-free software speedily and deliver enhanced customer experience.

    Conclusion

    The fast-changing competitive business landscape of today requires organizations to streamline their operations, increase productivity and fast forward the delivery of glitch-free software applications. To achieve these objectives, they need to make quality engineering as part of their development and testing cycles. However, QE ends up complementing the Agile and DevOps approach by achieving outcomes such as CI and CD. Furthermore, it leads businesses to get high ROI, better productivity, reduced cost of operations and enhanced customer experience.

    — Akshaya Choudhary

  • The Relationship Between Feature Flags and DevOps

    The Relationship Between Feature Flags and DevOps

    From 2017 I’ve started most DevOps conversations with, “DevOps is now boring, and I love it!” What I mean by boring is that we are arguing less and less about why you should embrace DevOps principles and practices and having more and more conversations about how to implement DevOps in the real world. As a result, we are getting even more specific about various implementations. One of those is the use of feature flags to increase application velocity, ability to roll back and maybe even canary releases.

    Feature flags seem obvious, but are still a relatively new endeavor—and, for now, still pretty much isolated to the unicorn dev teams. Feature flags allow developers to logically group features and create a toggle for them that can be switched in testing and even prod. The benefits of feature flags go beyond just getting features out faster:

    1. Launching complex feature sets incrementally versus in bi-weekly sprints (fast waterfall). Sometimes features are more complex and connected to multiple services, back-end changes, etc. With modern microservices-based architectures where small dev teams operate on code bases that are independent, this can be difficult. By grouping all the various changes across the entire application as a feature, it means that teams can release functionality they have built without waiting for everyone else and only after everything is in place to turn on the feature.
    2. Recover from risky releases. Part of having feature flags is you can release functionality to production faster. But this also means that you can release functionality that has not been vetted fully across the entire application. With feature flags, an initial rollback does not need to be related to infrastructure at all; it can just be a matter of toggling a feature in production.
    3. Create a value-based information architecture for your application. Developers still are very guilty of thinking of the application as their code base and their immediate teams. But the application from the user’s perspective is based on value. Feature flags, assuming you use some basic best practices for determining your flag structure and names, can group features by value and thus better align everything in the delivery chain to the value the application provides.
    4. Quality (QA and Q)  teams have more power and can provide more value with feature flags. With feature flags, developers can throw more functionality over the fence to QE faster and enable them to have more control of functionality being tested and released without engaging with Dev.

    I would say the initial driver for feature flags has been for A/B testing and canary releases. However, the reality of A/B testing and canary releases don’t make sense for everyone because their application may not have enough users or transaction volume to be statistically accurate to see the value.

    But the value of feature flags goes well beyond that. The challenge is, if you are not a DevOps and automation-focused organization, these benefits are not going to be there. Feature flags are an outcome to DevOps, but my hope is they also are a driver for DevOps. Organizations are guilty of looking at DevOps from the process improvement perspective only. But the real business benefit of DevOps is the value you provide your application users. And if you have a value-first mindset, not only are feature flags an obvious design pattern but also they necessitate that organizations think about their delivery chain in a highly efficient and critical way. Put another way, if feature flags are an outcome you seek, then DevOps processes are not a choice.

    — Chris Riley