devopsy.kinsta.cloud

Tag: developers

OverOps Brings Machine Learning to DevOps

OverOps has launched a namesake platform employing machine learning algorithms to capture data from an IT environment that identify potential issues before a DevOps team decides to promote an application into production.

Company CTO Tal Weiss said the OverOps Platform is unique in that, rather than relying on log data, it combines static and dynamic analysis of code as it executes to detect issue. That data then can be accessed either via dashboards or shared with other tools via an open application programming interface (API). The dashboards included with the OverOps Platform are based on open source project Grafana software.

That approach makes it possible to advance usage of artificial intelligence (AI) within IT operations without necessarily requiring that every tool in a DevOps pipeline be upgraded to include support for machine learning algorithms, Weiss said.

OverOps also includes in the platform access to an AWS Lambda-based framework or separate on-premises serverless computing framework to enable DevOps teams to also create their own custom functions and workflows.

Weiss said OverOps is designed to capture machine data about every error and exception at the moment they occur, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event. Log data is, by comparison, relatively shallow in that it is challenging to determine precise root cause analysis when trying to troubleshoot an issue, he said, noting the OverOps Platform offers visibility into the uncaught and swallowed exceptions that would otherwise be unavailable in log files.

DevOps teams spend an inordinate amount of time analyzing log files in the hopes of discovering an anomaly. But as IT environments continue to scale out, the practicality of analyzing millions, possibly even billions, of log files becomes impractical. OverOps is making the case for employing machine learning algorithms to analyze events before the log file is even created, which eliminates the need to find some way to store log files before they can be analyzed.

There’s naturally a lot of trepidation when it comes to anything to do with machine learning algorithms and other form of AI to manage IT. But as the complexity of IT environments continues to increase, it’s clear DevOps teams will need to rely more on AI to mange IT at levels of scale that were once considered unimaginable. For example, while microservices based on containers may accelerate the rate at which applications can be developed and updated, they also can introduce a phenomenal amount of operational complexity. Most DevOps professionals would rather automate as much as possible the manual labor associated with operations, especially if that leads to more certainty about the quality of the software being promoted into a production environment.

Of course, while making use of machine learning algorithms to analyze code represents a step forward in terms of automation, it’s still a very long way from eliminating the need for DevOps teams altogether.

— Mike Vizard

August 16, 2018
Bridging the Multi-Cloud, DevOps Skills Gap

The cloud is driving a digital transformation revolution throughout the world, as traditional “brick and mortar” companies morph into software companies. This is easy to see with retailers and publishers, but it’s also happening at companies such as ZipCar, Boeing and Liberty Mutual (more about them later). This transformation, while driving radical performance and cost improvements, has caused the skills gap to widen substantially as businesses struggle to find top developer talent—competing with the likes of traditional software companies such as Google and Microsoft. I attend the Cloud Foundry Summit in Boston to verify my assumptions.

The diversity of offerings of cloud products has opened up a variety of possibilities, and one specific usage is on the rise: the multi-cloud strategy. This means that a company is using multiple cloud providers to host its services. There are numbers of reasons to do this: to take advantage of price differences, distribute the traffic to serve different geographical regions or as part of a disaster recovery plan, to name a few.

Having a multi-cloud infrastructure brings a lot of complexity and challenges. Fortunately, solutions such as Cloud Foundry are designed to help companies embrace what the cloud industry has to offer, including the multi-cloud aspect. Cloud Foundry has actually seen a 12 percent increase in adoption from 2017 to 2018, and 42 percent of its users consider themselves developers or DevOps engineers.

The 2018 GitHub developer survey confirms the trend: “DevOps and machine learning are important trends in the software industry today. Languages and frameworks associated with these kinds of works are on the rise, and developers working in these areas command the highest salaries.” DevOps engineers are not only the second most well-paid developers, but they are also among the ones with the most experience.

DevOps engineers or site reliability engineers (SREs) are a rare type of talent, because these professionals need a wide range of knowledge within the software scope—more specifically, development skills and infrastructure/system administration skills. The fact that DevOps engineers are generally more experienced is because most people start as developers and then end up learning about infrastructure on the job, and this takes time. And our education system is to blame.

Most computer science degree programs do not focus on practical computer science and software development. System administration skills are often not covered at all, so there are hardly any graduates taking on this type of position. As a result, many engineers learn on the job rather than during their degree programs.

I heard time and again from attendees at Cloud Foundry Summit how difficult it is to find talent. When I asked about students graduating from colleges (even top colleges), they universally responded that new graduates were far “too green,” required months of training and were not familiar with or attracted to the DevOps/SRE career path.

