Forem: Arjan van Bekkum

Reflections of a DevOpsologist

Arjan van Bekkum — Tue, 14 Nov 2023 08:17:29 +0000

Author: Colin Dembovsky

“DevOps is the union of people, processes and products to enable continuous delivery of value to our end users.” Donovan Brown

At heart, I’m a developer. I love to sling code and be part of a team that slings code. But I’m also fascinated by people – and the intersection of culture and tech is what has drawn me to DevOps.

As I reflect over my journey, I see a lot of people who invested in me. Without them I would not be where I am today. Quite literally – I am an immigrant to the US and my career brought me here. I’ve also worked hard when opportunity presented itself. I’ve been mentored and have mentored others. I have learned some things along the way that I hope I can communicate through my story.

But wait – before I start: what is a DevOpsologist? I forget where I heard the term from (it’s not mine) but I love the sentiment. It comes from DevOps and the suffix “-ology” (the study of something, a branch of learning). DevOps is continually evolving and changing, and I don’t think we’ll ever “arrive”. Calling myself a DevOpsologist reminds me that there is always more to learn!

The Story

The Journey Begins

It was summer (at least in the Southern hemisphere) of 2004. I had just moved from Johannesburg to East London, South Africa where I joined a team of about 20 developers for a financial services company. I had been hired on as a senior developer – and little did I know that the next six years would come to define so much of my career.

I was now about three months into the job. My previous job hadn’t been anywhere close to anything from Microsoft. It was all C++, CORBA and Linux. Now here I was, a senior developer at a team using SQL Server and Web services built on .NET Framework 1.1. I had used CVS for source control before, and the new team was using WinCVS. It wasn’t pretty. There was almost no process in place – we deployed by using Visual Studio’s “right-click Publish” feature and fat-fingering was so common it was expected.

I remember thinking to myself, “I may not be the most experienced .NET developer, but there must be a better way to manage how we deliver code.” So I opened up a browser and used my favorite search engine, WebCrawler, to see if I could find anything better.

And I did. I found a tool that was so new it was still in beta. The installation took about a week – at one point the install failed and I couldn’t recover. In fact, the failure was so bad I ended up formatting the entire machine and starting again. But I persisted – and finally stood up a shiny new instance of Team Foundation Server (TFS) 2005 beta 2.

The Glorious TFS Days

So began my journey into DevOps. Except that the term DevOps hadn’t been coined yet. It was still “Application Lifecycle Management” (ALM). I don’t even think I heard that term until around 2008. But even if I didn’t know what it was called, I was doing it. Mostly by instinct.

We started by getting all of our code into TFS. We even started using automated builds with MSBuild! We could at least build from a known source of truth, rather than hoping what we had on our dev machines was the latest code.

Our next phase was adopting unit testing. I remember some very heated debates with the team. “We have too much code and our coverage will be practically zero!” was a common sentiment. I managed to convince the team that 0.2% code coverage is better than 0%, so we started by just ensuring that if we touched a method (or added one) that we would only deploy if we had a unit test for that changed code. Before long, we were in the 60% range for code coverage. Small, incremental changes added up having a large impact over time.

We also started using Work Item Tracking. We all underwent Prince2 training (it’s a flavor of Waterfall from the British Government) and customized our templates, work items and reports to match. Back then we had to create our own Release Management tool since there wasn’t one in TFS till years later.

Jump to Consulting

In 2008, I attended TechEd Africa in Durban, South Africa. This was my first large tech conference experience. I went to a talk by Chris Menegay, who ran a small consulting firm in Dallas, Texas called Notion Solutions. Chris had an ALM talk that featured TFS. I knew I wanted to move into consulting at some stage, but until that point I had no idea what to consult in! Hearing Chris talk about his team of ALM consultants, I knew that was what I wanted to do. However, my first child had just been born, and I didn’t think it was the right time to leave a job with a steady salary.

