devopsy.kinsta.cloud

Tag: support

The Great Debate: The Future of Humans and Software in the Age of AI

Listening to the two sides of the debate regarding how much AI will take over software development, delivery and support tasks and its impact on jobs is both exciting for technology and scary for humans. The debate goes something like this:

AI Advocate: Welcome to the future! With AI’s capabilities today, we’re looking at a world where software applications can practically develop, deliver and support themselves. The need for human involvement is diminishing rapidly.
AI Antagonist: That’s an overly optimistic view. You’re underestimating the value of human creativity, empathy and ethical judgment. There are areas where AI simply cannot replace the human touch.
AI Advocate: Consider design and specification. AI can generate prototypes and suggest improvements. It’s about efficiency and leveraging AI to cut down on the grunt work.
AI Antagonist: But who sets the vision? AI lacks the understanding of user needs and market demands that only humans possess. The strategic decision-making and nuanced understanding of user psychology are irreplaceable.
AI Advocate: True, but AI’s role in supervision and training cannot be overlooked. It can manage its operations, needing only minimal human oversight to update data and rules.
AI Antagonist: And yet, who ensures these AI systems are aligned with ethical standards and current practices? Humans are crucial for overseeing these systems, ensuring they operate as intended and do not deviate into unethical territory.
AI Advocate: I’ll give you that. However, in quality assurance and testing, AI significantly reduces the human workload by automating many processes.
AI Antagonist: Automation has its place, but human insight is vital for identifying complex issues and understanding user experience in a way AI cannot. There’s a depth to exploratory and usability testing that AI can’t reach.
AI Advocate: Ethical and legal oversight might be your strongest point. AI does struggle with nuanced decisions in privacy, security and bias. I concede that humans are necessary to navigate these complex fields.
AI Antagonist: And don’t forget about customer support. AI can handle routine queries, but complex problems and sensitive issues require human intervention. The personal touch is something AI can’t replicate.
AI Advocate: Innovation is a collaborative effort, I admit. AI assists, but human creativity drives continuous improvement and adapts to market trends.

What Are the Implications if the AI Advocate is Correct?

If the AI advocate’s vision comes to fruition, the implications for humanity could be profoundly transformative. First, the automation of routine and complex tasks alike would herald a new era of efficiency and productivity, potentially liberating humans from the drudgery of monotonous work. This shift could lead to an increased focus on creative, strategic and interpersonal tasks that leverage human strengths and foster innovation. Moreover, the widespread adoption of AI in software development could drastically reduce the time and resources needed to bring new technologies to market, accelerating the pace of technological advancement and potentially solving critical challenges in fields like healthcare, education and environmental protection. However, this future also raises concerns about job displacement and the need for societal adjustments to manage the transition, emphasizing the importance of re-skilling and education to prepare the workforce for a new economic landscape dominated by AI and automation.

What Are the Implications if the AI Antagonist is Correct?

On the other hand, if the AI antagonist’s perspective holds, the implications underscore the indispensable value of human involvement in technology. This scenario suggests that despite AI’s advancements, the nuanced understanding, ethical judgment and creative problem-solving capabilities of humans remain crucial. It highlights the potential risks of over-reliance on AI, including ethical dilemmas, privacy concerns and the perpetuation of biases if not carefully overseen by human intelligence. The emphasis on human skills and creativity could lead to a more balanced approach to technological development, where AI is used as a tool to augment human capabilities rather than replace them. This future would prioritize the development of technologies that are not only innovative but also ethical, user-centric and socially responsible, ensuring that technological progress benefits all of society.

A Balanced Future

Ultimately, the truth likely lies somewhere in between these two viewpoints, suggesting a future where AI and human capabilities are intertwined. The implications of such a balanced approach would be a collaborative ecosystem where AI enhances human efforts, leading to unprecedented levels of productivity and innovation while also creating new opportunities for human workers. This future emphasizes the importance of adaptability, lifelong learning and ethical considerations as central pillars of technological advancement. It also highlights the need for policies and educational systems that support the workforce in transitioning to roles that leverage human strengths in creativity, empathy and strategic thinking, ensuring that the benefits of AI are distributed equitably across society.

Image source: https://vecteezy_futuristic-technology-concept-mixed-media-innovations-data_7019122_167-3.jpg