Taos, a prominent Silicon Valley IT consulting and services provider, is among some that are getting creative when it comes to attracting and developing quality DevOps talent. “Our customers are increasingly investing in projects that require engineers trained in cloud technologies and DevOps,” said Trish Palumbo, vice president of Talent at Taos. “To meet the demand, we look for knowledge-seekers with a baseline of CS fundamentals to join the Taos DevOps Bootcamp.” The training is free and students get paid to attend.

As more businesses digitally transform, more developer talent will be needed. The Cloud Foundry Foundation has been aware of this skills gap for some time, having published a full report on the topic in 2016. The foundation continues to work hard to close this gap by hosting summits where developers can take training sessions, participate in a hack-athon and learn about a career in DevOps, while networking with experienced developers and organizations seeking talent. Cloud Foundry Summit is a crucial event for organizations in need of digital transformation, as this is one of the best industry conferences to meet top-tier talent.

— Sylvain Kalache

July 23, 2018
Reinventing Talent Acquisition, DevOps Style: 7 Ways to Become a ‘Destination Company’
Just as brilliant drummers have their pick of bands, top cloud-native developers and project managers can be choosy about their employers. They’re the rock stars of the business and they know it. If you’re not a “destination company” like Amazon, Facebook or Google, how do you entice top talent to work for you? And if you’re being wooed, what are the tip-offs that you’ll be valued?

We’ve been asking ourselves the same questions, and in this article we’ll share an approach that’s working for us. Your company can become more of a destination company in today’s “seller’s market” by applying a DevOps mindset to the way you recruit, hire, onboard and retain talent.

Begin by Imagining the End State

DevOps teams define success criteria upfront so that everyone shares the same goals. Knowing the end state when you start is just as important for becoming a destination company. So begin by imagining what your talent acquisition organization would look like if it were the world’s best. (Even if you fall short of our goals, you’ll still be better than before.)

To help seed your list, here are some of our ideas:
- Knowing the best places to find people with the right skills—or the right aptitude.
- Creating a concierge-like experience for candidates from the first contact. The idea is to make them feel welcome, valued and in the loop. More about this later in the paper.
- Making an offer no more than two weeks after first contact. Talented people don’t stay available for very long. A swift offer gives you a hiring advantage—and sends a message to the person that you value them.
- Fostering a culture that makes it easy for new hires to integrate into their new team, adopt the DevOps work style and feel connected to your company’s big picture—and want to stay.
Create a Concierge-like Hiring Experience

The key is to make the hiring process so welcoming at every step that it sways top candidates to work for you rather than their other suitors. Just as you do when developing software, focus on the experience. For example, since some engineers don’t like social interviews and questions that start, “Tell me about a time …” don’t do it. Instead, test candidates on the job they’ll perform. Ask developers to code so you can measure their speed, aptitude and empathy for users. Ask product managers to design a product that you’ve outlined in vague terms. Assess how well they:
- Draw out requirements from stakeholders and users.
- Create a screen flow for the app—a good demonstration of empathy.
- Describe the architecture at a high level so you can judge whether they understand what’s feasible. The description doesn’t have to be highly technical.
- Propose release milestones (minimum viable products) that reflect a logical build-measure-learn cycle. For example, MVP 1 might not include a login.
In our experience, candidates either love this process or hate it. In the latter case, we have a good clue that they wouldn’t have much fun working with us.

Look beyond skills. Technology is evolving quickly, so a candidate who can figure out the right path may be more valuable than one who knows a trendy programming language. We home in on candidates who can parachute into a situation, contextualize quickly and figure out the right next steps. That takes a combination of speed, aptitude and empathy.

How can you assess whether a person has empathy? Good question. Our view is that if they have empathy for their teammates, they’ll most likely have empathy for our end users as well.

Schedule a Pair Day

A pair day is an awesome way for a candidate to experience how you work. Here’s how we do it: The candidate joins us for morning standup and chooses a team. During the course of the day the candidate pairs with other engineers to deliver real customer value (stories from a backlog). This gives team members an opportunity to assess the candidate’s skills and work style in an actual work setting—and observe whether the candidate is loving it. At the same time, candidates can experience the team culture firsthand.

Immediately after pair day, we hold a short meeting to decide on next steps. Typically we conduct a Roman vote: Yes, let’s hire the candidate now, or no, not a good fit. We’re looking for individuals who raise the bar for the team as a whole. Rock stars. If the team is willing to fight for a candidate, that’s a good indication the person is a great fit and a bar raiser.

Recruiting: Learn from the Numbers

Cast a wide net initially, including talent channels such as tech meetups, college outreach and internships. Remember that you’re connecting with real people and the goal is to build relationships. Phony ads and mass-marketing strategies send the wrong signals. We’ve seen good results from hosting meetups—a great way to start informal conversations where you and the candidate can learn something about each other.

