Category: Doin’ DevOps

  • Product Mindset Key to Platform Engineering Success

    Product Mindset Key to Platform Engineering Success

    Platform engineering has taken the world by storm, and for good reason. Good platforms reduce TicketOps, standardize config setups, and cut lead time and time to market. Despite the discipline’s new popularity, there remain some questions about what sets platform engineering apart from DevOps. The answer to those questions lies in the platform as a product approach–the heart of every successful platform engineering effort.

    What is Platform Engineering?

    According to Luca Galante, platform engineering is “the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.” Platform engineers build an internal developer platform, which “consists of many different tech and tools, glued together in a way that lowers the cognitive load on developers without abstracting away context and underlying technologies.”

    What is the Platform as a Product Approach?

    A product approach requires user research, a defined mission, leveraging lighthouse teams, getting regular feedback, iterating and marketing your platform for internal buy-in. Together, these product management best practices will ensure your platform enables true developer self-service and finds the right level of abstraction.

    “Build it, and they will come” is not a viable strategy for ensuring developers will adopt your platform. Similarly, forcing developers to use a platform is likely to fail. Mandated usage creates resentment, reduces trust and results in shadow ops. To avoid your platform’s untimely demise, you have to treat your platform like a product and sell it to your customers: Your developers.

    This article provides a high-level overview of what a product mindset looks like in practice and why each component contributes to the success of your platform.

    Do Your Research

    Unless you gain a comprehensive understanding of developers’ pain points and what they’re already doing to mitigate those issues, you won’t build a platform people actually want to use. Hashicorp’s Michael Galloway shared this example of a user survey he conducted with his team while at Doma. The idea is to ask questions about the full software delivery process, from the planning stages of the interviewee’s work to debugging and testing. This way, the platform team can prioritize creating features to solve developers’ most frustrating problems.

    Oftentimes, platform teams will find that teams have conflicting wants and perspectives on what the platform should be. A platform product manager will help translate disparate responses into an actionable and successful plan. Successful platform teams also research open source and commercial tools and integrate pre-built solutions into their platform where beneficial. They study blueprints, like the internal developer platform reference architectures developed by McKinsey, as a starting point.

    Define Your Mission

    Your mission statement gives your platform team a clear identity and priorities. It’s also a starting point for understanding and communicating your impact on the business to relevant stakeholders. Good mission statements are emotional and inspiring, simple but meaningful, match the longevity of the organization and are informed by user research.

    Leveraging Lighthouse Teams

    When starting their platform engineering journey, many organizations don’t know what to build first. The confusion arises from having two important yet conflicting priorities. On the one hand, your platform team doesn’t want to bite off more than it can chew by building too many features at once. On the other hand, platforms that are thin enough to cover the entire enterprise often fail to provide enough value to individual teams.

    The way to strike the right balance is by leveraging lighthouse teams. A lighthouse team is the first group of people you’ll choose to build your organization’s platform for, so spend a lot of time with them to get it right. Cultivate ambassadors and evangelists and give them time to get the rest of the team (and the organization!) on board with your platform. Once you’ve built a platform that provides real value to your lighthouse team, repeat this process with more teams across the organization.

    The lighthouse team approach is valuable because it helps platform teams avoid boiling the ocean while also ensuring your platform provides real value every step of the way.

    Stay in the Loop

    Initial user research is not enough to sustain a successful platform engineering effort. Platform teams should solicit regular feedback from developers and use it to iterate the platform.

    Market Internally to Get Buy-In

    Conversations about platform engineering often focus on developers, but developers are not your platform’s only stakeholder group. Your platform team will also need buy-in from managers, SysAdmins, DevOps engineers and the C-suite.

    In his PlatformCon 2023 talk “How to communicate the business value of platform engineering,” Gartner’s Manjunath Bhat shared Gartner’s Enterprise Value Equation as a foundation for platform teams to understand and communicate the value of their Internal Developer Platform to different stakeholder groups.

    The process includes assessing stakeholder priorities and concerns, identifying and defining value enablers, building a value map to map value enables to stakeholder impact, supporting the value story through outcome metrics, and communicating the “why” and realized value to the organization.

    Sounds Great. What’s the Catch?

    Applying a platform as a product approach can be difficult in practice. For example, many organizations struggle to afford the internal developer platform the same considerations as they would an external product. When working with internal developers, it’s easy for platform teams to make assumptions about what those users know, want and need. However, platform engineering requires avoiding these assumptions and always seeking user perspectives.

    Another common pitfall organizations encounter is mandating platform adoption. Making the platform mandatory closes off the critical feedback loops platform teams need to gauge the success of their platform and make continuous improvements.

    Conclusion

    The platform as a product approach is what sets platform engineering apart from DevOps. It’s deceptively simple but important if you want to build an internal developer platform people actually want to use.

  • The Differences Between DevOps, DevSecOps and SRE

    The Differences Between DevOps, DevSecOps and SRE

    DevOps, DevSecOps and SRE are all quickly gaining traction within the tech world due to their effectiveness and promise of reliability for companies. Each framework provides various levels of safety and scalability—DevOps is agile, DevSecOps prioritizes security above all else and SRE focuses on performance optimization. Together, these are changing how software gets deployed from conception to production. We’ll break down each one in detail.

    What is DevOps?

    DevOps is a set of practices that combines software development and IT operations, which aims to shorten the software development life cycle (SDLC).

    DevOps bridges the gap between those two areas by bringing together different people–developers, operators, testers and system engineers–who are responsible for different parts of the software delivery process, from planning to deployment into production environments.

    A core tenet of DevOps is to automate manual processes within each stage of the SDLC, eliminating much of the redundant work that used to take weeks or even months. This automation significantly drives down costs, as well as reduces problems posed by human error when running manual tasks.

    The following are some of the core tenets of DevOps:

    1. Collaboration
    2. Quality and reliability
    3. Automation
    4. Scalability
    5. Security

    What is DevSecOps?

    DevSecOps (or DevOps security) is an emerging field within the DevOps practice that focuses on strengthening software security within the development and operations process.

    These three distinct groups often have different priorities when it comes to building software applications. Developers are focused on speed-to-market objectives from their employers or clients, operations focus on reliability and scalability, while security teams prioritize safety from malicious actors or data breaches. At the same time, with DevSecOps, these goals become united under one umbrella: Build fast and reliable applications with built-in protection against attacks.

    DevSecOps focuses on implementing security as code—or automating many routine tasks involved with identity management, like user authentication and authorization. To ensure that security is properly integrated into your DevOps pipelines, below are some key DevSecOps practices:

    1. Automate security processes whenever possible
    2. Encourage continuous testing
    3. Prioritize remediation over detection
    4. Create a culture around secure coding principles

    What is SRE?

    SRE stands for site reliability engineering. The basic idea behind SRE practices is that software engineers should be responsible for both the development as well as the reliability of their product as a whole. This means having an understanding of not only how users will interact with the application or service but also how it interacts with other services in its operating environment, such as databases, firewalls, cloud environments, etc.

    To maintain uptime while meeting these requirements, SRE applies various techniques like automation and continuous deployment processes to ensure high availability.

    A key goal of site reliability engineering is service-level objectives (SLOs), which measure how consistently a service meets its goals over a given period of time—such as how often it’s available, how quickly it responds to requests made by users or customers—and establishing goals around those SLOs. Achieving objectives like these helps organizations build customer trust in their products and services since it ensures that they have stable and reliable day-to-day operations.

    Here are some of the most important SRE principles:
    1. Automation
    2. Proactive monitoring
    3. Fault tolerance
    4. Measurement and analysis
    5. Service-level objectives (SLOs)

    DevOps Vs. DevSecOps Vs. SRE

    The differences between DevOps, DevSecOps and SRE can be summed up in three main areas: Scope, roles and objectives.

    DevOps focuses on improving the speed of releasing software by automating processes and optimizing collaboration between development and operations teams. This helps organizations create a continuous delivery pipeline to quickly deploy code into production with minimal risk. As such, it is typically focused on development or operations activities and has become synonymous with agile methodologies such as continuous integration/continuous delivery (CI/CD).

    DevSecOps expands upon these concepts to include security considerations from the very beginning of a project’s life cycle instead of tacking them on after the fact. By shifting security left in the process–meaning bringing security earlier into the design phase–teams are able to reduce risk early on while achieving faster results overall through continuous feedback loops.

    As part of this shift left process, DevSecOps practitioners focus heavily on automating security compliance activities as part of their job function rather than waiting until after deployment has occurred.

    Meanwhile, SRE focuses more broadly on keeping the user experience consistent across various products an organization offers by responding to customer needs quickly while creating automation processes that allow common tasks to be repeated without manual intervention from engineers or developers.

    Then there is also platform engineering, which is a closely related yet distinct discipline with its own unique responsibilities. While both DevOps and platform engineering involve automation and working with the infrastructure that supports software development, there are some key differences between them.

    Platform engineering can be defined as a practice that involves developing a standardized platform on which all applications will run. Platform engineers build the underlying infrastructure to support applications, including servers, databases, virtualization layers and networking components using standardized toolsets. An important task for this field is designing an application’s architecture in such a way that allows it to scale easily with increased demand or usage levels. Additionally, they create self-service tools that enable developers on their team to quickly spin up new environments without requiring outside assistance.

    Wrapping Up

    In conclusion, while all three approaches have similar goals–ensuring reliability, speeding up the software delivery process and securing user data–they do so using different strategies:

    ● DevOps favors automation.
    ● DevSecOps puts focus on proactive security measures.
    ● SRE prioritizes optimization, reliability and scalability.

    Each one can contribute significantly when appropriately implemented into any organization’s workflow, depending upon its own specific needs.

  • Why Multi-Cloud Cost Optimization is Harder Than it Looks

    Why Multi-Cloud Cost Optimization is Harder Than it Looks

    If your business is like most businesses that use the cloud today, you’ve gone multi-cloud. Nine out of 10 large companies have already adopted multiple clouds, and IT analysts expect that even more businesses will embrace multi-cloud architectures over the next several years. Now, the challenge facing those companies is how to optimize spending across multiple clouds. Many will find that, despite common narratives suggesting that cost savings are an inherent benefit of multi-cloud architectures, reducing spending when using multiple clouds can be a lot harder than it looks.

    This is, fortunately, a challenge that can be conquered easily enough. Keep reading for tips on updating your cloud cost optimization strategy to support multiple clouds.

    Multiple Clouds Don’t Guarantee Reduced Cloud Cost

    Before diving into strategies for reducing spending when using multiple clouds, let me dispel a common myth about the relationship between multi-cloud architectures and spending.

    Contrary to popular belief, using multiple clouds doesn’t guarantee that your business will spend less overall in the cloud, or even make it very easy to do so. Although advocates of multi-cloud strategies often promote the idea that using multiple clouds makes it simpler to find the most cost-effective cloud services because you have a larger menu of offerings to choose from, the reality is that cost-saving is not a common outcome of going multi-cloud.

    Sure, in theory, having multiple clouds does give you more opportunities to reduce costs. But in actuality, migrating workloads between clouds typically takes significant time and effort. Given that most mainstream cloud services–like VM hosting and object storage–have been commoditized to the point that there are rarely major pricing differences between them, few businesses are actually going to migrate workloads back and forth between clouds on a frequent basis in order to save a few dollars.

    To Reduce Multi-Cloud Spending, Focus on Cloud Provider Relationships, not Workloads

    That said, adopting a multi-cloud strategy does place you in a position to reduce overall spending–but it’s not because you can migrate workloads between clouds. It’s because you can leverage relationships with multiple cloud providers to negotiate pricing reductions.

    If your teams are actively using multiple clouds, you have a strong ability to negotiate enterprise pricing deals with the providers of each of those clouds. Each provider that you work with will be eager to earn as much of your business as possible, and if they know that your company is already also using a competitor’s platform, they’ll probably be more forthcoming with discounts in exchange for a commitment on your part to run more of your workloads on their cloud.

    How to Keep Multi-Cloud Cost-Efficient – but Also Flexible

    The caveat is that if you want to retain the flexibility that a multi-cloud architecture nominally provides, it’s important not to over-commit to any single cloud provider. If you do, you may find yourself locked into one cloud for certain workloads due to pricing discounts that you’ve negotiated for those workloads with that cloud provider.

    An effective approach for finding the right balance between pricing discounts and flexibility is to decide which percentage of your overall cloud spending you want to avoid tying to a particular cloud. For example, you might decide that it makes sense to commit 30% of your spending to one cloud provider and 30% to another in exchange for pricing discounts that negotiate with each provider. But the remaining 40% of your cloud spending won’t be linked to enterprise agreements with cloud providers, so you’ll be free to spend it in whichever cloud you like.

    Maintain Workload Portability to Minimize Multi-Cloud Spending

    As you work to optimize multi-cloud spending, strive to adopt portable workload technologies, like containers in place of ones that are harder to migrate between clouds, like VMs.

    This is important not just because portable technologies help to maximize the flexibility of your multi-cloud strategy, but also because they give you more leverage when negotiating with cloud providers. The providers realize that some types of workloads are harder to migrate than others, and they’re less likely to offer serious pricing discounts if they know it’s going to be very difficult for you to move your workloads to a competitor.

    But if you can say, “70% of what we deploy runs in Kubernetes and can migrate from your managed Kubernetes environment to your competitor’s offering next week,” you’re in a much stronger negotiating position.

    Conclusion

    In short, don’t assume that simply adopting a multi-cloud architecture will yield enormous cost savings just because you can easily move workloads from one cloud to another to take advantage of pricing differences. In most cases, you can’t.

    What you can do, however, is leverage your relationships with competing cloud providers to negotiate discounted enterprise pricing agreements. And the more portable your workloads are, the better able you’ll be to obtain serious cost savings while simultaneously enjoying the flexibility and agility that multi-cloud architectures stand to offer.

  • How Observability and Explainability Benefit the SDLC

    How Observability and Explainability Benefit the SDLC

    Software systems require continual modification to meet changing requirements, address errors, improve performance and enhance reliability. Yet, maintaining and modifying complex and distributed software systems as they change and grow can present challenges. When systems are designed with observability and explainability in mind, adapting, expanding and troubleshooting software becomes easier and more effective. Observability refers to the ability to discern and monitor software systems’ real-time behavior and performance. This allows developers to identify and fix issues before they become critical. Explainability articulates how and why the software system operates.

    Both observability and explainability can contribute to the health of the software development life cycle by improving visibility and transparency, helping developers better understand the system’s overall behavior, and allowing the easy identification of errors, all of which contribute to the software system’s overall stability.

    Overview and Benefits of Observability

    Observability combines data from various sources, including application performance management (APM) monitoring, infrastructure monitoring, distributed tracing, third-party integrations and machine-language data. The data is then structured and presented in an accessible way. The first step to building an observable workflow is to identify which metrics best measure the behavior and performance of a software system. This will vary based on the specifics of the system. As a software system operates, logs and traces keep track of activities, requests and responses. They can be used to find the causes of errors and performance bottlenecks. Application performance monitoring (APM), infrastructure logs, machine logs and application traces are just a few examples of logs and traces. These records provide the necessary data to create dashboards and visualizations, which can then be presented to organizational stakeholders.

    While observability is often compared to software monitoring, which generates data focusing on various metrics related to application performance, it differs from monitoring in several respects. Monitoring tracks raw data related to a few performance metrics. It provides information that is best used by the operations team. Observability uses a large amount of structured data to provide a more robust, accessible picture of the whole system, from front end to back end, that can be understood by employees throughout the organization—even those who do not work in development or lack a technical background entirely.

    Advantages of Explainability

    Explainability refers to transforming machine data into a clear articulation of how a software system works such that others outside the organization can understand it. This capability empowers developers and users alike by enabling them to understand what a software system does and how and why it does it, providing a deeper understanding of why errors occur and how to fix them. Presenting data in a visual format is often a vital part of explainability.

    Explainability is especially important in artificial intelligence (AI) and machine learning (ML) systems, where it constitutes a cornerstone of ethical AI development. Model tracing, which refers to monitoring an ML model as it executes to understand its decision-making process better, is a key component of explainability in ML.

    Best Practices and Common Issues With Observability and Explainability

    Before adding observability or explainability to the software development life cycle, it is important to revisit software life cycle best practices and examine what kind of data is being generated. Not all data is meaningful or useful in observability and explainability. Structuring and ordering data from logs and traces is time-consuming but vital to correctly analyze and draw conclusions from the data. For optimal results, it is important for traces to be appropriately tagged and named consistently according to conventions.

    Additionally, the tools used to implement observability and explainability can be complex. For organizations to achieve maximum benefits from these strategies, it’s important for employees to familiarize themselves with the tools and develop specialized knowledge and skills, which can take time. Finally, there are costs associated with implementing observability and explainability. On one hand, commercial software tools come with licensing costs, which can pose a barrier for small businesses. On the other hand, open source alternatives often do not perform well because they lack the funding and resources required to continuously update and enhance the software.

    Harnessing the Power of Observability and Explainability

    Observability and explainability have numerous benefits for organizations that use flexible, ever-changing and complex software systems. Any company interested in building smoother-functioning software applications stands to benefit. Though both observability and explainability require upfront investments of time and money, these investments pay off in the form of quicker and easier error correction, with resolution occurring in minutes rather than hours or days, and greater application stability. In customer-facing applications, this results in fewer crashes and a better experience for the user. Increased stability also makes it easier to scale applications without losing performance. As these benefits become more apparent, a significant number of companies will likely develop software solutions that are reliable, cost-effective and accessible. This will increase the adoption of observability and explainability, which will continue to influence the evolution of software systems.

  • DevOps Download: What to Know About Life in the Cloud(s)

    DevOps Download: What to Know About Life in the Cloud(s)

    According to the 2022 Flexera State of the Cloud Report, 89% of cloud customers now use multiple cloud hosting providers. Nearly nine out of 10 might sound high, but it tracks with the anecdotal evidence we’ve seen. For varied and good reasons, companies are spreading their usage across multiple hyperscalers rather than putting all their eggs in one basket.

    In this article, I’ll take a look at what life in the cloud(s) looks like today. Along the way, I’ll examine the value that companies and their DevOps teams can derive from this approach, the challenges to be aware of, use cases for making the multi-cloud move and more.

    What is Multi-Cloud?

    Multi-cloud is a type of cloud strategy approach where an organization uses computing services from at least two cloud providers to run their applications. Instead of a single-cloud stack, these environments include two or more public or private clouds, or a combination of both. With multi-cloud, you can have an application running on Google Cloud Platform (GCP), another in Amazon Web Services (AWS), and maybe one on premise for hard-to-move applications.

    There are three kinds of cloud setups. Single cloud is when workloads run solely on one environment. Hybrid cloud entails overlapping workloads across multiple clouds, such as operating the same programs on different providers for business continuity purposes. The final setup is planned multi-cloud, which disperses applications and usage across providers along specific lines, like having compute intensive applications with one provider and data analysis applications with another.

    Got a Preference?

    Make no mistake, using multiple cloud providers is more complex than a single host, but as its popularity shows, the benefits can carry more weight. Foremost, that’s because an organization gains the flexibility to create a best of all worlds situation, based on factors like the following:

    • Operational preference: Users may like different features from different providers, and splitting types of use can yield the ideal setup. For instance, a customer may run compute on AWS but want their business intelligence and machine learning on GCP. In this deployment, the front-end app could gather the needed information, then send the data to the other provider for analysis and ML.
    • Regulatory requirements: Certain workloads may require data storage in specific regions, but not all cloud vendors have multiple “regions” in each country. Companies that want to use the cloud can set up a “multi-region” environment by having one region on AWS and a second region on GCP within the same country.
    • Cost savings: Cloud providers offer different savings plans. For a savvy user, structuring a flexible program can take advantage of each to significantly reduce costs. It’s also a great way to avoid the pitfalls of lock-in and can make it easier to go elsewhere should a provider lose your trust.
    • Failsafe Options: Outages happen, so companies needing 24/7 access to apps will sometimes run portions redundantly on two hosts to ensure smooth operations. For example, a retail app may run on GCP and AWS with live failover between them. That way, if one goes down the other can kick in without noticeable downtime.

    Not Without its Challenges

    The benefits to running a multi-cloud setup are clear, but there are some challenges as well. A carefully planned multi-cloud setup can save money, but a careless approach will duplicate operations and cost. It also leaves companies vulnerable to mistakes that can lead to significant overrun, especially for hybrid cloud operations, which can be extremely complex. Specialists must be well versed in FinOps principles and experienced at writing modern applications that can scale and work across regions and clouds, to ensure success in a multicloud approach.

    Coming to Terms

    You’ll undoubtedly come across a lot of new ideas and terminology when researching cloud setups. Here’s a few of the more crucial ones to become familiar with as you plan strategy.

    • Lift and shift: This refers to cloud-to-cloud migration, in other words, taking what you have in one cloud and putting it in another, whether it is private to public or public to public.
    • Move and improve: This usually refers to migrating while making a small change to take advantage of a public cloud feature. For instance, you could be using open source Kubernetes on premise but want to move to a managed version. Eliminating management of Kubernetes would require a minor change but it improves operations greatly.
    • Cloudbursting: On premise offers hard limits to capacity. For companies able to anticipate business peaks, cloudbursting can scale workloads to an on-demand public cloud for a short period. For example, a retailer who operates on premise may cloudburst on Black Friday in order to handle a volume increase.
    • High Availability: The goal of this is to eliminate single points of failure by enabling users to continue working even if one of the IT components that an applications depends upon fails.
    • Disaster Recovery: Clouds offer solutions to help an organization restore critical systems and data after a disaster strikes. Recovery comes in three “heat levels”: Cold is for data backup only, warm restores operations in several hours, hot is for near-instant resumption of cloud operations.

    People and Processes

    The most important considerations for operationalizing multi-cloud are people and processes. Providers pump out new services fast, and not only can it be difficult for staff to keep up, it can be demoralizing when they’re unable to. Allowing time to succeed, fail and learn is key, and larger companies might consider designated specialists for each platform.

    When it comes to processes, management and security are highly customizable, but it requires deep knowledge to get them right. Operating via infrastructure as code rather than ClickOps is a must. The latter is a time consuming approach that requires selecting options in a provider menu and introduces both operational and security risks in the form of configuration drift.

    Life in the Clouds

    Multi-cloud brings strong benefits to DevOps. Organizations can get the right infrastructure balance based on their needs. Distributing workloads can reduce the impact of outages and bolster resiliency. There’s greater opportunity for cost savings, and scaling is simple. Ultimately, multi-cloud operational enhancements can result in more reliable and innovative solutions, which delivers on the mantra of DevOps itself.

  • DevOps Guide to the Salesforce Summer 2023 Release

    DevOps Guide to the Salesforce Summer 2023 Release

    The second installment of Salesforce’s 2023 releases provides some great eye candy for DevOps pros. From new admin features to user enhancements and the anticipated Flow updates, a lot is covered in the nearly 700-page Salesforce Summer ‘23 release. Let’s break down the highlights of some appealing features, why these updates will save all Salesforce users time and energy and explore key details of the impending transition to Flows.

    First, we’ll break down notable updates from this release that will save you time, help DevOps teams automate faster and enhance the experience for both you and your customers.

    User Enhancements

    There are lots of great adjustments to some tools we know you’ve been waiting for and some we hope will be made available to all users.

    ● Mass Quick Actions on Related Lists: This is a beta feature that you can opt-in to try. You can now add and update records directly from a related list—a time and tab saver! This feature has been requested many times and will decrease the need for custom-built interfaces. For instance, if you’re on an Account and want to edit the related Contacts, you can add, edit or mass update directly from the Account screen. This saves clicks and stops new tabs from opening and losing your spot, etc. Allowing users to update in bulk is a major win!

    ● Einstein Search: Advance your search capabilities by having additional field types to search within, such as picklist, which were not previously searchable. For example, if you have a picklist field on Contact, you can search for one of the values and any records with that selected value will appear. Users will get more relevant results in their search. This new enhancement is in beta, so we’d highly suggest opting in to give it a test drive.

    ● Lightning reports and dashboards improvements, including:

    Enhanced reports and dashboards with images and text descriptions let you add visualizations to your dashboards with company logos, helpful imagery or clarifying text. Explain exactly what the Dashboard is providing with helpful messaging or encourage the sales team with positive feedback about their work. This will not only better guide end users throughout the dashboard but will also increase engagement and personalization.

    Additional dashboard filters permitted: Dashboard filter allowance jumped from 3 to 5, making dashboards more configurable and customizable for different views and end users.

    A new ‘post to Slack’ option on dashboards: share analytics across your Slack workspaces so your colleagues can view, share, and subscribe to dashboard details and view in real-time.

    Note: While all of these improvements to reports and dashboards are amazing features, they are only available to unlimited edition users. We hope Salesforce will trickle this down to enterprise users soon.

    ● MFA auto-enablement continues: Unless you’re using a single sign-on (SSO) solution like Okta, Salesforce mandates the use of multifactor authentication (MFA). Hard enforcement is coming by spring 2024 when Salesforce initiates a full rollout, so we’d suggest getting ahead of it by implementing this now.

    Flows

    With the forthcoming transition to Flows, we find that the more Salesforce does with Flows, the better. In general, it gives users better tools to deliver to customers and offers better experiences overall. These Flow Builder updates are key:

    ● Send API callouts without using code (this is in beta). This is like having Postman-like capabilities right in Flow!

    ● Create screens that react to changes from other components on the same screen. This is huge, since you can’t create reactive screens in Flows right now. Workflow optimization is all about reducing clicks, which users can now achieve with reactive forms (this is also in beta).

    ● Log emails and use email templates with the ‘Send Email’ action. This was rigid before, as users had to pull in their own templates or make very basic emails in Flows. This is a basic but hugely helpful upgrade.

    Honorable Mentions

    • The new Undo field change feature: A lot of you have been waiting for this (ourselves included) since there is no such thing as “undo” in Salesforce … until now!
    • New Salesforce connect adapter for GraphQL: Developers and system architects will be happy to see this feature that allows you to access your external data by connecting to AWS Aurora via GraphQL queries from Salesforce as if the data were native. This saves you from having to copy and store your external data in Salesforce with complicated syncs.

    We’re all always hunting for ways to save time and simplify processes. Once again, Salesforce delivered with the Summer ‘23 release. Fewer clicks, bulk actions and more sharing and collaboration capabilities. And this one has a little bit of excitement for everyone–admins, developers and end users.

    The best thing you can do is to experiment with ways to optimize. There’s a lot in beta, so roll your sleeves up and dig in! Happy summer!

  • How New Tech Elevates Release Management’s Quality Standards

    How New Tech Elevates Release Management’s Quality Standards

    Release management is a critical discipline within software development and IT operations that focuses on the planning, scheduling, coordination and deployment of software releases. It includes the procedures, plans and methods employed to guarantee that software updates or items are sent to customers in a secure and effective way. Release management’s main objective is to make it possible for software releases to be delivered reliably and smoothly while causing as little disturbance as possible for the company and its users. This entails overseeing a release’s whole lifespan, from preliminary planning through testing, deployment and post-release support.

    Challenges in Traditional Release Management

    Traditional release management approaches often face several challenges that can hinder the efficient and effective delivery of software releases. These include manual and time-consuming processes, lack of visibility and traceability, complex and fragmented environments, limited collaboration and communication and a lack of effective communication channels and collaboration tools. Manual processes can be time-consuming, error-prone and lead to delays in release cycles. Lack of visibility and traceability can make it difficult to track the status of releases, identify bottlenecks and troubleshoot issues effectively. Fragmented environments can be complex and differ widely from one another, making managing and synchronizing these environments manually challenging and prone to errors.

    Limited collaboration and communication can lead to miscommunication, delays and misunderstandings. Traditional release management can lead to silos between development, operations and other stakeholders, hindering efficient coordination. Inconsistent release practices can lead to variations in processes, documentation and quality standards, making it difficult to establish a standardized and repeatable release process. Lack of automation and continuous integration can slow down the release process, increase the chances of human errors and inhibit the ability to deliver frequent, small and reliable releases. Limited scale and adaptability can be addressed by adopting new technology and modernizing release management practices. Automation, continuous integration, deployment pipelines, collaboration tools and standardized processes can help overcome these hurdles and enable more efficient, reliable and quality-driven release management.

    Benefits of New Technology in Release Management

    Advanced Testing Techniques for Improved Quality Assurance

    1. Enhanced speed and efficiency
    2. Improved interaction and collaboration
    3. Improved stability and quality of software
    4. Reduced risk and downtime

    Using New Technology: Implementation Techniques

    1. Organizational readiness assessment
    2. Choosing the correct technologies and tools
    3. Developing an all-inclusive release management strategy
    4. Embracing the DevOps and Agile principles

    The Impact of New Technology on Release Management Quality

    Automation: Accelerating Release Cycles and Ensuring Consistency

    Automation plays a pivotal role in release management by significantly accelerating release cycles. It reduces manual effort and expedites the delivery of software releases, leading to a faster time-to-market. Automated workflows enforce standardized practices, configurations and environments, resulting in more reliable and predictable releases. Automated testing frameworks and tools enable faster and more comprehensive testing, while continuous integration and automated build processes facilitate seamless integration of code changes. Automation also enables better visibility and traceability, allowing release management teams to track the progress of releases, identify bottlenecks and analyze performance metrics.

    Continuous Integration: Early Detection of Issues and Improved Collaboration

    Continuous integration has revolutionized software development practices by emphasizing early issue detection and enhanced collaboration. By regularly integrating their code, businesses can spot problems early and fix them, decreasing the possibility of significant issues later in the development cycle. Additionally, increased developer collaboration encourages better coordination, communication, and information sharing, which results in a more effective and unified development process.

    Organizations can profit from continuous integration by utilizing automated build processes, extensive test suites and a collaborative development environment. Early problem identification and enhanced teamwork not only lead to better software quality but also enable development teams to build applications more quickly and consistently. Organizations can achieve improved efficiency, productivity and success in the dynamic world of software development by adopting continuous integration as a core practice.

    The Role of Innovation in Breaking Barriers: Future Outlook and Trends

    Machine Learning and Artificial Intelligence in Release Management

    Release management is not an exception to the way that machine learning (ML) and artificial intelligence (AI) are transforming numerous sectors. Technologies based on machine learning and artificial intelligence (ML and AI) provide useful capabilities that can significantly improve release management procedures, increase effectiveness, and promote improved software quality. The function of ML and AI in release management is described in more detail below:

    Automated Testing and Quality Assurance:
    In release management, ML and AI may automate and enhance testing and quality assurance procedures. Intelligent algorithms can examine enormous amounts of data to find trends, anomalies and potential issues in brand-new software releases. To cut down on testing time and effort while maintaining high standards, ML models can be trained to anticipate and prioritize test cases. AI-driven testing solutions can also suggest the right test coverage and offer insights into the effects of code modifications.

    Predictive Analytics for Release Planning
    ML and AI approaches can be used to create prediction models for release planning using past release data, such as metrics, logs and performance statistics. These models are able to predict potential dangers, predict release dates, and allocate resources more efficiently. Release managers may prioritize important tasks, make data-driven decisions and improve the planning process for software releases by employing AI-driven insights.

    Anomaly Detection and Continuous Monitoring
    ML and AI algorithms can continuously monitor the production environment, analyzing real-time data to spot anomalies and potential problems. Release management teams can proactively identify and respond to performance bottlenecks, security breaches, and other key occurrences by putting in place sophisticated monitoring solutions. A faster and more reliable reaction to production issues can be achieved with the use of ML-powered anomaly detection, which can decrease the mean time to detect (MTTD) and mean time to resolve (MTTR).

    Impact Analysis and Risk Assessment for Releases
    ML and AI approaches can be used to evaluate the hazards that may be involved in a release. ML models can estimate the effect of a release on several areas like performance, stability and user experience by assessing historical data, code modifications, dependencies, and environmental factors. Release managers can prepare mitigation methods, make educated decisions, and reduce the likelihood of unforeseen problems throughout the release process thanks to these risk assessment skills.

    Intelligent Release Deployment and Rollback
    ML and AI technology can help with intelligently choosing when to deploy and roll back a release. In order to recommend deployment tactics, machine learning (ML) models can learn from previous deployment experiences, including success rates, user input and mistake patterns. In order to ensure a more dependable and error-resistant deployment process, AI algorithms can track the deployment process, evaluate the system’s health and initiate automated rollbacks if anomalies or severe concerns are discovered.

    In general, ML and AI provide valuable capabilities to release management, boosting testing and quality assurance, streamlining release planning, enabling continuous monitoring, analyzing release risks and simplifying wise deployment decisions. Utilizing these technologies enables businesses to improve software quality, streamline release management procedures, and deliver high-performing applications more effectively and reliably.

    Microservices Architecture and Cloud-Native Technologies
    With the advent of cloud-native technologies and the adoption of microservices architecture, release management has been transformed, enabling organizations to leverage the benefits of scalability, agility, and flexibility. Let’s explore how cloud-native technologies and microservices architecture enhance release management:

    Containerization and Orchestration
    Release management has a solid foundation thanks to cloud-native technologies like containerization (like Docker) and orchestration frameworks (like Kubernetes). Application components are encapsulated in containers, which makes them very portable and independent of the underlying infrastructure. Release management can use containerization to streamline application packaging and distribution while ensuring consistent application deployment across a variety of environments. Frameworks for orchestration allow for automated container deployment, scaling and administration, speeding up release management procedures.

    Scalability and Elasticity
    Applications can use cloud-native technologies’ inherent scalability and elasticity to dynamically modify resources in response to demand. The modular and independent services of the microservices architecture make granular scalability possible. Release management can use these features to scale individual services or components on their own, ensuring optimal resource usage and effective handling of increasing user loads. This adaptability reduces downtime and enhances the application’s general performance during releases.

    Fault Isolation and Resilience
    Failures in one service do not affect the entire system, thanks to the fault isolation and resilience that the microservices architecture fosters. Release management can use this resilience to lessen the impact of any potential issues during releases. It is possible to roll back or replace a specific service if it develops issues without affecting other services. Release management may efficiently manage errors, improve fault tolerance and maintain service availability during the release process by implementing cloud-native technologies and microservices.

    Observability and Monitoring
    The enhanced observability and monitoring capabilities made possible by cloud-native technology allow for release management. Platforms for container orchestration include integrated monitoring and logging capabilities that give information on the efficiency of an application’s use of resources and the state of the system overall. With the use of this information, release management teams can proactively monitor releases, spot abnormalities and quickly resolve problems. Observability and real-time monitoring support the release process by ensuring the dependability and stability of programs.

    Release management greatly benefits from cloud-native technologies and microservice architecture. Organizations can improve their dependability, achieve faster and more frequent releases, achieve scalability, fault isolation, and observability, and produce high-quality software applications by leveraging containerization, orchestration, CI/CD methods and many other technologies. Organizations are better equipped to manage complex release cycles and adjust to the changing needs of the software industry when they adopt these cutting-edge methods.

    Conclusion

    In this article, we have explored new technology’s role in raising the bar for release management quality standards. Organizations may increase communication, optimize processes, and more quickly produce high-quality software by adopting automation, continuous integration and DevOps approaches. The advantages and revolutionary potential of new technology in release management are apparent, notwithstanding the risks and difficulties that may arise. Organizations may promote continuous improvement, adjust to market demands and succeed in today’s changing business environment by tearing down barriers and embracing innovation.

  • 4 Things Engineering Leaders are Thinking About Right Now

    4 Things Engineering Leaders are Thinking About Right Now

    Spiderman and engineering leaders have something in common: They both have great power and great responsibility. Engineering leadership is more critical than ever, with more than 4.4 million software developers in the United States building our experiences daily.

    Leaders do more than just manage the day-to-day. They are called to influence, empower and motivate their teams. For engineering leaders, this means grappling with new challenges and opportunities as the technology landscape changes and evolves. This shift impacts how humans work, where we work, what our work looks like and how we need to be supported and seen in our roles across the board.

    Let’s dive into four challenges and opportunities that engineering leaders face and how they shape the future of software engineering.

    Communication in Remote & Hybrid Work

    It has been over three years since the way that we work shifted dramatically. Choosing the right fit between remote, hybrid and in-office is a challenge that companies across industries are still wrestling with. The hardest part? Communication.

    There’s no doubt that the flexibility of remote work is beneficial for workers’ mental health. The 2022 State of Remote Engineering Report found that developers reported better work-life balance (64%) and less stress (48%) from working remotely. However, they also reported that collaboration and inclusion took much more effort. Although flexibility is good for mental health, it may hinder spontaneous interactions. And although in-office work fosters face-to-face collaboration, it may limit geographical diversity. Striking a balance is top of mind.

    No matter what the office structure is, engineering leaders must establish clear communication channels, guidelines and regular check-ins with their teams. Engineering metrics are a great way to identify and address the wins, challenges, solutions and bottlenecks. They help leaders foster an environment that encourages collaboration, cross-functional teamwork, and knowledge sharing through regular team meetings, brainstorming sessions and collaborative projects to promote engagement and a sense of collective ownership no matter where teams and team members work.

    Generative AI

    Generative AI is top-of-mind for the whole world right now. It’s an exciting and potentially stressful time for engineering leaders to consider how generative AI may reshape the way we work. While there is a fear of AI replacing human roles, a more positive (and realistic) way to look at AI is by asking: What will this revolutionize, evolve, and enhance and what are the risks?

    Developers are thinking primarily about the emergence of large language models (LLMs) for code creation. Leaders should consider how AI can integrate into workflows to increase development speed, accuracy and efficiency. This is also an opportunity to enhance and leverage AI for tedious tasks so developers can focus on creative projects.

    Leaders must also consider the risks of generative AI. AI simply cannot replicate the complexity of the human experience, which will call for a layered approach to integrating AI into engineering teams. It also begs the question: What responsibilities do engineers have when working with AI? The benefits of streamlining, speed and accuracy may also alter what quality control and testing look like. It’s an exciting time for engineering leaders to embrace the future of work mindfully and strategically.

    Meaningful Metrics and Outcomes

    Engineering metrics are vital for measuring impact and outcomes to drive progress and inform decision-making. Engineering leaders must carefully evaluate and select metrics that align with their team’s objectives and adapt measurement practices accordingly. DevOps Research and Assessment (DORA) metrics are popular, serving as a jumping-off point for engineering leaders. When leaders carefully evaluate DORA metrics as applied to their team’s specific objectives and complement them with other relevant metrics, they can ensure that they capture the desired outcomes and provide a complete picture of engineering health to drive meaningful purpose.

    The added pressure to deliver results while upholding developer morale and efficiency underscores the significance of choosing appropriate evaluation methods that capture the desired outcomes. But most importantly, leaders need to consider what metric visibility means and how best to offer support.

    Fostering Engineering Team Health

    Besides technical aspects, engineering leaders are increasingly concerned about the health and well-being of their teams. Balancing meetings, focused work time and creating a positive work environment are vital factors that contribute to developer health and productivity. Engineering leaders should consider the individuals and team when encouraging breaks, time off and flexible working hours to prevent burnout and promote overall well-being. Some teams have implemented “No Meeting Wednesdays” and similar strategies to provide dedicated time for deep work and to minimize interruptions.

    Leaders should be focused on creating a culture that prioritizes psychological safety where team members feel comfortable expressing their ideas, concerns and feedback without fear of judgment or reprisal. In this fast-paced world, a leader must remember to be human first and encourage open communication, active listening and empathy within the team. Prioritizing collaboration, work-life balance and a healthy team dynamic is critical for engineering leaders aiming to foster long-term success.

    Engineering Leaders Have Great Responsibility

    Engineering leaders are at the forefront of shaping the future of software engineering. Balancing communication in remote and hybrid work environments, leveraging the potential of generative AI, choosing meaningful metrics and outcomes and fostering team health and well-being are critical areas they must address. By embracing these challenges and opportunities head-on, engineering leaders have the power to drive success and create thriving, innovative teams. So, let’s step up to the plate, embrace the evolving landscape of software engineering, and lead with purpose, empathy and strategic vision. Together, we have the power to shape a brighter future for the world of technology. With great responsibility comes great opportunity. Are you ready to don your leadership cape and web-sling your way to success?

  • Automation in DevOps: Advancements, Platforms and Examples

    Automation in DevOps: Advancements, Platforms and Examples

    Automation is the backbone of DevOps. By facilitating seamless integration and continuous delivery, it revolutionizes the ways organizations deliver software, products and services. When applied correctly, automation can significantly enhance productivity, reduce time-to-market, improve software quality and minimize the risk of human error.

    A range of automation tools support these goals, each tailored to a specific aspect of the software development life cycle (SDLC).

    From code integration to testing and deployment, these tools optimize processes and enable the rapid and reliable release of software. In this article, we will explore the role of automation in the DevOps landscape.

    The Importance of Automation in DevOps

    Automation in DevOps is the process of designing, developing and deploying software and systems with minimal human intervention. The goal is to streamline the software development life cycle from design, development and testing to deployment and management.

    Automation provides several benefits:

    1. Speed and efficiency: Automation enables quick development and deployment of software, which results in faster delivery of features and fixes to customers.
    2. Reliability: Automated systems are less prone to human error, resulting in more reliable code deployment and management.
    3. Consistency: Automation guarantees that routine tasks are performed the same way every time, ensuring consistent results.
    4. Reduced cost: Automation eliminates the need for manual intervention in routine tasks, leading to a reduction in operating costs.
    5. Increased productivity: By taking over routine tasks, automation frees up the team to focus on more critical, high-level tasks.

    Automation in DevOps: An Overview

    Automation in DevOps encapsulates various stages, from development and testing to integration, deployment, and monitoring. The process is often referred to as a DevOps pipeline, a set of practices aimed at reducing development times and improving software quality.

    ● Development: Automation begins at the development phase with tools for source control (like Git), which help developers manage and track code changes.
    ● Integration: The next step is continuous integration, where tools like Jenkins automate the build process, allowing teams to identify issues early in the development life cycle.
    ● Testing: Automated testing tools (like Selenium) streamline the testing process, ensuring that the code is error-free and ready for deployment.
    ● Deployment: Continuous deployment tools (like Kubernetes) automate the deployment process, providing fast, consistent and repeatable deployments.
    ● Documenting: Technical documentation is automated with tools like Scriversi to ensure updated, error-free documentation through each version and release.
    ● Monitoring: Finally, automated monitoring tools (like Prometheus) offer real-time insights into the application’s performance, facilitating proactive troubleshooting.

    Automation’s main objective is to minimize manual intervention, thus reducing the risk of errors, improving efficiency and fostering a culture of shared responsibility.

    Examples of Automation in DevOps

    1. Continuous Integration/Continuous Deployment (CI/CD): CI/CD is a critical element of DevOps automation. With CI, developers merge their changes back to the main branch as often as possible. The CI/CD server automatically builds and tests every change. For example, Jenkins, a popular open source automation server, allows developers to automate various stages of their build pipeline.

    2. Infrastructure-as-Code (IaC): This practice involves managing and provisioning computing infrastructure with machine-readable script files rather than physical hardware configuration or interactive configuration tools. For instance, Terraform, an open source IaC software tool, provides a consistent CLI workflow to manage hundreds of cloud services.

    3. Configuration Management: This is the process of maintaining a system’s configuration in a known, consistent state. For example, Ansible, a configuration management tool, helps to automate software provisioning, configuration management and application deployment.

    4. Monitoring and Logging: Automated monitoring and logging systems gather data on how software and hardware are performing and alert the team to any problems. One example is Prometheus, a popular open source monitoring and alerting toolkit.

    5. Technical Documentation: Proper documentation is crucial in the software development process. Yet, it is often overlooked or not updated frequently due to time constraints or the tedious nature of the work. When automated, it simplifies and automates the process of creating and maintaining technical documents.

    Final Thoughts

    In the world of DevOps, automation is not a luxury but a necessity. By automating repetitive and error-prone tasks, teams can focus on what they do best: creating innovative solutions that meet customer needs. From CI/CD, IaC and configuration management to monitoring and logging, automation simplifies the software development process, reduces human error and enhances speed and efficiency. Tools like Jenkins, Terraform, Ansible, Prometheus and Scriversi support this trend, providing various automation capabilities that make the DevOps approach more efficient and effective.

  • Breaking Boundaries: Integrating Generative AI for Developers

    Breaking Boundaries: Integrating Generative AI for Developers

    Many organizations are experiencing deficits in technical skills and gaps in productivity that ultimately harm their bottom line. To overcome those obstacles and drive growth, businesses can use generative AI tools like ChatGPT and Bard to handle large volumes of data and increase the speed and output of basic tasks without draining valuable human capital. Already, businesses are finding that saving time is one of the most valuable benefits generative AI can deliver. However, there must be oversight of deployments to avoid recurring pitfalls, as the technology contains just as much risk as it does opportunity.

    Generative AI provides developers with helpful task automation while simultaneously creating new challenges. Security, bias and IP questions have DevOps teams scratching their heads at how to best ethically and operationally implement generative AI. Developers must embrace these challenges to remain competitive in an increasingly automated and technologically-driven world.

    Maintaining Confidentiality of Company Code

    Generative AI’s ability to understand and solve code-related issues makes it an ideal tool to help software developers optimize code for faster feature development and quicker releases. By identifying where it can contribute to tasks, like legacy code conversion or automation of processes, companies can free up valuable developer time for building the tools that can grow the business or drive new initiatives. An added benefit is that development teams can automate the coding of new applications or systems by updating old code or re-using existing examples.

    ChatGPT, for example, can also turbocharge development time by scouring swathes of information on GitHub and other forums to find examples of whatever a coder is trying to build. A 2022 study published in the Proceedings of the Association for Computing Machinery on Programming Languages (PACMPL) found that developers could code faster and work more efficiently thanks to generative AI. Tedious searches in tech forums and manual copy-and-paste procedures are replaced by simply asking the right questions (via prompts).

    However, generative AI tools are not closed systems. As users enter data into ChatGPT, it is saved and aggregated to continuously train the language model, opening the door for potential leaks of sensitive company information. There is a serious, potential risk of employees using AI tools as sensitive data already makes up 11% of what employees paste into ChatGPT.

    As a third-party system, AI tools absorb every query, comment and question without any privacy guardrails for users. If an AI bot’s security is compromised, businesses can unintentionally hand over data to bad actors. Even without a hacker’s involvement, sharing confidential customer or partner information may violate contractual agreements and create long legal battles. Developer teams must remain conscious of AI’s security risks.

    Avoiding Bias Creeping Into Results

    It is of utmost importance that businesses make reliable, fair and traceable decisions based on the latest facts. Currently, ChatGPT-4 hasn’t reached the maturity level necessary to be trusted by most companies without significant verification measures. Already, testers have persuaded ChatGPT to make statements that are either inaccurate, biased or both.

    One key concern in generative AI is the ingrained and accidental bias in answers due to the human-generated content used to train large language models. ChatGPT works by searching for textual content relating to the question and recombining it for a distillation. In an almost democratic way, the majority opinion will dominate. For instance, if most people believe that the Swedish are hard drinkers, ChatGPT will say so. While the technology provides remarkably accurate responses in an alarmingly convincing way, it’s important to remember that it’s not always the most reliable or balanced source that wins.

    Furthermore, OpenAI, the creator of ChatGPT, has explicitly stated that its goal is to create a system where queries can be pre-processed before they are fed to the neural net. Answers can then be post-processed before being shown to users. But this safeguard lacks clarity around its objectives and opens the door for ideological or political manipulation.

    Companies considering implementing AI tools must carefully examine their potential applications to ensure they avoid scenarios where bias can result in insights and output that could end up harming the company and its reputation.

    Minimizing Developer Function

    Enterprises are looking for tools to integrate generative AI into existing business processes to enhance numerous functions and deliver greater value to their customers. While the technology still isn’t capable of replacing human developers responsible for updating and maintaining largescale software, updates to generative AI tools and integrations are occurring at a rapid pace, leaving businesses to determine which programs are most viable for developer function.

    As the economy continues to tumble closer to a recession, companies seek ways to minimize costs. And those looking to use generative AI to work with the source code and technical documentation the company uses to run its own operations—rather than the open source code tools like ChatGPT provide—face budgetary decisions. Implementing generative AI programs into the business model can be extremely costly if done wrong, leaving executives to weigh the benefits of adopting the tech versus the cost of trying to hire a full team of developers.

    Connecting the Enterprise to Avoid AI Pitfalls

    For businesses looking to build the connected experiences their employees, partners and customers desire, generative AI is a great resource to accomplish this. However, it’s just one piece of the puzzle that is a modern enterprise. These tools can only deliver smart answers if they get smart questions and businesses connect their internal processes and applications to enable machine learning on accurate and holistic datasets.

    Although AI poses many benefits for developers, such as increased efficiency, accuracy and the ability to handle large amounts of data, they must be wary of the potential security, ethical and budgetary concerns that impact employees, customers and the enterprise as a whole.

    However, once the concerns are overcome or managed, the power of large language models will be leveraged in all kinds of technology and business use cases. Certainly a truly transformational shift and a step change towards a world where technology and software play an unprecedented role in business and society.