March 1, 2024
The Practicalities of Open Sourcing

I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

Manage Your Expectations of External Contributions

If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

OSS can be Intimidating

While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

Issue Triage and the Support Price Tag

In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

The Need for a Private Mirror

There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

Saying Goodbye to Obscurity

Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

Unfriendly Dependencies

If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

Navigating the Ecosystem: Dealing With Dependency Upgrades

Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

Unexpected Benefits

Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

And that’s a wrap, folks. Best of luck with your open source journey!

February 13, 2024
Why You Need to Empower Your Developers

In recent years, the demand for software developers worldwide has increased. However, in 2020, when the pandemic hit, many CIOs pulled back considerably on their IT spending. This trend has quickly reversed. In 2022, worldwide IT spending is expected to reach $4.4 trillion. Additionally, according to the U.S. Bureau of Labor Statistics, employment in software development is projected to rise by 22%.

Although organizations across several industries are increasing investment into IT, the supply of technology talent has struggled to keep pace. With the demand for creativity, developers understand their importance and can better dictate their terms — including higher salary compensation and enhanced benefits. Organizations that don’t meet these expectations risk losing coveted talent.

Remote work continues to be a top priority for many developers, along with great company culture. To create a positive work environment for developers, business leaders must offer a culture that makes tech employees feel a sense of belonging and purpose while working remotely. Many developers also want opportunities for growth and the ability to provide agile and innovative toolsets to help increase productivity and collaboration.

Let’s discuss some of the ways modern organizations can still empower developers and how business leaders can build a workplace culture that attracts some of the best developers in the business.

Provide a Supportive Digital Workplace

Open source usage has increased significantly in the workplace and continues to be a formative resource for developers. The open source community provides many new technologies that developers seek and even require in order to work at the top of their abilities. For example, open source provides some of the most popular programming languages available, including Javascript, C+++, and Python. The presence of multiple languages makes it easier for developers to write code and produce high-quality work efficiently.

Open source communities help developers build their skills and allow them to customize their technology stacks, as a result allowing them to optimize their productivity and learn different techniques from other open source projects. There is little to no debate that open source is critical to the tech industry and developers. Embracing open source can increase satisfaction and create a better workforce overall.

Inspire Collaboration Among Software Developers

In the past, office perks such as free food and collaborative social areas were used to attract new employees and retain current employees. However, in the remote work world, these can no longer remain a priority. Instead, business leaders should prioritize the holistic professional experience that their organization provides its employees. For developers, in particular, building this experience falls on CIOs and IT leaders to ensure they are providing workplace satisfaction, modern technology and flexible processes. To do so, they need to focus on tools that promote productivity and communication.

Most employees are familiar with the workflow software and collaboration tools that many workplaces provide. Without these offerings, remote workers would feel confused by their workload at the worst and adrift from their co-workers at best. For developers, however, these general collaboration tools won’t cut it, as they are poorly suited for engineering workflows. General collaborative software doesn’t offer the ability for deep customization, nor do they adapt natively to deploy on-prem or in the private cloud. As a result, developers have little to no use for these tools.

And that lacking sense of utility makes a crucial difference. Developer burnout is at an all-time high and inefficient workflows can keep teams from performing at their best. Or, worse, it can frustrate individual employees, leading to lower retention rates and less attractive offerings for prospective employees. Business leaders looking to offer developers an improved working environment should provide a more integrated, developer-oriented tech stack.

Empowered Software Developers are Productive Developers

While the market has changed, for many developers, fragmented tools remain a top productivity challenge. Investing in modern tools and programming languages while also removing tech complexities are the keys to improving productivity and simultaneously creating a better developer experience. This is why organizations must implement open source applications so developers can have complete visibility and control over the entire stack.

With tool fragmentation causing a number of distractions, developers can become frustrated and spend time responding to every individual incident. This poses the threat of a developer losing their love of the work. By doing away with fragmentation from old technology and selecting relevant solutions, business leaders allow developers to do what they do best: Develop software.

When organizational leaders empower their developers, they in turn find their product teams are more productive and feel more tied to the organization as well as their customers and each other. Thus, what is best for developers is best for the organization at large.

September 20, 2022
Get Support for Rocket Open Source Languages