To identify the best talent sources, measure:
- Resumés submitted
- Percent of applicants that went to the second round (testing)
- Percent tested candidates who had a pair-day interview
- Percent of pair-day interviews that resulted in an offer
- Offers accepted
A note about full-stack developers: finding them is difficult. The same goes for product managers who can work on a DevOps team. We know we’ll have to kiss a lot of frogs to find these unicorns (pardon the mixed metaphor). To increase our chances of finding rare talent, we measure our recruitment activities and conduct A/B tests every step of the way—from job descriptions to talent sources. For example, our data shows that in some cities meetups work better than career fairs; in other cities, it’s the opposite.

When the data tells us that a recruiting activity doesn’t work in a particular market, we try something else. This, too, borrows a page from DevOps: Focus on data and the user need rather than clinging to subjective opinions about what works and what doesn’t. Openly share all of the data about sourcing and onboarding with your DevOps teams to get their input. The goal is continuous improvement.

Break Down Organizational Boundaries

Creating an engine to attract and onboard talent requires breaking down organizational walls. For example, sourcers and recruiters who are out in the field need a clear way to collaborate with the team members who conduct technical interviews.

Organizational change is never easy. We’re approaching it in the same way we get code into production. That is, we bring people together into cross-functional teams and ask them to work together toward a shared goal. Giving everyone a common goal avoids finger-pointing. Everyone has an incentive to do what’s right for the company and the candidates rather than just their team. And gaining more empathy for the other functions’ challenges helps team members come up with better ideas for creating a world-class recruiting and onboarding experience.

The cross-functional team should include a technical recruiter, executive recruiter, someone who runs meetups, someone in charge of onboarding, a technical screener and other people involved in the interview process. As it is for DevOps, the goal for hiring and onboarding is to go fast. That takes great communication and transparency.

Don’t Try to Boil the Ocean: Start Small

It’s not feasible to change the entire talent acquisition organization in one go. Better to start with a few teams and run mini experiments. When a new process improves hiring or onboarding speed or increases retention, scale it across the organization. And when a new process fails, do what DevOps teams do: Fail fast, share the failure so that everyone can learn from it and continuously improve.

Take care to select the right people to spearhead the transition. Look for people who are open-minded and have a good understanding of how the organization works today. If you’re into 16Personalities, you’re after Explorer types—those who have “a self-reliant mix of enthusiasm, quick thinking and ingenuity.” In our view, the right people for the transformation should see it as a short-term experiment because transformation should take on a life of its own, not remain the pet project for a few.

Roll out the red carpet for the cross-functional teams that spearhead the transformation. Limit other work for these team members: this needs to become their entire job. Celebrate each team’s success. The goal is for the first teams to model DevOps-style talent acquisition for their peers to ignite transformation throughout the company.

Don’t Stop After You Make the Offer

Consider pairing new hires with a buddy to integrate them quickly into the team. And to retain top talent, be proactive about offering new opportunities and training. Developing a tool that tracks lifetime project assignments, as we did at Cognizant, will help you identify the people who would benefit from and appreciate these opportunities.

Adopting the DevOps-style of talent acquisition we described isn’t easy. It takes new processes, cross-functional teams, data collection and analysis and transparent communications. The payoff: becoming more of a destination company for the rock stars who create great software—and earning their loyalty by making them feel valued.

This article was co-authored by Sam Harrison.

— Brian Roche
July 12, 2018
Cloud Performance Management Needs Precedence Over APM in a Cloud World

A majority of today’s businesses follow a cloud-first strategy. DevOps engineers with these businesses prefer using infrastructure as a service (IaaS), platform as a service (PaaS) or cloud services from leading cloud services providers (CSPs). Given the rate at which the IT is evolving now, from on-prem to XaaS, the future seems a lot more promising for Dev and Ops of an application.

But while the IT has evolved, have the monitoring and management tools evolved along these lines, too? Many DevOps engineers still use the good-old application performance monitoring (APM) tools for measuring the performance of apps and for debugging issues.

This article deliberates on shifting the focus from application performance management (APM) to cloud performance management (CPM).

APM is Good, Infra-Centric APM is better, CPM is the Best

Use of cloud services is a norm in DevOps today. On the one hand, these services act as building blocks for developing or running application(s) and contribute heavily to the performance of that application. On the other hand, they bring with them several layers of idiosyncratic abstraction layers. To top it, new cloud services or SaaS occasionally introduce new trends.

The monitoring and management market has yet to catch up with the pace at which IT is evolving. There are only a handful of cloud monitoring tools available in the market, and they provide siloed reports and dashboards. Result: DevOps engineers are still stuck with good-old APM tools.

APM tools are good at offering insights. However, these insights are just enough to understand what’s happening in the application tier.

