devopsy.kinsta.cloud

Category: DevOps Culture

  • How to Build Healthy Engineering Teams

    How to Build Healthy Engineering Teams

    A common challenge today for engineering teams is the increasing complexity of their jobs and figuring out how to make it both productive and enjoyable without burning out.

    Over the last 10 years, the role of a software engineer has evolved drastically. Software continues to reach unprecedented scale, it is becoming more complex and customer expectations are higher than ever. Organizations from all industries are now becoming software companies and, with the pandemic, everyone is feeling the effects of burnout.

    There are close to a million unfilled IT jobs in the United States. To ensure organizations are able to continue innovating, the industry needs the tools, state of mind and reliable practices to make this career sustainable.

    Creating an industry with healthy productivity is paramount. But too much of a focus on going faster without addressing burnout is a recipe for disaster. Engineering managers need to constantly balance both. Here are some things they should keep in mind:

    Invest in Engineering Productivity

    Companies are increasingly hiring for roles focused on engineering productivity—there are currently hundreds of open job postings from organizations looking for these skills. These jobs are aimed at making developers and engineers’ lives and work easier by focusing on streamlining how things are done within the engineering organization—including improving developer workflow processes, execution efficiency and product quality. They are often responsible for building internal tools that support cross-functional and developer workflows. Even with a relatively small engineering team, organizations can start thinking about bringing on a team member dedicated to making engineers’ roles within the company easier.

    Focusing on Healthy Productivity

    Productivity is, and will always be, extremely important, but potential burnout should also be seriously considered in the process. Remote work during the quarantine and the pandemic has brought this front and center. When people don’t have enough deep work time, they often work longer hours which can eventually lead to burnout. An average employee has 11 minutes to focus between distractions at work and then, after an interruption, it can take around 23 minutes to return to the original task. In addition, the average worker attends 15 meetings per week.

    There are many questions about how workers’ productivity has been impacted since early 2020, and research has found that developer productivity isn’t a problem—but burnout is. From March to December 2020 the study found:

    • Deep work time—a two-hour period of uninterrupted work—decreased by 22% between March and December 2020.
    • Average time in meetings went up by 67% from March to December 2020.
    • Pre-pandemic, 10% of developers were showing “always-on” behaviors at work, but that percentage went up to 15% and then to 20% by the end of the year.

    Focusing on driving healthy productivity—where developers are productive but not overworked—is key to keeping your employees.

    Strengthening Engineering Managers

    Managers play a key role in keeping engineering burnout in check. Ensuring that managers ‘manage well’ is not a new idea, but today there are particular complexities that make the engineering manager role both uniquely challenging and especially important.

    It is now widely acknowledged that culture is a considerable part of what gets employees to stick around. But culture isn’t only employee benefits like trendy offices, great snacks and other relatively superficial—though still important—benefits. What really matters is identifying and building teams that really care about one another on a personal level and making sure that incoming employees feel the same.

    With engineering teams, there is a tendency to focus primarily on the technology being created rather than the people who are creating it. While this approach can absolutely result in successful products, it is often the default management style for managers who don’t have the tools to do otherwise. Moving from software engineer to manager requires a whole new skill set that involves different communication styles, time management, organization, tools and software, scoping work, learning how to effectively delegate and identifying the right people to complete the team.

    As challenges continue to evolve, organizations need to ensure that engineering managers are able to support each individual on their team. It is so important to make sure that people feel aligned with a mission they care about and that their career interests and goals are being met. Not all of those can be measured with data, so managers have an all-important role in keeping up with the pulse of the team.

    Building Helpful Tools and Growing Developer Communities

    In the last decade, the speed of innovation in enterprise technology has skyrocketed and the amount of code and tools developers need to master has increased. At the same time, the number of unfilled job openings continues to grow. There are a lot of great trends that are helping to close this gap including low-code and no-code tools as well as a massive increase in community resources.

    No-code/low-code tools: As both technical and non-technical organizations hire an increasing number of developers, low-code and no-code have become more prevalent. With frameworks that allow even those without a technical background to deploy software, no-code tools open development capabilities to an increasingly diverse subset of people. While these tools will not replace developers, they will make it possible for more people to enter the field of software development and help companies continue to innovate.

    Developer community: The amount of resources available to new and existing developers has also skyrocketed in the last several years from open source communities to Stack Overflow to the ability to simply Google how to do something in code. The Linux Foundation’s extensive training catalog is one example; even Medium has a wealth of basic technical info, how-tos and deep dives available. If you’re looking to adopt a new tool, one of your main priorities should be to look at the size of the community so that you can easily troubleshoot problems if they arise. Having access to resources from community members that have gone through the exact same problems you encounter is priceless.

    The above are all just a start. Teams can go even further by finding and adopting analytics tools to dive deeper into specific productivity metrics. These can give managers and executive teams the hard data they need to make educated decisions that will help them keep their teams and drive innovation. It is worth investing the time and the tools to maintain your engineering resources. By doing these things, organizations can reach and maintain healthy productivity.

  • Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify Acquires OneGraph to Integrate GraphQL APIs

    Netlify this week announced it has acquired OneGraph, a provider of a platform that simplifies the integration and management of application programming interfaces (APIs) based on the GraphQL query language.

    At the same time, the company is committing $1 million to sponsor open source projects and setting aside $10 million for a Netlify Jamstack Innovation Fund that will help drive the development of emerging technologies. Those technologies will be consumed via the platform the company created based on Javascript, APIs and a markup language (referred to as Jamstack) to accelerate web application and website development. Rather than becoming investors in those companies, Netlify intends to make those funds available to advance the development of technologies that benefit the overall community.

    Fresh from raising an additional $105 million in funding, Netlify CEO Matt Biilmann said Netlify is committed to an ecosystem through which developers will be able to consume a wider range of services via both REST and GraphQL-based APIs. OneGraph will provide the core foundation for adding support for GraphQL to the Netlify platform, he noted.

    Overall, Netlify is trying to reduce the friction that developers encounter building web applications and the sites they run on, added Biilmann. That’s becoming especially critical as developers increasingly build microservices-based applications that invoke APIs to consume backend services that are made available via the Netlify platform, he added.

    Earlier this year, the company made available Netlify Build Plugins that provide DevOps teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications. Designed to be launched from within a Netlify platform, those plugin makes it possible to build a web application or website that can be launched directly from within a Git repository.

    The overall Jamstack philosophy enables DevOps teams to separate the development of frontends and backends of websites and applications. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    A recent survey of more than 3,000 Jamstack developers published by Netlify finds one-third of survey respondents have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including in advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience. Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey found.

    Jamstack is, of course, not the only framework for building web applications and the sites they run on. DevOps teams are increasingly being tasked with building a much wider range of external applications to drive digital transformation initiatives that are typically built using some type of JavaScript framework. The next big DevOps challenge, of course, is that as the number of applications being built continues to increase, so does the number of applications that need to be maintained and continuously updated.

  • Nvidia/ARM Wavering | Google Outage Outrage | Backblaze IPO on Fire

    Nvidia/ARM Wavering | Google Outage Outrage | Backblaze IPO on Fire

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

    Nvidia Can’t be Allowed to Buy Arm

    First up this week: Nvidia’s faltering attempt to buy Arm: Regulators around the world are alarmed by the idea. And now the UK—the legal home of the company—has taken the next step, which could nix the deal.

    Analysis: RISCy home for ARM

    This matters because ownership of the ARM ISA and the core designs would be a huge strategic stick to beat Nvidia’s competition with. Arm doesn’t make chips—it licenses technology to Nvidia and many of its competitors—AMD, Apple, Broadcom, Samsung and Qualcomm, to name but five. So this deal really shouldn’t go through, regardless of Nvidia’s fluffy PR reassurances.

    ARM chips aren’t just found in 99% of smartphones, but are an increasing fixture in the datacenter—especially where “performance per Watt” is important. They’re even found in exascale iron, including the Riken Fugaku, the world’s fastest supercomputer.

    Helen Thomas: Nvidia faces tough Arm wrestle

    It is one thing for a regulator to give your deal a thorough going-over. It is another for it to imply publicly that your assurances [aren’t] credible. … Nvidia got both from the UK’s Competition and Markets Authority. … The CMA’s full phase 1 report doesn’t make for easy reading.
    …
    The transaction, which was announced in September 2020, is bogged down in regulatory reviews around the world: … Arm’s “neutral” business model has always made it a difficult acquisition. … Arm licenses its designs to other chipmakers, providing scope to restrict rivals’ access.
    …
    Arm was a political talking point in 2016, when its sale to SoftBank … was waved through with embarrassing ease. There is now a much more muscular political take on UK national security concerns with a particular focus on tech.


    But if it’s owned by a Japanese company, why is the UK getting involved? Glad you asked—Aighearach answers:

    What did they buy? Shares of a UK company. … Then it is a UK company! … Buying shares is buying ownership, but it doesn’t move the company to another jurisdiction.
    …
    This blathering about “sold to a Japanese firm” is getting old.


    Nvidia claims, “The transaction will … boost competition and innovation.” Falmari finds that hilarious:

    Did Nvidia’s spokesperson previously work as a stand-up comedian? Because as jokes go, “boost competition” is a whopper. [Do you think] that’s what a company like Nvidia wants—to boost the competition?

    Google Cloud Outage has Ripple Effect

    Google’s load balancers all went offline for two hours on Tuesday. Aside from the knock-on Google Cloud failures, DevOps tools such as BigCommerce, Datadog, Deno, Discord, Egnyte, Evernote, Linear, Netlify and Toggl were reported to be affected. But perhaps the worst impact was felt by the poor, unfortunate users of Pokémon GO.

    Analysis: Paralysis

    In theory, putting all your eggs in one basket is okay—so long as that basket can reliably stop your eggs smashing on the pavement. But this isn’t the first time we’ve seen Google Cloud issues such as this; I can’t imagine it’s the last.

    Steven J. Vaughan-Nichols: Google glitch triggers major internet outage

    The result? Many of us have seen 404 errors when trying to get to some of our favorite web pages. … There appears to be more major sites having problems than not.
    …
    The specific problem seems to be with the GCP load balancers. These, working with Google’s Cloud Delivery Network (CDN) [are] designed to stop website failures and Distributed Denial of Service (DDoS) attacks by putting your website behind a single anycast IP.


    Are you feeling a touch of déjà vu? jeffbee, too:

    This is a sort of repetitive outage for Google. They’ve wiped out the GSLB configs before.

    A year ago there was also that big outage where they blanked out the whole Gmail delivery config and started rejecting all mail. … Config safety is not their strong suit.


    The #3 IaaS provider won’t get to #2 if it keeps this up. Here’s u/totopapa:

    I’m trying to convince my company to switch from AWS to GCP but an outage like this one is definitely a showstopper.

    Backblaze IPO Burns Brightly

    Backblaze is now NAS:BLZE. In its first week, the stock jumped 60%.

    Backblaze is well known for its tiny-margin consumer backup product and its open-source “storage pod” hardware—but is less well known for its DevOps-focused “B2” cloud storage service.

    Analysis: Can it Avoid Death-by-Packrats?

    Backblaze is trying to grow this newer DevOps business, without losing its classic consumer chops. But many of its former competitors have essentially dumped their “unlimited” offerings—it’s the old tragedy-of-the-commons problem.

    Jordan Novet: Backblaze [goes] public on small valuation and minimal funding

    In an era of blockbuster market debuts preceded by astronomical private financing rounds, Backblaze … a cloud service for backing up data … is a throwback to a time when sub-billion-dollar companies routinely went public to raise capital and build their profile … to win the trust of customers.
    …
    Backblaze shares climbed 24% in their debut on Thursday and another 12% on Friday, lifting the price to $22.31 and giving the company a market cap of around $650 million. … By the standards of its peers, Backblaze is a micro-cap.
    …
    One of Backblaze’s competitors is Amazon, the world’s fourth most valuable U.S. company. … Backblaze currently stores two exabytes of data — that’s 2 million terabytes — and has a half-million paying customers.


    Donovan Jones: Backblaze Targets $100 Million IPO

    The firm provides cloud-based storage services to small businesses and individuals worldwide. BLZE has grown revenue and gross profit impressively through the 2020 pandemic period and the IPO appears fairly valued, so is worth a close look.
    …
    The firm’s financials show strong revenue and gross profit growth. … The firm’s dollar-based net revenue retention rate for 2020 was 114%—a solid result. … The market opportunity for providing cloud-based storage services to small businesses and individuals is large and expected to grow at a material rate. … As for valuation, compared to partial competitor Dropbox, management is seeking the same Enterprise Value/Revenue multiple. [However] the combined revenue growth rate and EBITDA percentage rate … was 3% as of June 30, 2021, so the firm needs improvement in this regard.


    But there’s a long way to go, opines John Kozubik (aka rsync):

    Of the ~500,000 customers, 70,000 are B2 customers and 430,000 are “backup” customers—which are flat-rate “unlimited” users. … Roughly 85% of the user-base are paying $7/mo for “unlimited backup.”
    …
    These flat-rate users are very fickle and price-sensitive. … Roughly 85% of the user-base are paying $7/mo for “unlimited backup.” … It’s a fools errand to pursue this market and I assume the pivot to B2 was to build something more sustainable with a much higher price and usage ceiling.

    The Moral of the Story: Success is a journey, not a destination


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Kristin Wilson (via Unsplash)

  • Are You Feeling the Hiring Crunch?

    Are You Feeling the Hiring Crunch?

    After years of experience, we can now definitively say one thing about information technology: There is always a hiring crunch, and it will always be better soon.

    I first noticed this trend in InfoSec years ago. Everyone was short-staffed and looking for available candidates. Everyone wrote their recruitment text like there was no shortage and they could ask for the moon and everyone was certain that this temporary staffing shortage would end soon.

    It didn’t. It still hasn’t. And it has spread. DevOps in general, development in particular are acting exactly the same these days. And it’s not going to get better.

    So, my advice? If you absolutely must have a person, write your recruitment copy to reflect the actual skills you must have. No bells and whistles, no “We always include…” no “But what if we…” Hire for what you need. Or hire with an eye to training what you need. And offer competitive pay. No one here will argue that IT is underpaid, but when there is a shortage of people, or more are leaving than coming in, then the cost of employees goes up. That’s just the way it is. If you are only hiring the ones you must have, then you can afford to pay them a bit more.

    Meanwhile, invest in even more automation. Let’s face it; again, we can learn from InfoSec. They are doing more with less staff—even if “more” is not “everything that everyone wishes they could”.  They have at least partially conquered their staffing woes by increasing the use of automation. DevSecOps is automating even more of the space, so we really will eventually get over the InfoSec staffing shortage.

    We can do this for all of IT, too—just follow their lead. Invest in automation, take the risk and turn on automated actions. Start small, but get started. Relatively high turnover and lower qualified applicant counts are likely to be the status quo for the foreseeable future, so automating processes as much as possible is not taking away jobs at this point, it is improving response in light of a lack of people for the available jobs.

    So, to sum up:

    • Hire when you can, but be focused. Don’t ask for experience in all three big cloud providers if you’re looking for an Azure person. Don’t ask for fifteen years of experience in Go for that entry-level position. Be realistic, be laser-focused and get the person you need in.
    • Train when you can’t hire. Let’s face it, there are going to be people who are massively familiar with application security but who have never done DevSecOps specifically or never used your DevSecOps solution. Train them—whether they are internal or hired with an eye toward training.
    • For non-critical, long-term needs, explore automation options. That includes both things that are being done manually today and things that are not being done at all. Find a way to get it done in the absence of hiring someone.

    And keep rocking it. You are already getting the job done—I’m just recommending ways to stay on top of it and deliver more while you try to find the additional people you need. A balance of automation and hiring will help you sleep at night and make the rest of the org certain that IT is on the ball.

  • DevOps Dozen² 2021 Finalists Announced

    DevOps Dozen² 2021 Finalists Announced

    Today, we are delighted to announce the finalists of the DevOps Dozen² Awards 2021, celebrating the greatest innovators and their achievements in the DevOps space. Despite the many challenges of the past year, these individuals and companies have taken an active role in the DevOps community, demonstrating their leadership and commitment to the improvement of our industry. We had a record number of nominations this year which was terrific to see. It means even through the challenges of the last two years, the DevOps community has remained robust and active.

    Congratulations to every one of the finalists—it is quite an honor to make it this far. All of your hard work and dedication is greatly appreciated.

    Without further ado, here are the finalists for the DevOps Dozen² Awards 2021:

    DevOps Dozen Community Awards

    1. Best DevOps Industry Implementation

    2. Best DevOps Survey/Analysis/Research

    3. Best DevOps-Related Video Series (video)

    4. Best DevOps-Related Audio Podcast Series

    5. Best DevOps Book/eBook of the Year

    6. Top DevOps Evangelist

    7. Best DevOps Transformation (non-vendor)

    8. Best DevOps Virtual Event of the Year

    9. Most Innovative DevOps Open Source Project

    10. DevOps Executive of the Year (non-vendor)

    11. Best DevOps Presentation of the Year

    12. Best DevOps.com Article of the Year

    DevOps Dozen Tools and Services Awards

    1. Best End-to-End DevOps Tool/Service

    2. Best DevOps Repo/GitOps Tool/Service

    3. Best CI/CD Tool

    4. Best Value Stream Management Tool

    5. Best Observability Solution

    6. Best DevSecOps Solution

    7. Best Testing Service/Tool

    8. Best Kubernetes Platform/Service

    9. Best Cloud-Native Security Solution/Service

    10. Best DevOps for Mainframe Solution

    11. Best DevOps for DataOps/Database Solution

    12. Best New DevOps Tool/Service Provider

    Finalists were picked by the judges and also based on which entry had the most nominations. Every single finalist will receive a badge to display on their website and social media with a link to the voting/survey site.

    Voting for the winners in all 24 categories is now open to the public. To vote for the leaders, tools and companies you think are truly deserving of an award for their exceptional service to the DevOps community, please visit the DevOps Dozen² website.

    Winners will be chosen from among the finalists, with general public voting weighted for 40% of the final score and our judges’ selections for 60% of the final score. The deadline for public voting is Dec. 31 and the judges’ determinations will follow shortly thereafter.

    The winners will be announced at the Predict 2022 Virtual Summit Jan. 20 and will receive both digital badges and physical trophies celebrating their achievements.

    Thanks to everyone who has supported the DevOps Dozen² Awards by nominating candidates and voting. Good luck to all the finalists!

  • 4 Keys to Developing Ethical AI

    4 Keys to Developing Ethical AI

    Companies continue to grapple with how to use artificial intelligence (AI) technology in a way that doesn’t compromise privacy and that takes into account other key ethical considerations. It is undeniable that AI is one of the fastest-growing categories today. But if we are unable to build tools that live up to high ethical standards, not only are we doing end users a disservice, but we are failing to deliver on the promise of this technology as a force for good.

    AI and ethics has been one of the hottest topics within the technology community for decades. However, as an industry, we are still finding it hard to put our best foot forward in terms of ensuring ethical use—let alone solving the problems these systems were meant to address. Fortunately, there is one group that could be the guiding force we need: Developers.

    From the ideation process to implementation, the developer community is by far the group with the most intimate knowledge of how AI products actually work; therefore, they can have a tremendous influence on what these tools actually do and how ethical they are—and they need to be empowered to make these calls.

    With that in mind, here are four key questions that companies and their developer teams should ask as they work to build the ethical AI solutions of the future. 

    Is This Transparent in Every Way?

    If a developer ever finds themselves saying, “I don’t know,” when asked about how a product works or how the product is ultimately going to be used, production should stop immediately. The power of automation is tremendous. But given how quickly it can morph and learn, making sure that oversight and explainability are ingrained in its functionality is imperative to ensure ethical use. If this can’t be guaranteed, developers should be empowered to flag their concerns and look for ways to remedy them before continuing production.

    As AI continues to evolve, designing and developing AI systems will likely continue to lead us into areas where no clear legal, social or policy guidelines address many of the potential uses—and misuses. So, now is the time for developers to establish a transparent and clear channel of communication where they can actively raise concerns, discuss and deliberate on ethical dilemmas with diverse stakeholders. This is crucial in reducing or eliminating any negative effects of AI. Otherwise, we will continue to see the current faux pas around AI ethics continue.

    Have we Accounted for Risk or Exceeded Regulatory Boundaries?

    Virtually any big idea has its risks. Unfortunately, when it comes to AI, these risks generally involve unethical use or unintended consequences. The ongoing debate around facial recognition and AI is a perfect example of this. While this use case is intended to improve security and may have other benefits, facial recognition software comes with significant privacy risks and fears over misuse and misapplication. Moreover, because the regulatory landscape around AI is still taking shape, companies can fall into a trap of looking to exploit these gray areas in exchange for being the first to market or gaining a competitive edge. This is why companies that are not using ethical privacy-preserving AI in facial recognition implementations, for example, are having to walk back their products.

    Simply put, acting in this manner can have terrible consequences for the ethics around an AI product. But there is good news; the fix for this mistake is relatively straightforward: Instead of just making sure that products barely comply with regulatory gray areas, make sure they exceed them. Granted, this can lead to increased go-to-market time and significant leg work. However, this is the only way to realistically “future-proof” products against potential unethical use cases.

    Is This System Adaptable?

    Even the best preparation and forethought does not guarantee that a tool will operate exactly as it was intended. This is why it is so important for developers to have the ability to plan for contingencies and build adaptability into their tools so that adjustments can be made periodically if any ethical questions arise. This can be particularly helpful when it comes to addressing bias concerns that may occur as AI products learn and expand.

    Technology is a dynamic and rapidly evolving category. And as such, developers are often working on very compressed timelines. But to get AI right, developers need time to suss out the bigger picture around their products and bake in everything possible to make sure products are set up for ethical use in the short, medium and long term. If they don’t, not only will reputational damage be done to a company, but a company’s entire product pipeline could be stunted indefinitely as products need to be pulled offline entirely.

    Are Developer Teams Actually Prepared to Build Ethically?

    Setting a concrete mission statement that is centered around ethics is a great start for any technology company. But without a more systematic approach to instilling principled behavior in developer teams, companies will struggle to drive tangible results in their pursuit of building ethical products. Additionally, given how complex ethical AI development has become—thanks to innovations in quantum computing, among other things—even the most seasoned developers will have trouble keeping up with the developments and desired standards relating to a company’s ethical AI goals.

    Therefore, beyond just laying out overarching messaging, companies need to codify their ethical intentions by building an entire infrastructure that equips developers with the ongoing training and resources they need to constantly keep ethical standards in mind. If not, confusion will almost certainly ensue, missteps will occur and ethical standards will slip as a result.

    Unfortunately, despite the promise, the AI world has fallen short of meeting the ethical frameworks we need to have in place to both solve the problems of tomorrow while also serving the public good. But this doesn’t have to be the case. By asking these few simple questions, companies can empower developers and build the ethical development infrastructure that is needed for AI to achieve its full potential.

  • Nobl9 Adds Hydrogen Platform to Surface Technical Debt Issues

    Nobl9 Adds Hydrogen Platform to Surface Technical Debt Issues

    Nobl9 today unveiled a Hydrogen platform that makes it simpler for DevOps teams to identify technical debt issues as they manage service level objectives (SLOs) as code.

    Hydrogen enables DevOps teams to define SLOs using a simple wizard or by embedding code within their application as part of a DevOps workflow. That code is then used to automatically collect data from platforms such as Datadog, New Relic, Prometheus, Splunk and others with requiring any additional instrumentation.

    Nobl9 COO Kit Merker said that approach also makes it possible to surface technical debt that inhibits achieving those goals via the Hydrogen platform. Armed with those insights, it then becomes easier for DevOps teams to focus on reducing or eliminating that technical debt because Hydrogen automatically generates a ticket in the Jira project management application—widely used by DevOps teams—to make sure the issue is addressed. Otherwise, in the heat of a DevOps sprint, the issue is likely to be forgotten as the application development project continues to move forward, noted Merker.

    The ability to identify that technical debt is an outgrowth of the ability to manage SLOs as code that is enabled by the core Nobl9 software-as-a-service (SaaS) platform. Hydrogen extends that capability by automating workflows whenever a specific service shows indications that it cannot meet objectives because of a dependency on a legacy platform that needs to be upgraded, added Merker.

    There is also a service health dashboard that organizes SLOs into logical groups that are mapped to features via labels, which Merker noted makes it possible for multiple stakeholders to easily identify which issues affect a particular service most. Hydrogen can also trigger a variety of automated workflows to prompt additional investigations that escalate as services worsen.

    Overall, Hydrogen is designed to provide engineering teams with more accurate context that can be used to prioritize which issues should be addressed first during any technical debt planning cycle, said Merker. Hydrogen can enforce code release policies based on technical debt budgets that are enforced via integrations with continuous integration/continuous delivery (CI/CD) platforms.

    Technical debt generally refers to any code change that is required to optimize a service that is not immediately addressed. The more legacy platforms there are in an IT environment, the higher that technical debt tends to become. At a time when more organizations are building and deploying microservices-based applications, that technical debt, over time, tends to adversely affect applications that are much more dependent on external services than a traditional monolithic application. A single technical debt issue can have a cascading impact on multiple microservices-based applications that would, otherwise, would be difficult to detect.

    The challenge, of course, is that technical debt doesn’t always get the attention it deserves when most of the IT team is focused on rolling out the next great application. However, as application environments become more complex it may only be a matter of time before all the technical debt that is being accumulated becomes unsustainable.

  • Successful Software Development in a Hybrid Environment

    Successful Software Development in a Hybrid Environment

    The desire to work from home or from anywhere has only increased as the COVID-19 pandemic lingers. Employees cite a number of reasons why they prefer to skip the office, including cutting commuting times, being more productive, caring for family members and exploring new locations. People are increasingly comfortable with remote interactions and the new technology tools that have sprouted to support the work-from-anywhere trend. On average, employees said they want to work from home 2.5 days a week, according to a monthly survey of 5,000 Americans, while 73% of employees seek hybrid work environments where they have some flexibility in where and when they work. 

    The rapid spread of the COVID-19 Delta variant also prevented employers from enforcing a full-time return to the office. As a result, the new normal for today’s workforce will remain hybrid at best—a few days in the office and a few days working at home. We are a workforce in transition. For many companies, this has put an unnecessary strain on their digital transformation initiatives.

    A question remains: How can companies continue to innovate and execute on their software development initiatives with their employees separated from their teams and offices? Here are some of my recommendations for helping organizations to continue their software development projects in today’s hybrid work environment:

    Inclusive Environments

    Hybrid workforces require a highly inclusive environment. As a nearshore IT partner that works with hundreds of clients remotely, we ensure that our teams have the same access to managers, HR and the technology necessary to succeed on projects and to productively engage with clients. For example, we have learned that the best way to be inclusive is to take either an all-virtual or all-in-person approach during client meetings. It’s also critical to train your managers to provide the same advancement opportunities to employees regardless of whether they are in or out of the office. From the executive team on down, everyone needs to support employees, regardless of where they are. The same goes for onboarding new employees and partners—a mostly virtual process over the past 18 months. Increasing online mentoring and onboarding platforms to connect employees and to manage client projects while the workforce is hybrid is another significant approach we have taken to ensure everyone feels included and engaged. 

    Collaboration and Knowledge-Sharing 

    Employees were abruptly forced to transition away from the office where they were used to frequent impromptu meetings and lunchroom chats. For many, this shift had a negative impact on brainstorming, collaboration and knowledge-sharing and thus, innovation. We give our teams the flexibility to use different technology tools to make up for what they miss most in an office environment—regular, casual human interactions. Our teams use a variety of communications tools for frequent check-ins to connect with clients and their co-workers. As a result, our people say they are more engaged with team members and clients than ever before. They are doing more impromptu chats and “instant” meetings with colleagues and clients as if they were in the office. We also migrated to video conferencing as our communication channel of choice. Video conferencing tools increase engagement and allow team members to join virtual meetings anywhere from their preferred devices. The ability for teams to interact, share and collaborate wherever they are is essential to developing cutting-edge teams and software. 

    Trusting Cultures

    According to the Harvard Business Review, 34% of employees felt that their supervisors “expressed a lack of confidence in their work skills,” and an even more significant number of workers reported feeling that they needed to be constantly available to prove themselves. Sentiments like these highlight a lack of trust, impacting development outcomes. Employers need to trust that their employees are working diligently and consistently throughout the workday or whenever they can successfully complete the tasks at hand. For example, working remotely allows individuals to work when they feel most productive. Organizations need to recognize individual productivity cycles and understand that different team members may be productive during different times of the day, including outside of normal business hours. 

    Being transparent, forthcoming and open about expectations are keys to building trust with employees. Successful digital transformations and innovative software development are only possible with the right team and people. From a client’s perspective, these are the types of IT partners they want on their side. Technical aptitude and an environment where all employees feel valued, trusted and motivated to do their best are critical for developing effective digital solutions.

    Employees have made it clear that they don’t want to be back in the office full time. For many organizations, a return to normalcy centers on developing a hybrid workforce that can work effectively with digital development partners. Creating the right environment and strengthening employee relationships are keys to ensuring software development projects can continue successfully in today’s new normal.

  • Prioritizing Scalability, Reliability and Security in Engineering

    Prioritizing Scalability, Reliability and Security in Engineering

    As digital products and services are more deeply embedded in critical industries and infrastructure and the implications of problems grow in scope, engineering organizations are renewing their focus on building platforms that are scalable, reliable and secure. More importantly, they are recognizing that this isn’t the responsibility of an SRE or CSO, it’s an ethos that must be carried each day by every engineer on the team. This is an important shift—from teams and cultures that valued speed of delivery above all else to teams and cultures that make high-quality systems the foundation of everything they do.

    This isn’t easy, and big cultural changes don’t happen overnight. There are many things that can go wrong when the team is operating in the legacy mode of prioritizing quick time-to-market but there are also some strategies and best practices for beginning the process of cultural change across your engineering organization.

    The Old Way of Doing Things

    You’re the engineer on call, and you get woken up at 3:00 a.m. by an alert that tells you an app is down. Groggy and annoyed, you look at the message and have no idea what service it’s referring to or where to begin.

    After nearly an hour, you can’t figure out who owns the service or how to get it up and running. So, you call that senior engineer on your team—you know the one—the person who gets called every time there’s a tricky question or problem. Thankfully, they answer your call in the middle of the night and help you bring the app back up. But in a month, the same scenario happens again; only this time, when you go to call that senior engineer, they’re no longer there. They quit to go work at a company that cares about reliability.

    Best Practices for Today

    How can you avoid this vicious cycle? Here are some best practices you can implement to begin shifting focus away from speed and toward scalability, reliability and security.

    1. Evangelize the Narrative That the Systems you Work on Matter

    At the end of the day, your systems are there to serve your customers and users. Leadership and teammates who embody these values are incredibly important. People should worry about letting their customers down, not about being yelled at by their manager or receiving a bad performance review.

    2. Set Explicit Expectations about Uptime

    When you say that your app needs to have 99.99% uptime, it doesn’t have the same impact as saying 52.6 minutes of downtime a year. Translate uptime numbers so they’re tangible—and on people’s minds every time there’s an outage.

    3. Don’t Sweep Problems Under the Rug

    After the dust settles from an incident, it’s important to get together and talk about it. Be transparent about what happened, which person or team made the error and what the implications to users were. The idea isn’t to point fingers or assign blame but to bring the team together so that you can learn, evolve and figure out how to prevent this from happening in the future.

    Here are some questions you can use:

    1. Who wrote the code?
    2. How was it tested?
    3. Should our automated testing have caught this?
    4. Who reviewed this code?
    5. Were they the right people to review the code?
    6. Why wasn’t it caught in the staging environment?
    7. Who released it and who went through the release validation checklist?

    Formalizing this process lets everyone on the team know that mistakes are part of the job and that there’s a standard way that problems are handled. This is a great way to help engineers feel free to do their best work without fear or avoidance.

    4. Define Individual Owners for Every Piece of the System

    If there’s any confusion about who owns what within your engineering org, you need to address that right away; it’s a massive problem. Not only do you need an owner for every part of the system, but they must also be empowered to fix issues and know that they’re the ones on the hook.

    5. Invest in Documentation, Runbooks and Logs

    The owner of each piece of the application is also responsible for making sure that documentation is up to date, runbooks are clear and easy to follow and logs are readily accessible. When you’re getting paged at 3:00 a.m. about a service you’ve never heard of before, these resources are key.

    6. Prioritize the Delivery Pipeline Like it’s a Key Feature

    You should always be thinking about how to build safeguards around your workflows, like automated testing or new tools. This may mean you need to go toe-to-toe with product managers to make sure the work required to build a robust delivery system isn’t getting kicked down to the backlog.

    7. Get Business Buy-In by Using Terms They Understand

    Unreliable code is technical debt. And debt is something all leaders understand, regardless of their technical abilities. Stripe published a survey in 2018 that found the average developer spends more than 17 hours a week dealing with maintenance issues, costing $300 billion per year globally. If you’re pushing to invest in SRE practices, those numbers might help you make your case.

    Culture comes first, but the right tools can reinforce the culture and drive accountability over time. Tools that help teams keep track of critical information such as service owners, documentation and runbooks can help tremendously. Additionally, having easily available dependency maps of the architecture are key to quickly understanding complex systems. Lastly, setting organization-wide standards for best practices and providing templates for spinning up new services that follow these can help ensure that these things are not forgotten.

    This article was based on a talk given by the author at Conf42: SRE 2021. 

  • Low-Code and the Rise of the Citizen Developer

    Low-Code and the Rise of the Citizen Developer

    Low-code technologies have become increasingly popular for helping businesses adapt to ever-changing environments quickly by allowing them to build, customize and deploy apps with little to no coding. At Low-Code/No-Code Virtual Summit, taking place on Nov. 18 at 9 a.m. ET, luminaries of leading organizations in the low-code community will share valuable insights on their digital transformation journeys and the role of low-code/no-code in their digital strategies.

    Attendees will get an intimate look at how organizations are embracing low-code technologies to advance their business while improving user experience. The virtual event explores the vast and growing ecosystem of technologies that are changing the face of application development, featuring sessions on:

    • The rise of the citizen developer
    • Security and compliance in low-code applications
    • How low-code is transforming software development
    • Low-code versus no-code
    • Low-code trends

    Low-Code/No-Code Virtual Summit features an exceptional lineup of low-code and industry experts, including:

    • Derya Sousa, co-founder and COO at Kianda Technologies
    • Venkat Thiruvengadam, CEO at DuploCloud, Inc.
    • Andrew Manby, head of product management at HCL Software
    • Asna Javed, hybrid cloud build team and developer advocacy leader at IBM
    • Eren Akbaba, cloud architect at IBM
    • Charles Kolodgy, cybersecurity strategist, advisor and educator at Techstrong Research
    • Daniel Topham, CEM for digital, strategic solution architect at Everbridge
    • Bala Madhusoodhanan, principal architect at TJX
    • Paul Porter, VP of sales engineering at Everbridge
    • Gunndarr Dotter, regional sales director at HCL Software
    • Amy Hart-Koullapis, communications systems specialist, global marketing and communications at World Vision International

    The virtual environment features an auditorium where attendees can watch the sessions by the experts and an exhibit hall lined with booths showcasing the latest solutions from leading low-code companies. In the exhibit hall, attendees can download resources and interact with partner sponsors.

    To start off the event on a high note, we have scheduled a yoga class at 9 a.m. with a certified instructor.

    Registered attendees will receive a link to access the virtual environment on-demand for up to 30 days after the live event.

    To check out the full agenda and to register for free, visit the Low-Code/No-Code Virtual Summit website.