Ready to learn more about support options for Rocket open source tools? All Rocket maintenance contracts include new versions, releases, modifications, service packs, access to the Rocket Customer Portal, chat, 24×7 phone support, proactive alerts, tech notes and how-to webinars.

There are no support tiers—all customers receiving maintenance services get the same premium level of support.

Get Support for Rocket Open Source Languages

February 12, 2021
Native Docker for Windows Arrives: Are Containers Finally Serverless?
Is Docker finally ready for the age of serverless computing? That’s the message from the announcement this week of native Docker container support for Windows Server 2016.

If you’ve been following Docker for a while, you know that Docker containers originally supported only Linux operating systems. Then, Docker made its platform available for Windows users, too—but with the major caveat that Docker Engine ran inside a Linux-based virtual machine image on top. So, you could run Docker from Windows, but Linux was still the middleman.

Real Docker Containers

This week, that all changed. On Sept. 26, Docker announced the general availability of native Docker container support on Windows Server 2016. By “native,” Docker means that the containers run using new primitives—the equivalent of namespaces in Linux—that are built into the Windows kernel itself. There’s no more virtualization.

But that’s not all. The complete Docker tool set also now runs natively on Windows. The Docker CLI, Swarm orchestration, data volumes and all the other building blocks of a Dockerized infrastructure are officially compatible, as well as Docker containers themselves.

The support is the result of more than two years of collaboration between Docker and Microsoft, which is now a Top Five contributor to the Docker open-source project.

Caveats

Native support for Docker is a big accomplishment. But there are still some limitations, including:
- Docker containers can only run natively on Windows Server 2016 and Windows 10. Other versions won’t work with Docker because they lack the kernel enhancements necessary to support Docker containers, Scott Johnston, Docker COO, explained in an interview.
- Some advanced networking configuration features for Docker are not yet supported because the “plumbing” required to make those features work is not complete inside the kernel, Johnston said, adding Microsoft is working to change that.
- Most notably, Docker containers on Windows can only run Windows apps inside the containers. In other words, you can’t run an app compiled for Linux inside a Docker container running on Windows. You would need a Windows host to do that. (And the opposite holds true: You can’t run Windows apps inside Docker containers on a Linux host.) This is not something that will change, according to Johnston.
Docker Becomes Serverless

Docker the company is celebrating the support as an opportunity to expand the Docker ecosystem immensely. Support for Windows “doubles the potential market opportunity” for Docker partners, the company said in a presentation about the announcement. (By the way, Docker has good reason to want to keep its partners happy by giving them a larger ecosystem to work with. The integration of Swarm into Docker earlier this year undercut the value of some of Docker’s partners’ products. But I digress.)

The most interesting aspect of this news from a DevOps perspective, however, is that it means Docker is now much more serverless. A large part of the value of Docker containers is their ability to simplify application delivery. As long as you can package your app as a Docker container, you can deploy it on any server that has Docker running.

You don’t have to think about the underlying server hardware or configuration. In other words, Docker allows you to become serverless, because you no longer have to think very much about the server you are deploying to.

Previously, however, this flexibility was limited by the fact that you did have to think about the server OS. Now, with native Docker support for Windows, that’s no longer the case. It doesn’t matter whether your infrastructure is composed of Windows servers, Linux servers or both. As long as you install Docker on them, you can deploy to any server.

Of course, there is still the issue of having to make sure your app is compiled for the right operating system. But that is easy enough to manage in most cases during the build process.

— Chris Tozzi
September 27, 2016
DevOps and IT Support: 4 Principles to Keep Your Team Ahead of the Curve
Here’s the million-dollar IT question: what is DevOps and why does it matter to IT support?

Short answer: DevOps advocates collaboration between Development and IT Operations. It’s about constant communication, breaking down silos and a culture of collaboration. The DevOps movement has made great headway and many companies have adopted and are employing DevOps practices – Netflix, Amazon and Google to name a few.

But where do IT support teams fit into a DevOps environment?

When developers launch new features and services, it’s the support team that deals with issues and interactions with frustrated customers. Change is often the enemy of stability. But because innovation can’t be stopped, IT support teams need to catch up. That means making their operational environments resemble the way their software is developed. The problem is that IT agents and developers have different methodologies, work in different systems, and practically subscribe to different technology religions.