If you observe the above APM dashboard, there’s the summary of server status and app throughput, response time and more beautifully packaged with visualization graphs. If there’s a need, one can even get information on CPU usage, memory usage, disk usage details, etc.

Then there are infra-centric APM tools that go one level beneath the app tier to provide information on network statistics, such as bandwidth or opened ports. However, none of the tools provide complete contextual information. Day in and day out, a DevOps engineer must dabble with several dashboards.

Let’s take a look at a very simple scenario. Assume there is an image processing web application leveraging AWS cloud services such as EC2, S3 bucket for storage and SQS for queuing:

From the APM tool, you can continuously monitor the application for response time, then app servers for metrics such as throughput (with <=10 images), CPU utilization, etc. Everything looks fine on the top while the pipeline is moving smoothly.

Then one day, the number of users using the app at a particular time increases and the jobs start queuing up quickly on SQS, and the response time of the application suddenly goes low. However, the performance of all the servers seems fine on the APM tool.

In such a scenario, how do you debug the root cause that is affecting the response time without having a monitoring tool that is watching the AWS SQS?

Of course, AWS provides its own console to monitor its services. If the DevOps engineer is aware of the root cause, debugging is a child’s play. However, when the underlying issue is unknown, it leads to dependency on several tools, which can unearth facts for them.

When a business’ application or applications are dependent on several cloud services that do not have a monitoring tool yet, how can an APM tool, which can pull only specific data, help provide complete visibility?

In this cloud-driven world, a developer needs to be aware of how their application interacts with different tech stacks, and how that interaction drives performance, availability and cost.

Unified CPM Complements APM Bringing the Complete Context

The industry has traditionally separated the performance management of applications and infrastructure, resulting in multiple toolsets in each of these domains.Neither APM nor IPM alone will successfully address and solve shift-left monitoring requirements.

APM focuses only on the application tier providing visibility into just part way down the tech stack. If you are a DevOps engineer with an enterprise or an SMB looking into different customer applications, you know it is difficult to make sense of all the resource usage across availability zones and make a case of each application’s cost/performance trade-off, ability to scale, time-to-market, etc. While the cloud services make it easier for development, each service has its own learning curve and abstraction.

A unified CPM tool thrusts the context up to the shore of APM, in a tech stack. Developers need such tools where they can monitor all the services and get end-to-end visibility from a single pane of glass.

Conclusion

Analyzing performance of each dynamic service in context with other dynamic players (services) in the tech stacks will quickly provide the right context and help detect an underlying problem easily—especially, in cases where the problem lies with the cloud resources rather than the application code itself.

— Pradeep Kumar

July 11, 2018
The State of the Kotlin Programming Language in 2018

Pusher, the communications and collaboration API provider, recently released the findings of its “State of Kotlin 2018” research report. Over the past 24 months, adoption and use of the Kotlin programming language among developers has seen tremendous growth. Pusher has seen this growth firsthand, with more developers using Kotlin while building applications with the company’s products.

Earlier this year, Pusher surveyed more than 2,500 developers to get a better understanding of the ecosystem, specifically around usage, features and demographics.

Key report findings:

Kotlin is used both in work and personal projects, as confirmed by 60 percent of respondents. Kotlin is even more prominent in side projects, as they tend to be smaller, easier to convert and more experimental.

Android is hugely popular across the board, used by professional developers and students alike. However, when it comes to backend applications, Kotlin’s users tend to be more experienced developers.

Most Kotlin developers come from a Java background, or also work with Java. More than 87 percent of respondents have migrated existing Java code to Kotlin. However, more than a quarter of respondents who migrated Java to Kotlin needed to revert back due to both technical and organizational reasons. Tools that use reflection or generate code were mentioned most often as technical reasons to revert to Java.

Null safety is the favorite feature for 80 percent of respondents, whereas co-routines and multi-platform support are the least important.

The report concluded that Kotlin is overwhelmingly popular in the Android circles. This raises the question, Will Kotlin break into communities outside Android?

“We expect to see new generations of developers taking their first steps into programming with Kotlin,” said Pusher Developer Evangelist Zan Markan in an email. “It’s a modern, versatile, cross-platform language that can cross between OO, functional, scripting, and declarative paradigms with ease. This could mean that Kotlin will affect the wider programming language landscape by becoming a benchmark for what a programming language should be able to do.”

Read the full report here.

— Malia Powers

July 10, 2018
Get Serious About Building Out Your Ecosystem of Developers

Scratch a hypergrowth software company and you’ll likely find an organization focused on building an ecosystem of developers that will help it achieve platform status.

Getting there requires understanding that when it comes to developers, your API is your product. APIs aren’t just about integrating tools and apps; increasingly, they are the new way of doing business.