I attended TechEd Africa in 2009 – and Chris was a guest speaker again! This time I was ready for a change – so after his talk, I had a 5 minute conversation with him. I remember asking him if he did any work in South Africa, and he replied he could send a consultant over (later I found out he was thinking of Donovan Brown who worked for Chris at that stage). “No, I’m looking to get into consulting,” I responded. Chris and I had a chat with a key Microsoft figure – and someone I owe a debt to for all the help in my early days – Ahmed Salijee, who headed up Visual Studio sales for Microsoft in South Africa.

For some reason, Chris took a chance on me – and a few months later I started the South Africa branch of Notion Solutions! Chris put a few thousand dollars in so I had a steady salary, but I did everything. I was calling. I was delivering. I was invoicing – I learned so much during that time. Fortunately, I had the collective minds of Notion Solutions backing me, so I started confidently, even though I didn’t really know what I was doing. That was a good way to grow.

How did I get here?

In September 2010 Chris flew me out to a Notion Solutions gathering in Irving, Texas. It was a rare occasion to have all the Notion Consultants in a single place. I remember feeling awed. There I was in the same room as some of my “ALM heroes” such as Chris Menegay, Dave McKinstry, Abel Wang, Donovan Brown, Steve St. Jean and Ed Blankenship. “How did I get here?” I wondered – but I was determined that I would learn all I could from these folks and wouldn’t take my good fortune for granted!

Most of the Notion Team were Microsoft Most Valuable Professionals (MVPs) and I was inspired to attain that award too. So I started my blog – Colin’s ALM Corner which is still going today. In 2011, I was awarded my first MVP award. In 2012, I got to attend my first MVP Summit in Redmond, WA. There I met some folks that I am still connected to this day – leaders in the ALM community such as Marcel de Vries, René van Osnabrugge, Pieter Gheysens, Brian Randell, Nino Loje, Mickey Gousset, Esteban Garcia, Martin Hinshelwood and many others – including Steven Borg.

Moving to America

Steve and I connected really well – and eventually he offered me a position at his company Northwest Cadence. Northwest Cadence was based in Seattle and was also a small ALM consultancy. Northwest Cadence persevered through all the legal processes to move me and my family over to Seattle in 2016, and I’ve been in the US since.

Steve inspired me – he is an excellent communicator who knows something about everything. And his mastery of lean processes and agile was amazing. I remember thinking, “When I grow up, I want to be just like Steve!” I learned so much during my Northwest Cadence days, and still think in terms of flow, efficiency and queuing theory.

In 2018, Steve merged his company into Chicago-based 10th Magnitude. 10th Magnitude was doing some great Azure work, but was finding more and more customers wanted to modernize their software processes as they migrated their data centers to the cloud. The folks from Northwest Cadence brought a wealth of process consulting and DevOps to 10th Magnitude, so it was a really good fit.

Moving into… sales?

Soon after joining 10th Magnitude, there was an opening for a Solution Architect. I looked at the position and chatted to a few folks, and discovered it was a technical sales role. “I’m not a salesman, I’m a consultant!” was my initial reaction. However, I negotiated with the leadership and took the role on the basis that I would sell for 30% of the time, and consult for the other 70%.

That never turned out to be the case. I ended up selling far more than consulting. But one day I had an epiphany: I love to solve complex problems. And I was doing that in my sales process! I would meet with customers, and spend time to understand their environments, people and challenges. I then crafted services and deals that we would deliver to our customers to help them achieve their goals. While I was now in a sales role, I was able to do what I love doing – use tech and cultural engineering to solve problems.

What is this Git thing?

I remember when TFS introduced Git repositories around 2013. I couldn’t see the appeal – who would use a source control system that let you overwrite history? However, after spending some time with it I started to see the light – so much so that I did a talk at VSLive for a couple of years where I hypothesized that you can’t really do modern development if you’re not on Git!

And then – Microsoft purchased GitHub in 2018. So – reluctantly – I started to figure out how to use the platform. I preferred Team Foundation Server – which had changed names a couple of times and is now Azure DevOps. That is, until GitHub released GitHub Advanced Security (GHAS).