The silos only exacerbate the challenges that the support team ultimately faces:
- Scattered data limits incident and problem understanding.
- Deployment failures have a high risk of downtime. And too often, changes are made that IT support doesn’t know about.
- Support feedback often represents customers, and doesn’t always get communicated to development, product owners and product managers.
DevOps is ultimately a culture change. When all teams commit to a collaborative approach and common goals, it can shift the entire mindset from silos to working together to deliver better services. Agile, Lean and Kanban are popular approaches that facilitate rapid iteration, learning and information sharing. This means you shorten the feedback loop necessary to drive business agility.

CAMS, DevOps and IT support

How do we put DevOps principles into practice for IT support? Over the past 20 years, IT has built up a strong governance model based on ITIL and that can’t be forgotten overnight. While putting new practices isn’t easy, the best way to make big concepts real is a model that covers people, processes and systems. Luckily the CAMS mode coined by Damon Edwards and John Willis at DevOpsDays Mountainview 2010 [1].

It stands for Culture, Automation, Measurement and Sharing.

Principle 1: Culture

The model leads with culture, as it’s the most important facet to DevOps. Support teams learning from and supporting DevOps practices requires a cultural shift. While command and control is comforting, DevOps calls for speed and agility. Daily or weekly rituals can facilitate this cultural shift. Some rituals you can apply to your IT support team include:
- daily standups
- chatrooms
- scrum, sprint planning and retrospectives
- kanban frameworks
Be sure to focus on results, not just the activities. It’s not about the number of changes but the results of those changes.

And finally, understand team behaviors. Culture is a result of habits. You need to understand how your team works together, and what you can improve.

Principle 2: Automation

To move fast, you can’t do everything by hand. Automation is another principle of DevOps, but is most effective when it supports the people and processes in place.

Go from trapped knowledge to shared knowledge
- Known errors should be tracked at the time of deployment and communicated to support. Sound simple? You’ll be surprised how often it doesn’t happen.
- Support should link articles to incidents and problems, so everyone understands what’s causing the issues
Shift from orphaned tickets to linked tickets
- All teams should be responsible for ticket linking and documentation- including the service desk, admins, developers, and operations, so everyone knows what’s going on.
- Link incidents, problems and requests to all associated changes and releases.
Don’t just deploy, but support
- Continuous integration, continuous delivery, and continuous deployment are core to the First Wave of DevOps – thinking about the performance of the overall system. Support needs to be prepared to support, operate and ensure their ability to restore services. They need to know what’s being deployed and when, so they can give the right answers to the customer.
Help with testing
- Automated testing is key to a DevOps environment. Every time a developer commits code, they need to make sure all the code is operating the way it is expected to. If it breaks, tests can catch failures before anything is deployed and delivered. Support teams hold data about various customer environments that should be continuously fed back to testing.
Keep up with monitoring data
- Proactive monitoring helps developers stay ahead of problems before they snowball. In the same vain, support teams can identify customer problems faster by keeping aware of proactive monitoring and linking it back to their own incident management systems.
Principle 3: Measurement

Keep track of metrics that matter. Once you’ve established your individual and team goals, It’s important to measure how you’re tracking to those common goals. How long does it take to recover from failure? Try measuring ‘Mean Time To Repair’ (MTTR) and whether it increases or decreases over time. Here are a few other metrics your support team should keep in mind:
- How many repeated issues do you have? Measure repetitive incidents and how often they occur in a period.
- Are you meeting your targets? Measure service level targets in your service level agreements and operational level agreements in the context of deployments.
- What are your costs? What’s your cost per incident, along with the total cost of support? Take this in context with downtime costs. In some cases, increasing support costs may be the best thing to do to minimize impact to the business.
Principle 4: Sharing

And lastly, when it comes to sharing, ask yourself these questions:
- Does the organization understand what we’re doing? Do we share that understanding?
- Do all teams understand each other’s goals, hardships and priorities?
- Does your team’s outputs of processes flow with other team’s processes?
- Is knowledge shared across teams? If it’s in a system, is it accessible?
- How is your team collaborating with others? Are there unbarred channels for communicating?
- Are the right stakeholders kept in the loop of your projects, even if they’re not in your immediate group?
- Do your IT groups – development, operations, testing, support and even the business – share ownership of successes, failures and learnings?
- Do teams share tools and information? If not, do those tools integrate with each other?
Faster, better IT service is about culture, sharing and tools that enable your teams