Your mindset must be API-first and developer-first. Companies as diverse as Twilio, Google and Intuit know this. Even Salesforce generates as much as half its revenues from APIs.

At DocuSign, we’ve seen a 250 percent increase in transactions generated through the DocuSign API since we began doubling down on our developer experience. A few years ago, the API was less than 40 percent of overall transactions. Today, close to 60 percent of all DocuSign transactions are via the API.

Among the lessons we’ve learned while building our platform is that you’re committing a disservice if you only make your API available to a few enterprise customers and other select partners or organizations. In the developer ecosystem, transparency is a core value, and another is community and the ability to share code and experiences. In that spirit, here are some tips for getting started and advice on how to measure success and avoid potential landmines.

Step 1: Commit to Developers

Stop restricting who can get access to your API. Deliberately creating a developer platform and API strategy means getting serious about opening up your platform. Developers want to try your API before they commit to you, so let them have full access, for free. At DocuSign, developers can set up a sandbox account, generate an API key and kick the tires without paying us a dime. Build a developer center and invest in building tools for developers—everything from SDKs and how-to guides to sample applications. And be open to feedback from developers on their experience with the API.

Step 2: Invest in the Experience

Developers want easy, low-friction technology that will enable them to get up and running with your API quickly. Think about how you can make the entire experience completely self-service, from offering a developer edition or full featured “sandbox” to providing API plans. Offer as much as you can upfront so they never have to speak to your sales team.

Step 3: Make Your Content Shine

Content in all forms is key. Developers expect your API to be well-documented. Offer up sample code in languages they care about and cover common use cases. Your content should also be discoverable. Engineers must be able to find what they need without asking—don’t make it hard.

Step 4: Build Out Your Evangelism—and Support—Team

Evangelism is crucial in developer relations. Hire someone dedicated to it, as well as someone who can focus on developer marketing. Your support team should also include your own in-house API experts who can support your developer ecosystem. And make sure that you have a robust self-service support option, such as a community on Stack Overflow. At DocuSign, these folks are active on Stack Overflow and help developers who are working to go live with their apps.

Step 4: Measure Success

Monthly recurring revenue, numbers of sandbox accounts and active developers and the number of successful transactions from apps built on the platform are all key metrics, and it’s important to track them. Growth in sandbox accounts is an especially important performance indicator for us and today at DocuSign we have more than 80,000 sandbox accounts—almost double where it was last year. It is also important to look at where monthly recurring revenue is coming from. It varies by vertical, but we have found that when customers use our API they’re two to four times more valuable from a revenue perspective. Customers using the API also have a lower churn rate—they’re stickier. Last but not least, think about how you are going to measure developer satisfaction. Wootric provides a great way to measure NPS within your app and customer effort within your developer portal.

Pitfalls to Avoid

Most developers care about two things: 1) successfully launching something they can be proud of, and 2) that users will love what they’ve built. They get frustrated when your documentation stops or is incomplete, you don’t tell them what you’re going to build or what you’re going to ship, or you don’t build what you told them you were going to build. Let them know when your road map changes. Communication is very important. Establish that rapport, listen to feedback and take action on it. Keep living out the values of transparency and community, and you will start to see your developer ecosystem thrive.

— Marie Huwe

June 26, 2018
How to Cultivate a Loyal Developer Community

With the number of developer focused companies and products growing, building communities among engineers has become a key strategy to stay competitive. Augmenting and often surpassing traditional marketing techniques, this approach—although challenging—can be an incredibly effective way to engage users and get engineers excited about a product.

Since our inception over six years ago, DigitalOcean has worked to establish a robust developer community around our product through a variety of channels. This includes our public open-source focused Community, which attracts more than 3 million monthly visitors.

It Takes a Village to Make a Community

Beyond creating a product developers love (that always comes first), here are some best practices and lessons we’ve learned for cultivating a great developer community.

Develop Personal Relationships

A community implies connection, so first, look for ways to form connections directly and show people you care. In its early days, Twilio did a great job at getting out of the office and doing meetups to speak to devs directly, and I would argue this was essential to it becoming as successful as it is today.

This also involves finding ways to shine light on individuals in your community. When we found out one of our community members recently had a baby, we sent them a onesie for their newborn. Chances are, you also have community members who are doing amazing things, and would love the recognition for it—either on social media or your blog.

Taking the time to meet users where they are and working to establish closer relationships with them creates a virtuous cycle: these users help the community grow with their contributions, suggestions and feedback, and therefore feel more empowered to continue to invest in the community. Everyone benefits in this scenario and, equally important, your communication out to the community is genuine because you gain a deeper understanding of exactly who you are talking to and building for.

