staging-devopsy.kinsta.cloud

Tag: devops

  • How Platform Engineering Makes Software Sustainable

    How Platform Engineering Makes Software Sustainable

    The world is constantly becoming more and more aware of the importance of sustainability in every aspect of our daily lives from buying groceries to traveling, and the IT world is no exception. Indeed, sustainability is already gaining importance in software development. For example, in the latest version of Thoughtworks’ Technology Radar, “carbon efficiency as an architectural characteristic” is one of the new techniques of interest. Moreover, in its research “Predicts 2023: Environmental Sustainability Is Now an IT Sourcing Imperative,” Gartner states that “by 2026, 75% of organizations will increase business with IT vendors that have demonstrable sustainability goals and timelines, and will seek to replace vendors that do not.”

    This shows that there is a growing need for sustainability. How is the software development industry responding to this need? Many great initiatives are arising, but platform engineering, in particular, helps make software more sustainable.

    What is Platform Engineering?

    According to Gartner’s definition, platform engineering is “the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management.” This trend has gained momentum in the last few years, and an increasing number of organizations are adopting internal developer platforms (IDPs) to scale their development process. IDPs allow developers to self-service the technology they need, whether it is infrastructure, runtime resources or ready-to-use services. This helps speed up the development process and ensures higher-quality software.

    Platform engineering is becoming more and more popular and foundational. According to Gartner, “by 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery.” Therefore, given the expected widespread adoption of IDPs in the next few years, sustainability emerges as a requirement. Ignoring or underestimating the importance of sustainability may cause organizations to waste all the benefits ensured by an internal developer platform.

    Platform Engineering for Economically Sustainable Software

    To survive and operate properly in the market, a company has to be economically sustainable and therefore stable. Usually, software is an asset that contributes to revenue generation for the company, but it still has maintenance costs. To make software economically sustainable, the total cost of ownership (TCO) needs to be lower than the generated income.

    An internal developer platform can lower software product costs, making them more sustainable. How so? In a nutshell, by sharing resources that can serve multiple products and can be reused across multiple projects. Such resources include, but are not limited to, capabilities, processes, infrastructure, configuration, etc. Since the platform at scale manages shared capabilities, there product teams won’t waste time and effort replicating it every time. While lowering the TCO, this characteristic of platforms also contributes to reducing the software’s time to market.

    Moreover, platform costs are shared across the whole organization and are not part of the TCO of each software product. This helps software to be more sustainable from an economic point of view.

    Platform Engineering for Environmentally Sustainable Software

    When talking about sustainability, most people usually think about the environment. While respecting the environment is one of the most important factors, it is important to note that sustainability is not limited to this aspect.

    An internal developer platform can help software be more sustainable on two levels.

    • Observability: The platform should collect and easily expose metrics on the environmental impact of the software. Such metrics can include hardware resource usage, energy consumption and CO2 footprint.
    • Optimization: The platform should foster the adoption of sustainable patterns, like the ones provided by the Green Software Foundation. It should also include solutions that actively help reduce energy consumption, such as kube-green.

    It is important that both of these capabilities are present and implemented in the platform. Observability without optimization is useless, and optimization without observability cannot be done.

    Platform Engineering for Socially Sustainable Software

    When speaking about sustainability, social responsibility cannot be forgotten. The first social responsibility of each organization is toward its members and employees. Does developer self-service also have social implications? Yes, it does; mainly by improving the developer experience.

    Indeed, an internal developer platform helps organizations’ members to:

    • Reduce friction between teams: Since everyone can have everything they need right when they need it, there will no longer be bottlenecks and misunderstandings between different teams. This contributes to a better working environment where everyone feels welcome and more productive.
    • Decrease repetitive tasks and cognitive load for developers: Since the platform will manage and automate interactions with infrastructure and runtime, developers will no longer need to waste time and energy on such out-of-scope secondary tasks. This way, developers are more focused on their actual job of developing new features and they will feel more satisfied.
    • Enable work from anywhere at anytime: Since the platform can provide all technology and capabilities whenever a developer needs them, it will no longer be required that people work together in the same location and at the same time. In other words, IDPs enable remote and asynchronous ways of working. This allows organizations to offer remote working and to create distributed teams, ensuring a better work-life balance for the team members.

    All of this brings happier employees that will be more productive and satisfied with their work, which will reduce turnover.

    Conclusion

    The need for a more sustainable world is gaining momentum and involves every industry, including software development. No wonder Gartner included sustainable technology in the “Top 10 Strategic Technology Trends for 2023,” along with platform engineering. As platform engineering is being adopted by more and more organizations to accelerate software development, sustainability has to be addressed.

    An internal developer platform can help developers build more sustainable software. Platform engineering can help in all of these aspects, improving not only the developer experience but also the organization and the environment. This is just the beginning of the sustainable path platforms should follow, but the outlook is very encouraging.

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

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

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

    An Introduction to Monitoring-as-Code

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

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

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

    The Benefits That Make MaC a Must for DevOps Teams

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

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

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

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

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

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

    The Future of Testing and Monitoring

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

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    staging-devopsy.kinsta.cloud 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 tends to create an opportunity for others.

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

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

    Monster.com

    SnapLogic
    San Mateo, California
    Infrastructure Engineer
    $183,310

    LinkedIn

    Metropolitan Transit Authority – NYC
    New York, New York
    Cybersecurity Officer – DevSecOp/Cloud Infrastructure
    $144,500 to $191,000

    Dice.com

    Flexion
    Remote
    Azure DevOps Engineer
    $140,000 to $170,000

    Indeed.com

    Woven Teams
    Remote
    DevOps Engineer
    $116,000 to $147,000

    SimplyHired.com

    Raytheon Missile and Defense
    Schriever Air Force Base, Colorado
    Senior Software Engineer
    $75,000 to $161,000

  • Creating a Growth Loop for Your Open Source Project

    Creating a Growth Loop for Your Open Source Project

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

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

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

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

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

    Be Visible in the Open Source Community

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

    Give Developers What They Need

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

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

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

    Make Sharing Incredibly Easy

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

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

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

    Create Amazing How-Tos and Tutorials.

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

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

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

    Contribute to Other Open Source Projects

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

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

  • Database Virtualization – Driving the Next Big Transformation

    Database Virtualization – Driving the Next Big Transformation

    Data is both the most important asset and the biggest challenge for most corporations. It impacts every aspect of the business from financial considerations to AI/ML training. Data is used by development and DevOps teams, engineering teams, quality assurance, business intelligence teams and database administrators. Despite its central role in operations, traditional forms of database delivery remain complex, costly and time-consuming.

    In many cases, enterprise data is growing exponentially, increasing management challenges and driving up the cost of data storage. Duplicating data to each new environment as use cases arise is overwhelming DBA teams and incurring a significant storage footprint. This has resulted in data becoming a significant bottleneck for DevOps teams, highlighting the importance of finding a quick and automated solution for the replication process across non-production environments.

    What’s Changed?

    In the past, development teams would work with the same dataset for upwards of six months. This left DBA teams with plenty of time to meet all database delivery needs. However, as technology became more sophisticated and consumers grew more demanding, the data delivery life cycle was cut down dramatically. Today, with agile development, new features may be added every few days, if not hours. Coupled with QA teams’ requirement for testing data continuously, AI/ML teams requiring millions of data points for accurate training, and data analysts constantly needing fresh data for organizational growth, this means DBA teams are flooded with demands they are incapable of managing.

    What Now?

    Database virtualization is an automated and easy solution to the dataset bottleneck. By simplifying the creation and distribution of database replicas, DevOps teams will be able to create fully functioning virtual environments via a self-service process–allowing DBA teams to focus on more critical duties relating to production databases.

    Speed Up

    The first—and most obvious—advantage of this approach is the increased speed at which data is delivered. To keep DevOps teams productive and avoid the use of old, stale data, new environments need to be produced on demand. By integrating the production of new environments into the CI/CD pipeline, enterprises will be able to automate the process and provide DevOps teams with full autonomy. By cutting out the dependency on the DBA, teams will be able to access the data they need, when they need it.

    Scale

    Agility is fundamental to the success of database management. Each team requires an independent environment, unaffected by other use cases. The creation and supply of virtual databases allow for quick provisioning. Once created, these databases look identical to the original physical database and function completely independently of each other. Any changes made to a vDB remain unique to the environment it’s in.

    Save

    As the need for data grows, so does the cost of storage. Creating a physical copy for each team and use case results in a significant storage footprint. This means that these datasets come with a hefty cost. However, the creation of virtual databases led to a dramatic decrease in storage needs. Where traditionally, physical datasets can weigh upward of several TB, vDBs only weigh a few hundred megabytes. Further, virtualization solutions also compress the weight of physical copies – such as the golden copy – actively decreasing the weight and cost of storage across all fields.

    Secure the Database

    Even after the database delivery problem has been solved, enterprises are faced with another major issue – security. With so many different teams accessing data in virtual and low-level testing environments, the risk of ransomware and other cyberattacks increases dramatically. Generally, the investment in securing non-production environments is significantly weaker than in production.

    A common approach to address this issue is masking sensitive data so it is rendered useless to outside sources. However, traditional masking requires a data expert to manually sift through all existing data and implement data masking algorithms on any sensitive information found. This time-consuming solution creates a new data bottleneck. By automating the process and applying it to the golden copy, corporations can be confident that all vDBs created are completely secure and privacy compliant.

    Looking Ahead

    Database virtualization is the future of database replica management. Virtual databases are delivered in a matter of minutes, significantly accelerating the speed of delivery. These environments are easy to use, independent, and can be maintained via a self-service portal. The ongoing sync between the original database and the vDB ensures continuous access to the latest data without the need for timely or expensive processes.

    Effective database virtualization will allow well-established enterprises to more easily compete against those agile startups that face significantly fewer barriers to entry.

    Image Source: joshua-sortino-LqKhnDzSF-8-unsplash

  • The Business Case for DevOps Culture

    The Business Case for DevOps Culture

    Culture is nebulous. It encompasses all the behaviors and attitudes of an organization, from overarching business values down to the individual actions of an employee. Because culture is transient, it’s unique to every business, feels difficult to change and is even harder to measure. This can make it frustrating to see DevOps research continuously name ‘culture’ as the critical factor for DevOps success.

    Many teams are left wondering what a ‘successful’ culture looks like and struggle to pinpoint what changes they should make. While there isn’t a one-size-fits-all approach to cultural transformation since every business is different, there are three key traits of high-performing DevOps teams: Buy-in to the DevOps process, collaboration and continuous improvement.

    But even once you’ve identified how your team can embody these traits, it can still be difficult to put forward a case for improving culture when it’s so difficult to measure its returns. By linking each of these traits to measurable impacts on the wider business, it’s possible to make a strong business case for improving your DevOps culture.

    Buy-In Makes Your Business More Resilient

    No organization can foster a successful DevOps culture without buy-in from the whole team. Buy-in not only encompasses an understanding and acceptance of the DevOps process but is also a commitment to getting it right.

    Without cultural buy-in to the DevOps process, team members are more likely to circumvent established procedures. Following a DevOps process should overcome unnecessary downtime and failed releases, but neglecting the proper release management strategy will stop your team from seeing these improvements and hinder your ROI.

    Team buy-in to DevOps makes your release process far more resilient. With a common appreciation of and investment in DevOps, teams are far more likely to follow the planned and robust process. This attitude allows businesses to see far higher ROI. For example, Veolia, the energy and utilities giant, secured a 500% return on their DevOps investment within one year of buy-in to a new approach. Team buy-in is the first step you need to take in improving your DevOps culture—it’ll ensure the technical resilience of your processes necessary to secure ROI.

    Collaboration Makes Your Business More Efficient

    DevOps doesn’t just encourage collaboration between Dev and Ops teams—it encourages all team members to work together across functions and share responsibility.

    When only one team member has the expertise or responsibility required to move through a stage in your DevOps process, there’s a single point of failure. If this team member doesn’t have the capacity to unblock others, then the process is slowed and time is wasted. Collaboration and knowledge-sharing can overcome this bottleneck by empowering team members to handle a greater scope of the process. This avoids the significant costs that come with increased labor and missed opportunities by removing the pressure on individuals and drastically increasing the efficiency of the whole system. You’ll see an accelerated project delivery, which will be faster in getting value to your end users and see quicker ROI.

    Further, collaboration across the entire release process encourages all team members to remain mindful of compliance, which ensures you’re practicing DevSecOps at each stage of your release. Rather than handing development over to the dedicated compliance team once it’s complete, shared responsibility ensures that it’s baked into the DevOps process, saving time that could be needlessly spent at the end of development reworking to meet compliance stands. In the 2022 State of Salesforce DevOps Report, teams who self-reported as ‘excellent collaborators’ managed to avoid data and metadata loss in that year’s DevOps process, whereas only 25% of very poor collaborators could say the same. Excellent collaborators were much faster to restore when needed and significantly more likely to state that backups were their responsibility.

    To sum up, collaborative development teams are better at supporting the business growth needed to draw in customers. You’ll be able to sustain this growth, as efficient and secure releases will improve customer retention.

    Continuous Improvement for Your Team and Business

    Many teams only think about digital transformation when their process begins to fail, meaning the necessary changes require a disruptive overhaul of their whole system. Teams that nurture a culture of continuous improvement will make incremental improvements to their system, which avoids drastic ad-hoc changes and ensures the business will see continual value from gradual tweaks.

    It’s difficult to identify a singular ‘best DevOps system,’ as best practices are constantly shifting, but it is easy to realize that something could work better. Teams that reflect on their own systems and keep abreast of the latest tech trends can continually implement process improvements that amount to significant adjustments in the long term. This ongoing optimization of the DevOps process means no stasis and no need for disruptive and costly upgrades every few years.

    Developing your own team members not only creates a better DevOps process but also empowers team members to fill knowledge gaps, lessening the need for costly expert hiring or consultancy. Further, hiring and onboarding is a huge cost, which can be reduced by the morale and retention boost that comes with upskilling and collaboration. This will be critical as companies look at hiring freezes in the upcoming recession.

    Proving that small behavioral shifts can help maximize DevOps ROI will strengthen your business case for DevOps culture and create an agile team that can adapt as the landscape changes. Eventually, your DevOps ROI will become synonymous with your culture.

  • Salesforce Spring 2023 Release: Out With the Old, A Lot of the New

    Salesforce Spring 2023 Release: Out With the Old, A Lot of the New

    Salesforce is the connector and enabler of so many critical business functions. But that doesn’t mean it doesn’t come with its headaches. The environment is so complex that it really takes a conscious, focused effort to properly leverage all that Salesforce has to offer, as well as stay up-to-speed on everything that’s new and evolving.

    The Salesforce spring ‘23 release brought a lot of change. Some old tools disappeared and new products, dashboards and automation tools were introduced that admins will have to adapt to. There’s a lot to catch up on.

    Combing through the 600+ pages of release notes, there are three main themes represented in the spring release that will be useful to the entire organization, from DevOps and RevOps to sales and marketing teams, including: 1) new admin and developer tools and dashboards, 2) doubling down on low-code/no-code with enhancement to Flow and 3) commitment to security and permissions best practices.

    Admin and Developer Updates

    From an administrator’s and developer’s perspective, there are some exciting new features that will undoubtedly improve DevOps’ day-to-day. For instance:

    • Flows – allows you to migrate your old automations.
      • Connect to external data source (beta)
      • Support for lookup fields
      • Reactive screens (reduce the number of “Next” clicks)
      • Removal of “Iteration Limit Exceeded” governor limits
      • Element descriptions are now visible on the canvas
      • Migrate to Flow from Process Builder

    • DevOps Center – Still in V1, but it provides developers with a new interface.
      • Getting on the software development life cycle bandwagon so we can all say goodbye to change sets – finally!
    • Dashboards – Now you can insert text and graphics around charts.
      • Collections – organize reports and dashboard into logical collections that are free from their folder hierarchy. While they will still “live” in their folders, they can be accessed from a collection as well.
      • Add image and text components in your Dashboard to make better experiences with additional information, descriptions, instructions or whatever you want.

    These updates are not only useful for DevOps but, from an executive viewpoint, are extremely useful to showcase the business’s data with a clearer perspective. In other words, the new dashboards have more options to provide additional context and insight. In general, the user interface is not only more organized but can be navigated at a significantly faster rate than before.

    Doubling Down on Flow

    As the old adage goes, “Out with the old, in with the new;” Salesforce will be retiring the automation tools Workflows and Process Builders and converting them to Flow. The reason Salesforce is making this move—and ultimately forcing users to Flow—is because Workflows and Process Builders don’t have the flexibility or functionality that Flow does. Flow can create automation and provide great screen experiences that derive a far greater bandwidth of context and situational logic. The additions made to this much-anticipated migration tool will help administrators convert their current automation into Flow with less stress and hassle than rebuilding them all from scratch.

    So what is the timeline for this migration? Salesforce plans on blocking the ability to create new Process Builders in the Summer ‘23 release but has admitted that it’s not a hard date and will look at the success of customers’ migrations to Flow and feedback from the community. They have not yet announced a date for complete retirement but expect it to come sometime in 2025. That said, users should start doing this now. With any major change to your Salesforce environment, a plan is always recommended, especially with such a huge migration like this one. Given the amount of data and processes most organizations already have in place, we suggest taking time to strategize and test your migration prior to releasing it directly to Flow to make sure your order of operations for your automation is clear and follows best practices. Analyze your business processes and confirm with your users that these processes are still accurate.

    Commitment to Security

    As organizations lean more on Salesforce as their primary business operating system, Salesforce is becoming a critical piece of infrastructure rather than just software that businesses consume. It is also the “build-and-develop” nature of Salesforce that has more companies treating Salesforce as software they build rather than just software they use. The ripple effect is that as companies build within Salesforce, more developers are responsible for deploying and managing data. With that comes the responsibility for security and compliance.

    This has traditionally been handled as an administrative task, but now, Salesforce has created the tools for true enterprise infrastructure security and data management with permission sets and permission set groups. Even though permission sets have been around a while, the introduction of permission set groups and the growing need to transition permissions into more complex structures have changed the way permission sets are being consumed. Permission sets were previously used for basic exceptions to the permissions provided by profiles, but now they are front and center, providing even more organizational capability with Permission Set Groups (and their muting capability, but that’s a different story).

    Salesforce has taken note and announced the partial end of permissions within profiles as they lean into the new, better way to manage permissions. Profiles won’t be gone entirely, as they will still be needed for basic defaults, i.e., defining users’ default app selections. However, while Permission Sets will still have the responsibility for what apps you have access to, it will be the Profile that states which one is your default. This is also true for other types of assignments where there needs to be a single source of truth, like page layout assignments.

    Salesforce said they will be enforcing this plan in 2026 but are beginning to make sure everyone gets on board now by releasing great new tools to make this transition smoother, including user access policies and access to Permission Sets when adding new fields (currently only available for profiles). For large organizations, three years is just around the corner when it means implementing major overhauls in technology and philosophy to the business. While some are heading to building Permission Sets based on each object, I’d recommend basing them on features or functional areas to have the most control and the clearest overview of your new vast area of Permission Sets.

    Next Salesforce Release

    Overall, the spring ‘23 release was jam-packed with content to boost productivity, strengthen security, enhance the user experience and improve the overall business functionality. There are two Salesforce releases still to come in 2023, and I’ll be dissecting them both to highlight the most critical changes that can help you better your business. I’m looking forward to seeing what the summer ‘23 release has in store – any predictions on what Salesforce will come up with next? I’ve got a few guesses…

  • How to Maximize Telemetry Data Value With Observability Pipelines

    How to Maximize Telemetry Data Value With Observability Pipelines

    The software landscape has shifted significantly in recent years as companies digitize their operations and adopt cloud and microservices technologies. The complexity of modern software systems has led to an increasing need for real-time visibility into their performance—resulting in an explosion of telemetry data that is stretching IT budgets and outpacing engineering teams’ ability to find value in that data. In fact, data volume is growing at 23% yearly, while IT budgets are only growing at 5%.

    Managing all this data at increasing cost is further compounded by unpredictable software failures and ever-evolving security threats. As a result, companies are forced to pick which parts of their software to instrument and monitor. To overcome this challenge, a different approach to managing data is required.

    Observability pipelines are emerging as a way to address this problem. They centralize telemetry data (i.e., logs, metrics and traces) from many sources, transform that data to fit downstream needs, and route it to various destinations for analysis. With complete control of the data, companies can sort through large amounts and prioritize what is essential, allowing them to act swiftly to avoid disruptions while reducing costs by only storing the data they need.

    Research indicates 62% of organizations currently have an observability practice. This means 38% operate with limited awareness of what’s happening in their software. Even those with an observability practice can only afford to store some data and have to choose which applications to instrument. This leads to blind spots and, ultimately, issues that are time-consuming to fix due to a lack of data.

    Managing Limited Resources With Observability Pipelines

    Engineers face more demands in today’s fast-paced business environment than ever before. Despite an increase in their responsibilities, the size of engineering teams has yet to grow accordingly. Given this, there has been a rise in full-stack engineers responsible for technologies from the front end to the back end. Short on time and resources, it’s difficult for these engineers to instrument and monitor software.

    Observability pipelines help control the amount of telemetry data using various processors such as sampling, throttling, filtering and parsing, and only forward valuable data to the downstream systems. The rest of the data can either be discarded or stored in a low-cost system, such as Amazon S3. This reduces costs and lets engineers focus on analyzing relevant data to identify issues.

    Engineers can also use observability pipelines to consolidate data from various tools. Many teams use different platforms or open source tools, like Prometheus or Jaeger. The fragmented data makes it hard to solve issues and understand application health. Observability pipelines combine all this data to make it easier to act on.

    It’s also important to remember that real people work on these technical challenges. Engineers face burnout working long hours to keep up with software development demands. Constantly switching between tools and manually moving data adds to the pressure. Moreover, the number of data sources, observability tools, and platforms that need that data are constantly increasing. Embracing open standards such as OpenTelemetry can ease this integration burden. Engineers can swap out tools without extensive testing and integration. The increased control and easy integration enable engineers to focus on delivering business value.

    Making Data More Usable

    Teams across organizations want access to data but struggle to use it effectively. The difficulty stems from the lack of data usability: Telemetry data is unstructured; varying formats make it hard to use; data preparation is time-consuming and sensitive data in logs may lead to compliance violations.

    By most estimates, 80%-90% of data is unstructured, which makes it hard to store and analyze because it doesn’t adhere to traditional data models. Observability pipelines make sense of unstructured data before it reaches its final destination. This is achieved using data processors that shape and transform data to make it more actionable. These processors include advanced parsers that identify and extract relevant information, transforming data into consumable formats that make it easier to work with and analyze.

    The advantage of performing these operations within the pipeline is that the same data can be prepared to fit different use cases downstream. For instance, while one team may require data optimized for visualization and trend analysis, another may require complete data for threat hunting. These transformations are managed from a single control point, eliminating the need to maintain separate data streams.

    Observability pipelines can also help companies meet data compliance requirements. For example, teams can scrub, mask or redact PII data based on a defined key structure before the data reaches a SIEM or audit platform.

    Taking Immediate Steps to Make the Most of Telemetry Data

    Organizations can take immediate action to make the most of their telemetry data. First, they need to adopt a visibility-first rather than a cost-first approach. They should assess what software they’ve instrumented. This will identify gaps in telemetry, which can be used to develop a plan to instrument all software. Next, they need to create a strategy for managing their telemetry data, being particularly thoughtful about how and why the data is stored and analyzed.

    Once a company has taken these two steps, it can decide which tools to use. One of the great things about OpenTelemetry is that it provides flexibility for future decisions about what tools to use.

    As companies invest more resources into building observability practices, they’ll encounter problems processing an extraordinary amount of telemetry data for any meaningful action. Observability pipelines provide a competitive advantage of prioritizing the essential data that will enable companies to make better decisions faster.

  • Bug Bounty Vs. Crowdtesting Programs

    Bug Bounty Vs. Crowdtesting Programs

    Digital quality and excellent user experiences are more important today than ever. When a digital experience doesn’t work as expected or is rife with friction points or glitches, customers are quick to give up and move on to a better, easier solution. Bugs and defects often come with high stakes and can result in loss of revenue, dissatisfied customers and potential damage to a brand’s reputation.

    With this in mind, software testing is tasked with the important role of catching and fixing bugs and defects before they hit production. There are several approaches to finding bugs in software, two of which are bug bounty programs and crowdtesting. In this article, we’ll examine the values of each.

    Bug Bounty Programs

    A bug bounty program typically involves people outside an organization with software testing experience, leveraging their expertise to hunt down product defects in exchange for money. Bug bounty programs can be a cost-effective way to find defects that otherwise go unnoticed. They provide an outside perspective and a sanity check for digital products to find vulnerabilities and defects.

    From a security perspective, bug bounty programs are also valuable. Today’s security teams have trouble managing the sheer volume of software vulnerabilities found in software. That’s part of the reason behind the growing number of cyberattacks and breaches that continue to be a topic of discussion. Bug bounty programs leverage white-hat hackers to find and report vulnerabilities in an effort to improve overall security posture and support the organization’s own cybersecurity team.

    Bug Bounty Benefits

    Bug bounty programs offer a variety of benefits to organizations, including:

    ● Helping with blind spots: It doesn’t matter how well your software is designed and coded. Defects and bugs, whether minor or major, will find their way into applications. The developers themselves and internal testing teams may only test certain paths based on organizational norms. Bug bounty testers offer a fresh perspective that can help reduce overall blind spots in application testing.
    ● Resource flexibility: Most organizations don’t have the flexibility to scale internal resources on short notice. Bug bounty programs offer outsourced help and are flexible. They can be scaled up if needed to help with finding defects before a major launch. Or, if a business needs to save money, it can be scaled down by either reducing payouts or limiting testers to high-value defects.
    ● Continuous evaluation: Whether an application is in use by customers or is just a prototype, a bug bounty program can go to work finding and revealing bugs and vulnerabilities. Bug bounty programs can continuously search for bugs that help improve the quality of an application.

    Bug Bounty Challenges

    While there are some great benefits to using bug bounty programs, there are challenges, as well, including:

    ● Money focus: As the name suggests, this is a bounty program. High-severity defects come with a higher payout. If a large percentage of bug bounty hunters are focused on high-severity bugs and vulnerabilities because of the higher earning potential, they may miss the smaller defects. This can add up and result in a less-than-ideal user experience, with smaller issues going unfixed.
    ● The perspective of the tester: No matter how experienced and skilled a tester is, everyone is limited by their own blind spots and perspective. A diverse group of testers can help offset this, but there is still no guarantee that they will test the product in the same way that customers will use them. This challenge is multiplied when we add in different devices, operating systems, languages, and locations. Bug bounty hunters may be more focused on finding high-value issues to earn more, while an internal tester may be more invested in a specific product or feature and making sure it works as it should.
    ● Communication: Many have gotten used to working from home or from anywhere and collaborating remotely. Bug hunters work like this too, but they are outsourced assistance from an organization, which requires a bit of extra thought for communication, project scope and qualifications to make sure misunderstandings or lags in progress are kept to a minimum.

    Crowdtesting

    A crowdtesting model leverages skilled testers and testing teams that can be sourced from a globally dispersed community of independent digital experts. Depending on the size and diversity of the community, testers can apply a nearly limitless variety of demographic characteristics, locations, skill levels, spoken languages, abilities, devices, browsers and operating systems into a testing scenario. This breadth of feedback provides valuable insights into how real users will interact with an app, device or digital experience—which may not necessarily be the “typical” way it is intended to be used. This real-world interaction can unearth bugs, friction points and localization issues that may otherwise go unnoticed before the experience is released to actual customers.

    The remote and on-demand nature of crowdtesting provides scalability and timely results in comparison to more traditional testing methods, like offshoring or lab-based testing, which are typically more limited in scope and flexibility. Plus, the crowdtesting model inherently provides the ability to scale testing services up or down as needed to meet the project-based requirements of a company’s internal teams.

    Crowdtesting Vs. Bug Bounty Programs

    Both bug bounty and crowdtesting programs involve digital experts looking for app defects and vulnerabilities with the goal of improving digital quality. These programs can be aligned in this goal and even work in tandem, but there are some notable differences between them worth mentioning.

    ● Scope: Bug bounty program scopes will always be somewhat limited. Defects can be found outside of the payment scope and go unflagged. Crowdtesting allows for either a broader or more specific scope, depending on needs. Organizations can give specific instructions, like making sure UX considerations are taken into account.
    ● Volume: Both crowdtesting and bug bounties rely on skilled professionals who know how to root out bugs and defects. Crowdtesting, however, allows for as many or as few testers as needed. Instead of gathering a moderate amount of defects from a more technical audience, crowdtesting enables testing for any amount of defects from a diverse and vast pool of testers. As a result, crowdtesting finds a larger variety of defects, and across more devices, locations, and OS versions. This can also be a challenge, as internal staff can become overwhelmed by so many bug reports to look through and address. Therefore, prioritization is key.
    ● Flexibility: Digital quality is a multi-faceted process. It’s not just about functional and security bugs but also accessibility assessment, making sure to test using specific devices and use cases, and more. Bug bounties fall short here, while crowdtesting delivers the flexibility to test and address situations your potential customers may face when an application is live.
    ● Specificity: Most bug bounty programs are not tailored. They can be application- or region-specific, but that doesn’t always reflect a target customer use case. Crowdtesting enables an organization to focus on specific demographics in terms of user experience. An organization can specify testers in certain locations with a certain device or devices and who speak specific languages. Crowdtesting isn’t always just about technical ability; it’s about finding the correct group of people needed for the task at hand.

    Both bug bounty and crowdtesting programs provide unique benefits that help organizations improve overall digital quality. Bug bounty programs offer help with organizational blind spots while leveraging testing professionals in a flexible way. Crowdtesting enables businesses to harness the power of real people using actual devices out in the world to test for use cases. It delivers the power to augment internal testing initiatives, helping to improve overall quality, usability, accessibility and more. When improving digital quality and user experience are the goal and end result, bug bounty and crowdtesting programs can each be impactful and helpful for today’s businesses and for improving the user experience.

  • Low-Code Should be Worried About ChatGPT

    Low-Code Should be Worried About ChatGPT

    Is ChatGPT the technology revolution that will save the world, or the Pandora’s Box that will eventually destroy it? How about neither? Putting these two extremes aside, a more rational concern is whether ChatGPT will steal your job, especially if you work in software development.

    Is this a fair concern? Conversations like this are nothing new. New technologies always go through this cycle; starting with intrigue then moving onto fear and resentment until eventually being accepted and embraced as the new normal.
    ChatGPT and other natural language AIs are undoubtedly exciting new trends with huge potential. One area of ChatGPT’s potential that has largely been overlooked is how it can democratize software development. Should low-code/no-code providers be worried about this?

    Delivering the Low-Code Promise

    Low code has long promised to democratize software development by providing a way for non-coders to develop applications themselves. This “democratization of IT” promises a new wave of innovation by enabling organizations to create new processes without the new to engage with IT. While low-code has already achieved some great things when and where it has been implemented, the amount of change it can deliver is fundamentally limited by the developer’s choices. The developer still chooses which aspects of the application can be configured by the user, so the user still has no fundamental access to the code. While this has been low-code’s strength (since users cannot damage the underlying code if they can’t access it), users are still beholden to developers to do anything significant. ChatGPT could allow users to make more significant changes to applications, potentially enabling organizations to achieve far more than with low-code and in half the time.

    Software Development is Just the Start

    ChatGPT can achieve more than helping non-developers build the applications they need. If you think about the most common reason for an IT project failure, it is rarely down to poor delivery or mismanagement alone. Most IT projects fail because they do not deliver the outcomes that users want. This happens because of a communication breakdown between IT and end users. On one hand, users fail to convey exactly what they want and IT fails to ask the right questions to find out. The requirements (i.e., the intended outcomes) get lost in translation because technical and non-technical people simply speak different languages.

    In a scenario where the message is too often lost in translation, ChatGPT can serve as the interpreter between those who build and maintain IT and the wider staff who use it day-to-day. ChatGPT can bridge the gap because users won’t need technical skills to realize the changes they want.

    Always Start with the Business Case

    Delivering change in an organization is fraught with challenges and uncertainty. Like any project, it is important to start with the fundamentals of what you’re trying to achieve, not the technology you want to use. No matter how much you want to use ChatGPT, you must start by defining the outcomes you want to achieve and working backward from there. How you achieve these outcomes is a technical decision that comes much later. If one of your questions is to enable change to happen faster and to be more adaptive to the company’s needs, then ChatGPT may well form part of the answer. Just remember to define the problem first, build the business case and then evaluate the various solutions to achieve those objectives. Don’t get carried away by the hype.

    ChatGPT Needs Room to Flourish Outside of IT

    ChatGPT has the potential to be the bridge between technical and non-technical users in every organization. It can reduce the gulf between these radically different types of people to speed up change in the organization and deliver better outcomes for all. But it is crucial for technologies like ChatGPT to sit within the domains where they will have the best chance to flourish. In what might sound like a controversial statement from someone in the IT sector, I believe that, like low-code, ChatGPT must sit outside of the technical domain. ChatGPT needs to move out of the IT sector where it was born to reach its full potential. The question is, is IT ready to let it go?

    Image via Unsplash