Category: DevOps Practice

  • GitLab Strengthens Remote DevOps Management

    GitLab Strengthens Remote DevOps Management

    GitLab this week moved to provide remote developers with access to a more secure continuous integration/continuous delivery (CI/CD) platform while at the same time adding a dashboard that makes it simpler to track the overall status of application development projects.

    David DeSanto, chief product officer for GitLab, said GitLab Remote Development takes advantage of an instance of the GitLab CI/CD platform running on a Kubernetes cluster. That cluster is accessed via a Web-based integrated development environment (IDE) to eliminate the need for developers to create development environments on their local desktops.

    That capability reduces developers’ time and effort on tasks other than code and gives organizations more centralized control over the intellectual property being created, noted DeSanto. Organizations will no longer have to worry, for example, about theft of a developer’s laptop that has sensitive data on it, he added. In addition, organizations will be able to more easily create “golden” images that can be consistently accessed by developers residing in multiple locations.

    In addition to making it easier to centrally manage a distributed team of developers, GitLab is also adding a GitLab Value Streams Dashboard that provides senior executives with access to metrics that assess the overall health of an application development project. While GitLab has always provided metrics to DevOps teams, DeSanto said this dashboard, available as a private beta, makes it possible to identify, for example, bottlenecks that might result in delayed delivery of an application.

    Value stream management (VSM) is, of course, not a new idea. The issue that DevOps teams are trying to come to terms with is whether they need to adopt a dedicated VSM platform. The other option is to simply provide a set of dashboards that enable senior IT and business executives to track projects’ progress without deciphering a set of much lower key performance indicators (KPIs). Previously, the GitLab platform surfaced a lot of nitty-gritty details that don’t provide the context senior executives required, noted DeSanto. The Value Streams Dashboard metric surfaces KPIs based on DevOps Readiness Assessments (DORA) metrics from Google alongside other flow metrics.

    These latest offerings are part of a larger case being made for an integrated DevOps platform that reduces the total cost of application development by eliminating the need for organizations to integrate various tools themselves. Each DevOps team can employ as many of the modules GitLab makes available as they need. Once invoked, they take advantage of the same data store as every other element of the GitLab platform. That capability is becoming more critical as organizations embrace platform engineering to reduce the cost of application development using DevOps best practices, said DeSanto.

    It’s not clear how much interest there is in replacing legacy CI/CD platforms that, in some instances, have been in place for nearly a decade. However, as the pace at which applications are being built and deployed continues to accelerate, there is no doubt that organizations of all sizes will need to modernize application development processes.

  • Microsoft Outage Outrage: Was it BGP or DNS?

    Microsoft Outage Outrage: Was it BGP or DNS?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: All of Microsoft’s cloud services go down, everywhere except China. Redmond’s IaaS, PaaS and SaaS—including GitHub—were dead for several hours, and are still running unreliably—despite Microsoft saying it’s fixed the problem. (more…)

  • Don’t Hire for Product Expertise

    Don’t Hire for Product Expertise

    We all know the jokes about talent recruitment that “requires a century of experience in AI/ML.” With the number of layoffs, no doubt this type of approach will get worse. But that is not generally a tech problem; it is an HR problem–the problem of having people hire in tech that aren’t active in or knowledgeable about tech.

    The real concern that is very much a tech problem is hiring for product and/or technology. I will say outright: Stop doing that except in very special circumstances. Hire for the ability to find information. One of the other things we all joke about is increasingly convoluted interviews where the hiring company wants you to solve their problems in a fraction of the time it would actually take them to do it. Again, if you’re a hiring company doing this, knock it off.

    IT is an ever-evolving field, more so once Agile and DevOps are taken into account. Indeed, we would not be far off if we renamed the field Continuous Evolution, because tomorrow is guaranteed to hold different solutions, no matter what. The idea that requiring experience in Grafana or mastery of Python is an indicator of long-term success is downright farcical. There are positions where this is tolerable–if a position is for maintenance of a traditional app that is not going anywhere and is not getting massive updates, then a list of what tools are desired for the role is easy to build and will be lasting. But I would argue that hiring specifically for that application’s needs is not in the best interest of the organization as a whole, because that person is not portable and adaptable. For modern development, particularly of new products that are just now being architected, the needs are going to change in the process, so claiming you want X years of experience in Spring (when it may use a different framework by deployment time) is not productive.

    As we move into belt-tightening yet again, employees who can do the job and know how to look up new information will be worth their weight in gold. Having a person who can work on existing applications and drive innovation in future applications all in one body is important. Giving them a chance to exercise that drive to learn is also important, but is a separate issue. None of the areas I cover–applications, operations and security–are standing still or even coming close to standing still. The need for people who can go find out what is needed is huge.

    And while the internet is a horrendous mix of good and bad, the ability to find information—and even solutions to problems—is undeniably better than it ever has been. Having people skilled at using that information resource is the key to moving forward.

    So, find people that can solve problems given a modern context. Hiring for technology will solve today’s problems, but problems are not restricted to today, so solve ongoing problems. Gate for basic tech knowledge and skills, then evaluate for the ability to find answers. A far better use of everyone’s time during interviews would be—using email as an example—“Hosted Exchange just went down. Walk me through your troubleshooting steps. You have a couple minutes.” Or—using development as an example—“We just discovered that an OSS library we use has unacceptable vulnerabilities. Walk me through how you would find instances of it and what steps you would take to find replacements. Compliance is breathing down our neck, you have a couple of minutes to show us.” You get to see how they approach likely problems, they get to ask about the environment. Far better than “Show us all the steps to get BGP routing configured,” or “Develop an entire B-Tree while we watch,” questions. Certainly better than any question that ends with “And don’t use the internet.” Are you kidding? Can we talk about the field and what year it is?

    As I’ve said off and on over the years, you want the best coworkers you can get or the best employees you can get. Either way, hiring for expertise with a given tech product is not the best route to that goal. You rock—so get people with you who do, too. It’s not going to get less complex, so have peeps that can keep up and carry a load, no matter what tomorrow’s technology looks like.

  • What DevOps Needs to Know About ChatGPT

    What DevOps Needs to Know About ChatGPT

    OpenAI’s generative pre-trained transformers (GPTs) bring powerful AI language models to every IT community. Within the past few months, ChatGPT has become an incredibly popular derivative of GPT. GPT also has the potential to shake up the DevOps and DevSecOps communities. This article will provide an overview of GPT, its history, current status and future effects on IT, especially DevOps. 

    Learning Overview

    Understanding the difference between supervised and unsupervised learning is essential before understanding GPT. Machine learning and artificial intelligence (AI) use unsupervised and supervised learning approaches. A supervised model uses labeled data to predict outcomes, while an unsupervised model does not. In general, supervised models have some limitations. They need a large amount of annotated data to learn a particular task, which is often unavailable, and they also need to generalize beyond the task for which they were trained. 

    A generative language model is a class of statistical models that differ from discriminative models. You can, for example, generate photos of animals that look like real ones using a generative model. Whereas with a discriminative model, you can determine whether an animal is a dog or a cat. Generative models can assign probabilities to a series of words, such as those that predict the next word or sentence. A generative pre-trained transformer is unique because it uses both unsupervised and supervised learning from unsupervised unlabeled text and follows up with discriminative supervised fine-tuning. 

    GPT-based models—ChatGPT, for example—always return the text “I am” when asked, “I think, therefore …” On the other hand, if you ask ChatGPT, “Why did the rabbit cross the road?” it may respond thusly: 

    “The age-old riddle still awaits an answer: Why did the rabbit cross the road? It’s a mystery that has stumped people for centuries and will likely remain an enigma for years to come.” 

    In this way, we can better understand how GPT-3 works. When asked, “Why did the rabbit cross the road?” most humans will answer, “To get to the other side.” A Google search for “Why did the rabbit cross the road?” mainly yields joke punchlines on the first page of the results. GPT doesn’t differentiate between humorous or cynical answers or specific matter-of-fact answers. The model makes only guesses based on the data. Since, in this example, most of the highest-ranked answers are jokes, GPT’s answer is enigmatic at best. GPT is not pixie dust; it doesn’t have a sense of humor, is not sentient, doesn’t understand juxtapositions and, most importantly, doesn’t evaluate context. As another example, I asked a GPT-3 tool to provide biographical information about two individuals. Abraham Lincon was the first. Approximately ten paragraphs of accurate facts were generated by the GPT-3 tool. Second, I used Gene Kim, the author of The Phoenix Project and The DevOps Handbook. GPT-3 began inventing facts about the companies he worked for by the second paragraph. Additionally, it suggested that he had spoken at TEDx. While a Dr. Gene Kim has spoken at TEDx, that Dr. Kim is an opthamologist.

    History of GPT

    GPT was released for the first time on June 11, 2018. Sometimes it is referred to as the  GPT-1 model. A large dataset of online books was used to train it. A database called BookCorpus also was used for training. There were 7,000 unpublished books in the original BookCorpus dataset at the time of training. 

    OpenAI’s GPT-2 model was created in 2019 as a direct scale-up of the original GPT model. There were ten times as many parameters and ten times as much data in that training set. The GPT-2 dataset was based on an internal OpenAI dataset called WebText. A focus was placed on the quality of the documents when scraping web pages for this tool. The authors scraped all Reddit outbound links receiving at least three upvotes. GPT-2 used about 40GB of Internet text, 8 million web pages, and 1.5 billion parameters. In neural networks, parameters are often used as synonyms for weights (found more often in statistics literature). Parameters in GPT are the weights and biases of the dataset and generally indicate the power. 

    As the third-generation language model, GPT-3 was introduced in May 2020. It has 175 billion parameters, making it more accurate than its predecessors—an increase of tenfold in capacity over the next largest NLP model available. Sixty percent of GPT-3’s weighted pre-training dataset is filtered Common Crawl. Common Crawl is a nonprofit organization that crawls the web and makes its archives and datasets freely available. Since 2011, Common Crawl has collected petabytes of data. About 37% of the GPT-3 sources were WebText2 and other sources, while about 3% came from Wikipedia. OpenAI Codex was also included with GPT-3, which generated code and served as the basis for GitHub’s Copilot. 

    As part of its training, GPT-3 used data available until November 2019. Thus, GPT-3 was unaware of events beyond January 2020. COVID-19, for instance, was unknown to it. Even so, it did have extensive knowledge of coronaviruses, pandemics, Wuhan and SARS. As of September 22, 2020, Microsoft, through a considerable investment, received exclusive permission to use GPT-3; others can still access GPT-3’s public API, but Microsoft is the only one with access to the underlying model. OpenAI developed DALL-E in January 2021, which generated images using GPT-3. OpenAI introduced models in the “GPT-3.5” series on November 30, 2022, including the now-famous ChatGPT, derived from a model from the GPT-3.5 series. Unlike GPT-3, GPT-3.5 includes data up until November 2022.

    Current Status

    I have used several AI language model tools in the past few years based on GPT-3. It is used by Grammarly and by some useful writing tools like Jasper.ai and Wordtune. I also have had great success with GPT-3 research tools like Frase.io and Genei.io. One of my more recent go-to tools is called QuillBot. In my experience, these tools are aids, not replacements for writing. When I first started using these tools, I was writing a book about Dr. W. Edwards Deming. I would get inaccurate information about Dr. Deming’s childhood from a GPT-3-based tool. One time, it said he had six siblings. In fact-checking, GPT-3 confused Dr. Edwards Deming with Dr. Richard Deming. With surgically precise input, the results could be more accurate. One of my findings was that if I used a GPT-3 on a well-known subject, the information was primarily precise; however, lesser-known topics produce fewer facts. Furthermore, I learned from the documentation that when people talk about training GPT-3 models, what they really mean is that you can input a maximum of 2,048 linguistic tokens, which is about 1,500 words. In GPT-3, content is predicted by analyzing past context, one word at a time. The content you input to GPT-3 significantly impacts its output. As a result, it pulls words from a shortlist and calculates their probability of being used. A great set of tutorials on using GPT-3 can be found on Jasper.ai. This figure shows how Jasper (which is based on GPT-3) word prediction works.

    Image source

    People have accomplished some remarkable things by using the 2,048 tokens creatively, but complex training still needs to be improved. Due to the Microsoft deal, the original GPT models were close sourced, and robust training of GPT-3 models is unlikely to happen any time soon. 

    Future Effects on IT

    Where does all the hype come from? Despite its limitations, GPT-3 has created some unique industry artifacts. DALL-E and Copilot by Github are excellent tools. On September 8, 2020, the Guardian published an article titled, “A robot wrote this entire article. Are you scared yet, human?” This article was written by GPT-3. Using GPT-3, some full-blown novels have also been written; they’re not horrible, but they could have been better. According to a study conducted by Drexel University in 2022, systems based on GPT-3 could be used to screen for Alzheimer’s disease at an early stage. Just five days after its launch, ChatGPT surpassed one million users. It took 41 months for Netflix to reach one million users and 10 months for Facebook to reach one million users. By the end of the first quarter of 2023, ChatGPT will have over one billion users. Based on GPT-3.5, ChatGPT is more robust and up-to-date. 

    How smart is ChatGPT? Using a verbal-linguistic IQ test and Raven’s ability test, ChatGPT has an IQ of 147. GPT-3.5 has passed the United States bar exam, CPA exam and U.S. medical licensing exam. People often ask if it is plagiarism to use GPT-3. Technically, the answer is no. The GPT datasets are estimated to represent 300 years of pre-training with a connection of trillions of words. However, using these tools for rewriting other people’s work is, from an ethical viewpoint, plain and straightforward plagiarism. A recent set of tweets by Greg Brockman, president and co-founder of OpenAI and Sam Altman, CEO of OpenAI, sums up the current status of ChatGPT.

    What Does This Mean for DevOps Practitioners?

    AI learning models based on GPT-3 are here to stay. From grammar correction to proposal writing to code generation, GPT-3 has revolutionized everything. In my opinion, GPT-3 still needs to solve some challenges before it is of actual value to DevOps and DevSecOps patterns and practices. For example, a great use case for GPT-3 is training it to deal with organizational incidents. If a GPT model could be trained this way, it would become an excellent tool for providing adaptive diagnostics. Based on the current GPT implementation, this is very difficult or impossible. Another example would be to train the model with the organization’s IT risk policies and enable predictive solutions. The opportunities are endless. 

    An alternative to GPT-3 is InstructGPT, which OpenAI describes as more truthful and less toxic. It has also been noted that GPT-3 can generate untruthful outputs. GPT models aren’t generally aligned with their users. InstructGPT models follow instructions much better than GPT-3. Furthermore, InstructGPT produces more truthful and less toxic outputs. Therefore, they generate fewer harmful outputs and more facts.  The InstructGPT models use human feedback as part of the training model. Some of the real power behind ChatGPT is that it uses InstructGPT along with GPT-3.5. Some of my upcoming research will focus on prototyping some of the complex opportunities DevOps and DevSecOps practitioners currently face using InstructGPT. 

     

  • Dynatrace Survey Surfaces State of DevOps in the Enterprise

    Dynatrace Survey Surfaces State of DevOps in the Enterprise

    A global survey of 1,300 CIOs and DevOps managers working for organizations with more than 1,000 employees published today finds more than three-quarters of respondents work for organizations (78%) that deploy software updates into production every 12 hours or less, with more than half (54%) say they do so at least once every two hours. A total of 20% report they are deploying updates every minute or less.

    Conducted by the market research firm Coleman Parkes on behalf of Dynatrace, the survey also finds 90% of respondents reporting that the pace of digital transformation within their organization has accelerated in the past 12 months. More than a quarter (26%) expect the pace of digital transformation to continue to accelerate, the survey found.

    However, 55% of respondents work for organizations that make tradeoffs between quality, security and user experience to meet the need for rapid transformation. A total of 41% of respondents said they must sacrifice code quality and user experience due to meet demands for faster innovation, while more third (34%) also need to sacrifice code security.

    Overall, DevOps teams, on average, spend nearly a third (31%) of their time on manual tasks involving detecting code quality issues and vulnerabilities that conspire to slow the pace of innovation, the survey found.

    To address these issues, organizations plan to increase their spending on automation across development, security and operations by 35% by 2024, as they invest more in continuously testing software quality (54%) and securing production environments (49%), automatic vulnerability detection and blocking (41%) and automating release validation (35%). The average budget allocated to these activities in these large organizations is $9.1 million, the survey finds.

    A full 88% of CIOs said the convergence of observability and security practices will be critical to building a DevSecOps culture, with 94% noting that extending a DevSecOps culture to more teams is key to accelerating digital transformation. Only 27% of respondents claimed to fully adhere to a DevSecOps culture today. The biggest obstacles to achieving that goal are that security teams don’t trust developers (55%), developers perceive security teams to be blockers of innovation (49%) and the silos that exist between teams (36%).

    Organizations expect to increase their annual investment in DevSecOps automation by 2024 an average of 35%, but only a quarter (25%) said applying artificial intelligence to security was a priority. At the same time, only 28% of respondents said they are fully confident applications are fully tested for vulnerabilities before they are deployed.

    A total of 90% said increasing the use of AI for IT operations (AIOps) will be key to scaling up these practices. However, 70% of respondents said they need to improve their trust in the accuracy of AI’s decisions before they can automate more of their continuous integration/continuous delivery (CI/CD) pipeline.

    Bob Wambach, vice president of product marketing for Dynatrace, said there is a clear correlation between that accelerated pace of digital transformation and a need to deliver more frequent software updates that is driving those investments. Most organizations, however, are going to find it difficult to achieve all their goals unless they break down the silos that prevent them from automating and observing modern DevSevOps workflows, he added. Achieving that goal will also require DevOps teams to reevaluate which platforms they are employing as they move to reduce the current level of friction encountered when building and deploying applications, he added.

    It’s too early to say just how soon DevSevOps workflows will define the next era of software development. One way or another, it’s certain that every organization that embraces DevOps will need to address lingering application security issues.

  • Deploying a Service Mesh: Challenges and Solutions

    Deploying a Service Mesh: Challenges and Solutions

    A service mesh is a dedicated infrastructure layer that enables communication between microservices in a distributed application. It helps to abstract the underlying communication infrastructure, such as network protocols and load balancing and provides a consistent interface for microservices to communicate with each other.

    In a service mesh, each microservice in the application is represented as a “service” within the mesh, and the mesh acts as a proxy between the services, routing requests and responses between them. It also includes a control plane, which manages and configures the proxy instances and provides observability and monitoring capabilities for the services.

    Some of the benefits include:

    • Improved observability: A service mesh provides visibility into the communication between microservices, which can be helpful for debugging and monitoring the performance of the application.
    • Resilience: It can help to make microservices more resilient by providing features such as retries, timeouts and circuit breakers, which can help to prevent cascading failures.
    • Security: A service mesh can help to secure communication between microservices by providing features such as mutual TLS (mTLS) and rate limiting.
    • Ease of use: It provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications.

    Why is a Service Mesh Important?

    A service mesh is important because it helps to abstract the underlying communication infrastructure for microservices-based applications, which can make it easier for DevOps teams to build and manage these types of applications.

    One of the main benefits is that it provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications. For example, a service mesh can provide features such as load balancing, retries and timeouts, which can be useful for ensuring the resilience and reliability of the application.

    It can also help to improve observability for microservices-based applications by providing visibility into the communication between the microservices. This can be helpful for debugging and monitoring the performance of the application, which can, in turn, make it easier for DevOps teams to identify and resolve issues more quickly.

    What are the Main Deployment Challenges?

    There are several key challenges that a DevOps organization may face:

    • Complexity: Service meshes can be complex to set up and manage, especially in large, distributed applications. This can make it challenging for organizations to implement and ensure that it is configured correctly.
    • Operational overhead: Service meshes can add a layer of complexity to the application stack, which can increase the operational overhead of managing the application. This can be especially challenging for organizations that are not used to operating one.
    • Cost: While service mesh software is typically open source, the need to run a sidecar container alongside every container can increase the compute capacity needed to run a Kubernetes cluster.
    • Integration with existing systems: They can be difficult to integrate with existing systems and processes, especially if the organization has not previously used a service mesh. This can make it challenging to get the full benefits.
    • Lack of expertise: Service meshes are relatively new technologies, and there may be a lack of expertise within the organization. This can make it challenging for organizations to get started and ensure it is used effectively.
    • Performance overhead: Service meshes can add a performance overhead to the application as they introduce an additional layer of proxying between microservices. This can make it challenging to ensure that the application is performant and scalable.

    Best Practices to Ease Service Mesh Pain

    Here are a few best practices that can turn service mesh deployments from a pain to a pleasure.

    Use Configuration-as-Code in a GitOps Approach

    Using configuration as code in a GitOps approach is a best practice to improve reliability and maintainability.

    GitOps is a way of managing infrastructure and applications using Git as the single source of truth. In a GitOps approach, all configuration and deployment information is stored in Git, and changes to the infrastructure and applications are made by committing code changes to Git.

    Using configuration-as-code in a GitOps approach can help to improve the reliability and maintainability of the service mesh in several ways:

    • Version control: Storing configuration-as-code in Git allows you to track changes to the service mesh configuration and roll back changes if necessary. This can help improve the service mesh’s reliability by making it easier to identify and fix issues.
    • Collaboration: Git allows multiple people to work on configuration at the same time, which can make it easier to collaborate on changes and ensure that the service mesh is properly maintained.
    • Automation: GitOps approaches often use automation tools, such as continuous integration and delivery (CI/CD) pipelines, to automatically deploy changes to the service mesh when code is committed to Git. This can make it easier to manage and maintain and can help to improve its reliability by reducing the risk of errors.

    Focus On Developer Experience

    Ensuring a positive developer experience is a best practice because it can help to improve the productivity and effectiveness of the development team. A positive developer experience means that developers can easily understand and use the service mesh, and that it does not introduce unnecessary complexity or frustration into their workflow.

    Here are some ways to improve the developer experience:

    • Provide clear documentation: It is important to provide clear and comprehensive documentation on how to use the service mesh, including examples and tutorials. This will make it easier for developers to understand and use.
    • Integrate with existing tools and processes: The service mesh should integrate seamlessly with the existing tools and processes that the development team is already using. This will help to minimize disruptions to the team’s workflow and make it easier for them to work with.
    • Provide support and training: It is important to provide support and training to help developers understand and use the service mesh effectively. This can include online resources, in-person training, and support from the vendor.

    Reduce Costs With Low-Cost Cloud CPUs

    A service mesh increases the cost of an entire containerized deployment because it requires deploying a sidecar container alongside all workloads. When running on Amazon Web Services (AWS), the AWS Graviton processor can ease deployment by reducing the cost of running service mesh infrastructure.

    The AWS Graviton processor is a custom ARM-based processor designed specifically for use in Amazon Web Services (AWS) environments. It is optimized for running workloads commonly found in the cloud, such as microservices and containerized applications.

    Using the AWS Graviton processor can help to reduce the compute costs of a service mesh because it is generally less expensive than other processors, such as Intel Xeon processors. The AWS Graviton processor is also designed to be highly efficient, which can help reduce the service mesh’s overall resource utilization. This can help to reduce the cost.

    Choose the Right Control Plane

    Choosing the right control plane is a best practice because it can impact the performance, reliability and maintainability of the service mesh. The control plane is the central component that manages the proxy servers and enables you to configure and monitor the communication between microservices.

    Here are some considerations for choosing a good control plane:

    • Compatibility: It is important to choose a control plane that is compatible with the rest of the service mesh infrastructure, as well as with the application and its dependencies. This will ensure that the control plane can operate effectively and support the needs of the application.
    • Performance: The control plane should be able to handle the traffic and data volumes of the application without experiencing performance degradation. It should also be able to scale up or down as needed to meet changing demand.
    • Reliability: The control plane should be reliable and able to withstand failures without interruption. It should also provide features such as circuit breaking, retries and timeouts to help improve the resiliency of the service mesh.
    • Ease of use: The control plane should be easy to use and understand, with clear documentation and a user-friendly interface. This will make it easier for the DevOps team to manage and maintain the service mesh.
    • Integration with other tools: It is important to consider how the control plane integrates with other tools and systems, such as monitoring and logging tools, and how it can be integrated into the overall workflow of the organization.

    Conclusion

    In conclusion, deploying a service mesh can be a complex and challenging process, but it can also provide significant benefits in terms of improving the reliability, scalability and security of a cloud-native application. 

    Some of the key challenges include complexity, operational overhead, integration with existing systems, lack of expertise and performance overhead. 

    To overcome these challenges, it is important to choose the right service mesh, use configuration-as-code in a GitOps approach, choose the right control plane and ensure a positive developer experience. By addressing these challenges and following best practices, organizations can successfully deploy a service mesh and reap the many benefits it has to offer.

    Image Source 

     

  • A DevSecOps Process for Node.js Projects

    A DevSecOps Process for Node.js Projects

    Node.js is an open source development platform for running JavaScript code on the server side. Node is useful for developing applications that require a persistent browser-server connection and is often used for real-time applications such as chat, social applications, or news feeds. 

    DevSecOps is a way for development, security, and operations teams to work together throughout the project life cycle. It is often implemented by adding security to existing DevOps teams and agile processes.

    The idea behind this collaboration is to incorporate security early in the development process. This is called shifting security left. As security moves to the “left” of the development process, application vulnerabilities and bugs are discovered and addressed faster. This leads to more secure product releases with a reduced need to apply patches and troubleshoot in production. Applying DevSecOps to Node.js development can improve both the efficiency and security of Node.js projects.

    Common Node.js Attack Vectors

    Here are a few cyber threats that affect many Node.js applications.

    Cross-Site Scripting (XSS)

    XSS attacks inject manipulated client-side JavaScript code. Web apps are vulnerable to XSS if they don’t validate inputted hostnames from the DNS. Attackers can use forms to enter malicious scripts and hack into the system. In some cases, entering code into the filename can trigger cross-site scripting in the target browser. 

    A hacker can use your file upload form to hack into your system. There are many ways for this vulnerability to lead to a system compromise. Though usually mitigated by modern front-end frameworks, in some cases it may happen that putting javascript into the filename will trigger XSS in a user’s browser, allowing the theft of session IDs. In other cases, an attacker might get sensitive server information by uploading a file to the Node.js server and running it by exploiting a path traversal vulnerability.

    Code Injection

    Developers are responsible for writing secure application code, but it’s impossible to fully guarantee the code’s security when using open source components. A code injection attack involves injecting malicious code into the target system and forcing the application to execute it, allowing attackers to access the codebase. Inadequate data validation often results in code injection vulnerabilities.

    Default Cookie Names

    Cookies help web apps identify specific users by storing user actions in the underlying infrastructure (e.g., an eCommerce shopping cart that remembers the items a customer selects). 

    Developers should use custom names for cookies (rather than defaults) to prevent attackers from identifying and targeting cookies and extracting data. 

    Brute Force Attacks

    Brute force attacks often affect Node.js applications. An attacker randomly generates millions of passwords to find one that works, logging in to the application. You can prevent brute force attacks by strengthening the authentication mechanisms, limiting the number of permitted login attempts from a single IP, and encrypting stored passwords (using bcrypt.js).

    Cross-Site Resource Forgery (CSRF)

    This type of session hijacking forces an authenticated user to execute malicious actions on the target web application. The attacker hijacks a legitimate user’s session to bypass security controls and change the application’s state. CSRF can force users to transfer funds or change their account details, potentially compromising the web application’s security. 

    Node.js Security Best Practices

    Implement Strong Authentication

    A compromised, weak, or incomplete authentication mechanism is a common vulnerability. Many developers think of authentication as something that “just works”. However, authentication can easily be bypassed by attackers if not implemented correctly.

    In Node.js, you have the option of using the default Node.js authentication solution. There are a few things to keep in mind: 

    • Do not use Node.js’s built-in password library when generating passwords, use Bcrypt. 
    • Limit failed login attempts and do not notify users if their username or password is incorrect. Instead, return a generic “Invalid Credentials” error. 
    • Have a robust session management strategy. 
    • Implement two factor authentication (2FA). This can be done using modules like node-2fa.

    Alternatively, use one of many third-party solutions available for application authentication, which may be superior to built-in Node.js functionality. 

    Avoid Errors That Reveal Too Much

    There are many things to consider when building error handling functionality: 

    • Don’t give the user any details they don’t really need. Never return the entire error object to the client. It may contain information that you do not want to disclose, such as paths, other libraries you are using, or secrets. 
    • Wrap the path in a catch clause so that Node.js doesn’t crash if the request triggers an error. This prevents the app from crashing continuously, allowing attackers to send malicious requests that cause the app to crash.
    • Don’t expose your Node.js app directly to the internet. Use a component like a load balancer, cloud firewall or gateway. This means DoS attacks will be one step removed from your Node.js application.

    Using Security Linters to Capture Vulnerabilities in Code

    Code linters help identify various issues in code before compiling. They let you detect the most common issues and ensure you follow best practices.

    Code linters have their own rules, which you can customize according to your requirements. Before using a linter, make sure you enable rules related to security vulnerability detection in the linter configuration.

    Server-side Logging and Monitoring

    A good logging library provides developers with powerful troubleshooting and monitoring capabilities. On the other hand, unnecessary or excessive logging affects application performance and consumes more resources. Therefore, you should only use reasonable log levels when deploying applications to production environments.

    When constructing log messages, they must be in a format that can be read and understood by humans and machines. Logging ambiguous messages can lead to misunderstandings among developers. An error message must not only describe the problem but also advise what the user can or should do to fix it.

    It is also important to ensure that your logging mechanism captures all relevant information such as IP addresses, usernames, and actions taken. 

    Never retrieve or store sensitive information in application logs. This violates compliance standards such as PCI and GDPR. However, there are times when you need to record this information for troubleshooting – in this case, it is recommended to mask or anonymize sensitive information before writing it to the log.

    Implementing Node.js Security in a DevSecOps Organization

    Node.js security best practices are well known and security awareness is growing among Node.js developers. However, many organizations don’t have a clear organizational structure for implementing development best practices. Here are a few steps your organization can take to transition a Node.js development team to a full DevOps model:

    1. Adding mandatory guard rails for developers

    For example, adding static application security testing (SAST) within the IDE and on every commit. Linters should be deployed centrally with a consistent configuration for all developers in the team.

    1. Automated security testing in staging environments

    During the CI/CD process, when a Node.js application is deployed to a staging environment, there should be automated tests that can identify security misconfigurations and integration-related vulnerabilities. Dynamic application security testing (DAST) tools are ideal for this purpose.

    1. Runtime protection

    No DevSecOps process is complete without a safety net to identify security issues in production. This requires the use of tools like web application firewalls (WAFs), which can detect and block malicious traffic, and runtime application self-protection (RASP), which can proactively respond to attacks. Both these tools provide feedback to DevOps teams to help them identify and remediate vulnerabilities in the underlying application.

    By implementing these three stages, you can be sure that Node.js security is not just an ad-hoc practice but a formalized, coordinated process involving developers, operations teams and security experts. 

    Conclusion

    In this article, I explained the basics of DevSecOps and how to secure Node.js:

    • Implement strong authentication—In Node.js, you have the option of using the default Node.js authentication solution.
    • Avoid errors that reveal too much—Don’t give users more details than they actually need when displaying errors.
    • Using security linters to capture vulnerabilities in code—Code linters help identify various issues in code before compiling.
    • Server-side logging and monitoring—A good logging library provides developers with powerful troubleshooting and monitoring capabilities.

    I hope this will be useful as you implement Node.js security in your DevSecOps organization.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

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

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

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

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

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

    LinkedIn

    Major League Baseball
    New York, New York
    Senior DevOps Engineer
    $150,000 to $190,000

    SimplyHired.com

    JP Morgan Chase
    Senior DevOps Engineer
    New York, New York
    $137,750 to $225,000

    Indeed.com

    MORI Associates
    Pasadena, California
    Senior DevOps Engineer
    $118,000 to $150,000

    Monster.com

    United Nations Federal Credit Union
    Queens, New York
    DevOps Engineer
    $88,170 to $140,000

    ZipRecruiter

    Blue Rock Software
    Carlsbad, California
    DevOps Engineer – AWS
    $80,000 to $100,000

    Image Source: Photo by Mike Bowman on Unsplash 

  • 6 Ways To Empower Developers and Increase Productivity

    6 Ways To Empower Developers and Increase Productivity

    A big goal of DevOps is to increase productivity. Yet many organizations still struggle with the efficiency of their software release processes. In fact, 54% of engineers stated they have too many manual steps within their deployment process, according to an Armory survey. And with the pervasiveness of multi-cloud, developers now face an escalating number of deployment environments, each carrying their own nuances.

    Development teams want to move as quickly as possible without barriers. Yet, there are often hurdles to seamless deployments. For example, the code might be 100% ready to deploy, yet someone still must validate it before it reaches production. Manual bottlenecks like this in the CI/CD process can make developers feel like their code isn’t worthy of deploying and may even amplify feelings of burnout.

    I recently met with Anna Daugherty, senior product marketing manager at Armory, to see what technology leaders can do to remove barriers within their software release cycles and increase productivity. According to Daugherty, many of these strategies boil down to having empathy for developers and their needs. “Developers aren’t machines; they’re people, and people deserve to have a quality of life when they’re doing their jobs.” Below, we’ll highlight tips and tricks to keep in mind to improve release fluidity.

    1. Identify Where Your Manual Checks Are

    The first step to speeding up CI/CD is identifying where manual steps exist within the development workflow. The DevOps life cycle, often visually depicted as an infinity loop, includes many states, such as design, build, test, deploy, assess and monitor. But if each step has one or more manual steps, you accrue a lot of manual debt, said Daugherty.

    Therefore, engineering leads should seek to remove manual checks whenever possible. Of course, this may not be realistic within certain situations, such as financial institutions that require manual approvals at the last mile. However, everything should be smoothed out and automated up to that point, said Daughtery.

    2. Shift From Continuous Delivery to Deployment

    Depending on who you ask, the ‘CD’ in ‘CI/CD’ may stand for continuous delivery or continuous deployment. As part of reducing friction in the software release process, Daughtery encourages teams to begin to embrace the latter whenever possible. If deployment remains inhibited by unnecessary manual steps, it can decrease scalability and interoperability.

    3. Increase Confidence With Testing

    Of course, if we introduce more automation into the CI/CD pipeline, we must ensure the software is rigorously tested for errors and vulnerabilities. Daugherty encourages development to embrace automated, continuous testing approaches at every juncture, whether pre-production, inter-production, or throughout the application lifecycle. There are also advanced deployment strategies to consider, such as canary testing, which rolls out new changes only to a small subset of users or blue-green deployment can deploy to different places at different times.

    These deployment strategies can help build confidence while reducing the risk of disrupting a majority of your user base with untested production updates. “The more you can integrate testing into your process, the more confident your process will become,” said Daughtery.

    4. Chose The Right Toolsets

    So, how do we implement more automation into the DevOps cycle? And what sort of tools should we look for? According to Daugherty, when scouting for DevOps tools, technology leaders should prioritize open solutions that aren’t closed-off environments. Instead, they should offer flexibility and the ability to integrate with the tools you already use every day. “You can have all the tools in the world, but if they don’t fit together, that can drag down the process.”

    5. Consider Open Source Software (OSS)

    On that note, consider open source software (OSS) where possible. OSS like Argo or Spinnaker has the potential to empower developers and bridge gaps in the CI/CD process. Other projects from the Cloud-Native Cloud Native Computing Foundation (CNCF) and Continuous Delivery Foundation (CDF) are mature with proven stable adoptions.

    And although there is some weariness around OSS, particularly around unknown vulnerabilities and project maintenance concerns, “you can still be successful, secure, and scalable with open source,” said Daugherty. Open source also delivers community benefits and helps engineers feel like they are part of a bigger picture. “[OSS] is the opposite of burnout. It brings people together. It’s a community builder.”

    6. Become Developer-First

    Transitioning into a developer-first organization is another way to increase developer satisfaction and efficiency. But to become a developer-first organization, developers will need more say in the processes—this will involve balancing top-down requirements with total developer control. For example, leaders should suggest tools to enhance productivity but accept feedback on an ongoing basis to see what works best.

    To support these efforts, the concept of developer experience (DX) has entered the lexicon in recent years. Building with developer empathy can result in more usable, frictionless software that increases productivity. DX is crucial within the burgeoning area of platform engineering, as the goal is to create reusable, internal self-service platforms for developers to leverage.

    Interestingly, Netflix extolls what it calls full-cycle development, in which a developer oversees the building and operational aspects of a single component throughout its entire life cycle. “It’s an interesting way of addressing burnout because you feel more connected to what you create,” said Daugherty.

    Final Thoughts: DevOps Isn’t Dead

    Above, we’ve highlighted some potential strategies to increase developer productivity. By replacing manual bottlenecks with more automation, you can increase deployment fluidity. Considering how tools are acquired and iterating upon feedback from engineers can also help improve consistency while retaining quality talent.

    Looking to the future, Daughtery hopes that similar roles such as DevOps, site reliability engineering and platform engineering can come together and join forces. Because, at the end of the day, they share many goals. And contrary to some grabby headlines, DevOps is far from becoming obsolete. DevOps is not dead. It’s very much alive and increasingly important.

  • 8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: New ideas bring low-power ML inference, and more big-tech jobs are going. (more…)