To that end, it’s important to have someone or a team (for example: developer advocates or community managers) ready to engage directly with your community and bring the lessons back to the company. You’ll want individuals who are capable of responding, both offline and online, in an authentic way.

Create Avenues for Them to do Meaningful Work

While many developers enjoy their work, they often have far-reaching interests beyond code. Companies that find ways to help their communities meld code with what’s important to them personally will see much more stickiness and retention.

For example, developer analyst firm RedMonk has done a good job of creating conferences (MonkiGras and Monktoberfest) that go beyond technical presentations and instead create discussions around issues such as the intersection of society, culture and technology. This provides a forum for the developer community to connect over shared interests and experiences—not just code or languages.

We created a program called Write for DOnations that not only pays contributors for writing technical articles, but also matches this payout with a contribution from us to the author’s choice of tech-focused nonprofits. This not only incentivizes our community to remain active, but makes them feel they’re making a difference. Because we take time to build a relationship with each of our authors, they know that they can help make a regular investment in those organizations.

Make Product Development Decisions a Two-Way Street

If you’re creating products for developers, their needs should be top of mind. Using a product feedback forum allows developers to ask questions and make product requests while giving them a faster feedback loop for their product development. We launched our object storage solution “Spaces” last fall in large part because of the flood of requests we received via our User Voice voting system. We’re not alone by any means in creating two-way streets: GitHub has an extensive forum forum for users to talk about different elements on GitHub and get advice. Stripe allows its community to chat directly with its own devs on Freenode as a way of further fostering their own community.

Providing visibility into your own product road map is also critical — by sharing in advance what you’re planning with your users, you can help them make much smarter long-term decisions.

Meet Them Where They’re At

Connecting with developers in person is incredibly powerful, and meetups are a great avenue for this. However, if geographic barriers arise, broadcasting these meetups live is a nice way to engage people dispersed across multiple locations and ensure they too get value from your meetup programming.

On the more tactical side, sharing swag helps keep your product visible even after the meetup or event has completed. A nice shirt or cute sticker allows your community to feel connected and effectively act as brand ambassadors. We’ve seen this to great effect with our Hacktoberfest effort: After sending t-shirts to individuals helping out with open source projects, we often meet people later at conferences still sporting their well-earned tee.

Building a community takes effort. When beginning to forge one, it is invaluable to consider how your specific audience enjoys connecting and how the company can serve them best. There is no one formula for creating a vibrant, engaged community, but with some experimentation and a lot of listening, you can create something truly special around your product.

— Etel Sverdlov

June 21, 2018
DevSecOps: Embedding a Security Practice into your DevOps Approach

It’s a no-brainer that the element of security cannot be compromised even to the smallest of extents in today’s competitive, fast-paced, modern technology-driven IT infrastructure. However, to keep up with the rapid developments of other processes in this agile world, security is often given relatively less importance and in some cases, even left behind. As the term suggests, DevSecOps is primarily concerned with the incorporation of security in the DevOps pipeline.

The intended primary function of DevSecOps is to help overcome the aforementioned barrier by extending the conventional framework of DevOps and inculcating security testing by means of various security tools. This article attempts to explore the significance, characteristics, benefits and challenges involved in DevSecOps implementation and practice.

Why DevSecOps Matters

Since the rate of cybercrime over the past few years has been increasing at a significantly high rate, the need for adoption and implementation of DevSecOps is also intensifying. An analytical study from Cybersecurity Ventures predicts that the damages incurred from cybercrime will be as high as $6 trillion annually by the year 2021, double the $3 trillion in 2015. As the benefits reaped from implementation are linked directly to the reduction in cyberattacks, DevSecOps is becoming the center of attention of IT decision-makers.

Breaking Down DevSecOps

The following factors constitute the core of the DevSecOps approach and are the key to a successful implementation:

Automation

While the concept of DevOps revolves around automating the build, test and deployment sections, DevSecOps additionally focuses on automating security. Automation is crucial as the security—besides being able to be scrupulous and comprehensive—also has to catch up with the much faster release cycles driven by DevOps. The target of DevSecOps is automating all of the security controls, thus eliminating the need for manual interference.

People, Process and Technology

The trio of people, process and technology is the pillar and it directly influences the extent of success of any DevSecOps approach and practice. The People—considered as the weakest link of the three—are the security specialists and integration of the security team with the development team. Appointing “security champions” who form a cross-functional team to work on the application security, is a key element of the People practice. The Process involves standardizing the workflow, documentation and execution of the same to make sure that the security is transparent with other processes in the workflow. The Technology refers to the various facets deployed in DevSecOps such as the automated vulnerability management, automated compliance scan, etc., whose applications are directly involved in the implementation.

Different Tools for Different Functions