AppSec is the Future

I have a development background – Security was always the team that “prevented you going to prod”. I didn’t speak security, and I had never met a security professional that spoke developer.

But GHAS was different. I instinctively guessed that this was a tool that I wanted to align with. Over time, I was able to verbalize this instinctive feeling – it’s simply security tools for developers. I recognized that this was a game-changer.

At this stage I was the DevOps Practice lead at 10th Magnitude, and I created one of the first GHAS partner offerings. We had a 2-week GHAS Adoption service and were able to help onboard a few companies to GHAS in the early days.

Moving to GitHub

I also got to deliver some GitHub/10th Magnitude Roadshows. I met a few Hubbers during that time – including Kevin Alwell, a Solution Engineer on the east coast. In 2021, I applied for a Solution Engineering position at GitHub – and about two days later, Kevin called me out of the blue. After catching up, he told me there was a Solution Engineer role he thought I would be good for… and the rest, as they say, is history.

Reflections

I’ve had an incredible journey – and still have lots to look forward to! The advent of generative AI through ChatGPT and GitHub Copilot is just beginning to revolutionize development as we know it. If software has eaten the world, it’s now AI’s turn!

Since I am a self-confessed DevOpsologist, I proclaim to be constantly learning. So what have I learned over the years working in DevOps?

Find your inspiration outside of your career

My faith and my family are the core of my identity. I love being an SE and a technologist – but that’s what I do, not really who I am. This has been vital to handling pressure and hard times – when work sucks (as it inevitably will be from time to time), I don’t feel that I suck. I’ve found that, ironically, living for something other than work and technology has led to more fulfillment in work and tech! So find something that you can be passionate about that isn’t your work – and your work will actually improve!

People matter

I love to sling code. I love being a geek. But no matter how technically proficient I am, and no matter how amazing the tech is, people are still the heart of DevOps. I see a lot of companies that fail not because they are not smart, and not because they have the wrong tools, but because they don’t prioritize people and culture.

One of my favorite Laws is Conway’s Law. Conway (a programmer) introduced an idea in 1967 that showed a “homomorphic force” between the communication structure of a company and the architectures it produced. In other words, the culture plays a vital role in shaping the technology.

If you haven’t yet read Team Topologies do yourself a favor. Stop debating if you should implement microservices and spend some cycles on designing your Teams. In other words, people matter – so align with that force so that you’re not fighting it all the time.

I have had to learn (and still am learning) that how you say something is just as important as what you say. This was something I had to learn as a consultant – and I still have to work on it every day. I can come off as cutting and dismissive – a byproduct of my wiring to see to the heart of a problem very quickly. But I have to constantly think about how I communicate what I see. Because people matter.

Stay teachable

A corollary of the above is that you matter. And if you matter, then you’re worth investing in. One of the best ways to invest in yourself is to ask for feedback (or consider unsolicited feedback carefully). We all have blind spots, biases and areas we can grow in. If you are not able to admit when you are wrong – and learn and grow – then you’re going to cap your potential.

Managers, peers and customers have all at some time or other given me feedback about something. Each time I try to figure out what I can learn from that feedback. At times, I have “chewed the meat and spat out the bones”. Not all feedback is always correct – so I try to find the things that I can learn and grow from – and ignore the rest.

Keep learning

This is a core strength of mine (from Gallup’s CliftonStrenths). So learning comes easily to me – that’s not the case for everyone. But I believe that everyone should always be learning. And it’s close to being a requirement in DevOps given the pace of the software industry.

I could have ignored GitHub Advanced Security – after all, I’m not a security professional. However, I applied myself to learn about it – and it’s been key to my success in the past few years. Sometimes, you’ll need to just knuckle down and learn about something even if it’s not “in your lane” – you’ll be surprised at what might happen!

Take calculated risks

