devopsy.kinsta.cloud

Category: DevOps Practice

  • Optimizing the Developer Experience in 2023

    Optimizing the Developer Experience in 2023

    2022 was a banner year for innovation, but not only in the traditional “churning out new features” way. Many organizations started thinking about their processes and how to amplify them to maximize efficiency and employee retention. And when they started digging, companies realized that the developer experience was a major pain point that could be rectified–and a ripple effect of positive gains would result.

    Companies started looking more closely at how the tools and processes developers use support and enhance their work. Great tools and thoughtful processes boost developer happiness and satisfaction. And when those levels rise, guess what else increased? Productivity, efficiency and employee retention rates.

    We saw this trend of developer support take hold last year, but with more work to be done across many companies, we’ll see it continue in 2023 and beyond, impacting just about every facet of tech in new ways. Many companies have realized what does work by trying what doesn’t work and are making big changes from there.

    Shifting Results

    A major player in the changing developer experience has been the shift left approach that’s taken hold in recent years. About 80% of organizations have said they are adopting this idea of moving more of the responsibility for security and compliance to the front of the pipeline to avoid a compliance scramble at the point of delivery. The result, however, is a compliance process that ends up being more complex and less efficient, putting additional burdens on developers.

    Involving more people creates more opportunities for security breaches and slows down the entire software delivery life cycle. It also shifts security responsibilities to developers and requires them to do significantly more than is listed in their job description. In fact, 60% of those shifting left said their development team is bearing the burden of the change. Rather than focusing on writing code, developers have been called on to understand regulatory policies, build regulatory controls into their applications or pipelines, inspect massive log files generated by more and more diagnostic tools for security info and spend more time in meetings to discuss audits. That’s not a recipe for fulfilled developers; it’s the path to a loss of innovation.

    Stop Paying the Compliance Tax

    When developers–or anyone on your team–are tied up in compliance tasks, they aren’t spending that time in profit-earning efforts. This “compliance tax” costs companies an estimated 15% each year–that’s 15% of their time spent managing compliance instead of innovating or providing services that add value. That’s not to say that compliance isn’t important–it’s essential, in fact–but limiting the burden of compliance improves the overall experience of developers.

    When developers aren’t innovating, they’re not happy. They want to be writing great code, not translating regulatory governance policies. In today’s culture of quiet quitting, companies simply can’t afford to turn over compliance tasks to developers. It’s a waste of their talent and a surefire way to lose great developers and the chance to attract new ones.

    Shift Left, but Do it Right

    The good news is the compliance tax is largely avoidable. Instead of shifting responsibilities left, shift compliance everywhere. No one person or group, including developers, should be in charge of these tasks–that approach just isn’t comprehensive enough to ensure security and compliance throughout the software delivery life cycle.

    Instead, security and compliance should be moved away from a point-in-time part of the cycle to a continuous process built into every step of the life cycle. CI/CD reduces the burden on any one person or group and is proven to be more efficient at catching anything that is non-compliant. When the tools are doing the heavy lifting, the people aren’t making as many mistakes and non-compliant code isn’t slipping through.

    Baking in compliance allows developers to spend more time doing what they do best: Creating amazing features. This, more than anything, will boost the developer experience. Developers want to create and, when they experience the right environment and the right resources, innovation tends to happen.

    Beyond the Developer Experience

    Focusing on the developer experience pays off in more ways than just creating happy employees (though that alone is reason enough to make a change). Innovative developers are the backbone of leading tech companies. When they’re churning out new features that are getting public recognition and are touting a culture with a positive developer experience, companies attract more talented developers and the innovation loop continues.

    So, if you’re looking for more innovation in 2023, start where you’ve always started: Your developers. Set them up for success by automating what can be automated and baking in the mundane – yet essential – tasks to truly optimize the developer experience. Then sit back and watch what incredible capabilities your developers can generate.

  • Complexity is Still With Us

    We have come a long way and had a lot of improvements over the years, but we still struggle with the ability to simplify things faster than we create complexity. It isn’t enough that each new wave of Really Important Bits™ comes with its own issues and layers and complexity; we also haven’t been cleaning up our previous Really Important Bits™ projects. We haven’t cleaned up the successful ones and we haven’t cleaned up the failures.

    It is time to start. Honestly, we are looking at an extended stretch of ‘Do More With Less,’ and we need to get our houses in order. Want to do more with less? Start by standardizing. Yes, that one project that used Really Important Bits™ (or its companion product Really Cool Tech™) was neat and all, but keeping a technology and its layers and pieces laying around for a single project is not great management. In fact, it isn’t management at all; it is letting things happen. I’d call it chaos, but then we’d have to have a whole conversation about Dungeons & Dragons and, frankly, it is happening in the forum of the overall enterprise architecture so it’s not actually chaos, it is simply excess technical debt.

    DevOps was never meant to be a destination, but on this cross-country road trip, our IT car will get filled with garbage if we don’t take the time to clear out the Really Important Things™ of last year or the last management team or the latest merger. We cannot continue to layer more on without relieving pressure somewhere. AI has the potential to offer some pressure relief in some areas, but we were already behind, so for a variety of reasons, it isn’t the silver bullet we need. Those reasons are simple–it is less secure to leave 50 different ways to do the same thing laying around. AI is resolving some problems and freeing up time, but you’re still wasting time and money on redundant or unused Really Important Things™.

    Some things simply cannot be cleaned up without a massive investment. That’s fine—I hope after years of using DevOps methodologies you have them on a list of things that you’d like to upgrade/replace, but it just isn’t feasible to do so. Focus on the things that you can simplify. The famous low-hanging fruits are fine, just like simplifying things in the early days of DevOps meant that each piece of low-hanging fruit freed up more time to focus on other issues, the same is true now that the low-hanging fruit is generated from DevOps. Or DevOops, in some cases.

    How did I get here, you ask? I was writing a simple overview of Git, CI/CD, DevOps, DevSecOps, GitOps, etc., etc. for a newer technologist, and realized that in between those important parts are a whole lot of tools and technologies we thought were important, but which are no longer terribly useful or necessary. I did her the favor of not including the by-the-wayside technology spaces and product markets. I removed the complexity, you could say.

    And keep rocking it. No matter how far along you are in your IT career, you can look back at all of the things you have learned. Apply that learning to simplifying and improving. Reduce overhead by reducing redundancy and look forward to the next Really Important Thing™ you’ll get to learn about. Keep improving—both your knowledge and the environment. And we’ll keep cheering you on.

  • State of DevOps Report Finds a Rise in Platform Engineering

    State of DevOps Report Finds a Rise in Platform Engineering

    The speed of software development velocity is increasing, and to enable this, platform engineering is emerging to evolve the DevOps practice. Interest in platform engineering is rising—so much so that Puppet emphasized platform engineering in its 2023 State of DevOps Report.

    A whopping 94% of respondents agreed that platform engineering is helping their organizations better realize the benefits of DevOps. The move toward platform engineering has increased over time, bringing benefits such as increased release velocity, reliability and efficiency.

    Below, we’ll highlight some of the key takeaways from the report. We’ll define what platform engineering is and highlight its benefits. We’ll also consider obstacles on the path to embracing a platform-based development culture.

    Platform Engineering Supplants DevOps

    DevOps has been in use for a decade or more at most institutions, maturing steadily with new automation and infrastructure abstraction. The latest evolution of DevOps is a practice known as platform engineering—51% of organizations have already adopted this practice within the last three years and 93% said it’s a step in the right direction.

    Platform engineering is the discipline of designing and building self-service capabilities to minimize cognitive load for developers and to enable fast-flow software delivery.

    In essence, platform engineering is the process of creating standardized, self-service infrastructure that helps developers get up and running quickly. These self-service platforms typically handle capabilities like deployment (43%), operation of infrastructure (43%), monitoring production applications (42%) and security and compliance (42%).

    These shared internal platforms are maintained by a central platform team that embraces a product mindset to iterate the technology based on user feedback.

    State of Platform Engineering

    Platform engineering is relatively new— 27% of platform teams have formed within the last two to three years. Notably, big tech companies hopped on the bandwagon years ago, and non-tech companies are now following. Regardless, 70% believed their timing was “just right.”

    The goals of a platform engineering team are numerous. According to the Puppet report, 54% said problem-solving is the top goal. This is followed by educating and empowering developer teams (47%), setting best practices (46%) and optimizing iteration (44%). A platform engineering team’s scope of work is primarily focused on automating workflows and building and managing infrastructure.

    The ‘correct’ number of internal platforms is a moving target. The majority of organizations (57%) have between two and four platforms, and 30% have five or more internal self-service platforms. This demonstrates that although platform engineering is somewhat centralized, it’s also flexible to the needs of an organization.

    Benefits and Hurdles

    So, what are some benefits as opposed to traditional DevOps? Well, the most common benefit is improved system reliability, at 60%. This tracks, as a standardized platform could reduce human error and missteps in the development workflow. Following this benefit is improving efficiency (59%), speeding up delivery time (58%) and improving workflow and process standards (57%).

    The most common driver of adoption is increasing the speed of delivery. Slight more than half of respondents (51%) said development speed has somewhat increased since the inception of the platform team, and 42% say it’s increased by “a great deal.” Other top drivers include the need to scale, free up engineering time, control infrastructure spending and avoid duplication across teams. Those with more mature adoption tend to be more satisfied with the result, indicating that results increased over time.

    Of course, no new technological introduction comes without its hurdles, and platform engineering is not immune from certain pain points. For example, 34% said that cycle time is slower than expected. This might be due to nascent industry adoption and a lack of best practices.

    Just under one-third (32%) also noticed resistance to platform team adoption, and 32% reported a lack of communication around changes. Organizations will likely have to increase transparency and reduce siloing to encourage productive platform adoption that satisfies the needs of various stakeholders.

    According to the report, product management skills can help realize these goals. Some of the most fundamental product management skills here include strong communication skills (61%), problem-solving expertise (60%) and the ability to foster collaboration (54%). Many companies will also have to convince senior management to invest in platform engineering—nearly half agreed that senior management doesn’t yet understand its value.

    Future Outlook

    Confidence around platform engineering is increasing, especially for teams with mature DevOps approaches. As a result, the practice will likely gain more traction in the coming year—71% of respondents reported their firm plans to hire people with platform engineering experience over the next 12 months.

    Over the next year, organizations that adopt the practice will want to increase awareness of platform capabilities and set expectations across the organization. This will also include setting governance policies and satisfying the needs of specific developers, departments and the organization as a whole.

    Above, we’ve scratched the surface of the current state of platform engineering, its benefits and its pain points. For plenty of other insights, you can pick up a copy of The State of DevOps Report 2023: Platform Engineering Edition from Puppet by Perforce here.

  • Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta Makes No-Code Integration Tool for Identity Platform Available

    Okta today made generally available an Actions Integration capability that makes it possible to integrate third-party tools without having to write any code.

    Shiven Ramji, chief product officer for Okta, said this no-code integration capability for the Okta Customer Identity Cloud extends a simpler approach for managing secrets that is invoked via an application programming interface (API).

    At a time when more responsibility for application security is being shifted left toward developers, the Okta Customer Identity Cloud is gaining traction as an alternative for managing secrets more securely, noted Ramji. Rather than developers attempting to manually verify the identity of end users, it becomes easier to manage identity flows within the context of a larger application development workflow using a cloud service, he added.

    In addition to giving developers access to Actions Integration, Okta is also making third-party integrations developed by partners available via the Auth0 Marketplace. The goal is to encourage providers of application development tools to build integrations that development teams can simply download when needed, said Ramji.

    It’s not clear how much influence developers are exerting over how identity is managed as more organizations embrace DevSecOps best practices for building and deploying applications. Regardless of approach, the overall state of application security should continue to improve as developers embrace new methods of managing identity within their applications. One of the issues that frequently creates a security breach is when developers forget to remove secrets created during the application development process before an application is deployed in a production environment. Cybercriminals today routinely scan for secrets that have been inadvertently stored as text within an application.

    Lees clear is the degree to which developers may opt to update existing applications to take advantage of identity management services that can be invoked via an API or whether they will opt to switch to a cloud service for only new applications.

    One way or another, organizations of all sizes will need to find a way to make it easier for developers to manage identities across multiple applications. There is often a tendency to ascribe responsibility for managing identities to development teams without always providing access to a set of tools to manage the process. In about half of the instances in which organizations adopt Okta Customer Identity Cloud, the decision is made by developers, said Ramji. Many of those developers discover the Okta service when they are building a proof-of-concept for their application, he added.

    The other half of the time the decision is made by more senior leaders on behalf of an entire development team, said Ramji. In some of those cases, organizations are even going to far as to create a team of specialists for managing identities across a portfolio of applications, he noted.

    The core issue, as always, is determining how much time and effort developers will want to spend on identity management versus writing business logic code. All things considered, most developers are going to find it a lot more convenient to invoke an API to access a cloud service versus setting up and maintaining a vault full of application secrets on their own.

  • The API Economy: Increasing Potential to Monetize Public APIs

    The API Economy: Increasing Potential to Monetize Public APIs

    API-first strategies are becoming more commonplace throughout today’s digital strata. APIs connect microservices architectures, power new digital transformations and help development teams avoid reinventing the wheel for common functions. And although most are built to connect internal components, studies indicate a movement toward more externalization and monetization of public APIs.

    Over three-fourths of developers now view participating in the API economy as a priority for their organization or plan to prioritize it soon, found Rapid’s newly released 2022 State of APIs report. The survey, which surveyed hundreds of professional developers, also uncovered a modest increase in companies seeking to generate direct revenue from APIs.

    Below, we’ll review some intriguing statistics from the Rapid report and consider the major takeaways technology professionals should consider in the year ahead.

    API Reliance Increases

    Reliance on APIs is rising across the board. Over 62.6% of developers reported relying on them more in 2022 than in 2021. Internal APIs help avoid development duplication and third-party APIs can quickly integrate standard functionality related to payments, messaging, geolocation, data sharing and many more areas. For example, ChatGPT has demonstrated the power of standard APIs to deliver advanced AI/ML to the masses in a programmatic way.

    As a result of this interest, the majority of organizations now consider participating in the API economy as a top priority. And as an organization grows larger, its reliance on APIs is likely to increase. A full 40% of the largest companies surveyed reported having more than 250 internal APIs. Nowhere is this more prevalent than in financial services. This finding makes sense, given how APIs can automate payments and underpin the open banking movement.

    In terms of who is using APIs, it’s most commonly full-stack or backend developers, the report found. One intriguing factoid is just how much of this work is now dominating developers’ time. Impressively, 65.5% of developers reported spending ten hours or more working with APIs in their job; 14.5% of them said that work takes up all of their time.

    In terms of design styles, various standards are used throughout the web development sphere. Yet REST is still king—69.3% of engineers used REST in production. REST is followed by webhooks, WebSockets, AsyncAPI, serverless and FaaS, SOAP, GraphQL, Kafka and gRPC, in descending order of popularity. Across the board, these statistics showed a steady increase from last year.

    Of note is that most APIs are built for internal purposes. These often wrap a database or provide open access to an internal microservice. Private use cases are by far the most common approach; according to the report, 75.1% of respondents worked on internal APIs. These findings aligned with other industry reports, such as the Postman State of the API Report, which found that, in 2022, 58% of API initiatives were private.

    Third-party APIs (53.9%) and partner-facing services (48.9%) trailed behind internal APIs in popularity. Interestingly, while internal use cases have remained steady, both partner and public-facing strategies have increased since last year. While the growth was a modest 5% for most sectors, partner-facing APIs in some industries grew by nearly 10%.

    Spotlight on Monetization

    Many still view APIs as operational glue for internal data or connecting partner services. Yet, the possibility of monetization through self-service developer portals shouldn’t be overlooked—countless API-first startups are actively gaining traction and funding. And monetizing this power is seen as a holy grail to some unicorn-chasing VC funds.

    Most APIs are purely for in-house internal integrations and are typically not externalized to the outside world for profit. However, this is slowly changing. In fact, 42.6% of organizations are now monetizing APIs, representing an increase of about 5% from 2021.

    As one may have guessed, financial services are leaders in monetizing their external APIs. The telecommunications industry is also noticeably active in monetization, too. Furthermore, with size comes increased monetization potential—about half of the companies with a large footprint of ten or more internal or external APIs also monetized them.

    API Economy in 2023

    Looking to the future, most anticipate more reliance on APIs across sectors — 69.2% expect to rely on APIs even more in 2023. Yet, organizations will have to grapple with particular hurdles in this newfound landscape. For example, a cloud skills gap might bar some groups from realizing the benefits of an API strategy. Other concerns include ungoverned sprawl, authorization concerns, shadow APIs and escalating attacks on public-facing endpoints. Also, some organizations are still determining how to best secure and scale their use of new styles, like GraphQL.

    A standards-based approach that applies platform-wide governance will likely be necessary to maintain an efficient yet stable API footprint. To meet these high quality standards, testing is nearly universally applied—92.7% of those surveyed test their APIs or plan to do so. The most common tests ranged from functional testing to integration testing, acceptance testing and performance testing.

    The Rapid 2022 State of APIs report received 850 responses from over 100 countries. For more insights, readers can view the complete results here.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

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

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers. Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role, it creates an opportunity for others.

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

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

    Indeed.com

    Virtuoso
    Fort Worth, Texas
    Senior Cloud Infrastructure Engineer
    $140,000 to $160,000

    Monster.com

    Ness USA
    Stony Brook, New York
    Lead DevOps Engineer (AWS)
    $130,000

    LinkedIn

    Deloitte
    Phoenix, Arizona
    DevOps Specialist Senior
    $125,000 to $209,000

    SimplyHired

    Hewlett-Packard Enterprise
    Remote
    DevOps Engineer
    $110,000 to $150,000

    ZipRecruiter

    USAA
    Multiple Locations
    Public Cloud Infrastructure Engineer – Midlevel
    $89,200 to $160,600

  • Why MLOps Hurts: 3 Pain Points for DevOps Teams

    Why MLOps Hurts: 3 Pain Points for DevOps Teams

    Machine learning operations (MLOps) is a practice that aims to improve the collaboration and communication between data scientists and IT professionals in the development, deployment and maintenance of machine learning models.

    MLOps aims to streamline the process of building, testing and deploying machine learning models by automating and standardizing the various tasks involved. This includes automating the training and testing of models and the deployment and management of models in production.

    MLOps involves using tools and processes to automate the various steps involved in machine learning model development and deployment. This includes tools for version control, continuous integration and continuous deployment (CI/CD), and tools for monitoring and managing the performance of machine learning models in production.

    By adopting MLOps practices, organizations can improve the speed and efficiency of their machine learning model development and deployment and reduce the risk of errors and inconsistencies in the process.

    What Role do DevOps Engineers Play in MLOps?

    In MLOps, DevOps engineers play a crucial role in supporting the development and deployment of machine learning models. Their responsibilities may include:

    • Setting up and maintaining the infrastructure needed to support machine learning models, including hardware and software environments, data pipelines, and monitoring systems.
    • Automating the various tasks involved in machine learning model development and deployment, including training, testing, and deployment, using tools such as continuous integration and continuous deployment (CI/CD).
    • Monitoring the performance of machine learning models in production and troubleshooting any issues that may arise.
    • Collaborating with data scientists to understand the requirements and constraints of machine learning models and to help them implement and deploy their models effectively.
    • Managing the release process for machine learning models, including coordinating with different teams, conducting testing and validation, and rolling out updates and improvements.

    Challenges to Implementing MLOps

    MLOps is not without its challenges. Here’s what to consider when developing and deploying your machine learning pipelines. 

    Data Security

    Data security is a key challenge of MLOps for DevOps teams because machine learning models rely on large amounts of data to function effectively. Ensuring the security and integrity of this data is critical to the success of the model and the overall MLOps process.

    There are several risks to data security that DevOps teams need to consider in MLOps:

    • Data breaches: Machine learning models often work with sensitive data, such as personal information or financial data. If this data is not secured properly, it could be accessed by unauthorized parties, leading to data breaches and potential legal and financial consequences.
    • Data tampering: Machine learning models rely on the accuracy and integrity of the data they are trained on. If the data is tampered with or manipulated, it could affect the model’s performance and lead to incorrect or unreliable predictions.
    • Data privacy: Machine learning models may work with data that is subject to privacy regulations, such as the General Data Protection Regulation (GDPR) in the European Union. Ensuring compliance with these regulations is critical to avoid fines and other consequences.

    Model Deployment

    Model deployment is a key challenge of MLOps for DevOps teams because it involves integrating the machine learning model into an existing application or system and setting up the infrastructure to support it. This can be complex, especially if the model is part of a larger application or system, and requires careful planning and coordination.

    There are several challenges that DevOps teams may face when deploying machine learning models:

    • Integration: Machine learning models need to be integrated into an existing application or system in a way that is seamless and does not disrupt the overall functionality. This can be a complex task that requires careful planning and testing.
    • Testing: It is important to thoroughly test the machine learning model before it is deployed to production to ensure that it functions correctly and meets the required performance standards. This may involve testing the model on a variety of data and in different environments to ensure that it is robust and reliable.
    • Performance: Machine learning models may require specialized hardware and software environments to support their performance. Setting up and maintaining these environments can be a challenge for DevOps teams.
    • Scalability: Machine learning models may need to scale up or down depending on the volume of data and the demands placed on them. Ensuring that the model is able to handle different workloads and scale appropriately is a key challenge for DevOps teams.

    Model Performance and Maintenance

    Model performance and maintenance is a key challenge of MLOps for DevOps teams because machine learning models require ongoing monitoring and maintenance to ensure that they continue to perform well in production. This can be a complex and time-consuming task that requires close collaboration between data scientists and IT professionals.

    There are several challenges that DevOps teams may face when it comes to model performance and maintenance:

    • Model drift: Machine learning models can suffer from model drift over time, where the model’s performance begins to degrade due to changes in the data or the business requirements. This can be difficult to detect and can significantly impact the model’s accuracy.
    • Data changes: Machine learning models rely on the accuracy and integrity of the data they are trained on. If the data changes over time, the model may need to be retrained or updated to ensure that it continues to perform well.
    • Hyperparameter tuning: Machine learning models often have several hyperparameters that need to be set to optimize their performance. Identifying the optimal values for these hyperparameters can be challenging and the model may need to be retuned over time to maintain its performance.
    • Model versioning: Machine learning models may need to be updated or replaced over time to improve their performance or to address issues. Managing different versions of the model and coordinating the rollout of updates can be a challenge for DevOps teams.

    5 MLOps Best Practices to Help DevOps Teams

    There are several best practices that DevOps teams can adopt to help overcome the challenges of MLOps:

    1. Automate as much as possible: Automating tasks such as model training, testing and deployment can help streamline the MLOps process and reduce the risk of errors and inconsistencies.
    2. Use version control: Version control systems such as Git can help track changes to the machine learning model and its supporting infrastructure, making it easier to roll back changes or deploy updates.
    3. Use CI/CD: CI/CD pipelines can help automate the process of building, testing, and deploying machine learning models, improving the speed and efficiency of the MLOps process.
    4. Monitor and log model performance: Setting up monitoring and logging systems can help DevOps teams track the performance of machine learning models in production and identify any issues that may arise.
    5. Collaborate and communicate effectively: MLOps requires close collaboration between data scientists and IT professionals. Establishing clear communication channels and effective collaboration processes can help ensure that all parties are working towards a common goal.

    Conclusion

    In conclusion, MLOps can be a challenging process for DevOps teams due to the complexity and specialized nature of machine learning models. There are several pain points that DevOps teams may face when implementing MLOps, including the complexity of setting up and maintaining the necessary infrastructure, the difficulty of collaborating and communicating effectively with data scientists and the challenges of ensuring the security and integrity of data used to train and test machine learning models. 

    By adopting best practices such as automation, version control, CI/CD pipelines and effective collaboration and communication, DevOps teams can help overcome these challenges and improve the speed and efficiency of machine learning model development and deployment.

  • FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

    FAA Ground Stop due to Technical Debt? | Don’t Do DIY Crypto!

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

    This week: The FAA’s NOTAM database gets corrupted, and Threema shows why DIY cryptography is bad. (more…)

  • AppSec in the Cloud: What DevOps Teams Should Know

    AppSec in the Cloud: What DevOps Teams Should Know

    Cloud application security refers to the measures and controls that are put in place to protect cloud-based applications and data from cyberthreats, unauthorized access and data breaches. These measures can include technical controls such as encryption, access controls and secure networks, as well as operational controls like policies and procedures for managing and securing data in the cloud.

    Cloud application security is important because it helps to ensure the confidentiality, integrity and availability of data and applications in the cloud. It is especially critical for organizations that store sensitive or regulated data in the cloud, as a security breach could have serious consequences for the organization and its customers.

    There are many different approaches to cloud application security, including the use of security protocols, identity and access management (IAM) systems and security information and event management (SIEM) tools. Some organizations may also choose to use cloud security platforms, which provide a range of security services and tools that can be used to protect cloud-based applications and data.

    How DevOps Secures the Cloud

    DevOps is a software development approach that aims to optimize the collaboration and communication between development and operations teams to deliver software more quickly and efficiently. It involves using automation, continuous integration and delivery and other tools and practices to streamline the software development process.

    Cloud security operations, or CloudSecOps, refers to the practices, processes and tools used to secure and manage cloud-based applications, systems and data. CloudSecOps is a key aspect of DevOps, as it helps to ensure that cloud-based applications and systems are secure and compliant, while also allowing for rapid deployment, scaling and management of applications in the cloud.

    There are several key ways that CloudSecOps can be implemented in the cloud as part of a DevOps approach:

    • Automated security testing: CloudSecOps can be implemented using automated security testing tools, which can be integrated into the CI/CD pipeline to continuously test and validate the security of code changes.
    • Identity and access management: CloudSecOps involves using identity and access management (IAM) systems to control and monitor access to cloud-based resources. These systems can be integrated into the DevOps process to ensure that access to cloud-based systems is properly managed and secured.
    • Security as Code: CloudSecOps can be implemented using security-as-code practices, which involve writing security policies and controls in code and integrating them into the CI/CD pipeline. This allows organizations to automatically enforce security controls as part of the software development process.

    4 Cloud Application Security Best Practices

    Understanding and Monitoring Dependencies in Cloud Applications

    Application dependency mapping is a technique that can be used to visualize and understand the dependencies between different components of a cloud application. This can help organizations identify and manage the risks associated with dependencies and ensure that all application components are up-to-date and secure.

    There are several key benefits to using application dependency mapping as a cloud application security best practice:

    • Improved visibility: Application dependency mapping provides a clear and comprehensive view of the dependencies between different components of the application, which can help organizations to better understand the risks associated with these dependencies.
    • Improved risk management: By understanding the dependencies between different application components, organizations can identify and prioritize the most critical dependencies and take steps to mitigate any associated risks.
    • Improved security: By regularly monitoring dependencies for updates and vulnerabilities, organizations can ensure that all application components are secure and up-to-date.
    • Improved compliance: By understanding and managing the dependencies between different application components, organizations can ensure that they meet compliance requirements for storing and processing data in the cloud.

    Cloud Database Security

    Cloud database security is a critical aspect of cloud application security, as it involves the measures and controls that are put in place to protect data stored in the cloud from cyberthreats, unauthorized access and data breaches. 

    Ensuring the security of cloud-based databases is important because these systems often store sensitive or regulated data. A security breach could have serious consequences for the organization and its customers.

    There are several key best practices for ensuring the security of cloud-based databases:

    • Encryption: Encrypting data at rest and in transit can help to protect against unauthorized access to data stored in the cloud.
    • Access controls: Implementing fine-grained access controls can help to ensure that only authorized users have access to data stored in the cloud.
    • Security monitoring: Monitoring for security events and anomalies can help to identify and respond to potential threats to data stored in the cloud.
    • Compliance: Ensuring that cloud-based databases meet compliance requirements for storing and processing data is an important best practice to protect against data breaches and ensure regulatory compliance.

    Apply Cloud Governance Policies

    Cloud governance refers to the practices, processes, and controls used to manage and govern the use of cloud-based resources and services. Some of the key ways that organizations can apply cloud governance policies to improve the security of their cloud-based systems include:

    • Establishing policies for access and use: Organizations can establish policies that define who has access to cloud-based resources and how they can be used. This can help to ensure that access to sensitive data and systems is properly controlled and monitored.
    • Implementing security controls: Organizations can implement security controls such as encryption, access controls and secure networks to protect data and systems in the cloud.
    • Ensuring compliance: Organizations can establish policies and procedures to meet compliance requirements for storing and processing data in the cloud.
    • Monitoring and auditing: Organizations can establish policies for monitoring and auditing the use of cloud-based resources to ensure that they are being used in accordance with established policies and procedures.

    Identify, Categorize and Protect Sensitive Data Stored in the Cloud

    Sensitive data refers to information that is highly confidential or regulated and that requires special protection to ensure its confidentiality, integrity, and availability. There are several key steps that organizations can take to identify, categorize and protect sensitive data stored in the cloud:

    1. Identify sensitive data: The first step is to identify the sensitive data stored in the cloud. This may include personal data, financial data, intellectual property and other types of sensitive information.
    2. Categorize sensitive data: Once the sensitive data has been identified, it is important to categorize it based on its level of sensitivity and the potential risks associated with it. This can help organizations to prioritize the protection of different types of sensitive data.
    3. Protect sensitive data: There are several different measures that organizations can take to protect sensitive data stored in the cloud, including encryption, access controls and secure networks. It is also important to implement policies and procedures to ensure that sensitive data is handled and processed securely.

    Conclusion

    In conclusion, application security in the cloud is a critical concern for DevOps teams, as it involves the measures and controls that are put in place to protect cloud-based applications and data from cyber threats, unauthorized access, and data breaches. 

    To ensure the security of their cloud-based systems, DevOps teams should implement a range of best practices, including understanding and monitoring dependencies, implementing security controls, managing identities and access, and ensuring compliance. By following these best practices, DevOps teams can help to ensure the security and integrity of their cloud-based systems and protect against potential threats.

  • Are We Delivering?

    Are We Delivering?

    I had an interesting conversation today where I was told, “We do great with CI but terrible at the CD part.” My immediate reaction was to point at all the great CD activity going on in vendor space right now. But as I stopped to ponder, I realized that we’re doing all of that great CD activity to play catch-up.

    DevSecOps has us covered in spades—the toolsets allow for scanning and protection all through the process, from the first line of code to application retirement. I would argue that after being left out in the cold, DevSecOps has done a better job than DevOps at the right side of the equation.

    In DevOps, the various “cloud-native” deployment models (I use scare quotes because they’re not really cloud-native. If you dig into them, nearly every one of them includes Kubernetes in their definition of cloud) are starting to do the job admirably, but in shops starting to automate the entirety of the process, the CI part has been automated and code delivery accelerated for a good long while.

    In short, adoption seems to prove, once again, that the benefits of rapid development are more important than the benefits of offering a stable, repeatable deployment environment. This makes one wonder what, exactly, we should be doing to convince IT and business leaders in orgs smaller than web monsters that security and repeatability both demand the implementation of capable continuous delivery.

    I think we failed the audience when we allowed pundits to blather on and on about deploying thousands of times a second when most applications in most orgs need to deliver at a significantly slower pace. And not only that, but want to deliver at that slower pace, given the “Don’t fix what isn’t broken” rule. Even if the environment is stable, rolling out for a single minor bug fix is possible but it’s not the best use of time—both computer and human.

    But we are catching up. We have things like GitOps and Kubernetes automation catching up with the rate of development; security is already there and test automation is ready to find issues before deployment. It is simply implementation that is behind and, as time goes on, more orgs will get the implementation part nailed.

    And through that process, you’ll be there, rocking it. Step up and make sure it is done right. The entire process is there; you could sleep better at night knowing that it is all in place and you are not likely to get a midnight call. Your org loves stability, you love good nights of sleep … Go out and get it.