There are a number of security tools that specialize in various aspects of the DevSecOps approach, including testing, secrets management, attack modeling and red team. Selecting the right tool for the right function is paramount and it is not always easy since many of them are still in the emerging phase.

With DevSecOps, You Get …

Enhanced overall security: The overall security of the infrastructure is strengthened by identifying and reducing vulnerabilities as and when they occur. In case some minor breaches happen, the rate at which the recovery happens is also escalated.

Total Cost Reduction: Unlike the conventional approach, in DevSecOps the security issues are identified and dealt with in the development phase itself. Consequently, this leads to reduced overall costs incurred in the development and security of applications.

Accelerated delivery speed: The implementation of DevSecOps consistently strives to detect and eliminate the security bottlenecks at various stages of development. This, in turn, increases the speed at which the product is delivered.

Besides the above-mentioned benefits, DevSecOps also nurtures an environment of transparency and helps in increasing the customer value.

But, Implemention is not a Piece of Cake

Comprehensibly, there are many challenges that lie ahead before DevSecOps implementation. The availability of sufficiently skilled cybersecurity professionals is one of them. This is because the extent of expertise needed in cybersecurity is underrated when compared to other business units. Unlike the traditional environment, a DevSecOps methodology means that the various internal teams of the business unit such as the development and security teams need to work in unison, which might not always go smoothly. The fact that building secure code is time-consuming can frustrate developers, as it hampers their speed of delivery. Many mid- and low-level organizations are skeptical about security as, economically, it is viewed as more of a liability rather than an asset.

In my next article, I will be applying a templated approach to shortlist tools that would be suitable for your organizational needs. For illustration, a series of webinars that cover the various aspects of implementation of DevOps can be found here.

According to the WhiteHat Security Application Statistics Report, “The average customer takes 174 days to fix a vulnerability found when using dynamic analysis in production. However, those who have implemented DevSecOps do it in just 92 days. If we look at vulnerabilities found in development using static analysis, an average company takes 113 days, while the DevSecOps companies take just 51 days.” It is evident that, in the long run, the benefits reaped from DevSecOps outweigh the challenges. A successful approach drastically reduces the chances of succumbing to cybercrimes while being agile and revolving around the mindset, “Everyone is responsible for security.”

— Kavin Elango

June 14, 2018
Spring Cleaning 101: Polishing Up Your DevOps Processes
Dev teams should take time to tune up agile processes and continue advancing their shift toward DevOps

Release cycles are accelerating, but not as fast as development teams want. Customers’ desired release rates are moving at an unimpressive pace; those looking to push out new updates on a weekly basis often find it looks more like a monthly basis—and that just isn’t going to cut it.

As the frequency of execution increases, dev teams find themselves between a rock and a hard place. While the growing demand for faster turnarounds isn’t poised to slow down anytime soon, teams struggle to integrate a set of tools into an efficient pipeline to get the job done within the time allotted. With demand on the rise, how can teams work together to fast-track their release cycles?

It’s time for dev teams to apply a little more elbow grease.

With spring cleaning season upon us, dev teams across industries should take time this season to tune up agile processes and continue the work of advancing their shift toward DevOps.

Dust Off Roles and Responsibilities

A once very siloed practice, software development has since taken on a much more agile approach across teams as the need for faster release cycles rapidly grows. According to a recent VersionOne report, nearly 75 percent of respondents attribute the need to accelerate software delivery to their adoption of agile practices. While DevOps is meant to help dev teams deliver applications at a high velocity, managers encouraging the implementation of these processes often overlook the true meaning of DevOps and the effects these transformations will have on its current employees and their roles.

At its very core, DevOps is the combination of development and operations, which covers a wide range of tasks once performed by developers, testers and operations at different stages throughout the software development life cycle (SDLC). However, a more agile approach means these different processes (building, testing, etc.) are in a more tightly coordinated execution, requiring each of the different silos to have a better understanding—and knowledge—of each process.

Before jumping in to update any processes or technologies, it’s important to ensure all teams are aligned on their evolving roles and responsibilities. Sit down with individuals, teams and their managers to get everyone on the same page and provide guidance on best steps for moving forward this year.

Shrink the Skills Gap

Despite developers’ growing list of responsibilities, a 2018 report from LinkedIn found that there is a significant skills shortage when it comes to software engineers and other similar career trajectories. That gap shrinks even further when you consider the different roles within software engineering itself. For example, developers have recently taken on more responsibility as “full stack developers,” assuring high-quality outputs and confirming there are no bugs in their code, yet have very little knowledge of how to implement continuous testing.