I didn’t know if consulting would be a good long-term choice for my career. I didn’t know if moving to the US would be good for my family. I didn’t know if moving into sales would be something I could do long-term. I approached each decision as rationally as I could, seeking input from friends, family, peers and managers as appropriate. But I never let myself get into “analysis paralysis”. At some point, I had to take some calculated risks. Thankfully, I’ve had a good run, even when there was uncertainty.

In closing

Being in DevOps has been incredibly fulfilling – from the work I’ve been able to do, to the people I’ve met, to the ways I’ve grown and developed as a person. Every day I count myself fortunate to have a job I love – and to be in an industry that’s continuously changing and evolving. I hope that my story and some of my learnings can inspire you to keep growing – and hopefully, I get to hear your story some day.

This article is part of XPRT. Magazine #15

Download here

The post Reflections of a DevOpsologist appeared first on Xebia | Xpirit.

Securing Azure Service Bus

Arjan van Bekkum — Thu, 02 Nov 2023 00:00:01 +0000

Author: Olena Borzenko

Security should be considered from the initial stages of designing a product rather than as an afterthought. This is particularly important for Service Bus as it often forms a part of a larger system. Security requirements may vary depending on the use case; for instance, a banking solution would have different security needs compared to a solution for a local bakery.

Let’s examine common security risks, understand the importance of data encryption and various robust authentication methods such as Azure AD and shared access signatures, explore strategies for network protection, and emphasize the value of logging for enhanced oversight.

Data Protection and Risks

The sensitivity or potential impact of a data leak may be high when transmitting data via Service Bus, particularly if it involves financial transactions, medical records, or sensitive personal information. It is crucial to protect the data from risks such as data exfiltration, unauthorized data movements, and unauthorized access. It is also important to have proper logging to monitor what is happening with the data.

Service Bus performs encryption in transit, or in other words, it ensures that data is encrypted while being transmitted. This includes encryption when data is moving from the client to Service Bus, within Service Bus, and from Service Bus to the consumer. By default, Azure Service Bus supports TLS 1.2 protocol on public endpoints. Initially, it was TLS 1.0, but due to customer demands for higher security, it now defaults to the higher version. However, this doesn’t mean that versions 1.0 and 1.1 are deprecated; they are still supported for backward compatibility, and users can set a minimum TLS version in their namespace. During other exchanges, secure protocols like HTTPS for straightforward RESTful operations and AMQP for efficient message queuing are used.

Besides encryption in transit, Service Bus also performs encryption at rest, meaning messages are encrypted while they are at rest (stored). This process is done automatically, and users don’t have to do anything to enable it. The encryption uses Azure storage encryption, and Service Bus is transitioning to service fabric storage for improved performance and cost savings.

But what if the built-in security layers are not sufficient to meet customer requirements? In such cases, users can enhance security by bringing their own encryption key, stored in Azure Key Vault — a method commonly referred to as BYOK (Bring Your Own Key). The provided key can be used to encrypt data, adding an extra layer of security. This is particularly important for organizations with stringent security policies.

So far we’ve examined some built-in security features as well as the method of introducing an extra layer of protection using the BYOK approach. There are also actions that can be taken on the client side for more advanced scenarios.

For example, an additional layer of encryption can be implemented by the client, an approach we can refer to as client-side encryption. The data protection step is performed before sending the data to Service Bus. While this is the most secure method, it also requires the most effort, as the client is responsible for both encryption and decryption. This approach is commonly used in highly sensitive environments like healthcare, where data breaches can have significant consequences.

As we can see, there are many different mechanisms to secure our data. For maximum security, we can go a step further and opt for multi-layer encryption. By combining client-side encryption, bringing your own key, and the platform encryption provided by Service Bus, we can achieve the highest level of data protection.

Authentication methods

As previously mentioned, Azure Service Bus offers two types of authentication: Azure Active Directory (Azure AD) and Shared Access Signatures (SAS) keys. Let’s take a brief overview of these two types to understand what might be more suitable for certain needs.

