Category: Blogs

  • The Evolution of Technology Driven Banking

    The Evolution of Technology Driven Banking

    History repeats itself with every technological revolution, sparking the same old fears about job loss and human redundancy. Much of this is unfounded because each time, when routine and repetitive jobs got mechanized, those who were displaced often were elevated into bigger, better roles. The pattern was consistent across industries; whether it was manufacturing, retail, entertainment or banking, the technology of the day – from the steam engine to the mainframe – augmented and amplified, rather than eliminated, the work of human beings.

    This time around, the debate is about cloud-driven banking shaking up employment in the financial sector. But the reality is the same, as always.

    A Look at Banking Functions

    To understand what is happening, let us segregate various banking functions from an inside-out perspective. Strategy definition occurs at the top, at the level of the board and senior management. Lower down the order, the strategy is converted into plans, which are then executed by various teams. All these activities involve data operations such as collection, comparison, tracking, monitoring and course correction. There is no interaction with the end customer just yet.

    The second set of functions is aimed at achieving strategic and financial goals. These functions relate to business execution – expanding the corporate, retail or investment banking business, adding branches, acquiring customers and so on. The desired outcomes are defined as KPIs for individual managers, expressed as growth targets and budgets.

    The moment of truth is when these internal functions flow out of the bank to the last mile – in other words, when a frontline employee, such as a branch manager or relationship officer, comes in contact with the end customer. Not much has changed in the way banking has been transacted since 14th century Greece. The counter has been replaced by the teller window, but the interactions are still about facilitating lending, borrowing and payments. What has changed, however, is the number and type of participants. In addition to the money lenders and joint stock companies of old, today there are banks, of course, but also fintech firms and big tech companies. The mode of service delivery also has changed (perhaps beyond recognition) to include branches, mobile phones, websites, wearable devices and even social media applications.

    The Role of Machines

    Let us examine the role of machines (which includes software and digital technology, including cloud) in each set of functions. Strategy visioning and implementation clearly need human intelligence; however, machines can provide rich, accurate and timely data so the people in charge can make better decisions. Similarly, while planning activities – involving interpretation, visualization and application of past experience – too cannot be handed over to machines, they can certainly leverage machine learning to do what-if analyses and simulate various scenarios in real-time.

    Business execution functions offer more potential for humans and machines to actually work together, by farming out repetitive and routine work, such as data collection, comparison and analysis, to the latter. Following that, the human workers will apply their wisdom to machine-generated insights to take course-corrective actions to, say, improve revenue, lower cost, enter new markets, etc. In each case, far from taking over the role of human workers as feared, the machines are actually elevating them.

    Several operational goals are set up as part of business functions, with managers at the head office, zonal or branch level assigned responsibility for achieving them. While the managers make the decisions – for example, which channels to employ – implementing those decisions at scale is only possible with the help of machines – think origination, onboarding, document verification, KYC checks, credit rating analyses etc. This is how Paytm onboarded 200 million customers when India announced demonetization, and RBL acquired massive digital deposits during the pandemic lockdown. Without support from machines, their human employees would only have been able to handle a fraction of the business volume.

    That being said, there are some jobs that can, and should, be given to machines. A good use case is technical resolution – attending to issues in databases, networks, servers or applications – that can be performed proactively, preemptively and efficiently by AI-driven systems at a scale that is out of reach of human workers. What’s more, the systems will continue to learn and improve over time, so humans need only step in to resolve complex or exceptional issues. When a customer calls a contact center, call tracking, tracing and auditing, as well as caller identification, are best left to the machines, which will also route the call to the best available agent; the system can also suggest the best solution based on past history. Note that while the machines take over these jobs, no roles are actually lost. The agent remains in charge of making the final decision and communicating it to the customer.

    Cloud-Driven Banking

    Now let’s look specifically at the impact of cloud-driven banking on human workers. When it comes to lowering cost while improving agility, the cloud is unbeatable. Today, when banks are under immense pressure to reduce cost from both a low-interest environment and new competitors operating at half their cost-to-income ratios, it is unviable for them to maintain expensive physical infrastructure, such as data centers. Cloud service providers and hyperscalers are the answer for managing everything from servers and systems to databases and data centers. Outsourcing these functions relieves the banks’ operators but does not make them redundant, because they can be redeployed in higher roles, such as planning for growth. This means that instead of providing services to the business organization, they will demand services from the cloud providers; in other words they will become “service seekers” instead of “servicers.” In this role, they will require higher-level skills like negotiation, critical thinking and decision making.

    To sum up, whether it is artificial intelligence or machine learning, when technology takes over a routine banking function, it always opens the doors for human workers to elevate themselves into a more rewarding role. Cloud-driven banking is no different.

  • Languages and DevOps: To The Cloud!

    Languages and DevOps: To The Cloud!

    Cloud and DevOps are almost a match made in heaven. Cloud started truly gaining steam in the age of DevOps and Agile, and has adapted – or grown up in it – well, depending on your viewpoint. If not for the combined issues of data gravity and data (im)mobility, we might have gone even farther than we did into the cloudy world.

    While the breadth of possible cloud apps means a wide variety of languages is in use, Node rules this roost. Every conceivable language is used in cloud development – because, in the end, they’re just servers – but Node is the go-to language of today. The broad use and appeal of JavaScript make it an obvious choice for enabling full-stack development, and the pool of developers is larger than any other language today. Other languages are used, but not in the numbers that Node is. Python is the challenger, and a surprising number of PHP sites still exist, but forward-looking development aims at Node or Python. Considering the distance from the hardware, there is less call for C in cloud than there is in other areas of development, but it isn’t gone, since interfacing to the OS is also often done in C.

    Targeting cloud is not so much about language as it is DevOps tooling, though. All of the major Git companies have cloud-centric extensions (this is the core of GitOps) that raise the level of “fully automated.” Cloud environments, by their nature, provide APIs for infrastructure, and the Git vendors (and many, many others) have hooked into those APIs to make deployment an integrated part of DevOps at a level of detail that other environments (with the exception of containers) require a lot of work to match.

    The negative to cloud-centric development is lock-in, of course. Creating an entire DevOps toolchain and process that supports vendor X will not work directly with vendor Y. Tools can help with this issue, but the real solution is in our next installment – container development.

    The part of development that arguably benefits the most from cloud-centric development is testing. It is easier to spin up a test environment as-needed and spin it back down when testing is done – no need for a spare set of hardware or a stand-alone VM server; just redirect the DevOps ecosystem and spin it up, then account for data (scrubbing, copying, etc), and you’re off. Codify the steps for data, and you have a re-spinnable environment for test-on-demand.

    The part of cloud that is arguably the weakest is security. Let’s face it, far more of your infrastructure is publicly (or semi-publicly, if running in a VPC) exposed than in a data center. There are far more places to lock down, and a sometimes-bewildering number of options to secure. But the flexibility of pay-as-you-grow makes it an appealing option, and there are tools to help manage all those lockdown points. Just make sure that you’re not the weak point in the shared security model.

    You. Rock.

    Cloud makes a lot of things easier, and Node makes development of any step in the stack easier by using the same underlying language on the server that is used in browsers and in many mobile development platforms. Node “feels” more right for web development, at least because one connection, one call … even if it makes long-running processes require a bit more work.

    Whatever you choose, pay attention to how deeply invested in the cloud vendor’s proprietary interfaces you are, because, like all technical decisions, one day you or your replacement will have to get around those interfaces. And keep making the software the org needs.

  • EP 7: Accessibility and Usability

    EP 7: Accessibility and Usability

    In episode 7, we discuss strategies for incorporating accessibility and usability into DevOps and software creation processes.

  • Progress Unveils First Update to Chef Automation Portfolio

    Progress Unveils First Update to Chef Automation Portfolio

    Progress today announced it has enhanced its Chef Enterprise Automation Stack (EAS) and released a new version of Chef Infra Client that promises to make the programming language on which EAS relies more accessible.

    Sudhir Reddy, vice president of engineering for Progress, said the latest versions of both offerings are the first updates to the Chef portfolio since Progress acquired the company last fall.

    Chef EAS combines elements of the Chef portfolio in a way that makes it easier to develop and integrate DevOps workflows that span everything from provisioning infrastructure to deploying applications. The latest update to EAS adds the ability to automatically execute compliance audits as part of any Chef Infra Client run using Chef InSpec tools. At the same time, the latest update also simplifies the implementation of the patch management processes.

    DevOps teams can also view and manage Chef Infra Server details via the Chef Automate framework. Those views, when combined with Chef Infra Client Run Reports, provide insights into the various policies and Chef objects in use on a system.


    Finally, the Chef Workstation module includes the Chef Habitat command line interface (CLI) to further simplify workflows.

    Ultimately, Progress is moving toward creating a common user experience across all elements of the Chef EAS suite of tools, Reddy said. In effect, EAS is emerging as the control plane through which the entire Chef portfolio will be managed, Reddy added.

    Meanwhile, Infra Client 17 promises to make the Chef Language underpinning that suite more accessible. It provides a streamlined developer experience as well as pre-built integrations with various cloud services. In addition, Progress is adding support for various ARM processors used in cloud services, macOS Big Sur, the Apple M1 architecture, Windows 8 and PowerShell Core.

    Progress also enhanced its ability to securely capture metadata from the Amazon Web Services (AWS) public cloud as well as capturing data from Microsoft Azure clouds.

    An early pioneer of a framework for automating IT infrastructure-as-code management, Chef is still widely employed. However, rival open source frameworks have since emerged, which Chef eventually responded to by making its core platform also available as open source software as it changed its business model. Progress today also announced it will recognize external contributors to the platform with recognition awards. Progress reports that, in 2020, there were more than 6,000 contributions from over 350 contributors in the Chef community in support of Chef Infra, Chef InSpec and Chef Habitat.

    It’s still unclear how the battle for infrastructure-as-code framework management supremacy will ultimately play out. While many developers have clearly shown a preference for rival open source tools, Progress is positioning the Chef portfolio as a framework for IT organizations that need to automate processes at scale, including how application are deployed on infrastructure that is provisioned as code.

    Of course, many rival framework providers have similar ambitions. The challenge, of course, will eventually be convincing organizations that tend to employ a wide range of tools across different departments to finally standardize on one framework versus another.

  • Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    Eclipse Foundation Creates Adoptium Working Group for OpenJDK Binaries

    The Eclipse Foundation announced today a working group that will establish a governance framework for an Eclipse Adoptium project that enables developers to download compatible runtimes based on OpenJDK source code.

    Members of the Adoptium working group include Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic and Red Hat.

    OpenJDK is a free and open-source implementation of the Java Platform, Standard Edition that is provided by Oracle. AdoptOpenJDK was created in 2017 to provide open source, high-quality Java runtimes based on OpenJDK. Since then, AdoptOpenJDK has been downloaded more than 240 million times.

    The Eclipse Foundation is now continuing that effort under an Eclipse Adoptium project that aims to become the primary source for OpenJDK-based binaries. The Eclipse Adoptium working group has negotiated with Oracle to create an OpenJDK Community TCK License Agreement (OCTLA) that will enable it to run compatibility tests to ensure conformance to the Java specification.

    Mike Milinkovich, executive director of the Eclipse Foundation, said the Adoptium WG will provide the infrastructure, marketing, community building and developer education required to ensure timely releases and adoption of Eclipse Adoptium runtimes.

    OpenJDK is a reference implementation used by multiple vendors to create their own binaries, which are only guaranteed to be compatible with the standard until the next update arrives; updates are released approximately every six months. The Eclipse Adoptium project will make it simpler for developer teams to identify which binaries are compatible with specific implementations of OpenJDK. Ultimately, the goal is to encourage developers to build applications using frameworks that make use of new OpenJDK features as they are added to the platform versus continuing to rely on older binaries.

    At the same time, however, the Eclipse Foundation is also looking at making it simpler for enterprise IT teams to rely on long term support (LTS) licensing agreements that would be based on Eclipse Adoptium runtimes, Milinkovich noted.

    Despite the plethora of programming languages developers use and even after 25 years, Java remains the dominant language for developers working in enterprise IT organizations. Over the last few years, OpenJDK has gained traction as organizations adopted an open source implementation of the specification that enabled providers of frameworks for building applications to reduce licensing costs.

    It’s not clear at what rate enterprise IT organizations are replacing proprietary editions of Java with OpenJDK. However, in the wake of the economic downturn brought on by the COVID-19 pandemic, reliance on open source software has increased to reduce costs. At the same time, many organizations are looking to build microservices-based applications using Java frameworks that are based on OpenJDK runtimes.

    Regardless of the underlying platform employed, as developers are asked to build and deploy applications faster, most of them will rely on the programming language they already know rather than take the time to master another.

  • Managing Business Risk in a DevOps Context

    Managing Business Risk in a DevOps Context

    We hear a lot in the industry about the importance of automation in DevOps to enable speed. However, there is another element that is often missing in the discussion – risk, compliance and security. Traditionally we have a zero-sum approach, where we need to either go fast or be safe and secure. It’s one or the other. Or, maybe not! There is an 80%-80% middle ground to consider. Balanced development automation is a natural evolution of DevOps; it is not just about the technical side anymore, but also includes the risk and the compliance side, as well.

    Aligning Executives

    How do we get business executives and risk executives, at the strategy level, to align on this idea of balanced development automation? First, it is important to realize that what represents a risk for businesspeople is different than the risk that’s perceived by the development group.

    For example, let’s say there is an urgent requirement for some sort of additional business functionality in response to competitive action, or even in response to a pandemic. From a business standpoint, risk might represent a failure to deliver an effective solution within the particular timeframe required. From an IT standpoint, concerns about risk are likely going to be different from the business risk.

    That being said, it’s a futile exercise to convince business management to think in terms of perceived IT risk as opposed to business risk. IT must be able to translate the risks of their development work into business risk, or management may not see the potential impact of that risk. And so, pressure remains to “Get this thing done as quickly as possible!”

    Even at the executive levels, there is a discrepancy in identifying what risk really is. That is true at similar management levels at different organizations, even within the same industry. Let’s look, for example, at the whole issue of security and how much effort we should be paying to validate the security of a system that we’re putting in place, or that we already have in place. If an organization has experienced a breach, they are much more likely to have a management team that is concerned about security. In a different organization that has not seen any security breaches, they may not be paying as much attention or making the appropriate investments to make sure systems are secure.

    Aligning DevOps and Security

    We also need DevOps engineers and security engineers to align at the tactical level. So how can these teams, that are typically at the program or project levels, integrate and think about balancing development speed with risk and security? Operational teams are very important in achieving balanced development automation. If we look at the risks from the perspective of the development team, it doesn’t matter what technology you’re using to develop an application, or even if you’re implementing someone else’s application.

    From an IT standpoint, one of the most likely risks is failure to deliver functionality of the particular project that you’re doing. That is an example of delivery risk, which senior management is very concerned about. The way that tends to manifest is in delayed delivery or allowing the business to change their mind during the particular project. The risk of not delivering the functionality that’s required is increased. The process is just going to crack simply because the project has not been managed effectively, requirements were not stabilized or adequate testing was not done.

    That is an extremely high risk that development groups need to be aware of. A development group needs to apply some type of balanced methodology and minimize the likelihood of a gap between the expected outcome of the project and the actual outcome.

    Demand for Balanced Development Automation

    Today’s business context demands both speed and some awareness of risk from development teams. This will only be achieved through alignment at the executive level and at the tactical level. Focusing on areas of business risk are essential to achieving this alignment.

  • Cooperative Gaming: Software Teams’ Secret to Success?

    Cooperative Gaming: Software Teams’ Secret to Success?

    Trust falls and team backpacking trips are out — cooperative gaming is in. Don’t think embarking on group Minecraft missions could help deliver great software products? Think again. A 2019 BYU study found a 20% increase in office productivity after just 45 minutes of gaming.

    Software engineering is a mentally taxing endeavor, and many developers are under mounting pressure to deliver. To destress, many software teams use gaming to unwind during work hours. Gaming, it turns out, has added benefits of improved morale, increased productivity and lowered ego around unofficial hierarchies within the office. Setting aside time to recharge with collaborative gaming could increase a workplace’s health and help software teams work together to deliver products more efficiently.

    I recently spoke with Max de Lavenne, founder and CEO of Buildable, ally to the workplace gamer, to see why he embraces gaming as a regular part of his software developer team’s weekly regimen. Buildable adopted gaming and saw a notable impact; de Lavenne shared how other teams could similarly introduce gaming to improve performance.

    Gaming in the Workplace

    Traditional business environments don’t typically embrace fun activities on the clock — there is a clear separation between work and life. But at Buildable, gaming is integrated into the weekly routine. The Buildable engineers set aside about 45 minutes mid-week for collaborative gaming, typically on Wednesday or Thursday. The Buildable team, made up of about 20 software engineers, favors Rocket League and a modded version of Minecraft.

    According to de Lavenne, gaming is a great way to foster collaboration and intuitive group thinking. “Getting recharged is really important,” he said. He encourages the team to adopt cooperative multiplayer games; no solo play. He also discourages violent and aggressive RPGs, like first-person shooters.

    Workplace gaming isn’t unique, in and of itself — many teams at other companies will often play Haxball during coffee breaks or get into a Call of Duty: Warzone match from time to time. Yet, few leaders have the stomach to sanction gaming as integral to the developer’s workflow and overall team dynamic.

    “Engineers collaborate best when they respect each other and have confidence in each other’s skillsets,” said de Lavenne. “They are individuals, but there’s a lot of groupthink in teams.”

    Benefits of Gaming

    Gaming has proven benefits. In fact, researchers at Kansas State University found that employees who spent one or two minutes during breaks in their day playing games such as Candy Crush on their phones reported being happier than their peers. Similarly, de Lavenne noticed improved mood and other positive outcomes from collaborative gaming at Buildable, including:

    • Better team morale: Having scheduled gaming breaks to look forward to each week keeps attitudes positive. Software engineering can cause fatigue, which managers need to monitor carefully. “People get tired, and there’s only so much the brain can do,” de Lavenne said .
    • More fluid communication: Collaborative gaming focuses a team’s effort on a collective activity free from monetary incentives, bonuses or other hidden agendas. Afterward, de Lavenne said he’s noticed more fluid communication emerge among the team.
    • Increased collaboration: There’s satisfaction in doing something together, and de Lavenne reports that gaming has redefined collaboration for his team in unique ways. Employees take the cooperative, creative attitude fostered from gaming experiences and apply it to more structured, scrum-type environments.
    • Increased productivity: Dedicating one hour for gaming per week equates to about a 2% loss of labor time. However, de Lavenne reported that the productivity gains afterward surpass that lost time and more.
    • Reduction of ego: In work environments, unspoken hierarchies inevitably exist. Interestingly, collaborative gaming can completely reverse those social dynamics. Seeing senior engineers at the bottom of a gaming leaderboard can be humorous and boost confidence for younger engineers.
    • Combating isolation: Throughout the pandemic, remote work has left many of us feeling lonely. For young engineers without families, a big chunk of social interaction may occur in the workplace. Games can help maintain good spirits by bringing teams together virtually.

    Tips for Encouraging a Healthy Gaming Culture

    The overall goal is to promote enjoyable, freeform shared experiences. To enable this, de Lavenne shared a few tips on integrating games into developer team workflows.

    First off, gaming should not be mandatory, as making it a required activity would somewhat defeat the purpose. Instead, gaming should be fun and completely voluntary. If people would rather get in some physical exercise or check Instagram, they should feel just as free to do so.

    Also, as much fun as gaming with the team could be, it’s helpful having the CEO removed from this activity, de Lavenne advised. This is important so that players don’t feel they’re constantly monitored. Yet, leaders may want to have a say in the type of game, as well as when it’s played.

    Furthermore, the game doesn’t need to be an immersive RPG — it could be as simple and accessible as Jackbox. Cooperative board games like Dungeons & Dragons or Gloomhaven could have just the same effect as digital games.

    Outside of encouraging collaborative gaming, leaders can take other actions to boost morale and productivity. One such action is leaving chat channels unmonitored, so that team members can engage with each other on whatever subject they want without oversight. Another way to affect morale is location, noted de Lavenne. As I’ve written previously, hiring interest is expanding outside of traditional tech hubs. Buildable, for instance, chose to headquarter in suburban McMinnville, Oregon, for its walkability, greenery and better work-life balance than in larger cities.

    Gaming Is Where It All Began

    Multiplayer video games, LARPing, and AR/VR environments not only offer an escapist retreat — they represent nostalgia. For many programmers, video games were a doorway to the computer science field in general.

    “I’ve rarely met a software engineer that never gamed,” de Lavenne added. Gamers often seek out the highest-performing machines. And chances are, those kids with limited resources built their rigs from scratch. “This inspires you to learn about hardware, and you start to care about speed, compile and software activities,” said de Lavenne.

    From Atari to Minecraft, gaming has been a shared passion among generations of programmers. Recognizing this affinity can unite a team. Because at the end of the day, “building good software is all about people,” said de Lavenne.

    Of course, software development takes extreme diligence, planning, and structure to deliver bug-free, user-centric products. But under intense pressure to perform and meet new digital innovation demands, software developers could get burned out without a bit of distraction. With gaming, “the team really comes alive,” de Lavenne said.

    So, when things get slow, check out what’s hot on Steam. You may, ironically, just find your next productivity breakthrough.

  • Grafana Labs Aligns with Elastic on Observability

    Grafana Labs Aligns with Elastic on Observability

    Elastic and Grafana Labs have allied to create a plugin through which DevOps teams that are employing Elasticsearch within a DevOps workflow will be able to invoke a monitoring platform, based on Prometheus, that is managed by Grafana Labs.

    Raj Dutt, Grafana Labs CEO, said both companies are dedicating engineering resources to building and maintaining a plug-in for a service, based on open source Prometheus software, that is rapidly becoming a de facto standard for observability in DevOps environments. One of the primary reasons for that expanded usage is that Grafana Labs doesn’t require DevOps teams to move data into a central repository to analyze it, Dutt said.

    The overall goal is to eliminate the “tunnel vision” that results when relying on tools that only visualizes a narrow set of metrics, Dutt added.

    The cloud platform provided by Grafana Labs is based on open source Grafana visualization tools. The primary tool for visualizing Elasticsearch data is based on open source Kibana tools. Grafana, however, is based on a fork of Kibana, so the plug-in represents an effort to bring those two open source communities closer together. The two companies plan to collaborate on including more aggregations, broader query language support and support for space-saving constructs like rollups as the partnership evolves.

    Grafana Labs provides a cloud service that aggregates data, pulled from multiple instances of Prometheus, deployed on clusters and servers. Prometheus, especially, gained a lot of traction as organizations began to deploy Kubernetes clusters that are also based on open source software. Both Kubernetes and Prometheus are being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    Once DevOps team initially employ Prometheus to monitor Kubernetes, they frequently expand deployments to monitor additional platforms. That shift has resulted in many providers of proprietary monitoring tools to extend the data they consume to include the metrics captured locally by Prometheus. Grafana Labs claims it has more 1,000 customers, including Bloomberg, JP Morgan Chase, eBay, PayPal and Sony, for a total of more 650,000 active installations of Grafana around the globe. Existing customers of Elastic that are paying for Elasticsearch support include Cisco, eBay, Goldman Sachs, Microsoft, The Mayo Clinic, NASA, The New York Times, Wikipedia and Verizon.

    It’s not clear to what degree Grafana and Kibana might ultimately re-converge one day, but it’s clear there will be a fair amount of ongoing cross-pollination across the two projects. In the meantime, DevOps teams should be able to opt for whichever open source visualization framework they prefer alongside Elasticsearch.

    In the longer term, it’s clear greater appreciation for observability platforms that provide more context will drive a wave of consolidation among all the monitoring tools that enterprise IT teams rely on today. As part of the transition, enterprise IT teams might even standardize on a set of visualization tools that would eliminate the need to master different user interfaces. After all, the only way to actually achieve observability is through a set of tools that makes surfacing the context required easier to consume.

  • Make GitHub Backups Part of Your Development Process

    Make GitHub Backups Part of Your Development Process

    GitHub’s platform is the largest host of source code in the world, hosting over 190 Million repositories. So much of the code we rely on every day is hosted there. You are, in all likelihood, using it. But what would you do if, one day, all of the project code GitHub stored for you disappeared?

    Just like all other cloud services, GitHub follows a cloud computing principle called “shared responsibility” for data protection and security. It essentially means that users of a cloud platform and providers of said platform split the responsibility for safeguarding data. In other words, users are just as responsible for mitigating risks on their side of the equation as GitHub is on theirs. It’s all laid out in GitHub’s terms and conditions:

    Taking this into account, there are a handful of things that can impact your ability to access to data in GitHub. Here are a few:

    Account Compromises

    In July of 2019, Ubuntu Security reported that the credentials for a company-owned GitHub account were compromised. These compromised credentials were used to create repositories, issues and more.

    In this case, critical infrastructure was decoupled from GitHub, and the breach wasn’t allowed to spread. However, Ubuntu had to restore various repositories and issue trackers to their previous state. When rolling back from an account compromise like this, backups are infinitely helpful, as they give you a previously good state to compare with the current state.

    Additionally, attackers often leave backdoors in compromised codebases. This can allow them to gain deeper access once the initial discovery and remediation process is completed. If you only have your infected codebase, it can be challenging to uncover all the infected files or identify possible vectors for future attacks. Restoring to a previous version of your code eliminates that threat.

    Ransomware Attacks

    Ransomware is the act of taking control of data and encrypting it so that only the attacker can unlock it. The attacker will usually ask for a ransom to unlock the files; otherwise, they may delete the data.

    In May 2019, ZDNet reported on a ransomware attack in which a hacker held various repositories hostage for a fee. The hackers modified the git histories to the point where the repositories were unusable, and they demanded payment within 10 days to reverse the changes.

    These attacks can create a severe disruption in operations. Developers will be unable to commit code, creating a complete stoppage in new feature development. Bug fixes and even support tickets (if managed through GitHub) could also be affected. However, restoring from a backup would allow a business to continue working.

    Service Downtime

    Depending on a third party always carries some risk, and GitHub is no exception. No service can deliver 100 percent uptime, but when your entire business (or codebase) depends on GitHub’s availability, you might want to mitigate that risk by having your own backups.

    For example, in June 2020, GitHub experienced a major, hours-long outage before stability returned. So, if all your work was stored in GitHub, you would have had to wait for access to be restored. This downtime can be devastating if it occurs during a crucial launch window.

    These are just three examples, and they happen more often than you think. A recent report by Oracle and KPMG found that 49 percent of IT professionals could attribute recent data loss to their failure to safeguard data. That’s essentially the same odds as a coin flip. Having continual access to all your work shouldn’t be left to chance. That’s why you need a backup strategy.

    Strategies for Backing Up Data in GitHub

    1. Managing Your Own Backups: This means you are responsible for all the infrastructure, business processes and ongoing repair costs to create the backups. You might think this will be a more cost-effective option, but the ongoing labor and maintenance expenses tend to add up quickly. It also means your team may use up cycles on something that is not part of the core business. What you make up for in control, you lose in time and spent resources.
    2. Using a Third Party to Manage Your Backups: Sometimes referred to as Backup-as-a-Service (BaaS), this involves outsourcing backup management responsibilities to a separate company. It removes the responsibility from your business, but it might seem more expensive upfront. In most cases, there is nothing to do after choosing a provider. They manage the entire process, from cradle to grave. This includes any API updates (which can happen often), implementation and ongoing maintenance. The drawback is that you lose control. Terms of service can change, or the data that’s backed up could change. And, not all BaaS solutions are transparent in what they do and how they access data.

    So, What’s the “Right” Choice?

    For most businesses, the sheer amount of work required to build and maintain backup software is a non-starter. Development cycles are too valuable to tie up with work not directly supporting the business’s product roadmap. You may get to a size where you think adding this competence makes sense; however, even some massive multinational corporations use some form of BaaS.

    Just make sure you do your research. Read reviews, speak to their sales or development team and confirm that they know what they are talking about. You need to determine if they have built a credible product. For many PaaS and SaaS tools, third-party backup applications are built by faceless companies with no track record. Considering the level of access they will have to your data, you want to ensure they are reputable with a proven history of successfully building backup software.

    Regardless of the method you choose, having a backup strategy in place is vital. Due to the nature of how GitHub works and how important your code repositories are to your business, the sooner you get something in place, the better.