This spring, spend time with employees to brush up on their skills, refine their job responsibilities and uplevel their expertise. While this isn’t a task that can be performed and executed on overnight, some recommendations to kick start the process include:
- Get leadership on board: To fund any of this, teams will need leadership buy-in. Be sure to sit down with those in senior positions to explain the benefits to teamwide training from both an organizational and economic perspective.
- Try the buddy system: Pair up programmers of different skills and levels to mentor one another. Consider it as a coaching system in which team members can provide feedback and training in real time with real-world projects.
- Consider augmenting software delivery practices to improve quality: acceptance test driven development (ATDD) is a proven accelerator and behavior-driven development (BDD) helps bridge varying skills and blind spots between the different personas across the SDLC.
Pick up New and Improved Processes for Increased Productivity

As release cycles accelerate, team leads need to take a close look at each of the stages throughout the SDLC to determine where the roadblocks occur and what exactly is holding employees back. Analyzing not only the quality of outputs, but also how quality assurance is embedded throughout continuous integration (CI) process is a good start.

Throughout the DevOps journey, there are a number of developers across different feature teams adding to, editing, updating and continuously testing code at any given time. Establishing best practices and some basic ground rules can be a simple way to ensure visibility into each of the teams’ productivity. Everyone must constantly be aware of which teams are moving along and which are struggling a bit to make sure code is well-maintained (e.g. determining if your testing code blocking your CI integration) and that there are no memory leaks or poor code development practices throwing the process off. Continuous testing across different feature teams will also assure that every code component for different functionalities is working once they all finally merge.

Getting everyone on the same page will also make it easier to simplify real-time decision making. Be sure to work with teams to define their dashboards, ensuring everyone is seeing the same actionable results at any given time.

Revamp Your Tech

While people and processes should be a main focus for spring cleaning, don’t forget about the tech. The different types of technologies utilized throughout the DevOps pipeline must integrate seamlessly with everything mentioned above.

First, consider your lab environments. The lab is the glue that keeps the entire CI process together, supporting all platforms (whether mobile, desktop, web, etc.). If unstable or unavailable at any given moment, the entire process breaks.

As more organizations begin to adopt these agile approaches to software development, it’s also important to remember that it’s nearly impossible to build a “one-size-fits-all” solution; every new process, tool or technology should integrate well within the existing toolchain, which will vary from business to business. For the most success, don’t jump to conclusions and totally overhaul your current stack. Today, there are very few vendors that offer solutions that address every step throughout the development process. Instead, develop new APIs or integration points that make it easier to diversify the set of tools you already have.

Finally, consider your frameworks. When it comes down to it, there are material differences between the developer’s objectives around tests and the test engineers. Make sure the entire team has tools and access to different frameworks based on their needs. A developer, for example, would use a tool such as Espresso or XCUItest to run a small number of unit tests, whereas test engineers require end-to-end functional test frameworks, such as Appium or Selenium.

Conclusion

While it won’t always be easy, it’s important to take some time this spring to get your DevOps teams looking squeaky clean. Don’t forget to focus on polishing up your processes, training team members and sprucing up your stack to ensure release cycles are on time—and spotless—by the time the summer rolls around.

— Eran Kinsbruner
June 8, 2018
Microsoft Snaps Up GitHub for $7.5 Billion

Recognizing the role GitHub plays in the larger developer and DevOps ecosystems, Microsoft is acquiring the software development platform for a cool $7.5 billion, the two companies have announced.

GitHub, the world’s leading software development platform, has more than 28 million users who “learn, share and collaborate to create the future,” according to the press release announcing the acquisition.

“Developers are the builders of this new era, writing the world’s code. And GitHub is their home,” wrote Microsoft CEO Satya Nadella in a blog post. He noted Microsoft is the most active organization on GitHub, with more than 2 million commits made to projects.

“Microsoft has been a developer-focused company from the very first product we created to the platforms and tools we offer today. Building technology so that others can build technology is core to our mission to empower every person and every organization on the planet to achieve more,” he wrote.

GitHub CEO Chris Wanstrath was quick to point out the irony of Microsoft, once a bastion of proprietary software and apps, purchasing a repository for open source code.

“When GitHub first launched ten years ago, I could have never imagined this headline,” he wrote in his blog. “Git was a powerful but niche tool, clouds were just things in the sky, and Microsoft was a very different company. Open source and business, people said at the time, mixed as well as oil and water.”

That said, there is a certain synergy between the two companies, he noted. “We both believe that software development needs to become easier, more accessible, more intelligent, and more open, so more people can become developers and existing developers can spend more time focusing on the unique problems they’re trying to solve.”

Under the terms of the agreement, Microsoft will acquire GitHub for $7.5 billion in Microsoft stock. The acquisition is expected to close by the end of the calendar year.

Keep checking devopsy.kinsta.cloud for updates on analysis on Microsoft’s purchase of GitHub and its potential impact on the DevOps community at large.

— Charlene O’Hanlon

June 4, 2018