As a more modern and recommended form of authentication, Azure Active Directory (Azure AD) offers a range of features that enhance security and ease of management. It supports various types of accounts, service principals and provides a streamlined and secure method for managing identities. Its flexibility makes it easier to manage access for different clients or customers. For those looking to further tighten security, it’s possible to disable SAS authentication entirely and rely solely on Azure AD. Additionally, custom roles can be created to offer more granular permissions, allowing for tailored access control based on specific needs.

Another robust authentication option, known as Shared Access Signatures (SAS) keys, involves generating a connection string from primary and secondary keys for authentication. These keys can be set at different scopes — namespace, topic, or queue — to allow fine-grained access control. To serve various consumers or users you can also create multiple keys but it’s important to note that they are static and require manual rotation for enhanced security, especially the root manager key that controls the entire namespace. For extra security, using a token provider, such as an API that issues authentication tokens, is recommended over direct key usage. Although SAS are somewhat dated, they remain supported and are useful for systems restricted to this authentication method.

Network-level security

Having explored data protection measures and authentication methods, let’s now turn our attention to another crucial aspect of securing Azure Service Bus: network-level security.

One effective measure is to set Service Tags on the Service Bus namespace, which allows you to specify which Azure services can access your Service Bus. Additionally, IP Filtering can be employed to limit access to specific IP addresses or ranges. For those using the premium tier of Service Bus, adding the Service Bus to a Virtual Network can further minimize the attack surface.

It’s worth mentioning that Service Bus is a foundational element of Azure’s architecture and offers tier-specific features. For instance, the premium tier provides advanced options like VNet integration, mainly because it operates on a dedicated resource model, unlike the standard tier.

Who knows, maybe in the future the gap between the two tiers will be bridged to some extent. But for now, this gap results in a significant price difference between the standard and premium plans. Despite the use of dedicated hardware resources like virtual machines in the premium service, efforts are underway to narrow this price difference and make the subscription more accessible and affordable. Additionally, guidance and templates may be introduced to help determine the continuous need for the service or its occasional use.

Logging and monitoring for security and system health

As we conclude our comprehensive exploration of Azure Service Bus security, let’s delve into the indispensable aspects of logging and monitoring for both security and overall system health.

Service Bus generates a significant amount of logs, accessible through Application Insights and Log Analytics. The Kusto Query Language (KQL) is particularly useful for those who wish to work with these logs, as they include information about messages sent, connections made, and operations performed.

There is also support for Azure Policy, which allows users to set policies for various configurations. For example, a user can set a minimum TLS version across all subscriptions to ensure that security standards are met. This helps ensure that everyone adheres to the same security principles.

It is important to not only log information but also to actively monitor it for anomalies or issues. Service Bus allows users to set up alerts based on certain conditions or dynamic thresholds. For instance, if there is an unusual spike in connections, an alert can be triggered. This proactive monitoring is crucial, especially for those on duty, to quickly identify and address issues.

Through Azure Monitor, users can integrate with other services such as Logic Apps or Azure Functions. Some companies have automated their workflow such that when an alert is triggered, the system analyzes what’s happening, assigns it to the correct team, sets a priority, and creates a ticket. This streamlines the process and ensures that the right people can start working on the issue promptly.

In summary, the level of security implementation should be tailored to the specific scenario, taking into account the criticality of the data and operations involved. For instance, a small customer sending a few messages may not need the same robust measures as a large organization handling sensitive data. Alongside this, configuring encryption is a pivotal step, with options like client-side encryption providing added assurance by keeping keys on-premises. While Azure is compliant with GDPR and other standards, it’s essential to verify these, especially when dealing with sensitive information.

This article is part of XPRT. Magazine #15

Download here

The post Securing Azure Service Bus appeared first on Xebia | Xpirit.

InnerSource

Arjan van Bekkum — Mon, 30 Oct 2023 14:40:19 +0000

Authors: Jasper Gilhuis & Arjan van Bekkum

Is InnerSource written weird?

