devopsy.kinsta.cloud

Category: DevOps Onramp

  • Mastering DevOps Automation for Modern Software Delivery

    Mastering DevOps Automation for Modern Software Delivery

    DevOps automation services are a crucial aspect of modern software development that helps organizations to improve their software delivery processes and keep up with the pace of innovation. With DevOps automation, developers can automate repetitive and time-consuming tasks, enabling them to focus on writing code and delivering features faster and with higher quality. By automating processes such as continuous integration, continuous delivery and infrastructure-as-code, organizations can reduce costs, improve collaboration between teams and respond quickly to changing business needs and customer requirements.

    In this article, we will discuss the basics of getting started with DevOps automation services, including popular tools and best practices that organizations can use to implement a successful automation strategy.

    Agility and Efficiency for Smart Digitalization

    Emerging technologies like multi-cloud, IaC, AI/ML and IoT have only increased the importance of DevOps automation, as they bring new challenges demanding agility, flexibility and efficiency in software delivery processes. Multi-cloud and hybrid cloud environments, for example, can benefit from automating the deployment and management of software across multiple cloud environments. Similarly, AI/ML and IoT require organizations to collect and process large amounts of data in real-time, which can be challenging without automation. DevOps automation can help organizations automate data pipelines and analytics, enabling them to process data faster and more accurately.

    Here are some benefits of DevOps automation:

    ● Speed and Efficiency: DevOps automation enables organizations to deliver software faster and with higher quality. By automating repetitive and time-consuming tasks, developers can focus on writing code and delivering features.
    ● Agility and Flexibility: DevOps automation provides organizations with the agility and flexibility to adapt to changing business needs and customer requirements. Automated processes make it easier to release software updates and respond quickly to market demands.
    ● Cost-Effectiveness: DevOps automation reduces the costs associated with software development by reducing manual labor and minimizing errors. It also enables organizations to use cloud resources more efficiently, which can result in cost savings.
    ● Improved Collaboration: Bringing the different stakeholders along with devs and operations, DevOps fosters a collaborative approach toward enhanced CI/CD. By automating processes, teams can work together more effectively and share knowledge and feedback in real-time.
    ● Scalability: DevOps automation enables organizations to scale their software delivery processes quickly and efficiently. Automated processes make it easier to deploy software across multiple environments and platforms, which is essential for organizations that need to scale rapidly.

    Getting Started With Efficient DevOps Automation

    Implementing DevOps automation requires a well-planned strategy, best practices and the right set of tools. In this section, we will discuss how to successfully implement DevOps automation in your organization.

    Understanding DevOps
    Before you begin with automation, it is essential to understand the principles and practices of DevOps. DevOps is a culture that emphasizes collaboration and communication between software development and IT operations teams to build, test and release software more quickly and reliably. There are some common tools that DevOps teams use for their work, collaboration and communication:
    ● GitHub: The Git repository hosting service used for version control and source code management functionality, especially for distributed projects.
    ● JIRA: A project management tool that helps teams plan, track and manage software development projects.
    ● Slack: A communication platform that enables real-time messaging, file sharing and collaboration.

    Choose the Right Tools
    Automation is at the heart of DevOps, and selecting the right tools is crucial. Choose tools that fit your requirements, budget and infrastructure. Some popular DevOps automation tools include:

    ● Jenkins: An open-source automation server that enables continuous integration and continuous delivery (CI/CD) pipelines.
    ● GitLab: A web-based Git repository manager that provides CI/CD capabilities, project management, and collaboration tools.
    ● Puppet: An open-source configuration management tool that automates the deployment and management of software across multiple environments.
    ● Chef: A configuration management tool that automates the deployment and management of software across multiple environments.
    ● Ansible: Open source tools for automating software provisioning, deployment and configuration management

    Identifying Processes for Automation

    First, list all the critical processes within your organization that can be enhanced with automation. Start with the repetitive and time-consuming tasks that can be automated, such as code testing, deployment and monitoring. There are a number of popular tools that can help with such automation:

    ● Selenium: An open source testing framework that enables automated testing of web applications.
    ● Docker: A containerization platform that enables the creation, deployment and management of containerized applications.
    ● Kubernetes: The open source container orchestration tool is essential in the DevOps pipeline for orchestration and automation of the deployment, scaling and management of containerized applications.

    Creating a Plan

    Once you have identified targets for automation and selected tools, create a plan for automation that includes a roadmap and milestones. Start with small projects and gradually expand the automation to cover all aspects of the software development life cycle. Some popular tools for strategizing these life cycles are:

    ● Trello: A project management tool that enables teams to organize and prioritize tasks using Kanban-style boards.
    ● Asana: A project management tool that enables teams to track and manage tasks using to-do lists, calendars and timelines.

    Training The Team

    Automation requires new skills, so it is essential to train your team to use the tools and processes effectively. Provide training and resources to help your team learn new skills and techniques. Some popular education and training resources include:

    ● Udemy: An online learning platform that provides courses on DevOps automation tools and techniques.
    ● Coursera: An online learning platform that provides courses on DevOps and related topics.
    ● Pluralsight: An online learning platform that provides courses on DevOps automation tools and techniques.

    Implementing Continuous Improvement

    A continuous feedback loop is essential for DevOps’ iterative process and continuous improvement. Integrate mechanisms for evaluating your automation processes, identify areas for improvement and make necessary changes. Here are two common tools used to do this:

    ● New Relic: An application performance monitoring tool that provides real-time visibility into the performance of software applications.
    ● Splunk: An operational intelligence tool that enables organizations to analyze and visualize machine data in real-time.

  • The Future of Continuous Testing in CI/CD

    The Future of Continuous Testing in CI/CD

    If you ever wonder why continuous testing is so important, think about the following: In the past, software testing was typically done after the code was written and sent to the QA department for independent testing. When bugs were discovered, the code was returned to the developers for correction. While this testing method worked, it was time-consuming. Nowadays, companies want to produce high-quality products quickly, so they need a faster and more efficient testing process. This is when continuous testing comes in.

    In this article, we will explore continuous testing from its current state and its future in CI/CD to the emerging technologies and trends that will shape its development. We will also cover the importance of continuous testing for businesses and some of its challenges.

    What is Continuous Testing?

    Continuous testing is a software testing approach in which tests are automated and run throughout the software development life cycle. It is a part of the continuous delivery (CD) process, in which software changes are delivered to customers continuously and iteratively.

    Continuous testing aims to identify defects and issues as early as possible, reducing the cost and time of fixing them later. Continuous testing provides immediate feedback to the development team, helping them to detect and address potential problems quickly and efficiently.

    According to the Reports and Data source survey, 21% of QA professionals have incorporated continuous testing, source code management and continuous integration into their DevOps process to speed up code release.

    Advantages of Continuous Testing

    Here are several advantages of implementing continuous testing as a part of the software development process:
    ● Continuous testing enables teams to identify bugs earlier in the software development process;
    ● Continuous testing provides immediate feedback to developers on the quality of their code, enabling them to address any issues immediately;
    ● You can minimize business risks by assessing and identifying potential issues before they become real problems;
    ● Automating your test cases can reduce the time spent on testing;
    ● Accelerating the process of software delivery to production helps release the product faster;
    ● You can run performance tests in similitude, which can increase the speed of test execution.

    Disadvantages of Continuous Testing

    While continuous testing has become an integral part of the software development process, it’s not without its challenges. As software development teams work to incorporate testing into their CI/CD pipelines, they may encounter obstacles that can hinder their progress.
    ● Continuous testing requires a different skillset than traditional testing, including expertise in DevOps, automation and CI/CD pipelines;
    ● Different tools and technologies are available for continuous testing, and choosing the right ones can be tough. Integrating these tools with other parts of the development process can also be challenging;
    ● To fully realize the benefits of continuous testing, you need to update your testing strategy by moving away from relying solely on traditional testing methods and adopting a well-defined approach to test data management;
    ● Failing to integrate code regularly can result in issues such as duplicated coding efforts and non-compatible code, leading to defects.

    Emerging Technologies in Continuous Testing

    With the increasing demand for faster and more reliable software releases, emerging technologies such as AI/ML, automation and DevOps appeared in continuous testing. These technologies help teams to automate and streamline their testing processes, identify defects more quickly and improve overall software quality. Let’s examine some of them:

    Artificial intelligence/machine learning (AI/ML). AI and ML refer to the field of computer science that deals with developing intelligent machines that can simulate human intelligence and learn from data.

    One of the main benefits of AI and ML in continuous testing is the ability to automate test case generation, which reduces the need for manual testing and frees up time for other tasks. This enables testers to test applications more comprehensively and frequently, ensuring defects or issues are identified and addressed quickly. AI and ML increase testing accuracy by identifying patterns and anomalies in the testing data.

    AI and ML techniques can efficiently and rapidly analyze extensive amounts of data, allowing them to recognize patterns and irregularities in testing data that human testers might overlook.

    Automation: Automation in continuous testing refers to using automated tools and processes to execute software tests repeatedly and consistently. It involves automating various stages of the software testing life cycle, such as test planning, test case design, test execution and test reporting.

    Automation can efficiently perform regression testing, ensuring that changes do not introduce new defects or issues in the software. Tests can be executed 24/7 without human intervention, reducing the time and cost required for testing.

    DevOps: DevOps in continuous testing is the application of DevOps principles to continuous testing, focusing on integrating testing into the software development life cycle and enabling faster and more reliable delivery of software.

    In the context of continuous testing, DevOps emphasizes testing integration into the development process, enabling developers to detect and fix defects early in the cycle. DevOps also promotes automation, collaboration and communication between development and operations teams, allowing faster and more efficient testing and deployment.

    Blockchain: Blockchain technology has been gaining increasing attention in the software development and testing industry due to its ability to provide secure and tamper-proof data storage.

    In continuous testing, blockchain stores testing results and data in a decentralized and transparent way, making it virtually impossible for anyone to modify or manipulate the data. This enhances the credibility of the testing process and outcomes and provides an added layer of security to ensure the integrity of the data.

    Blockchain technology enables efficient and seamless data sharing between stakeholders involved in the testing process, enabling faster and more accurate decision-making.

    Internet-of-Things (IoT): In continuous testing, IoT simulates many IoT devices and platforms, enabling testers to test their applications across multiple devices and platforms. This ensures that applications are compatible with various IoT devices and platforms and perform reliably and consistently in various environments.

    For instance, when creating an application that needs to run on multiple devices, it is possible to use an emulator to test the app on your laptop without setting up a development environment for each type of device.

    IoT-enabled continuous testing provides real-time feedback on the performance and functionality of applications, enabling organizations to identify and address issues quickly and effectively.

    Trends in Continuous Testing

    Continuous testing is rapidly evolving to meet the needs of modern software development practices, with new trends emerging to address the challenges development teams face. Three key trends currently gaining traction in continuous testing are cloud-based testing, shift-left testing and security testing. These trends are driven by the need to increase efficiency and speed in software development while ensuring the highest quality and security levels. Let’s take a closer look at these trends.

    Cloud-Based Testing: Continuous testing is deployed through cloud-based computing, which provides multiple benefits like ease of deployment, mobile accessibility and quick setup time. Businesses are now adopting cloud-based services due to their availability, flexibility and cost-effectiveness. Cloud-based testing doesn’t require coding skills or setup time, which makes it a popular choice for businesses.

    AI-Driven Testing: AI-driven continuous testing is often integrated into cloud-based testing platforms, providing end-to-end automation for web, mobile and API testing. AI and cloud-based testing allows for access to testing environments anywhere, anytime, and provides for regular automated testing using platforms like Selenium.

    Shift-Left Testing: Shift-left testing is software testing that involves testing earlier in the development cycle rather than waiting until later stages, such as system or acceptance testing. The goal of shift-left testing is to identify and address defects as early as possible.

    Delaying testing until the end of development often results in more complicated bug fixes since the software is already fully built. This can cause an increase in cost and time to market. Identifying and fixing bugs earlier in the software development life cycle is generally more cost-effective.

    As IBM’s Systems Sciences Institute claimed, repairing a bug discovered during implementation costs roughly six times more than one found during design. If a mistake is detected after product release, the cost of fixing it is four to five times greater than one found during design and up to 100 times greater than one found during the maintenance phase. This suggests that a bug’s cost increases exponentially as the software progresses through the SDLC.

    Low-Code/No-Code: Low- or no-code in continuous testing refers to using visual interfaces and pre-built elements or modules to create and execute automated tests instead of writing complex code. Low-code/no-code testing tools often provide drag-and-drop interfaces and pre-built components that can be combined to create tests, reducing the time and effort required to develop and maintain test scripts.

    This type of testing provides several advantages, such as allowing non-technical business experts to run testing, speeding up test production and execution and enhancing product quality by enabling more thorough and efficient testing.

    Generally, according to statistics, by 2025, around 70% of new business applications are predicted to use low-code or no-code technologies.

    Security Testing: Due to the rising incidence of cybersecurity threats and data breaches, security testing has become a crucial aspect of software quality assurance. In the year 2023, the tech world anticipates that there will be a stronger focus on security testing, with the emergence of more advanced tools and methodologies aimed at detecting and resolving security weaknesses in software applications.

  • Why You Need a Multi-Cloud and Multi-Region Deployment Strategy

    Why You Need a Multi-Cloud and Multi-Region Deployment Strategy

    As I began writing this article, I encountered some technical challenges in my attempt to provision three cloud providers in three separate regions to simulate multi-cloud and multi-region deployments.

    I couldn’t get one of the regions to behave as I expected when provisioning the environment. As it turned out, the region (and by association, cloud) was down due to a cut undersea cable, and it would take several weeks until the outage was mitigated.

    Fortunately, there are plenty of clouds in the sky to choose from, but this experience emphasized the importance of multi-cloud redundancy, especially in a production environment.

    This article examines the benefits of adopting a multi-region and multi-cloud deployment strategy for better resiliency, regulatory compliance and optimal user experience.

    Resilient Reasons to Choose Multi-Cloud and Multi-Region Architectures

    The first reason to choose a multi-cloud or multi-region environment is for data resilience. When our data is in a single region or on a single cluster, there is a good chance that you will experience data failure. You need a mitigation strategy if you want to keep the data lights on 24/7. These strategies fall into two buckets: Multi-region and multi-cloud.

    We first need to define the differences between multi-cloud and multi-region. The architectures are simply the implementation details of how we plan for one versus the other. However, depending on your database provider, those details can represent a significant time investment, which we’ll look at later.

    Multi-Region

    With multi-region, we typically deploy our applications to globally distributed regions. However, regional deploys are subjected to physical faults. Inclement weather, political unrest, acts of foreign or domestic terrorism and other physical variables have all led to regional outages in the past.

    Regardless of the cloud, the regions are exposed to similar physical faults. Instead of losing your data, we can switch to another region to handle the workload. Even though much as our industry hates latency, it is always preferred over loss.

    Deploying to multiple regions allows for failover handling. If the Sydney region goes down, Singapore may still be online. It would be a globally bad day if the same physical faults simultaneously impacted Frankfurt, Sydney and Seattle, for example.

    Multi-Cloud

    Physical faults are only one of the problems that public and private clouds encounter. User error, poorly configured networks and even banal errors can have substantial consequences that impact entire clouds, either from the provider or the user.

    In these circumstances, regional failover won’t help you. An expired certificate, accidental deletion or disabling the wrong port will take you offline, regardless of whether you’re in Seattle or Sydney. If that happens, someone somewhere is most definitely awake and is likely very unhappy.

    Choosing a multi-cloud configuration protects you from these types of faults so that if Google, for example, has interruptions, AWS is still online—or IBM, Deutsche Telekom, OVH or Hetzner.

    The Correct Answer: Deploy Both!

    Multi-region is a go-to method to mitigate against mostly physical faults. Multi-node clusters in each of those regions handle general data corruption or failures on a more granular level.

    Multi-cloud is a go-to method to mitigate configuration or software-level faults, which are not that uncommon.

    The correct answer is to blend the two, working within operational cost constraints and general survivable requirements from regulatory and business objective use cases. For example, I do want access to my heart-rate data from two years ago, but the order of browsing across Amazon shopping is less important.

    Regulatory Reasons for Multi-Region Architecture

    Apart from data resiliency, most companies serving a global market are subject to a number of geopolitical influences, as well. Most users will be familiar with the GDPR regulations ensuring European data stays on European soil. Further regulations require the ability for government oversight to request data at will from service providers, which requires its own set of reasonable isolation from those not in those jurisdictions.

    Using a multi-region database provider allows companies to ship single binaries of software without creating isolated applications for different countries—a practice that was the norm not too many years ago.

    Performant Reasons for Multi-Region Architecture

    Co-locating data and access provides the optimal pathway for getting a user’s data to the end destination. It goes without saying, but the less copper your data has to traverse, the faster the experience will be for your users. Retention and regulation aside, in many cases, you need to mitigate latency caused by region separation.

    It’s not just the individual user’s data. Imagine a sales enablement platform where an account executive needs to manage all of APAC or EMEA. If these accounts are optimally stored for reads on geo boundaries, you can remove seconds of delay between page navigations for your account manager. We all know how much account executives like to click!

    Choosing a DB Provider With Multi-Region and Multi-Cloud

    At this point, you should be convinced of the benefits of multi-region and multi-cloud deployments. But at what cost? Creating replication, failover, logging and synchronization mechanisms is a big, expensive ask. Even with deployment tooling, coordinating all the pieces for multi-region deploys is still a significant operational lift, let alone multi-cloud, where variables in APIs come into play.

    Choosing a single provider that deploys across regions and clouds means you get to benefit from their collective experience while reducing a significant burden.

    Having a database provider offer one-click multi-region deploys is the way to go, but you still need to handle the data access layer. The role-based access, federation and other settings that enable your developers still need to be distributed along with the underlying data sources.

    You need a provider that makes it simple to deploy the same configuration for horizontally scaled instances, leaving you to pick your geo router of choice to distribute the request to the nearest point of presence.

    Closing

    Multi-cloud and multi-region deployments provide significant redundancy, scalability and flexibility. Not only does this enable faster access times and improved reliability, but also provides the flexibility required to adapt to disruptions or unpredictable increases in traffic.

    Deploying multi-cloud and multi-region is no small feat–but the peace of mind and security it provides make it worth the effort.

  • What Is a Cloud Operations Engineer?

    What Is a Cloud Operations Engineer?

    CloudOps, short for cloud operations, refers to the processes, tools and strategies employed to manage, monitor and optimize the performance, security and availability of cloud-based infrastructure, applications and services. It encompasses a set of best practices and methodologies that ensure the smooth functioning of cloud environments, including resource provisioning, configuration management, automation, deployment, monitoring and incident response. The primary goal of CloudOps is to maintain reliable, scalable and cost-effective cloud solutions that meet the needs of businesses and their end-users.

    What is a Cloud Operations Engineer?

    A cloud operations engineer is a professional responsible for managing, monitoring and optimizing cloud-based infrastructure, applications and services within an organization. They play a crucial role in ensuring the smooth functioning of cloud environments by handling tasks such as resource provisioning, configuration management, deployment, automation and incident response. 

    Additionally, they collaborate with development and IT teams to design and implement scalable, secure and cost-effective cloud solutions that align with business objectives and end-user requirements. Cloud operations engineers must possess a deep understanding of cloud computing technologies, platforms and best practices, as well as strong problem-solving, communication and collaboration skills.

    Responsibilities and Roles of a CloudOps Engineer

    A CloudOps engineer plays a vital role in managing and maintaining cloud infrastructure and services. Their responsibilities and roles might include:

    • Cloud infrastructure management: Design, deploy and maintain cloud infrastructure, ensuring optimal performance, security and scalability.
    • Cloud migration: Responsible for planning, executing and managing cloud migration of applications, workloads and infrastructure from on-premises or other cloud environments to a target cloud platform.
    • Resource provisioning: Allocate and manage cloud resources such as compute, storage and networking to meet the needs of applications and services.
    • Configuration management: Define and implement infrastructure configurations and manage changes to maintain consistency across environments.
    • Automation: Develop and implement automation scripts and tools to streamline and simplify repetitive tasks, improving efficiency and reducing human error.
    • Monitoring: Set up and maintain monitoring tools to track the performance, availability and security of cloud services, proactively identifying and resolving issues.
    • Incident response: Troubleshoot and resolve incidents, collaborating with development and IT teams to minimize downtime and maintain service quality.
    • Security and compliance: Implement and enforce security policies, best practices and compliance requirements to protect sensitive data and maintain cloud infrastructure integrity.
    • Cost optimization: Monitor and analyze cloud resource usage to identify opportunities for cost savings, recommending and implementing cost optimizations.
    • Backup and disaster recovery: Develop and maintain backup and disaster recovery plans to ensure data and application availability during unforeseen events.
    • Collaboration and communication: Work closely with development, IT and business teams to ensure alignment with project goals and provide guidance on cloud best practices.
    • Continuous improvement: Stay up-to-date with emerging cloud technologies, platforms and trends, continuously improving cloud operations and adapting to changing requirements.
    • Documentation: Create and maintain comprehensive documentation of cloud infrastructure, configurations, processes and procedures to ensure knowledge sharing and team collaboration.

    How to Become a CloudOps Engineer

    Becoming a CloudOps engineer typically requires a combination of education, relevant experience and certifications. The following steps can help you pursue a career as a CloudOps engineer:

    • Gain foundational knowledge: To become a CloudOps engineer, you will need a solid foundation in IT infrastructure, networking and cloud technologies. You can gain this knowledge through a degree in computer science or information technology or through certifications such as AWS Certified Solutions Architect or Microsoft Certified: Azure Solutions Architect.
    • Develop cloud skills: CloudOps engineers need to have expertise in cloud platforms such as AWS, Azure or Google Cloud. You can gain experience by working with cloud technologies in your current job or by creating personal projects on cloud platforms.
    • Learn automation tools: CloudOps engineers need to automate infrastructure and deployments using tools like Ansible, Puppet, Chef or Terraform. You can learn these tools through online courses or tutorials.
    • Develop soft skills: CloudOps engineers need strong communication, collaboration and problem-solving skills. You can develop these skills by working in team-based environments, attending networking events or conferences and taking courses or workshops in communication and collaboration.
    • Gain experience: To become a CloudOps engineer, you need hands-on experience in deploying, managing and monitoring cloud infrastructure. You can gain this experience by working on cloud projects, participating in hackathons or contributing to open source cloud projects.
    • Consider certification: CloudOps engineers can demonstrate their expertise through certification programs such as AWS Certified DevOps Engineer or Microsoft Certified: Azure DevOps Engineer. Certification can help you stand out in a competitive job market and demonstrate your proficiency in cloud technologies.

    Conclusion

    In conclusion, a cloud operations engineer is an essential professional in today’s cloud-centric IT landscape. They play a critical role in managing, monitoring, and optimizing cloud infrastructure, ensuring that applications and services run efficiently, securely and cost-effectively. 

    With a deep understanding of cloud technologies, platforms and best practices, they collaborate with various teams to align cloud solutions with business objectives and end-user needs. As cloud adoption continues to grow across industries, the demand for skilled cloud operations engineers is expected to rise, making it a promising career path for those seeking opportunities in the ever-evolving world of cloud computing.

  • The Role of SBOMs in Software Supply Chain Security

    The Role of SBOMs in Software Supply Chain Security

    The software supply chain has become increasingly complex and dynamic with the rise of cloud computing, open source software and third-party software components and APIs. Widespread damage can occur if third-party APIs, cloud services, SDKs and open source software have security flaws. As a result, software supply chain security has emerged as a critical concern for organizations across industries. Supply chain attacks have become more frequent, sophisticated and devastating, as evidenced by high-profile incidents such as SUNBURST, Kaseya and Apache Log4j.

    To address the growing challenge of software supply chain security, organizations have turned to leveraging software bills of materials (SBOMs). SBOMs are a standardized inventory of software components used in a particular product or system, including their versions, dependencies and sources. SBOMs provide transparency and visibility into the software supply chain. They can be an effective approach for identifying and mitigating security risks, compliance issues and operational challenges – assuming organizations have the right tools to fully benefit from SBOMs, including runtime discovery, in place.

    SBOMs are not a new concept, but their adoption has accelerated in recent years due to a number of important factors, including the following.

    First, regulatory agencies, such as the U.S. National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA), have been advocating for SBOMs as a best practice for software supply chain security. NIST has released a draft guidance document on SBOMs, and CISA has mandated SBOMs for federal contractors and subcontractors.

    Second, industry initiatives, such as the Open Source Security Foundation (OpenSSF) and the Software Assurance Forum for Excellence in Code (SAFECode), have promoted SBOMs as a key element of software security. OpenSSF has launched a working group on SBOMs and published the Open Source Software Security Mobilization Plan to improve the resiliency and security of open source software (OSS), including guidelines for SBOM management; SAFECode published a whitepaper on SBOMs.

    Third, supply chain attacks have highlighted the need for SBOMs as a proactive and preventive measure. SBOMs can help organizations detect and respond to vulnerabilities, malicious code and unauthorized changes in the software supply chain. SBOMs can also support incident response and recovery efforts by providing accurate and comprehensive information about the affected software components.

    Fourth, customer demands and market pressures have influenced the adoption of SBOMs. Customers are increasingly aware of software supply chain risks and are asking for SBOMs as part of their procurement and evaluation processes. Some industries, such as health care and automotive, have mandated SBOMs for safety and liability reasons. SBOMs can also enhance brand reputation, customer trust and competitive advantage for software vendors.

    Fifth, technological advancements have facilitated the creation and consumption of SBOMs. The emergence of open standards, such as CycloneDX and SPDX, has enabled interoperability and integration of SBOMs across different tools and platforms. The development of automated tools, such as software composition analysis (SCA) and vulnerability scanners, has enabled the generation and validation of SBOMs in a timely and accurate manner. The integration of SBOMs with other security measures, such as identity and access management (IAM) and security information and event management (SIEM), has enabled an effective view of software supply chain security.

    However, SBOMs are not a silver bullet for software supply chain security. They are only as good as the data they contain, and the quality of data can vary depending on the source and the method of collection, particularly around the application software stack of APIs, cloud services and SDKs. SBOM inventory is constantly changing, and being able to leverage their up-to-date data requires more than a snapshot from traditional source code static analysis approaches, but rather continuous runtime analysis and dynamic inventory.

    For example, common vendor management and software composition analysis (SCA) approaches often lack source code access for mobile, web, cloud and commercial-off-the-shelf (COTS) software, as well as third-party API services.

    For a more effective approach, organizations can benefit from a full-stack attack surface management (ASM) software supply chain solution that delivers continuous third-party application asset discovery and dynamic tracking of third-party vendors. These newer approaches automatically categorize assets under known vendors, allow customers to add additional new vendors, curate individual assets under any vendor, and alert on increases in policy violations and high embed rates of third-party vendors within key applications. These automated capabilities allow vendor management teams to remedy supply chain security problems more quickly and easily and much more accurately than older approaches.

    It is important to note that SBOMs also require collaboration and communication among multiple stakeholders, including software vendors, suppliers, customers and regulators. They may also pose some privacy and intellectual property concerns since they can reveal information about the software components and their relationships.

    Overall, organizations need to adopt a comprehensive and risk-based approach to software supply chain security, of which SBOMs and tools to best leverage their information are an important component. Organizations should establish policies and procedures for SBOM creation, management and sharing, as well as for validation and verification. Organizations should also integrate SBOMs with other security measures and practices, such as threat modeling, penetration testing and code review to best ensure the security of their software supply chains.

  • Improving DevX Gives Your Business a Boost

    Improving DevX Gives Your Business a Boost

    As organizations transform and grow, different methodologies and development tools can come together, creating an extra level of complexity for your mainframe application development teams. In a perfect world, developers would be able to focus on delivering solutions without worrying about all the infrastructure necessary to make that happen. Building a better developer experience, or DevX, can make that a reality.

    DevX is about meeting developers where they are, at every stage of their career, delivering compatibility with and connectivity to the tools and devices that they want to use so they can focus on what they do best: Coding and releasing high-quality mainframe applications faster and more frequently and fostering better productivity and more innovation.

    Automation is integral to removing friction for developers. A modern integrated development environment (IDE) with built-in automation allows developers to find and manage code more efficiently and with greater quality and move quickly and easily from coding to editing to debugging to testing.

    Modern tooling can simplify and accelerate how developers work by giving them a visual representation of their code layout in a single-pane-of-glass view. They can move quickly in a natural, easy way with more information at their fingertips while built-in automation offers assistance at the right moment without getting in the way.

    This can seem difficult when dealing with mainframe application development and longtime mainframe developers who are still working with tools from the 1980s haven’t directly benefitted from the intervening decades of improvements. What they might not realize is that the improvements made for other platforms are available to mainframe developers, too. By engaging them in your DevX modernization efforts, you can improve their experience—and that of their team members.

    Elements of a Productive Mainframe Developer Experience

    • A modern DevX adopts flexible agile processes that give developers predictable capabilities and enable smaller, iterative changes with faster feedback. It also syncs distributed and mainframe development teams to foster greater collaboration for additional process improvements.
    • A better DevX is platform-agnostic, creating a development environment where developers can focus on the functionality of the applications they’re building instead of the deployment mechanism, leveling the playing field for every generation of developer.
    • With an improved DevX, developers can achieve the full potential of DevOps. Implementing DevOps for source code management (SCM) functions allows developers to understand the scope of any changes needed before they start coding, which helps speed approvals through concurrent work streams.
    • The single biggest boost to productivity—and an integral component of DevX—is shift left automated testing that enables developers at all skill levels to test new code immediately and find and fix bugs earlier in the development cycle when they’re easier to fix—and before they reach the end user. Continuous testing also automatically prepares test data within the DevOps toolchain.
    • An improved DevX delivers operational insights, so developers aren’t just catching issues but also understanding and prioritizing them, working hand in hand with the operations team to make the overall system better. It also empowers newer developers to address and correct any issues that arise in legacy code without poring over hundreds of modules to find what they need to improve. DevX tools work together to give developers an opportunity to leverage operational data in a whole new way.

    Once you have the tools, your mainframe developers need to be supported by a culture and education that teaches them how to use them and understand the benefits they offer. If you implement new tooling that nobody will use, the transformation is for naught. It’s important to start with the user experience and find the right tools to address it rather than starting with a tool and forcing its use just because it’s new. Continuous improvement is an important part of this; otherwise, you could bring the mainframe developer experience from the 1980s up to today’s standards only to have it freeze in place. This is why metrics and analytics are so important.

    As you speed up delivery, you also want to make sure the quality improves. With an improved DevX, you’re consistently finding defects earlier in the life cycle, which results in safer, more efficient delivery of better-quality code. By tracking velocity with metrics such as user stories delivered in one sprint, you can gauge how those changes are making a difference. You can also demonstrate how automation helps eliminate human error, increases code drops, and improves business agility.

    If you’re giving your mainframe developers everything they need to do their jobs easily and more efficiently, they’re exponentially more likely to adopt the tool and advocate for it—because a better DevX improves the day-to-day employee experience for longstanding and next-generation developers. By removing the drudgery of tasks that take developers away from writing code, you’re unleashing their creative and enabling them to achieve even greater levels of innovation—and you’re also improving your hiring and retention practices.

    Improving the mainframe DevX pays dividends across your business, from your developers to your customers to your stakeholders, so you can bring more new features to market faster and enable a competitive response for revenue-generating solutions. The mainframe is here to stay. Make sure you’re building a modern development environment that empowers your developers to respond nimbly in the face of change and make change your advantage.

  • How to Secure C-Suite Buy-In for Your DevOps Efforts

    How to Secure C-Suite Buy-In for Your DevOps Efforts

    You could be forgiven for assuming DevOps is the modus operandi only for big modern enterprises like Tesla and Uber, but this is not the case. DevOps builds on earlier approaches, such as Agile development and Lean methodology, by emphasizing the importance of collaboration between development and operations teams and the use of automation to streamline the software development process.

    So, while the term “DevOps” is relatively new, the principles and practices that it encompasses have been in use for many years.

    In a traditional waterfall model, the software development process is split into distinct stages, with each stage being completed before moving on to the next one. The development and operations teams work in separate silos, with little interaction between them until the end of the development process when the finished product is handed over to the operations team for deployment and maintenance.

    Benefits of DevOps

    In contrast, a DevOps model emphasizes collaboration and communication between the development and operations teams throughout the entire software development life cycle. The goal is to create a culture of shared responsibility for the success of the project, with both teams working together to ensure that the software is developed, tested and deployed quickly and efficiently.

    DevOps also emphasizes automation, with the use of tools and processes to streamline the aforementioned project tasks. This automation helps to reduce the likelihood of errors and allows the teams to focus on higher-level tasks.

    Overall, the key differences between DevOps and a traditional waterfall model are the emphasis on collaboration and communication, the use of automation and the focus on shared responsibility for the success of the project.

    In short: Speed, time to market, agility and cost savings.

    What’s Driving DevOps Transformation?

    Any company, regardless of size, can release faster with DevOps. Look at the agile FinTech success stories; look at the generative AI success stories. In terms of cost savings too, it’s not ‘How much am I paying for 10 people, 20 people, 100 people…?’ From a DevOps standpoint, cost means penalties avoided from failing to release on time, project delays and project poor quality.

    Overall, development practices are evolving. Some clients call DevOps ‘zero rework’ development, others refer to it as ‘shift-left development.’ Whichever term you prefer, the context is the same: They want faster release and to reduce duplication of work. The way to achieve ‘shift-left’ or ‘zero rework’ would be through DevOps transformation. All of the individual pillars of DevOps concern shifting left, causing them to release faster and achieve their cost optimization.

    However you refer to it, DevOps is mainstream because of its scalability benefits, as well as the agility to react to unforeseen situations during development, QA or operations. This equates to competitive advantages and future-proofing.

    Challenges of Implementing DevOps

    Every business is different, but many of the challenges are the same. One of the main challenges is understanding your company’s specific blend of pain points on its road to DevOps transformation. Common challenges include:

    Vision – DevOps is not a top-down initiative. The role of executives in DevOps is to define a vision; if the vision is not clear, you won’t have buy-in. You can have the best tools and technology but if you don’t have buy-in, then it won’t work.

    Investment – DevOps is a change in every aspect of people, processes, technology and culture. You can’t just bring in this change with zero investment. It’s not unusual for costs to go up for the first couple of years after moving to DevOps because you’re transitioning from manual testers and normal developers to fungible team members that come at a premium. The cost advantage shows up after at least a year as rework goes down and the quality of release incrementally increases, leading to a better customer experience. So, it’s self-funded from the efficiencies it will bring in … but only if you persevere.

    Celebrating Success – Too many people try to boil the ocean with DevOps transformation. This leads to frustration, misaligned teams and, eventually, poor results. If you start small with DevOps transformation, it soon shows its superiority as a business model. This inspires your leadership and your executive teams to see the benefit of DevOps and buy into it by osmosis rather than taking the word of that executive with a big idea and a big purchase order.

    Culture and People – This is more than just a technology play. In fact, technology is the easy part. People, processes and culture all need to transform to implement DevOps. You need to move from a project to a product-based methodology. From a people perspective, you can’t bring in manual testers or manual validators to do DevOps. Any successful DevOps implementation has to get this right.

    How to Implement DevOps: The Hub and the Spoke

    Again, start small. You could start with only continuous integration and then move on to add continuous deployment. If you start over aspirationally, you are more likely to fail and go back to the old ways. As you expand DevOps gradually, you can follow the hub and spoke model.

    In the hub and spoke model, the hub is a lean team responsible for setting up the tools, automation and best practices. The hub is responsible for defining what is to be executed. The spoke, on the other hand, is responsible for execution. The spoke is the extended team and their individual projects which they are responsible for executing.

    The hub is also responsible for enablement by defining what processes, best practices, tools and pipelines should be used. Teams in the spoke will use the pipeline to promote their goal from development to QA, from QA to staging and from staging to production.

    Next-Gen DevOps

    The evolution of DevOps continues even for early adopters, especially with the introduction of AI and generative AI. How do you use AI to validate your requirements? How do you use AI to decide what infrastructure is needed and when? How can you use AI to optimize your test sets? Next-gen DevOps is about smarter DevOps and intelligent DevOps.

  • What’s the Difference Between DevOps and Platform Engineering?

    What’s the Difference Between DevOps and Platform Engineering?

    The DevOps space is buzzing with a new trend—platform engineering. Platform engineering has been gaining steam over the last few years but has really peaked in interest lately. In fact, according to a study conducted by Puppet Labs, 51% of organizations have adopted platform engineering or plan to do so in the next year. But what exactly is platform engineering, and how is it different than DevOps?

    Below, we’ll explore the nuances between these two concepts. We’ll review what DevOps and platform engineering are and see how they’re similar and dissimilar. We’ll also outline the benefits of platform engineering and suggest some best practices to make the most of this emerging discipline.

    What is DevOps?

    DevOps is a broad topic, but it generally involves efforts to increase software release efficiency and frequency. Some of the hallmarks of the DevOps discipline include reducing siloes between teams and increasing collaboration. DevOps is often directly associated with various tools that automate the process of moving code from a local environment into production, also known as continuous integration and continuous delivery (CI/CD). Monitoring, incident management and configuration management tools also support the DevOps process.

    “DevOps reflects more of a philosophy and a way of working,” said David Sandilands, senior solutions architect for Puppet. DevOps enables more of a shift left mentality. Instead of having operations teams “guarding the gates,” developers work in partnership with Ops. In doing so, groups can decrease build time significantly, he said. This style helps engineers incrementally and rapidly release new features, replacing old waterfall development cycles.

    The ultimate goal of DevOps is to automate the software life cycle and shorten the feedback loop. Thus, DevOps takes a life cycle approach to shipping applications more efficiently, streamlining phases such as build, release, configure, monitor, plan, create and verify. Microservices architecture and containerization also often play a crucial role in enabling DevOps.

    What is Platform Engineering?

    Platform engineering is all about developing a self-service internal platform that serves the needs of developer consumers. Although DevOps opened things up and empowered individual developers with advanced automation, it left organizations with scattered tooling and processes, especially at large enterprises. For example, various infrastructure-as-code (IaC) configurations might exist for similar functions within the same organization but be unknown to engineers in different departments. Not to mention, overseeing a growing DevOps pipeline means added responsibilities around continual updates and security.

    Platform engineering places more control in the hands of a central platform team rather than individual developers. These teams typically treat the platform as a product. They do so by evaluating the needs of developers across an organization, building out internal self-service tools that suit the needs of most consumers and maintaining the platform.

    The 2023 State of DevOps Report found that this self-service approach typically handles areas like deployment, operation of infrastructure, monitoring production applications and security and compliance. Other capabilities, such as abstracting Kubernetes or overseeing secrets management, may also play a role in these efforts.

    Benefits of Platform Engineering

    • Improve developer experience: Platform engineering can enhance the experience a developer has with their software build and release systems. A better developer experience can do loads to improve morale and create a more productive engineering atmosphere.
    • Standardize DevOps practices: By bringing together common DevOps approaches into a shared platform, organizations can begin to standardize with reusable build processes and automated infrastructure. This can unite an organization on common runtimes, observability methods and deployment processes. This can streamline the introduction of DevOps practices to an organization.
    • Secure the DevOps pipeline: Various vulnerabilities exist within tooling that comprises modern CI/CD chains and cloud-native open source software. By outsourcing DevOps responsibility to a shared platform team, the organization can coalesce around more secure practices and avoid overlooking important updates or holes.
    • Supply additional guardrails: Platform teams might also assist in the acquisition of new tools as well as outlining and enforcing policies for software infrastructure. While this may come at the cost of customization, additional guardrails can help avoid shadow IT and governance around internal development. Letting platform teams handle it could make maintenance easier across an organization.

    Platform Engineering: Under the DevOps Umbrella

    I don’t see platform engineering as replacing DevOps. Instead, I view platform engineering as falling under the umbrella of DevOps since platform engineering takes DevOps processes and makes them more reusable and self-service. Both use a lot of automation and share many of the same end goals.

    However, there are nuances between the two approaches that reflect the recent trends in the IT market. With DevOps, the market was more interested in shifting responsibility left and empowering individual developers to oversee the entire software life cycle. Now, as sprawl and shadow IT emerge, the pendulum seems to be shifting back toward a bit more centralization and governance with platform engineering.

    Platform engineering is typically more of an in-house development initiative. So, what are some best practices IT divisions should remember to get the most out of platform engineering? Hope Lynch, senior director of platform at Cloudbees, shared some great strategies to consider that revolve around treating the platform as a product. Doing this involves accepting feedback from developers, not controlling everything and always maintaining a focus on developer experience.

    Hopefully, by following these tips, organizations should have a better grasp of the emerging discipline of platform engineering and have the confidence to begin introducing platform-based concepts within their own environments.

  • Quick Guide to Azure Storage Pricing

    Quick Guide to Azure Storage Pricing

    Azure Storage is a cloud-based storage service from Microsoft Azure. It provides a scalable, secure and highly available data storage solution for businesses of any size.

    The platform includes various services such as Azure Blob, which is a service for storing large amounts of unstructured data such as documents, images, videos and backups. Azure Files is a fully managed file share service for cloud-based applications. Azure Tables is a NoSQL key-value store used to store semi-structured data. Azure Queues is a messaging service used to store and process messages between applications or services.

    Finally, Azure Disks is a service that allows you to store and manage data in virtual hard disks used in virtual machines. With Azure Storage, businesses can easily manage their data, control access and scale their storage as per their needs without worrying about hardware or infrastructure management.

    How does Azure charge for storage space (bandwidth, capacity, number of transactions and quantity of transferred data)? What are the usage factors impacting Azure Storage fees: Region, account, access tier, replicas, egress?

    How Azure Storage Pricing Works

    Azure pricing for its storage services is based on several factors including storage capacity, data transfers and transaction counts. The cost of storage varies depending on the region and access tier selected, as well as the type of storage being used.

    For Azure Blob Storage, customers are charged for storage capacity, data egress (outbound data transfers) and the number of transactions (read, write and list operations).

    Azure Table Storage charges are based on the number of table entities stored and the amount of data transferred. Azure Queues are charged per transaction and data transfer, while Azure Disks are billed based on the provisioned capacity and the number of transactions.

    Several usage factors can impact Azure Storage fees, including the region where the data is stored, the storage account type, the access tier selected, the number of replicas and the amount of data transferred out of the storage account. 

    Overview of Azure Storage Pricing

    Blob Storage

    Azure Blob Storage pricing varies depending on the storage tier, data volume and whether customers opt for pay-as-you-go or reserved capacity.

    For pay-as-you-go pricing, Premium storage is charged at a flat rate of $0.015 per GB/month, while Cool and Archive storage are billed at $0.01 and $0.0099 per GB/month, respectively, regardless of data volume. Hot storage costs $0.018 per GB /month for the first 50 TB with the rate gradually decreasing with higher usage. For instance, customers who consume more than 500 TB/month pay $0.0166 per GB.

    Customers can also reserve blob storage in 100-TB or 1-PB blocks for one or three years. The prices for reserved storage vary by tier. A three-year Archive storage reservation costs $84 per 100 TB or $810 per PB/month, while Hot storage costs $1,244 per 100 TB/month for three years. For one-year reservations, Archive storage costs $91 per 100 TB or $883 per PB/month, and Hot storage costs $1,545 per 100 TB/month. For a one-year reservation, the cost of Hot storage is $15,050 per PB/month, and $11,963 per month for three years.

    Files

    Microsoft charges customers for Azure Files depending on the storage tier and whether they reserve storage capacity. Pay-as-you-go pricing ranges from $0.015 per GB/month for Cool storage to $0.016 per provisioned GiB/month for Premium file storage.

    Customers can commit to reserved storage capacity in increments of 10 TiB or 100 TiB for one or three years. A three-year reservation of 10 TiB Cool storage costs $101.39 per month, while one year costs $125.92 per month. However, the price increases significantly for the Premium offerings, with a three-year reservation of 10 TiB costing $1,081.34 per month and a one-year reservation costing $1,343.50 per month. 100 TiB reservations range from $983/month in the Cool tier for three years to $12,779.50/month in the Premium tier for one year.

    Nevertheless, there are other fees that add to the total cost such as read and write transactions, snapshots, metadata storage and early file deletion fees. These ancillary fees can impact the overall cost of using Azure Files and customers should account for them when estimating their expenses.

    Tables

    Azure Tables pricing is available in various tiers, including locally redundant storage (LRS), geo-redundant storage (GRS), read-access geo-redundant storage (RA-GRS), zone-redundant storage and geo-zone-redundant storage. 

    Customers are charged between $0.045 per GB/month for LRS and $0.01265 per GB/month for geozone-redundant read-only storage. Additionally, Microsoft charges a $0.0036 fee for each set of 10,000 transactions made on Azure Tables.

    Queues

    Compared to Blob and File Storage, the pricing model for Azure Queues is more straightforward. Customers are charged 4.5 cents to $0.075 cents per GB/month, depending on whether they choose local redundant storage (LRS) or read-access geozone-redundant storage (RA-GRS). Additionally, there is a $0.004 fee for every set of 10,000 operations in Class 1 and 2.

    Managed Disks

    Azure Managed Disks have numerous pricing options that can be overwhelming. The cost of using Managed Disks depends on several factors, including the disk size, performance, reservation period, capacity and disk type.

    The cheapest option for Managed Disks is the P1 disk, which costs $0.6 per month for 4 GiB of capacity in addition to $0.03 per mount/month. On the other hand, the P80 disk is the most expensive option, as it has a 32 TiB capacity costing $3,276.80 per month, in addition to $219/mount. However, the cost of a P80 disk can be reduced to $3,113/month (plus the $219/mount fee) with a reservation of one year.

    Azure Storage Vs. AWS Storage Pricing

    Here is a comparison of the pricing for similar storage services offered by Azure and AWS. As part of an Azure or AWS cost optimization strategy, you might consider combining services from both providers.

    Block Storage

    Amazon EBS is Amazon EC2’s basic storage device, with a price of $0.045 per GB for HDD and $0.10 per GB for SDD, with higher IOPS resulting in higher prices. The free tier includes 30 GB of SDD.

    For comparable regions in the U.S., Azure charges $0.05 per GB for HDD and $19.71 for 128 GB of SSD per month.

    Azure Managed Disks offer greater flexibility and easier backup than Azure Virtual Disks or Amazon EBS, with adjustable volume sizes and available IOPS. Managed Disks pricing starts at $19/month for a 128 GB disk, providing 500 IOPS.

    Object Storage

    Amazon S3 and Azure Blob Storage are both scalable services for storing objects (unstructured data) where data is stored together and cannot be changed in parts. Prices vary depending on the region, but for a comparable region in the U.S., Amazon S3 storage costs $0.023 per GB/month for the first 50 TB in addition to network usage fees. The free tier offers 5 GB of storage, while archive storage (Glacier) is $0.004 per GB/month.

    Azure Blob Storage starts at $0.0184 per GB/month for hot storage, although prices decrease to $0.01 per GB per month for cool storage and $0.002 for archive storage. Prices for both services increase for greater redundancy. 

    File Storage

    Amazon Elastic File System (EFS) is an equivalent service to Azure File storage and allows users to mount files to Amazon EC2 servers. It uses NFS V4.0/4.2 to mount files and is not available in all AWS regions (currently, four are supported), requiring a Direct Connect line or VPN for on-premises mounting.

    For a comparable U.S. region, Amazon EFS costs $0.30 per GB/month and the free tier offers 5GB on sign-up. Azure File Storage prices start at $0.06 per GB/month for local redundant storage, with prices increasing for more distributed redundancy setups. It is worth noting that both Azure and AWS charge additional fees for data access.

    Conclusion

    In conclusion, Azure Storage offers a range of services for storing and managing data in the cloud, each with its own pricing structure. While the pricing varies based on several factors including storage capacity, data transfers and transaction counts, it is essential to consider other usage factors, such as region, account, access tier, replicas and egress. 

    Customers should review these factors carefully and estimate their expenses to select the right storage service that meets their needs and budget. By doing so, they can leverage Azure Storage’s flexibility and scalability to store and manage their data efficiently in the cloud.

  • 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.