A collaborative culture is critical to success in DevOps. Aligning support and development can help your organization understand what services the business wants and needs to be productive.

About the Author/Sid Suri

Sid Suri is the Vice President of Marketing for JIRA Service Desk. He’s worked in various technology marketing roles over the last fifteen years at Salesforce.com, Oracle (CRM), InQuira (acquired by Oracle) and TIBCO Software. He has an MBA from the Haas School of Business and a bachelors in Economics and Italian from Middlebury College. He lives in San Francisco, California.
December 9, 2015
Benefits for the Product Team in Working Support Cases

An increasingly popular practice that’s being adopted by DevOps groups are developers working regular shifts in front line support. The thinking behind this exercise is pretty sound. When exposed to the real world problems and frustrations customers face when using their software, a developer’s work becomes more about supporting that customer experience and increasing customer satisfaction and less about “Get the tests passing and ship it fast!” The practice also increases an individual developer’s understanding of the larger solution their company provides. If a particular developer is master over a small part of the total application, working support will give them valuable insight into the bigger picture of the problems they’re solving and how well their corner of the world is supporting the larger solution.

We practice this at my company, Datical, but on a wider scale. In addition to the app dev engineers every member of the product team, myself included, regularly works support cases in direct contact with the customer. It has been a pretty eye opening experience for all of us and we are most certainly realizing the promised benefits of this practice.

Our product team operates with a single guiding principle: Well defined, customer driven requirements yield excellent solutions. When you schedule calls or take customers to lunch, you get a lot of great feedback on where your product should go and net new features you should consider implementing to improve the overall solution. The conversations we’ve had with customers in this way are generally very positive and supportive with a focus on future direction and growth.

Working a support case is an entirely different and much more crucial customer conversation. The conversation that takes place during a support interaction is centered on a pressing need. The customer may need clarification on usage that isn’t as intuitive or well documented as it should be. They may be dealing with a gap in previous requirements or a coding defect that is keeping them from completing a goal. Whatever prompted the call, it’s occurring because the customer is not delighted and we are getting a firsthand, real time account of what is problematic and what we must do better. These needs translate directly into our product plans and requirements.

But there’s more to glean from these interactions than the matter at hand. When the customer is amenable we like to use GoToMeeting to remotely look over their shoulders as they demonstrate for us the issue they are having. During their demonstration, we get additional insight into the mechanics of our solutions. How do customers interface with our products? Are there minor inefficiencies our users have to contend with that they aren’t reporting? A few of the most well received features we have delivered since adopting this practice have been very small stories that were pretty easily addressed, which removed a minor annoyance that was encountered frequently in our workflows. We’ll release these fixes with a minimum of fanfare, but they are almost always noticed, commented upon and appreciated by the customer.

The last class of lessons learned from our foray into front line support pertains to my new favorite non-word, troubleshootability. When something goes wrong, how easy is it to diagnose the problem and how long does it take? How detailed and centralized is your logging? Are users being updated on the progress of long running operations? If an error is encountered due to customer misuse, is the customer appropriately guided to correct the error? Anything that we can do to shorten the cycle and cut through the murk when something does go wrong improves the overall experience with the product and increases customer trust.

Working support in product management and engineering has been a really great exercise. It’s given us a deeper understanding of our solutions, our users, our strengths and our weaknesses. This understanding has led to requirements that are tightly focused on our customers’ needs, holistic development practices concentrated around comprehensive customer workflows, and a solution that clearly communicates what’s going on as it happens for fast diagnosis and remediation of issues in the field. I highly recommend it.

About the Author/Peter Pickerill

Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. His ability to understand product demands from a customer’s perspective and translate those demands into actionable product and development plans has led to expanded duties at every company for which he’s worked. In his time at Symantec, Pete worked directly with large financial services companies and online retailers to implement and improve online fraud prevention solutions that were used daily by millions of people worldwide. In addition to managing a development team and product schedule at BMC, Pete worked directly with large financial services institutions to provide the features they needed to achieve greater efficiency and cost savings in their application deployment processes.

Connect with Peter on twitter: @PetePickerill

August 5, 2015