devopsy.kinsta.cloud

Category: DevOps Onramp

  • How Good Developers Become Good Engineering Managers

    How Good Developers Become Good Engineering Managers

    Being a good engineering manager means that, to some degree, you have a natural affinity for the work involved. And if you’re a good developer, you likely already have some of those innate skills and attributes.

    But simply having the skills doesn’t mean you’ll enjoy being an engineering manager. For example, the nature of the role is that you’re no longer the one writing the code. I’ve known great architects who became great managers, but they ended up going back to being individual contributors (ICs) because they missed working with nitty-gritty coding details and the joy that brought them.

    It helps to take a realistic inventory of your skillset and preferred working style before making the transition. There are certain competencies you should have completely dialed in, and other tips to know that will help your transition.

    Basic Skills of a Good Engineering Manager

    If you’re a good engineer, you likely already have the following foundational skills that also make a good engineering manager. With these in your toolbox, you’ll have a better chance at success.

    1. Attention to detail. The buck stops with the engineering manager. You need to know when to push and ask questions and how to set outcomes for your team’s accountability. If you work loosely as an IC and need reminders about your own work, you probably won’t do well as a manager.
    2. Amazing personal planning skills. As an engineering manager, you’ll be planning an entire team’s work. If you’re terrible at planning your own work, maybe the engineering manager role isn’t for you.
    3. Speak intelligently about broad technical topics. If you’re a good developer, this shouldn’t be a concern. You’ll need this knowledge to advocate for your team and justify their work to upper management.
    4. Team player attitude. Even as an IC, you should have a collaborative, team-oriented mindset. It goes without saying that you’ll need this when leading others.
    5. Interest in managing others. This might seem obvious, but if you don’t have a natural interest in managing others and in the people side of engineering, you’ll be unhappy as an engineering manager.

    Making the Transition From Developer to Engineering Manager

    If you can do all of the above and are ready to make the transition from developer to engineering manager, here’s what to be aware of as you navigate that process. These tips aren’t meant to deter or discourage you but rather provide a helpful dose of reality.

    Satisfaction in your work takes new forms. If you’re an excellent developer, you know the value you bring and likely get personal satisfaction out of the contributions you make. As a manager, it’s harder to see the direct value you provide. Shift your mindset and realize that now, you’re the one enabling developers to do that rewarding work, and that’s the value you provide. You’ll learn to take enjoyment and fulfillment from your team’s accomplishments.

    People take up a lot of your time. What most frequently catches new engineering managers off guard are the people-related aspects of the role. They’re not prepared for how much time managing people takes. I’ve seen it over and over again where a new manager thinks they can still set aside time to code, but you really have to prioritize learning the craft of management.

    Remember to communicate upward. In the absence of information, it’s human nature to assume the worst. When I was at BitBucket, I assumed that because I had always done a good job, the leaders would think my team was crushing it. The opposite was true; leadership thought everything was on fire.

    I started sending updates every two weeks to various levels of management, and that’s when I learned the power of upward communication. I realized I needed to sell my team’s work, contributions and challenges. Learn what higher-level leaders are looking for and then give them that information regularly.

    Context-switching is part of the job. As an IC, constant context switches kill your day. But being an engineering manager means dealing with endless context-switching. Going to multiple meetings is baked into the job, and you’ll still have to find ways to block off time to get other work done.

    Shield your team. You also need to be prepared to help protect your team from context-switching. You might learn information that’s important to your team during your many meetings, but not all of that needs to be communicated with them. Filter out the junk so it doesn’t rain down on them and they can maintain their flow.

    Being an engineering manager can be a rewarding role that has a considerable impact on an organization. The more prepared you are for the realities of the role and its differences from being a developer, the more you’ll enjoy it and the more successful you’ll be.

  • The Best (and Worst) Reasons to Adopt OpenTelemetry

    The Best (and Worst) Reasons to Adopt OpenTelemetry

    It was a rainy day in Seattle at KubeCon + CloudNativeCon North America in December 2018 when I first encountered the term ‘OpenTelemetry.’ At that time, I was an active member of a working group focused on developing W3C Trace Context, a standard now extensively employed for context propagation in distributed systems. It is likely no coincidence that some key individuals in this working group also played a pivotal role in orchestrating the merger between two prominent open source telemetry products: OpenCensus and OpenTracing. I never would’ve guessed that, in 2023, OpenTelemetry would become the second-largest project in the CNCF, sitting just behind Kubernetes.

    As is the case with any popular new technology like OpenTelemetry, the hype can make it difficult to discern signal from noise. During my years working in observability, I’ve had the chance to chat with many organizations that were thinking about using OpenTelemetry or already actively use it. Through those conversations, I’ve heard many reasons for adopting OpenTelemetry, some good and some bad. In this post, I will share examples of the best and worst reasons to adopt OpenTelemetry to help you cut through the noise.

    Poor Reason One: Following the Crowd

    It’s never a good idea to adopt something solely because others are doing it. Just because you saw a conference talk praising a new technology as the greatest innovation since sliced bread doesn’t necessarily mean that technology is suitable for your specific use case.

    Speaking of which, have you clearly defined your use case? To start, ask yourself the following three questions:

    1. Are you able to determine at any given moment whether your systems are performing as expected, such as meeting their service level objectives (SLOs)?
    2. When something goes wrong, can you easily pinpoint the root cause?
    3. Are you able to drill into previously unidentified problems, also known as “unknown unknowns”?
    If you answered these questions with “no,” you certainly have observability gaps worth tackling, and OpenTelemetry may help close some of them.

    Poor Reason Two: Building Your Own Observability Product

    Gathering telemetry data can be a challenge, and with OpenTelemetry now handling essential signals like metrics, traces and logs, you might feel the urge to save your company some cash by building your own system. As a developer myself, I totally get that feeling, but I also know how easy it is to underestimate the effort involved by just focusing on the fun parts when kicking off the project. No joke, I’ve actually seen organizations assign teams of 50 engineers to work on their observability stack, even though the company’s core business is something else entirely.

    Keep in mind that data collection is just a small part of what observability tools do these days. The real challenge lies in data ingestion, retention, storage and, ultimately, delivering valuable insights from your data at scale. Chances are, a homegrown solution won’t give you a return on investment that your company would appreciate.

    However, whether you build your own system or use an existing product, OpenTelemetry may be a good fit for your observability stack.

    Poor Reason Three: ‘Vendor Neutrality’

    People I chat with often cite vendor neutrality as a major reason for their interest in OpenTelemetry. While there’s some truth to this, which I’ll touch on shortly, it’s important to take this argument with a grain of salt to avoid over-promising your management.

    If you’re a developer, you’ve likely worked with database abstraction libraries and have probably mentioned to someone that they allow you to swap out the database at any time–using MySQL today and Oracle tomorrow, for instance. While that’s the promise, I’ve never seen this happen in my career. There’s more to consider other than the SQL dialect when switching a database backend.

    In the same vein, the idea of vendor neutrality suggests that you can easily switch your observability backend. While this might be true in theory, in practice, vendor lock-in often occurs on the backend, where people and processes become closely tied to the tool currently in use.

    So, if you believe you’ve achieved vendor neutrality by going all-in with OpenTelemetry, I’d encourage you to think twice and consider building a stronger case. Vendor neutrality should not be your only reason.

    With all that said, it’s time to focus on the good reasons to use OpenTelemetry today. Trust me, there are plenty, and they’re definitely worth considering.

    Good Reason One: Bridging Gaps With Manual Instrumentation

    Nearly every observability tool out there today relies on some degree of auto-instrumentation. This means once you’ve added their respective language SDK to your code, the library will utilize a technique called “monkey patching” to insert observability code that runs automatically.

    At the very least, auto-instrumentation will search for recognized libraries and APIs and then add some code to indicate the start and end of well-known function calls. Additionally, auto-instrumentation takes care of capturing the current context from incoming requests and forwarding it to downstream requests.

    However, auto-instrumentation falls short when it comes to pure userland code, particularly for dynamic languages like JavaScript. It won’t catch your blocking Fibonacci function that’s slowing down all your requests by 50%. In some cases, you might also have to add your own context-propagation logic to RPC calls not captured by the auto-instrumentation.

    That’s where manual instrumentation comes in. In the past, vendors provided an API for their SDK, allowing developers to manually add instrumentation code to segments that weren’t auto-instrumented. This often resulted in code being littered with vendor-specific instructions. This brings us back to the topic of vendor neutrality. While adding a dependency to your project is usually no big deal, it becomes cumbersome when 20% of your codebase is made up of vendor-specific observability instrumentation.

    OpenTelemetry addresses this issue by offering both auto-instrumentation and a vendor-neutral API for manual instrumentation. This allows observability vendors to access the data while maintaining vendor neutrality within your codebase.

    Good Reason Two: Sending Data to Multiple Vendors

    I’ve yet to come across a large organization that relies on just one observability tool. Different parts of the organization have unique needs and perspectives when it comes to data, and it’s rare that a tool designed for SREs satisfies all use cases developers have and vice versa.

    At the same time, it’s not practical to instrument code specifically for each vendor. Doing so would lead to performance issues and other problems, such as double-tracing. For example, if multiple vendors modify an outbound HTTP request to add context, which one takes precedence?

    OpenTelemetry addresses this by offering a unified way to instrument code and multiple integration points where vendors can capture the collected data and send it to their respective backends. As a result, a single application can send data to multiple observability backends with a minimal added performance impact.

    Good Reason Three: Gaining Insight Into Third-Party Libraries and Services

    In an era where many applications depend on third-party libraries and services, gaining insight into all your application dependencies has become increasingly difficult. It’s also challenging for observability vendors to keep up with every new library and service that’s released.

    Traditionally, vendors would try to reverse-engineer these services and apply the aforementioned monkey patching to add in their code. However, since every vendor must do this for each service, it ends up being a lot of redundant work. A key goal of the OpenTelemetry project is to make it easy for infrastructure and library vendors to add instrumentation hooks to their code. This way, their offerings can be monitored without the need for reverse engineering. The observability community is gradually making progress on this goal. One successful example is Istio, which emits OpenTelemetry data that can be easily consumed by observability backends to understand what’s happening inside the service mesh.

    Unsurprisingly, cloud vendors like AWS, Microsoft and Google are among the founding members of the OpenTelemetry project. They share a strong interest in defining a format that allows observability vendors to seamlessly consume data from cloud services. OpenTelemetry Protocol, or OTLP, is set to become the standard for emitting observability data from these services that would otherwise be black boxes.

    Wrapping it Up

    “If all you have is a hammer, every problem looks like a nail.” This statement holds especially true when selecting tools in the tech industry. While there are many good reasons to adopt OpenTelemetry, it’s crucial to approach technology choices pragmatically.

    Avoid jumping on the bandwagon for its own sake; instead, carefully evaluate your use case and assess the available tools. OpenTelemetry is undoubtedly here to stay, and if you’re new to the topic, taking a closer look at the project and adding it to your toolbelt makes perfect sense.

    And don’t forget: OpenTelemetry is open source. Your contribution is always appreciated.

  • The Now and Next of Automation

    The Now and Next of Automation

    Today’s never-ending flood of data has many of us drowning in noise. And while humans are still essential for thoughtful analysis and driving action, it’s no longer possible for a human to parse gigabytes of data alone.

    How do you begin to filter out the noise and then understand what to do with it? How can you get to the root cause of an issue so you can act on and resolve it? Most of all, how can you do all of this while being more productive and driving more innovation instead of constantly putting out fires?

    Automation is the obvious answer. For many organizations, automation isn’t just about efficiency – it’s about survival. Automation can make organizations more agile, resilient, and capable.

    Where you sit within an organization or team, however, often dictates how automation can help with your specific goals or alleviate your immediate pain points. Mandi Walls, a DevOps advocate with PagerDuty, offers some advice on how even less experienced teams can use automation to perform simple tasks, solve problems and improve the work environment.

    We hear a lot these days about A.I. and machine learning, or tools like Chat GPT which to some is a harbinger of robots finally replacing humans. Putting the hyperbole aside, where do you see automation today? Is it still a “nice to have” for engineering teams or a “must-have” to do their jobs effectively?

    Automation is definitely a “must-have.” Manual processes are risky; they can inadvertently introduce too many errors, especially in complex environments. The scope and complexity of modern technical ecosystems is just too vast for teams to effectively cope with using only manual methods.

    This is especially true for teams that develop and manage customer-facing services. Having a successful product leads to more customers, which requires more capacity and creates more complexity. To deliver the kind of performance customers expect, teams need to be fast and efficient. That’s where automation comes in.

    What are some specific types of automation that engineers and IT pros should be aware of?

    Some automation has become more or less ubiquitous, such as tools that enable configuring and building large numbers of systems with little human intervention. Other processes might feel less like “big-A” automation–for example, continuous integration/continuous delivery (CI/CD) pipelines are automation.

    Humans also aren’t manually building many software packages anymore. The use of automation in the software testing process has greatly expanded in the last several years, changing the jobs of QA engineers significantly.

    Is self-service automation – aka true autonomy that doesn’t require human intervention – the ideal end state for a digitally mature organization? When is the best time to jump in?

    Organizations that wait for a perfect opportunity to automate their processes risk wasting a lot of time and resources in the interim. Teams can look at any of the tasks that they regularly perform and assess them as candidates for automation.

    Tasks can be assessed in a number of different ways, but for teams just starting out with automation, seeking tasks that are low complexity and low impact is a strong starting point. Even if we look just within the realm of tasks that might be utilized during incident response, teams might have any number of tasks related to information gathering, log preservation, system diagnostics, and other telemetry that responders run for every incident. There’s no reason to require humans to run those well-understood tasks!

    As teams get more comfortable with creating and using automation, they can seek out more complex tasks to automate. And it’s entirely possible that there will be tasks that teams aren’t able to automate fully! Those tasks might be too complex, require a lot of human input or interaction or have too many edge cases for the team to create automation for.

    Are the principles of automation the same in simple versus more complex environments like Kubernetes?

    The principles are essentially the same, but the constraints and tools may be different. In some environments, a simple shell script might be enough to accomplish our goals. In other environments, we might need to make use of APIs or vendor SDKs to do what we want.

    On that topic, is self-service automation in cloud environments the preferred path?

    Actually, self-service is sort of how the cloud really got going! Development teams armed with nothing more than a credit card got the environments they needed without going through lengthy procurement processes.

    Now that cloud is a critical part of many workloads, organizations are putting more rigorous guidelines in place. The cloud platforms are also much more complex, with more service offerings than in the early days, which makes automation more important than ever. Automation helps organizations ensure that their cloud environments meet their security and compliance requirements, helps manage spend and still provides enough flexibility for all teams to get work done. And with self-service automation, developers can request an environment in the cloud to develop their service and have that service meet all the organization’s standards without having to keep up with all the details themselves.

    What about toil? Can that be fully eliminated through automation, or is some toil still necessary?

    I’m not sure I’d say toil is necessary, as much as it tends to be inevitable. There will likely always be some boring, repetitive tasks that are too unpredictable or unstable to automate well.

    That said, teams certainly don’t need more toil; having too much repetitive work tends to lead to less job satisfaction and higher attrition rates, so teams should be looking to minimize as much toil as possible where they can.

    Is there one myth or misconception, either about automation overall or self-service automation in particular, that you’d like to clear up? What’s the reality?

    First of all, don’t worry. You won’t be able to replace your team with a set of shell scripts! Seriously though, automation isn’t about “doing more with less.” It’s about doing more with the same. Automation is an approach to help teams cope with the day-to-day running of complex environments and will need to be managed as part of those environments. Managers need to make sure they are allotting time for the creation and maintenance of automation in the same way they would for other tools and applications.

    Interested in learning more about PagerDuty? Stop by Booth S49 at KubeCon to speak with an expert or see a demo!

  • Why Monitoring-as-Code Will be a Must for DevOps Teams

    Why Monitoring-as-Code Will be a Must for DevOps Teams

    Over the last decade, we’ve seen an increasing number of operations teams and development teams using an infrastructure-as-code (IaC) process for provisioning cloud-based infrastructure. In that model, IaC tools like CDK, Pulumi or Terraform are employed to allow developers to code, deploy and manage cloud-based infrastructure. The advent of cloud services and IaC tools has freed engineering teams from error-prone (and slow) manual infrastructure provisioning processes. The ability to codify your infrastructure next to your version-controlled application code has been a game-changer for many organizations.

    An Introduction to Monitoring-as-Code

    With IaC becoming an increasingly valuable tool for managing infrastructure, it’s only natural that other parts of the ecosystem follow that shift left philosophy, including how testing and monitoring are done.

    Similar to IaC, the monitoring-as-code (MaC) concept allows us to describe a monitoring infrastructure as code. Today, many DevOps teams are employing MaC by using some of the aforementioned IaC tools like Terraform or Pulumi—in conjunction with monitoring platforms like Checkly—to create, run and manage their browser and API monitoring regimens. In these examples, monitoring checks can be defined in JavaScript, TypeScript or HCL, and then those can be committed together with application code. Modern MaC matures fast; it does not even require traditional IaC tools but enables MaC without extra tools. Modern platforms enable this by shipping CLIs to achieve this. Making monitoring an integral and companion part of your codebase comes with many benefits and advantages.

    Just as IaC has become an integral part of the new paradigm for managing cloud-based infrastructure, here are a few reasons why I believe MaC will also become a must for modern DevOps teams.

    The Benefits That Make MaC a Must for DevOps Teams

    Flexibility and Programmability
    By adopting MaC, your automated testing infrastructure is defined as code and lives next to your application code in your code repository, giving you all the benefits that entails. Testing and monitoring are no longer treated as separate from your application code.

    Update Monitoring With Your Code Changes
    As mentioned in the previous bullet, MaC places your testing and monitoring next to your application code. So when your application code is updated, your testing and monitoring ships right alongside it, streamlining the process. That makes your testing and monitoring solutions deployable, with MaC giving you the ability to schedule tests on a continuous, around-the-clock basis from distributed locations across the globe.

    Monitor and Test on Staging
    In the past, synthetic monitoring was primarily meant to run on production: Once your apps were deployed, monitoring kicked in and alerted you when things failed. With MaC, that monitoring can now run locally alongside your application code in a CI/CD flow, allowing that app code to be tested and even monitored continuously on staging before getting deployed on production.

    Speed and Automation Efficiency
    With monitoring now embracing the “as code” paradigm, new checks can be spun up quickly and in far less time than a non-MaC monitoring approach. All of that increased speed and efficiency will have a real-world impact on dev, ops and QA teams, saving engineers hours now automating once-siloed manual and inflexible work.

    Scale as Needed
    Finally, given that your tests live right next to your application code, it’s much easier to observe, manage and understand what is being monitored. That insight and visibility also make it much easier to scale your testing and monitoring efforts across teams, organizations and even across the globe. All of that enhanced efficiency frees dev and QA teams to focus on other tasks while simultaneously providing better testing and monitoring support across the organization.

    MaC Benefits in Action
    As an example, all of the aforementioned benefits are being employed by a large health care provider that recently adopted a MaC workflow. That organization relies on a MaC testing and monitoring workflow—based on tests written in Playwright—to automate its synthetic monitoring efforts. In particular, a MaC approach has enabled the QA and dev teams there to quickly build, validate and deploy an entire suite of checks from their local development environment.

    The Future of Testing and Monitoring

    With MaC now moving in the same leftward direction as IaC, I believe that the future of monitoring will become increasingly accessible, flexible and frictionless for any modern developer. MaC will also be increasingly based on open source testing and automation frameworks like Playwright, Puppeteer and others, which have been used and adopted for automation and testing for years.

  • A DevOps Guide to the Language of DevSecOps

    Security is increasingly important for DevOps due to the growing complexity of applications and the accelerated pace of development. As organizations adopt DevOps practices, they face new challenges in securing applications and infrastructure:

    • Increased complexity and automated processes: With automation at the core of DevOps, processes and applications are more intricate. This can introduce vulnerabilities if not carefully managed and secured, as they often involve multiple systems and components that need to be protected.
    • Reliance on code repositories: DevOps teams depend heavily on code repositories for version control and collaboration. However, these repositories can be targets for attackers seeking to inject malicious code or steal sensitive information, making it crucial to secure access and maintain good security practices.
    • Larger attack surface: The DevOps pipeline consists of numerous tools and components, including source code management, build systems, testing frameworks and deployment tools. Each of these elements presents potential attack surfaces and needs to be secured to protect the overall application.
    • High-velocity development: The rapid pace of development in a DevOps environment can sometimes lead to security being overlooked or deprioritized. As new features are pushed out quickly, there may be less time for thorough security reviews.
    • Tooling limitations: While many DevOps tools come with built-in security features, these may not be sufficient to protect against all threats. Relying solely on these features could create a false sense of security, leaving organizations exposed to potential attacks.

    What is DevSecOps?

    DevSecOps enables teams to shift security left and integrate it continuously across the entire SDLC rather than as an afterthought. It is a cultural shift even for DevOps teams, as it requires all members to adopt a security mindset that ensures software is not only released fast and at the highest possible quality but also includes all security measures and checks from the design phase.

    It typically involves adopting secure coding practices and implementing application security testing tools that help design, test, verify, release, and update secure software in a secure manner. It requires ensuring that not only the software itself is secure, but also the development environment and the entire supply chain is secure. As a result, DevSecOps rely on a high level of automation tools to reduce manual work to a minimum.

    DevOps Guide to Security Acronyms

    All DevOps pros need to become familiar with key security concepts. Here are a few concepts that will help you communicate better with security teams in your organization and one day become a DevSecOps geek yourself.

    1. SBOM—Software Bill of Materials

    A software bill of materials (SBOM) comprises all components and software dependencies in the application’s build and delivery. It provides visibility into all the different components and licensing included in a piece of software to help discover potential vulnerabilities and licensing risks.

    2. DAST – Dynamic Application Security Testing

    DAST involves analyzing applications or services while they are running to identify security vulnerabilities. This technique typically simulates attacks to learn how a malicious actor might exploit the user or application interface. Teams use DAST tools to detect complex vulnerabilities caused by specific functionality that a static analysis tool cannot find when analyzing the source code.

    3. SCA – Software Composition Analysis

    SCA tools identify security vulnerabilities in third-party components and dependencies. Teams can integrate SCA to run across the entire development pipeline to build an open source dependency tree for the application and map these components against a database of known vulnerabilities. The tool generates reports on vulnerable open source components found in the application that require fixes or patches.

    4. SAST – Static Application Security Testing

    SAST tools analyze the source code of applications, services, and microservices, trying to identify potential vulnerabilities caused due to insecure coding practices. Teams can integrate SAST tools into their continuous pipeline, setting them up to automatically search the source code for coding patterns and insecure objects or functions that can result in security vulnerabilities. SAST is commonly used to identify vulnerabilities during the coding phase or when pushing code to a testing environment.

    5. IAST—Interactive Application Security Testing

    IAST involves analyzing the source code for vulnerabilities while the application is running. The main advantage of IAST is that this method reports vulnerabilities in real-time and does not add additional time to the CI/CD pipeline. It works from within the application, distinguishing it from both SAST and DAST techniques that work externally. IAST does not scan the entire codebase. Instead, it checks only the aspect exercised during the functional test.

    6. RASP—Runtime Application Self-Protection

    RASP is a defensive technique built into the tested application to detect and respond to attacks as they occur. It is typically implemented using third-party tools embedded within the application to monitor incoming requests and the application’s behavior, such as packages, plug-ins or libraries. These components inspect requests and the application’s behavior to block and protect against threats.

    7. OWASP—Open Web Application Security Project

    OWASP is a nonprofit devoted to helping improve software security by offering free resources and tools. This organization consists of a large community of volunteers who help propose, build and manage projects and educational materials that support the wider software development and security community.

    8. XDR—Extended Detection and Response

    XDR solutions collect and correlate deep activity data and detections across various security layers, including endpoints, emails, servers, networks, and cloud workloads, performing automated analysis to help detect threats faster. Teams can use this information to take quicker action during investigations. The main advantage of XDR solutions is that they help break down the security silos that allow stealthy threats to evade detection. 

    9. XSS—Cross-Site Scripting

    XSS is a security vulnerability. It plagues so many web applications that it has yet to be removed from the OWASP Top 10 web vulnerabilities list since it was first included in the 2003 version. XSS vulnerabilities enable threat actors to execute malicious script code in one or multiple users’ browsers. Actors often use XSS to gather sensitive information, such as user session details and personal data. 

    10. SQLi—SQL Injection

    SQLi is a code injection technique that enables threat actors to attack applications. It typically occurs when applications require user input, such as usernames, but receive a malicious SQL statement instead. To launch this attack, actors must locate vulnerable user inputs in the web application, create input content and send it. If the database executes the malicious SQL command, the attacker gains access to the database.

    11. CSRF—Cross-Site Request Forgery

    CSRF is a common web application attack that exploits the trust between a user and an application to conduct various malicious actions. Threat actors use CSRF to hijack an authenticated session between a user’s browser and an application. Once actors have access to the session, they can use it to execute functionality on that application.

    12. SAML—Security Assertion Markup Language

    SAML is a standard used to securely share information about identities, authentication, and authorization between various systems. It is typically implemented with the Extensible Markup Language (XML) standard for data sharing and often provides an open framework to implement a federated identity system like single sign-on (SSO). 

    Conclusion

    In today’s chaotic cyber landscape, DevOps teams cannot solely prioritize the fast release of high-quality software. To ensure their software, infrastructure and development environment are protected, DevOps teams must integrate security into the entire SDLC. This endeavor requires adopting a security mindset and utilizing tools that help create an efficient and secure pipeline. 

    The acronyms discussed in this article include essential security aspects DevOps teams should get familiar with, such as the OWASP organization that provides important guidance on building secure software, tools that help shift security left and common web vulnerabilities. However, teams should branch beyond these practices and tools to create a comprehensive security policy that covers their unique needs and requirement.

    Image Source 

  • Creating a Growth Loop for Your Open Source Project

    Creating a Growth Loop for Your Open Source Project

    Every open source project hopes to achieve escape velocity, attracting enough users and contributors to become a successful, sustainable project that expands over time. But how do you attract developers and create the cycle of adoption that can lead to a thriving ecosystem?

    It obviously starts with building a great product that developers love to use, and there’s an element of luck in finding this sweet spot and breaking through. But there’s also a lot that you can control. I was fortunate to have helped create an open source project, Streamlit, that expanded quickly and our company was acquired last year. I wanted to share what worked for me in the hope that it also can be helpful for you.

    My guiding principle is to meet developers where they are and make it as simple as possible, at every step in the journey, to discover your project, learn how to use it and build great products. Depending on the type of open source project you’re creating, providing a simple way to share artifacts and use cases built from your code—in our case, this was applications—can also be a powerful way to raise awareness.

    I think about this in terms of a “growth loop” with multiple points of entry where developers can get interested and get started. These entry points include developer forums, source repositories, your documentation page, learning assets, your website and more. The point is to eliminate friction at every point in this loop and make it as easy and fun as possible to start building and sharing with your code.

    For organizations trying to get their open source project off the ground, here are some key learnings about what worked for my company in building this growth loop and some tips for driving continued adoption and innovation.

    Be Visible in the Open Source Community

    We made it a point to go where developers are already at, including forums like Reddit and Stack Overflow and conferences like ODSC and FOSDEM. Engaging with developers to understand what they really need from your project and how to reduce points of friction is key. We were always grateful when people gave us feedback and we reached out to any developer who engaged with our product, whether they had 10 followers or 10,000. I’ve found that developers really appreciate it when you “show up,” and you learn an incredible amount that can help your project succeed.

    Give Developers What They Need

    Don’t hold back features or functionality that developers will find useful. Developers should have access to everything they need and feel confident that they won’t run into a significant paywall that prevents them from scaling. Building a successful open source project is a bottom-up process, and that means eliminating barriers to entry and making your code as easy to use as possible.

    Where developers go, enterprises typically follow. If you can build a tool that developers love so much they’re coding with it in their free time, they’re likely to take it into the workplace. If your goal is monetization, this is where you’re most likely to have an opportunity to recoup your investment.

    Enterprises require particular features around security, access management, IT support, scaling, service level objectives (SLOs) and other areas—capabilities they are often willing to pay for. So, consider a model where you give developers everything they need to become super users and look for adjacent areas where you can charge for enterprise-type features or enterprise implementations that businesses need.

    Make Sharing Incredibly Easy

    If developers build great things with your code, it’s helpful if they can share those things with the community to show what’s possible and drive interest. You can think of this as a type of advertising. Most developers aren’t won over by traditional ads, but discovering cool things that other developers have done with your code can be a great way to attract new users and fuel the cycle of discovery and adoption.

    So think about the natural output from your project that developers could share with the community. Can they put code on GitHub? Share an app or visualization they built? Post a speed comparison? What can they put on Twitter if they love your project and want to show what they’ve achieved with it?

    Our project is for building data apps, so early on, we added a feature that allowed people to take a screen recording and share their work on Twitter so others could see it in action. Later on, we added a free cloud offering so they could directly share apps with the community. Think about what works for your project and how you could make sharing easy.

    Create Amazing How-Tos and Tutorials.

    These can be important entry points on your growth loop, and it’s best to provide them through developers’ preferred channels. YouTube is a go-to for tutorials of all types, and you can also leverage Coursera, Educative and other e-learning platforms. Someone on my team created a Coursera course for our project that has more than 20,000 enrollees, and one of our Code Camp videos has been viewed over a million times.

    Get creative. If your project is starting to see traction among students, think about providing educational materials that professors can use in the classroom. Online interactive courses are not only a great way to learn programming, they make it easier for educators to manage coursework and see who’s keeping up. This is an excellent way to promote your project and capture new developers.

    Documentation is another important entry point. Our documentation page is starting to look like an e-learning course itself, with guides for getting started, sample code and sample apps. Documentation pages can be listed by search engines, and we found it was worth the engineering time to make this happen.

    Contribute to Other Open Source Projects

    Giving back to the community is a good practice for anyone who cares about software, but it can also benefit your project: Contributing to open source projects helps ensure that your software will be compatible with the tools your target developers use. As well as ensuring interoperability, this can help raise awareness of your project in relevant developer communities.

    Reaching critical mass with an open source project is about understanding what your target developers need, being smart with your resources and removing friction wherever you can. This concept of a growth loop worked for our project, and I hope it helps you to achieve success with yours.

  • 5 Key Performance Metrics to Track in 2023

    5 Key Performance Metrics to Track in 2023

    It’s never a bad time to adopt healthy new habits for the mind and body, and for developers, it’s always a good time to consider new best practices at work. As 2023 rolls on, I’ve been thinking about some key performance metrics that help to ensure critical applications and websites perform optimally throughout the year—especially during unpredictable spikes.

    To see why this is important, just look at the problems Ticketmaster had in November 2022 when Taylor Swift’s concert tickets went on sale. Fans of the pop idol (including me!) swamped the Ticketmaster site and brought the system to its knees, resulting in frustrated customers and a wave of bad publicity for the company.

    These usage spikes and the problems they can produce are not uncommon. The holiday sales period, starting with Black Friday and Cyber Monday, is notorious for technical issues that can cost retailers millions due to lost sales and other problems. And it’s not just retail. A few years ago, the Internal Revenue Service (IRS) had to extend its tax deadline after a rush of last-minute filers knocked its systems offline.

    Fortunately, developers can mitigate these problems with the right planning and practices in place. There are key performance metrics that developer teams should monitor, especially in times of peak traffic, to avoid application crashes, long wait times—and burnout for the teams who have to fix these problems when they arise.

    Here are the five performance metrics developers should be tracking in 2023—especially on their busiest days of the year.

    Web Vitals

    The largest contentful paint, or LCP, measures the load speed of a webpage. Having a fast LCP is a clear sign that a customer’s experience is optimal as they toggle between pages. In tandem, the cumulative layout shift, or CLS, scores how a user is experiencing unexpected layout shifts. This plays out on busy shopping days: Typically, these pages have ad and sales notifications that affect a brand’s main page layout, potentially causing shoppers to experience unexpected shifts. This can reduce their ability to shop and becomes a hindrance if a developer cannot quickly access and address the issue.

    Error Count Vs. Error Rate

    Error counts typically increase alongside site traffic as more people flock to a website—that’s a natural occurrence. The error rate is more telling because it reveals if a greater proportion of users are experiencing issues with your application or website. Developers who see an increase in this metric should investigate and take action.

    Mobile Monitoring

    More and more consumers are using their mobile devices to shop and manage all aspects of their lives. For example, mobile accounted for 45% of sales during the holiday shopping period in 2022 from October to December. Mobile performance metrics are critical to understanding what is happening on your users’ devices during these busy times. Vitals like frozen and slow frames or cold and warm starts when an app opens provide visibility into how fast views are loading for your users. As became obvious with the Taylor Swift incident, a slow shopping experience can lead to an outcry and a lot of upset customers.

    Outside of vitals related to mobile performance, it’s important to monitor mobile changes through application release health. Developers can see this in the rate of crash-free sessions and crash-free users as traffic to an application increases—which helps to identify abnormalities in the overall health of the app.

    Slow Database and HTTP Ops

    During sustained traffic spikes, database queries and HTTP requests that take too long to execute harm the user experience. Hitting a slow checkout process, or seeing the dreaded spinning beach ball after adding a product to the cart, confuses shoppers. They don’t know if they should refresh the page, and often they will abandon a purchase completely.

    What’s more, if a developer is working on a backend framework, slow database and HTTP ops could also be a sign of an N+1 query problem. At that point, an application is making database queries in a loop and causing performance issues for the purchaser.

    User Misery

    This is a homegrown metric we use at Sentry; tracking user misery helps developers understand a customer’s experience with an application. It is a ratio of unique users who have experienced load times at 4x a configured threshold in a Sentry project and thus serves as a proxy for customer frustration. With this user misery score, our developers can see which transactions have the highest negative impact on users and prioritize fixing them.

    Providing a smooth end-user experience is table stakes for businesses throughout the year, but especially during high-pressure, culturally-driven spending moments. In any of these scenarios, developers behind the scenes often work long and odd hours to address performance issues and ensure the most seamless experience. You can’t prepare for everything that can possibly go wrong, but you can be equipped with the right tools and metrics to quickly identify and remediate any problems that occur.

  • Why Observability is Important for Development Teams

    Why Observability is Important for Development Teams

    Observability, which allows development teams to understand better how their systems behave in production, is critical to successful software delivery. According to Gartner, by 2026, 70% of organizations that successfully applied this practice will achieve shorter latency for decision-making, enabling competitive advantage for target business or IT processes.

    Observability allows development teams to identify and diagnose issues quickly to make decisions that improve overall software delivery performance. Let’s take a closer look at why this practice is critical for development teams.

    Differentiating Observability and Visibility

    To better understand observability, it’s essential to clear up a common misconception – that observability and visibility are the same. Two critical differences exist between the two. Visibility allows development teams to look at the surface-level aspects of an application or system. In contrast, observability provides deeper insight into what an application is doing in production. Being equipped with a deep knowledge of observability allows developers to be more productive within their respective organizations.

    Impact on Developer Productivity

    With observability, developers can identify and diagnose issues within applications quickly, giving them more time to fix bugs and time for resolution, which are both critical success factors for software delivery. Observability allows organizations to quickly identify and respond to potential problems, such as operational issues or security breaches, before they become issues that impact customers or users. While there is no such thing as perfect software, observability helps developers quickly find and fix issues, bottlenecks, inefficiencies, etc., so they can get back to doing what they love: Creating new software.

    With the benefits of observability, developers naturally gravitate toward tooling and technology. There are many tools available for developers to take advantage of, and development teams must learn how to use these tools to integrate them into their applications and services. Let’s explore some of the more popular options.

    The Shift to Cloud-Native Tools

    The shift to cloud-native tools is driven by the increasing popularity of cloud computing and its benefits, such as scalability, cost-effectiveness and flexibility. The move to cloud-native has made an enormous impact on observability efforts. Having good tooling and processes available positively impacts observability efforts because it’s a critical aspect of the developer communities’ systems. Overall, the shift to cloud-native tools is driven by the need for organizations to take advantage of the benefits of cloud computing and the need for more efficient and flexible deployment and scaling of applications.

    Some of the most common tools in observability include:

    These tools offer developers greater insight and knowledge into how applications behave. The cloud-native approach necessitates a new way to aggregate all of these operations.

    Conclusion

    With observability, developers can understand how their systems work in production. These systems act in different ways depending on the environments they run in. Therefore, organizations must do more to provide developers with sufficient observability because of the limited visibility into the overall system performance.

    Observability allows developers to act quickly and remedy issues before they go into production and organizations can better measure success relative to the application’s performance. Hours of developers’ time are spent manually debugging and troubleshooting when organizations could have a system in place to do this automatically and allow developers to get back to what they love doing most: Creating software. Observability helps organizations make better-informed decisions, improve operations and performance and achieve their objectives more effectively.

  • 5 Unusual Ways to Improve Code Quality

    5 Unusual Ways to Improve Code Quality

    Code quality refers to how well-written and maintainable software code is. It encompasses factors such as readability, efficiency, scalability, reliability, maintainability and security. High code quality ensures that software is easy to understand, modify and extend, has fewer bugs and is less likely to break down. It also reduces development time and costs and improves the overall user experience. One common approach to determine code quality is to use automated tools that analyze the code based on predefined quality standards and generate a report with a numerical score.

    Why is Code Quality Important?

    Generating high-quality code ultimately enhances the end user’s experience. Focusing on creating quality code can also help consumers understand the safety and reliability of the software or program they’re using.

    Low-quality code can affect user experience and satisfaction, making it critical to write high-quality code that functions properly. When developers write low-quality code, it can create vulnerabilities that expose the software to cybersecurity threats, resulting in bugs and functionality issues and impacting the software’s reliability. 

    Here are some additional reasons high-quality code is important: 

    • Enhances code readability: Readability is important because it leads to higher rates of understanding among other developers. A code that’s easy to read is also easy to improve.
    • Improves the level of program sustainability: Program sustainability measures how long a code can survive with minimal changes. High-quality code can last for years, making it more sustainable.
    • Increases transferability: Transferring code from one platform to another is a complicated process. It’s much easier for developers to transfer high-quality code, as they only need to make minimal changes.
    • Lowers costs related to program or software: When software lasts for a long time with few errors, it can save a company money. Instead of paying for additional time to rewrite low-quality code, the company can rely on the original, high-quality source code.

    5 Unusual Ways to Improve Code Quality

    Here are a few ways you may not have thought of which can help your development team improve code quality and end-user satisfaction.

    Bug Bounty

    A bug bounty program is a type of crowdsourced security testing in which an organization offers rewards to independent security researchers or ethical hackers for identifying and reporting vulnerabilities in their software or systems. By offering rewards for vulnerabilities, organizations can incentivize security researchers to find and report security issues before they can be exploited by attackers.

    Bug bounty programs can improve code quality in several ways:

    • Incentivize security testing: Bug bounty programs incentivize security researchers to test an organization’s software or systems for vulnerabilities. This can increase the amount and quality of security testing that is done, leading to a more secure product.
    • Encourage responsible disclosure: Bug bounty programs encourage security researchers to report vulnerabilities directly to the organization rather than publishing them publicly or selling them on the black market. This allows organizations to fix vulnerabilities before they are exploited by attackers.
    • Provide feedback on code quality: Security researchers who participate in bug bounty programs can provide feedback on code quality which can help organizations to improve their development practices and write more secure code in the future.

    Auto-Generated Documentation

    Auto-generated documentation is a type of documentation that is generated from code comments and metadata as part of an automated development pipeline. It is typically generated using tools such as Javadoc, Doxygen, or Sphinx, which parse code comments and metadata to generate HTML, PDF, or other formats of documentation.

    Auto-generated documentation can improve code quality in several ways:

    • Improved code readability: Auto-generated documentation can provide clear and concise descriptions of code functionality, making it easier for developers to understand the code and its purpose.
    • Better code organization: Auto-generated documentation can help developers organize their code by providing a clear hierarchy of classes, methods, and functions, making it easier to navigate and maintain the codebase.
    • Consistency: Auto-generated documentation can ensure that documentation is consistent across the codebase, reducing the risk of errors and misunderstandings.
    • Quality assurance: Auto-generated documentation can be used as a quality assurance tool, helping developers to identify errors and omissions in their code comments and metadata.

    Coding Conventions

    Coding conventions are a set of guidelines and standards that outline how code should be written and formatted to promote consistency and readability. They typically cover aspects such as naming conventions, code structure, formatting, and documentation. 

    By following coding conventions, developers can improve code quality and make their code easier to read and understand, which makes it easier to maintain and modify. They also help ensure that code is consistent across a project or organization, which can make collaboration and integration of different code segments easier.

    Typical elements that coding conventions dictate include:

    • Naming conventions for variables, functions, and classes.
    • Indentation and formatting of code blocks.
    • Use of whitespace and comments to improve readability.
    • Guidelines for handling exceptions, errors, and input/output.

    Quality Gates

    Quality gates are a set of checkpoints or criteria that software must meet before it can progress to the next stage of development. They are typically used in software development processes to ensure that the software is of a certain quality and is ready for release.

    Quality gates can be automated or manual, and they are typically implemented at key points in the development process, such as after unit testing, integration testing, or acceptance testing. They can include metrics such as code coverage, code quality, functionality, performance and security.

    By enforcing quality gates, development teams can catch and address issues earlier in the development process, which can reduce rework, save time and ensure that the final software product meets the required quality standards.

    Smart Code Snippets

    Smart code snippets, also known as intelligent code snippets or live templates, are pre-written code fragments that can be inserted into a code file with placeholders for variables or user-defined inputs. They are designed to help developers write code more efficiently and accurately by reducing the amount of repetitive or boilerplate code they need to write and by providing contextual awareness and intelligence.

    Regular code snippets are static pieces of code that can be inserted into a file as needed. They typically contain pre-written code blocks or templates that can be customized to fit the specific use case.

    In contrast, smart code snippets are dynamic and can adapt to the context of the code being written. For example, a smart code snippet might include placeholders for variables that need to be defined or automatically fill in common code constructs based on the context of the code. 

    Conclusion

    The five lesser-known ways to improve code quality discussed in this article offer a starting point for teams looking to take a fresh perspective on their development process. Improving code quality is critical for the success of any software development project. While there are many established methods and best practices for improving code quality, there are also some less conventional approaches that can be surprisingly effective. By adopting a creative and open-minded approach to software development, teams can identify new ways to improve code quality and build more reliable, efficient and secure software.

    Image Source 

  • Understanding Cloud APIs

    Understanding Cloud APIs

    Six out of every 10 businesses had moved their workloads to the cloud as of last year. More steady traffic in the cloud and more direct cloud instances mean more to juggle–and the need for greater customization and integration. That’s where APIs come in. APIs are doing for the cloud what they did for on-premises resources: Segregating, simplifying, specializing and integrating services across a network–only this time, it’s future-proofing the architecture by building it in the cloud. As one cybersecurity researcher quipped, “Everyone wants to use APIs to build innovative solutions, but no one wants to invest in building them.” Cloud APIs will soon spell the difference between companies that can keep up with digitization and those that can’t.

    Ultimately, it will come down to which organizations take the time to understand them and use them to their best benefit.

    What is a Cloud API?

    Simply put, “a cloud API is a software interface that allows developers to link cloud computing services together.” APIs allow services to share functionality and information for other programs to use, and nowhere is this more important than in the interconnected ecosystem of the cloud.

    Because APIs act as a waiter in a restaurant, the better the waiter, the simpler ordering will be for you and for your customers. The best cloud API connects backend cloud components, services and platforms and does all the busy work so all your users see on the front end is a seamless customer experience. Since most of the work of tomorrow will be in the cloud (and is moving there in ever-increasing numbers), to not build up this functionality now is to take a deliberate risk.

    Types of Cloud APIs

    There are several types of cloud APIs based on the four major areas where cloud computing will require integration–either with another platform or another cloud provider.

    ● PaaS APIs (Service level): These platform-as-a-service APIs are designed to integrate with databases, portals, storage components and messaging systems, providing access and functionality in the cloud.
    ● SaaS APIs (Service level): Referred to as software-as-a-service APIs, these connect application layer resources with the cloud and underlying IT infrastructure. A CRM is a good example of where these types of APIs can be used to create a “cloud application extension” for your ecosystem.
    ● IaaS APIs (Service level): Infrastructure-as-a-service APIs control the distribution and deployment of specific cloud resources, performing such tasks as rapid provisioning and de-provisioning, network configurations and workload (VM) management in the cloud.
    ● Cross-platform APIs: Because many environments use multiple cloud providers and platforms, cross-platform compatibility is required. Cross-platform APIs streamline data management by allowing tenants to access their cloud-based resources and workloads from any of their cloud providers, not just their primary one. They provide a higher level of abstraction by translating a specific provider’s API calls into a more generic form, making accessibility, manageability and interoperability in the cloud easier.

    Cloud API Security

    In many respects, the security threats faced by cloud APIs are the same that any cloud-based resource would encounter and present the same challenges. That being said, malicious API traffic surged over 117% last year, from an average of 12 million to over 26 million calls, according to one industry report. The same study revealed that over a third of respondents experienced authentication and data exposure-related incidents with their APIs, and 54% delayed rolling out a new application because of API security concerns.

    Unguarded, a cloud API could present the keys to the kingdom and allow an attacker to access the hub of not just one but several cloud providers and their workloads, resources and assets. Protecting cloud-based APIs with standard authentication and authorization practices such as OAuth2.0 and OpenID Connect can reduce the chance of a lateral attack.

    Why Cloud APIs

    Cloud usage is not set to slow down and will soon become ubiquitous. Companies that aren’t on it are migrating their workloads in greater numbers and entrepreneurial ventures are spinning up as cloud-native. Cloud APIs are simply the logical response to the complexities that come with the terrain. Without cloud APIs, the user experience will be negatively impacted and will only become more apparent when compared with companies that do use cloud APIs.

    For companies looking to innovate in 2023 and release new applications, APIs are the way to cut-and-paste the process safely. Similarly, as more cloud-based services become API-reliant, application reusability is another factor requiring cloud APIs. And lastly, the complexity of cloud products, platforms and ecosystems (even within one organization) makes cloud APIs a necessity for smooth interoperability. And they help with scalability–multiple components of a cloud-based service can be parsed out, updated and patched individually and refined separately so that one area can develop without being dragged down by the whole. Cloud APIs allow for that granular level of customization that can help an organization refine its edge.

    Simply put, organizations will need these APIs to not only compete but stay relevant as businesses continue to take their fight to the cloud.