devopsy.kinsta.cloud

Author: Jeremy Freeman

  • What Will DevOps Look Like in 2024?

    What Will DevOps Look Like in 2024?

    The last two years have been marked by significant downsizing in technology companies. As large layoffs at companies like Amazon, Meta and Google make major headlines, there is a general shift away from the “spending cash and growing fast” mindset that free capital and strong growth during the pandemic launched in the tech industry. The name of the game is to be more conservative with spending, and that mindset will drive a lot of investments in the next year. While these cost pressures may feel challenging to technology organizations, there are a few key opportunities as well. Many trends are starting, sustaining and ending, so let’s focus on the top six likely to drive changes in the industry in 2024 and beyond.

    1. AI—Specifically Generative AI—Move Right on the Hype Cycle

    While AI is not new, OpenAI and ChatGPT have created an amazingly accessible and powerful tool that is positioned to drive a lot of value. The hype cycle is still in full swing as dozens of new uses of the technology hit the market daily, and if you’re not trying to build a generative AI-enabled product, you’re getting asked when you will start. In 2024, we will likely see LLMs move into the trough of disillusionment as inflated expectations and projects don’t all play out. However, those organizations with generative AI products that truly deliver value to users should expect to see massive growth. Technology organizations will need to make hard decisions about AI products. You will either find traction in the next year and see huge growth or quickly find it doesn’t work and shift focus back to non-AI products.

    2. Developer Experience Gains Momentum

    While DX has been talked about for years, we’re seeing new investments in tools that empower developers. This trend is partially born out of a need to reduce tool and system sprawl for engineering teams, to empower teams and allow them to move faster and to improve efficiency. While you may not build or buy a DX platform, you will likely start a DX team or committee that better represents the folks building your software. This will lead to some great internal changes and key efficiencies getting attention that may have been previously overlooked. The wonderful thing about this trend is that it both brings efficiencies to the organization and makes developers’ lives easier. It’s a win-win!

    3. Increased Pressure to Reduce Costs

    Even for organizations that have avoided layoffs, most are seeing pressure to shift into a leaner existence. This often means critically looking at all sources of spending and taking on new projects to optimize them. Maybe a cloud re-platform can reduce hosting spend by 20%, or maybe you start looking to remove or combine SaaS tools to reduce seats. You may even see hiring freezes for critical teams. Organizations will have to embrace other trends to increase the efficiencies of their teams to meet business demands here. Don’t be surprised to hear “do more with less” become a mantra around the office.

    4. Increased Accountability Through Data

    While data platforms for technology organizations continue to grow, teams are finding that it’s not enough to just measure a few metrics. Organizations will be required increasingly to use the data they have to show they are delivering value. Partially due to increased pressures mentioned above, teams will need to become more predictable, and better at identifying and handling risk at every stage of development. It’s no longer enough to just build a great development engine, teams must ensure that the engine can power them to their destination.

    5. ESG in Technology

    Focus on DEI in technology continues to require significant investment, however, organizations are starting to consider a broader umbrella of social responsibility. This can range from considering the environmental impacts or carbon production of your servers to changing your software supply chain to avoid supporting particular organizations. These types of requirements are appearing sooner and more overtly in the software development process, and may significantly impact how teams choose to build or implement software.

    6. DevSecOps Continues to Grow

    There has been a renewed focus on security in recent years after some critical attacks exposed vulnerabilities in the software supply chain. It’s not surprising that security is now written into the fabric of how we build and deliver software. Teams are now expected to consider security at all stages of development from product planning to operation in production, and require additional experts, training and resources to both monitor and ensure compliance. Requirements for SaaS products continue to evolve as the last remnants of on-premises solutions evaporate, and teams should be prepared to move quickly as new threats are discovered and need to be patched.

    As the technology industry prepares for 2024, it’s clear that innovation and adaptation will be the keys to success. From the continued evolution of AI and the growing focus on the developer experience to the imperative to reduce costs, increase accountability through data, embrace ESG practices  and fortify security through DevSecOps, technology organizations face an exciting future.

  • Yes, Software Development is an Assembly Line, but not Like That

    Yes, Software Development is an Assembly Line, but not Like That

    I grew up in a manufacturing town. Nearly everyone worked for (or previously worked for) the local textile factory. My father was no exception. He had a few jobs but eventually landed a management job at the factory and started working closely with the engineers and other plant operators. At the time, I was in high school and about to start my education in software development. At the time, I felt–maybe hoped–that my world and the world my father was steeped in were vastly different. I was working on cutting-edge technology in the software space while he was helping design and run decades-old manufacturing facilities. It took years to learn that wasn’t the case.

    Agile Software Development

    I was lucky to be able to learn about software engineering while also hearing my father learn about lean manufacturing at the same time. In the beginning, I failed to see the connection between them, but as I learned and read more about this relatively new “agile” thing, I started to see the big picture. It should come as no surprise to folks that agile software development grew out of manufacturing systems developed for exactly the same reasons–to build things more efficiently.

    That same desire to deliver value faster at a lower cost drives much of the innovation and growth in every business, including software companies. It’s not surprising that key leaders in the industry found those impressive innovations in industrial engineering and began adapting them to software. We know that waterfall and agile were adopted from industrial engineering, and the next big software development innovation will likely be as well.

    Improve Business Efficiency

    We can see many of the agile processes directly map back to either lean philosophy or even older industrial processes. Just-in-time manufacturing, or the idea that you keep an extremely limited number of raw or intermediate materials, is a philosophy that focuses on narrowing your manufacturing process to the essentials. Most agile practitioners argue similarly that your stories and shipped features should be as small as possible to deliver only the value required by the user. Both systems aim to improve business efficiency and agility by reducing potential waste (material breakage, for one, and over-engineering for the other).

    All of these parallels make perfect sense to me. However, there was one component that never really clicked. A ticket and a widget are incredibly different things. Let’s explore this difference in two ways.

    Traditional manufactured goods are usually tangible things. Tangible things often provide value for a fixed amount of time to a single user. For example, a delicious baked snack I pick up on a road trip provides maybe 30 seconds of value when I get back in the car; however, that car may provide 30 years’ worth of value to multiple users. Features in a software platform similarly provide value to users that vary in scale and duration. Here’s where we find an interesting divergence. A good provides a set amount of value and is often produced in bulk; a feature in a SaaS platform is often produced once and can provide an unbounded amount of value.

    Compare and Contrast

    Another way to see the contrast between the types of products is to look at the differences between engineers in each discipline. In a traditional manufacturing environment, the engineers are not the people actually operating the machines to produce the widgets. The engineers design the manufacturing lines and the products that will be produced on them. In software engineering, the engineers are the ones producing the features. Curious.

    However, if we look closely at the two roles, we see that they are actually producing similar things. Manufacturing engineers produce assembly lines and manufacturing processes that can produce those units of value. Software engineers are largely the same, also producing systems and processes that deliver units of value. The manufactured widget of software is actually the discrete user interactions with those features and pieces of software, not the features themselves. The assembly line in software engineering isn’t, as many think, the engineers producing features. Rather, it’s software producing value-creating experiences for users.

    While this is interesting, how does it help us? I’ll propose two key ways.

    Manufacturing processes are extremely adaptable to managing the technology and platform. Systems like Total Quality Management, which are focused on driving a cultural mindset of continuous improvement and an entire company focused on providing very low defect rates, easily translate to customer satisfaction in software organizations. Just to pick on TQM a bit, if we were to adapt it to software, we would focus on the number of times users are impacted by a defect more than the number of open bugs. Instead of tracking the number of defects and searching for more, we would be tracking the number of users who either failed to receive the promised value from the product or had severely diminished value. That would drive investment not only at the engineering level but would create buy-in from the whole company. Everyone in the company is interested in a conversation about how many users aren’t able to gain value from a feature, but many fewer are interested in how we go from 20 open bugs to 10 open bugs.

    Secondly, this mindset shift can help bridge the expectation gap between engineering and the business. I’ve been a part of many conversations where engineering has discovered a potentially serious flaw, and the whole team is in agreement that this is potentially one of the most serious bugs we’ve found in a while. However, when they bring this issue to the business side, that passion gets quickly overruled if engineering can’t show that that bug is “impacting customers.” Those debates often fall into conversations of projected odds better left to the sportsbook room in Las Vegas. While there are obvious exceptions for security exploits, compliance issues, and other business risk-driven defects, the business is justified in not investing in fixing a defect that users aren’t impacted by.

    Reporting Performance Issues

    Conversely, this line of thinking can help engineering convince the business that something is a critical problem and needs to be addressed. While previously, I would have reported performance issues in terms of p99 times or average load times, that doesn’t describe performance in terms of our unit of value. If our unit of value is a customer using our app or a feature, then each negative interaction is a broken widget. As an example, I’ve since taken to reporting performance issues in terms of the number of sessions with a frustratingly long load time and the number of clients and users that are experiencing those.

    Manufacturing is perhaps the most varied industry in existence, adapting itself to produce nearly everything from food to raw materials to consumer electronics to clothing. That long history, many contributions from a massive number of brilliant engineers, and significant innovation have led to dozens of amazing systems for delivering value. While I proposed two examples of how we should give these processes a second look as engineering and business leaders, it’s worth dusting off some manufacturing engineering books and giving them a read yourself. You may find the key to outpacing your competitors was drawn up by an industrialist decades ago.

    My first college internship was at one of the factories my father worked at in the engineering department. I was able to see firsthand how deeply some of today’s engineers think about these types of production processes. They really know how to ship stuff, and software engineers may have a lot to gain by learning from them.

    Now, go build great things!