You will find a few related hits in Google if you search for "Inner Source", but back in the early days, no related hits where found. So, it was decided to call it InnerSource to get better reach!`

What is InnerSource?

InnerSource can be defined as the application of open-source software development principles within an organization’s internal software development processes. It draws on the valuable lessons learned from open-source projects and adapts them to the context of how companies create software internally.

Similar to the familiarity of “Open Source”, InnerSource encourages collaboration within the confines of an organization. It entails leveraging publicly available software, often used by developers in their daily work, and allows for feedback, including requests for new features, bug fixes, and changes, fostering collaboration akin to open-source projects.

InnerSource operates on four core principles, briefly summarized here, with more details available at InnerSource Commons. InnerSource Commons is a community-driven organization that aims to promote and facilitate the adoption of InnerSource practices to improve software development within organizations. It provides a platform for knowledge sharing, collaboration, and the development of valuable resources for the InnerSource community.

Openness: Openness in InnerSource projects ensures accessibility and simplifies contributions. It involves well-documented projects, making it easy for anyone within the organization to discover, understand, and participate. Host team contact information is readily accessible, and intentions to accept InnerSource contributions are communicated through relevant channels, promoting successful collaboration.
Transparency: Transparency is fundamental for effective InnerSource collaboration. Host teams must provide clear insights into the project’s direction, requirements, progress, and decision-making processes. Communication should be detailed and accessible to individuals beyond the core team, facilitating contributions from guest teams.
Prioritized Mentorship: InnerSource relies on mentorship from host teams to guest teams, guided by trusted committers. This mentorship elevates contributors on guest teams, enabling them to engage with and modify host team projects effectively. Host teams should prioritize mentorship, assisting guest team contributors when needed, and fostering beneficial relationships within the organization.
Voluntary Code Contribution: InnerSource thrives on voluntary participation, where guest and host teams engage willingly. Guest teams contribute code to host teams and accept these contributions voluntarily. This voluntary approach ensures alignment with each team’s objectives, allowing host teams to accept contributions that align with their mission and guest teams to prioritize contributions that serve their goals. Full collaboration extends to code contributions to maximize InnerSource’s benefits.

Why InnerSource and the Problems It Solves

When adopting InnerSource within your organization, defining your goals and understanding what problems it can address is essential. Clarity in your objectives helps people relate to and engage with InnerSource effectively.

Are you aiming to improve Developer Velocity, as measured by the Developer Velocity Index (DVI) (1), which correlates with faster revenue growth, higher shareholder returns, increased innovation, and improved customer satisfaction? Alternatively, are you fostering a collaboration mindset, emphasizing knowledge sharing and collaboration? Perhaps your focus is on breaking down traditional boundaries through DevOps practices. Identifying your true north star for InnerSource enables you to tailor its implementation to address specific challenges and objectives within your organization.

Benefits of InnerSource

The advantages of adopting InnerSource are substantial and include:

1. Mitigating Inter-Team Dependencies: When teams operate in isolation, working solely on their individual “projects” or “repositories” without sharing their work, it often leads to code duplication across multiple areas. This results in wasted effort as people tackle the same problems independently and can also introduce subtle variations in behavior for identical solutions. InnerSource promotes knowledge sharing and collaboration on shared solutions, significantly reducing code redundancy and enhancing efficiency.

2. Resolving Dependencies Effectively: In larger organizations, there’s typically a constant struggle for resource allocation and prioritization. This often leads to battles outside of the team’s immediate focus. InnerSource helps by providing teams with visibility into available software resources and contacts within the organization. This transparency enables teams to collaborate on improving code or adding new features, all with the approval of the original owners, without waiting for prioritization decisions. While it requires some initial coordination, it is often more time-efficient than waiting for prioritization decisions.

Interaction Model

As we are building communities around projects you can clearly see communication is key. In this asynchronous world, let alone timezone differences and cross-organization collaboration, it is obvious that you need to set up your guidance in a clear and easy-to-find way. GitHub provides a comprehensive set of documented principles and practices to assist you in getting started with community collaboration. These resources cover various aspects, from establishing code of conduct guidelines and creating community profiles to utilizing pull request templates. Additionally, GitHub offers a range of communication tools to support effective collaboration within your community. You can access these valuable resources at https://docs.github.com/en/communities.

Product Team: The original product team plays a pivotal role in the development and upkeep of the core project. They are the primary decision-makers, determining which contributions to accept or reject. Additionally, they provide valuable guidance and mentorship to external contributors, ensuring the project’s alignment with its goals and maintaining its overall quality.
Product Owner: The product owner defines the project’s overarching vision, goals, and priorities. Collaborating closely with the original product team ensures that contributions harmonize with the project’s objectives. Often, they prioritize specific features or enhancements based on user needs and market demands.
Trusted Committers: Trusted committers are individuals or team members who understand the project and have earned the community’s trust. Their primary role involves reviewing and approving contributions from external contributors. Beyond this, they are crucial in mentoring and guiding contributors, ensuring the project’s ongoing quality and consistency.
Contributors: Contributors are external individuals or teams that aim to make valuable contributions to the project. They actively submit code, bug fixes, or new features for review and integration into the project. Seeking feedback and collaboration within the project’s community, contributors drive the project’s evolution and improvement.
Consumers: Consumers, which include end-users and stakeholders, are the beneficiaries of the project’s functionality. They utilize the project or product created through the collective efforts of the original product team, external contributors, and trusted committers. By leveraging these contributions, consumers meet their needs, provide usability feedback, and enjoy ongoing enhancements.

InnerSource Patterns

The InnerSource Patterns are a valuable resource that offers actionable insights and best practices for implementing InnerSource principles within an organization’s software development processes. These patterns serve as a roadmap to facilitate effective collaboration, knowledge sharing, and project contributions, mirroring the successful dynamics of open source communities. By harnessing these patterns, organizations can streamline their development workflows, cultivate a culture of transparency, and drive innovation through collective efforts. Each pattern provides a structured approach to address specific challenges, making the adoption of InnerSource a well-guided and efficient endeavor. You can explore these patterns in detail at InnerSource Commons Patterns.

One particularly noteworthy pattern that stands out in revolutionizing workplaces through InnerSource is the “Gig Marketplace” Pattern.

Gig Marketplace Pattern

The “Gig Marketplace” pattern is dedicated to dismantling organizational silos by establishing an internal marketplace for tasks or projects. This innovative approach empowers teams to collaborate with flexibility and efficiency, offering and requesting expertise or services across different departments. This pattern encourages the free flow of skills and resources, enabling teams to tackle challenges and complete projects swiftly while nurturing a culture of collaboration and knowledge exchange.

Areas to apply InnerSource

Cloud Infrastructure

The landscape of cloud architecture is evolving and growing increasingly intricate. Notably, many companies are witnessing the emergence of Cloud Centers of Excellence (CCoE). These entities primarily shoulder the responsibility of managing shared infrastructure within cloud environments. Beyond infrastructure management, they are vital in monitoring security and ensuring its continual upkeep. Within CCoEs, teams specializing in these tasks are commonly called platform teams.

Modern cloud infrastructures often follow the hub and spoke model, exemplified by Microsoft’s Cloud Adoption Framework (CAF). In this model, the hub represents the centralized component responsible for monitoring and regulating both inbound and outbound traffic. Conversely, spokes represent isolated workloads where teams can execute their software or applications. These spokes are intricately linked to the hub. Typically, it falls upon the workload teams to create and manage the specific infrastructure they require.

To ensure that workload teams adhere to compliance standards, the platform team equips them with essential building blocks for infrastructure creation. These building blocks are available to all teams needing infrastructure resources, including the platform team. Building blocks are often constructed using tools like Bicep or Terraform, both of which support the creation of modules that can be hosted in repositories such as Azure Container Registry or Terraform Cloud.

Crucially, when the source code of these building blocks is accessible to all teams, any team member can contribute changes or updates. However, for quality control and to ensure ongoing compliance, all alterations to the building blocks require approval from the Platform team. This mechanism ensures that the building blocks continue to meet the necessary standards. In the context of InnerSource, the platform team serves as the trusted committer, overseeing these collaborative contributions.

Utilizing Packages

In the contemporary landscape of software development, packages have become indispensable. Both frontend and backend applications heavily rely on these packages. Many of these packages are open-source and meticulously maintained by passionate individuals. They find their hosting platforms in package managers like NuGet and NPM, with GitHub as one of the most prominent platforms for hosting these open-source packages.

GitHub’s foundation rests on principles of developer experience and open-source collaboration. This orientation means the source code for numerous packages is accessible to anyone, allowing for contributions from a wide community of developers. Changes to these packages undergo review and approval processes, typically overseen by package maintainers—dedicated groups of individuals who consistently contribute to the package’s development and upkeep.

In addition to open-source packages, organizations also rely on company-specific packages. These packages often encompass specialized functionalities, such as authentication or logging methods. Rather than each team independently reinventing these functionalities, organizations follow a similar principle: creating packages that can be shared across multiple teams. These packages are available through platforms like Azure DevOps Artifacts or GitHub Packages.

When multiple teams within an organization use these shared packages, it becomes essential that they have the flexibility to make adjustments and improvements as needed. Embracing the same open-source principles that govern external packages, these organizations naturally foster a community of regular contributors. Within this community, individuals emerge as trusted committers responsible for reviewing and approving changes to these vital shared packages, ensuring they remain robust and aligned with organizational needs.

Applications

Like infrastructure and open-source packages, application developers can also adopt an open-source approach. Open-source applications often serve as alternatives to well-known applications, for example, Photoshop and The Gimp. Some companies even choose to open-source the tools they use, making them accessible to all. By doing so, they harness the collective power of the community to enhance these applications. The same principles that apply to open-source packages are extended to open-source applications, allowing anyone to contribute new features or fix bugs. Trusted committers play a pivotal role in reviewing and approving these changes.

Now, imagine if these open-source principles, championed by passionate individuals, were applied to company software. Picture making the applications within a company available for everyone, enabling all employees to contribute to the company’s software.

This approach fosters collaboration among teams and departments, effectively breaking down silos and encouraging knowledge sharing. It’s a recipe for innovative solutions as a broader set of eyes scrutinizes the codebase, potentially catching bugs, security vulnerabilities, or design flaws at an early stage. InnerSource encourages developers to share their expertise and best practices, elevating the overall skill level of your team and mitigating the risk of knowledge loss when employees depart.

Distributing knowledge and responsibility makes the organization less susceptible to key-person dependencies. Others can readily step in to maintain and enhance the code if a developer leaves. Promoting InnerSource cultivates a culture of openness and transparency, resonating throughout the organization and enhancing company culture and employee morale.

Summary

This article explores InnerSource, a practice that brings open-source principles to internal software development within organizations. InnerSource encourages collaboration and feedback while maintaining security boundaries. It operates on four key principles: Openness, Transparency, Prioritized Mentorship, and Voluntary Code Contribution. These principles address organizational challenges such as improving Developer Velocity and fostering collaboration.

The benefits of InnerSource include reducing inter-team dependencies and resolving resource allocation challenges in larger organizations. It promotes collaboration, knowledge sharing, and efficiency. The article also outlines a role-based interaction model involving the Original Product Team, Product Owner, Trusted Committers, Contributors, and Consumers, all working together to develop and maintain projects.

Embracing InnerSource helps you build an inclusive organization, where people are able to showcase their expertise and offers a modern approach to work that aligns with the preferences and values of younger generations. It promotes flexibility, cross-functional collaboration, knowledge sharing, and inclusivity, all of which can enhance job satisfaction, innovation, and organizational agility.

(1): https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/tech-forward/why-your-it-organization-should-prioritize-developer-experience

This article is part of XPRT. Magazine #15

Download here

The post InnerSource appeared first on Xebia | Xpirit.