Who’s behind Linux now, and should you be afraid?

Most Linux kernel code isn’t developed by who you might think. Here’s a closer look at why this matters.

If you think that Linux is still the "rebel code”—the antiestablishment, software-just-wants-to-be-free operating system developed by independent programmers working on their own time — then it's time to think again.

The Linux kernel is the lowest level of software running on a Linux system, charged with managing the hardware, running user programs, and maintaining security and integrity of the whole set up. What many people don’t realize is that development is now mainly carried out by a small group of paid developers.

A large proportion of these developers are working for "the man” -- large establishment companies in the software and hardware industries, for names like IBM, Intel, Texas Instruments and Cisco. That's according to a Linux Foundation report on Linux kernel development published in February. I
Nobody codes for free

In fact, it turns out that more than 80 percent of all Linux kernel development is "demonstrably done by developers who are being paid for their work," by these big (and sometimes smaller) companies, according to the report.

One organization that isn’t featured in the report's list of companies paying its staff to develop the Linux kernel is Microsoft, a company whose proprietary software model once made it enemy No. 1 for many in the open source movement, but which now claims to embrace free code.
INSIDER: SUSE Linux 12 challenges Red Hat

But one that is featured in the report is Huawei, the Chinese technology company founded by a former Chinese People's Liberation Army officer. That’s a possible cause for concern: The company denies having links to the Chinese government, but some governments, including those in the U.S., U.K. and Australia, have banned the purchasing of certain Huawei hardware products amid worries that they may contain software back doors that could be used for spying.

About 1 percent of all the changes to the Linux kernel are currently written by developers paid by Huawei, according to the report.
Keeping open source open

Amanda McPherson, vice president of developer forums at the Linux Foundation, points out that the whole point of open source software is to remain open to review and close scrutiny, in contrast to proprietary software that runs in many hardware products sold by Huawei and other companies.

“No one can submit a patch on their own," she says. "Security is always a concern, but every patch goes through maintainers, and there is lots of code review. That is a much more secure mechanism than a closed system with no source code availability."

That may be true, but the severe Heartbleed and Shellshock vulnerabilities recently discovered in the open source Bash and OpenSSL software demonstrate that insecure code can be introduced into open source products—unintentionally or perhaps deliberately —and remain undetected for years.

The fact that the vast majority of Linux kernel developers are paid to do so by their employers is a big change from the Linux that Linus Torvalds, then a student at the University of Helsinki, first announced on comp.os.minix in August 1991. At the time he said, "I'm doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones."

In fact, the volume of contributions from students and other volunteers to the Linux kernel has been in steady decline for some time, according to the report: from 14.6 percent of contributions in 2012 to just 11.8 percent now.

"I think that when we started collecting these figures, it was a surprise that so many contributors are paid, and in fact it still is a surprise to the general public. But Linux is a highly commercial enterprise," McPherson says. "Many people thought it was volunteers working in their basements. I think it is good that companies are contributing, even though they are contributing for selfish reasons. They are supporting Linux, but they can't own it or dictate how it is developed."

She points out that if Linux were an application, then paid-for developers would be adding features that met the needs of the corporations that paid them. But the kernel is much more low-level code, and the sorts of contributions that paid developers make often involve enabling hardware connections by providing kernel drivers.
Losing its amateur status

An interesting question, then, is why Linux kernel development has changed so much from the "just a hobby" approach originally envisioned by Torvalds back in 1991, to professional developers working on company time.

One obvious possible answer is that large enterprises, especially hardware manufacturers like Intel or Texas Instruments, have an interest in ensuring that there are Linux drivers for their hardware, and that the kernel can otherwise support their products. Over time, as Linux has become increasingly popular, this type of support has become increasingly important.

But McPherson believes a simpler reason is more plausible. "Kernel developers are in short supply, so anybody who demonstrates an ability to get code into the mainline tends not to have trouble finding job offers. Indeed, the bigger problem can be fending those offers off," the report says.

On a more positive note, the report does highlight some of the achievements of what McPherson describes as "the most collaborative software project in history."

Thanks to contributions from 11,695 developers working for over 1,200 companies, the kernel has been updated with major releases every 8 to 12 weeks. Each release includes more than 10,000 changes, which means that changes are accepted into the kernel at the staggering rate of more than seven every hour.

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com

The day the first iPad arrived

Five years ago Friday, April 3, 2010, the first Apple iPads were delivered to the public.

April 3, 2010
Tablets had always flopped so there was no shortage of naysayers pooh-poohing Apple’s new iPad when the first model was delivered to homes and made available in stores on April 3, 2010. While sales growth has slowed recently, the naysayers could not possibly have been more wrong. Here are some images from the iPad’s debut day.

Sign of things to come
A fan outside the Apple Store in New York City.

Lining up
In what has now become a ritualistic sight for Apple product launches, customers line up for the first iPad outside of a store in San Francisco.

Lining up the goods
A store employee prepares the product for sale in San Francisco.

Initial reaction
Andreas Schobel reacts after being among the first to purchase an iPad at the San Francisco store.

A Halloween costume to come
Lyle Haney walks along the waiting line wearing what would become a common Halloween costume.

300,000 sold that day
A worker rings up a sale in the New York store. Apple reported that it sold 300,000 iPads on that first day.

Mr. iFixIt among buyers
Luke Soules, co-founder of iFixit, was among the first to walk out of the Richmond, Va., store with a pre-ordered iPad. Here is the tear-down iFixit did on the machine.

Employees cheer
Store workers cheer as hundreds of shoppers enter the Chicago outlet.

'Hey Steve, here’s your iPad, buddy’
Steve would appear to be Steve Mays. The UPS guy who brought him his iPad is not identified, but you can hear him announce the delivery here.

You could Google it
And this is what the Google search results page looked like on Day One of the iPad.

It was front-page news
Including in the Honolulu Advertiser, for example, which warned readers to “expect a crowd.”

At the bar
By evening, many an iPad owner was enjoying a new way to end the day with a newspaper and a nig

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com

CRISC Certified in Risk and Information Systems Control

QUESTION 1
Which of the following is the MOST important reason to maintain key risk indicators (KRIs)?

A. In order to avoid risk
B. Complex metrics require fine-tuning
C. Risk reports need to be timely
D. Threats and vulnerabilities change over time

Answer: D

Explanation:
Threats and vulnerabilities change over time and KRI maintenance ensures that KRIs continue to
effectively capture these changes.
The risk environment is highly dynamic as the enterprise's internal and external environments are
constantly changing. Therefore, the set of KRIs needs to be changed over time, so that they can
capture the changes in threat and vulnerability.

Answer: B is incorrect. While most key risk indicator (KRI) metrics need to be optimized in respect
to their sensitivity, the most important objective of KRI maintenance is to ensure that KRIs
continue to effectively capture the changes in threats and vulnerabilities over time. Hence the most
important reason is that because of change of threat and vulnerability overtime.

Answer: C is incorrect. Risk reporting timeliness is a business requirement, but is not a reason for
KRI maintenance.

Answer: A is incorrect. Risk avoidance is one possible risk response. Risk responses are based
on KRI reporting, but is not the reason for maintenance of KRIs.

---

QUESTION 2
You are the project manager of a HGT project that has recently finished the final compilation
process. The project customer has signed off on the project completion and you have to do few
administrative closure activities. In the project, there were several large risks that could have
wrecked the project but you and your project team found some new methods to resolve the risks
without affecting the project costs or project completion date. What should you do with the risk
responses that you have identified during the project's monitoring and controlling process?

A. Include the responses in the project management plan.
B. Include the risk responses in the risk management plan.
C. Include the risk responses in the organization's lessons learned database.
D. Nothing. The risk responses are included in the project's risk register already.

Answer: C

Explanation:
The risk responses that do not exist up till then, should be included in the organization's lessons
learned database so other project managers can use these responses in their project if relevant.

Answer: D is incorrect. If the new responses that were identified is only included in the project's
risk register then it may not be shared with project managers working on some other project.

Answer: A is incorrect. The responses are not in the project management plan, but in the risk
response plan during the project and they'll be entered into the organization's lessons learned
database.

Answer: B is incorrect. The risk responses are included in the risk response plan, but after
completing the project, they should be entered into the organization's lessons learned database.

---

QUESTION 3
You are the project manager of GHT project. You have identified a risk event on your project that
could save $100,000 in project costs if it occurs. Which of the following statements BEST
describes this risk event?

A. This risk event should be mitigated to take advantage of the savings.
B. This is a risk event that should be accepted because the rewards outweigh the threat to the
project.
C. This risk event should be avoided to take full advantage of the potential savings.
D. This risk event is an opportunity to the project and should be exploited.

Answer: D

Explanation:
This risk event has the potential to save money on project costs, so it is an opportunity, and the
appropriate strategy to use in this case is the exploit strategy. The exploit response is one of the
strategies to negate risks or threats appear in a project. This strategy may be selected for risks
with positive impacts where the organization wishes to ensure that the opportunity is realized.
Exploiting a risk event provides opportunities for positive impact on a project. Assigning more
talented resources to the project to reduce the time to completion is an example of exploit
response.

Answer: B is incorrect. To accept risk means that no action is taken relative to a particular risk;
loss is accepted if it occurs. But as this risk event bring an opportunity, it should me exploited and
not accepted.

Answer: A and C are incorrect. Mitigation and avoidance risk response is used in case of negative
risk events, and not in positive risk events. Here in this scenario, as it is stated that the event could
save $100,000, hence it is a positive risk event. Therefore should not be mitigated or avoided.

---

QUESTION 4
You are the project manager of a large construction project. This project will last for 18 months
and will cost $750,000 to complete. You are working with your project team, experts, and
stakeholders to identify risks within the project before the project work begins. Management wants
to know why you have scheduled so many risk identification meetings throughout the project
rather than just initially during the project planning. What is the best reason for the duplicate risk
identification sessions?

A. The iterative meetings allow all stakeholders to participate in the risk identification processes
throughout the project phases.
B. The iterative meetings allow the project manager to discuss the risk events which have passed
the project and which did not happen.
C. The iterative meetings allow the project manager and the risk identification participants to
identify newly discovered risk events throughout the project.
D. The iterative meetings allow the project manager to communicate pending risks events during
project execution.

Answer: C

Explanation:
Risk identification is an iterative process because new risks may evolve or become known as the
project progresses through its life cycle.

Answer: D is incorrect. The primary reason for iterations of risk identification is to identify new risk
events.

Answer: B is incorrect. Risk identification focuses on discovering new risk events, not the events
which did not happen.

Answer: A is incorrect. Stakeholders are encouraged to participate in the risk identification
process, but this is not the best choice for the

---

QUESTION 5
You are the risk official in Bluewell Inc. You are supposed to prioritize several risks. A risk has a
rating for occurrence, severity, and detection as 4, 5, and 6, respectively. What Risk Priority
Number (RPN) you would give to it?

A. 120
B. 100
C. 15
D. 30

Answer: A

Explanation:
Steps involving in calculating risk priority number are as follows:
Identify potential failure effects
Identify potential causes
Establish links between each identified potential cause
Identify potential failure modes
Assess severity, occurrence and detection
Perform score assessments by using a scale of 1 -10 (low to high rating) to score these
assessments.
Compute the RPN for a particular failure mode as Severity multiplied by occurrence and detection.
RPN = Severity * Occurrence * Detection
Hence,
RPN = 4 * 5 * 6
= 120

Answer: C, D, and B are incorrect. These are not RPN for given values of severity, occurrence,
and detection.

---

Best Isaca Certification, CRISC Training at certkingdom.com

642-736 Implementing Advanced Cisco Unified Wireless Security (IAUWS)

---

QUESTION 1
What is the purpose of looking for anomalous behavior on a WLAN infrastructure?

A. Identifying new attack tools
B. Auditing employee's bandwidth usage
C. Identifying attacks using signature matching
D. Improving performance by load balancing

Answer: A

---

QUESTION 2
As of controller release v5.2, which two statements about wired guest access support are true?
(Choose two.)

A. It is not supported on the Cisco 2100 Series Controllers.
B. No more than three wired guest access LANs can be configured on a controller.
C. Layer 3 web authentication and passthrough are not supported.
D. Wired guest access cannot be configured in a dual-controller configuration that uses an anchor
controller and a foreign controller.
E. The wired guest access ports must be in the same Layer 2 network as the foreign controller.

Answer: A,E

---

QUESTION 3
The wireless client can roam faster on the Cisco Unified Wireless Network infrastructure when
which condition is met?

A. EAP-FAST is used for client authentication on the wireless network.
B. Cisco Centralized Key Management is used for Fast Secure Roaming.
C. QoS is being used on the WLAN to control which client packets get through the network faster.
D. RRM protocol is used between multiple APs that the client associates to while roaming.

Answer: B

---

QUESTION 4
Which option best describes an evil twin attack?

A. A rouge access point broadcasting a trusted SSID
B. A rogue access point broadcasting any SSID
C. A rouge ad-hoc with the SSID "Free WiFi"
D. A rouge access point spreading malware upon client connection

Answer: A

---

QUESTION 5
Which two configuration parameters does NAC OOB require on a SSID/WLAN? (Choose two.)

A. WMM enabled on the WLAN
B. Open authentication on the WLAN
C. AAA override configuration on the WLAN
D. 802.1x configuration on the WLAN

Answer: B,D

---

Best Cisco CCNP Certification, Cisco 642-736 Training at certkingdom.com

3V00290A APDS Avaya Scopia Online Test

---

QUESTION 1
You are proposing videoconferencing for a customer with 15 large meeting rooms, 25 small
meeting rooms, and 4000 employees dispersed over three continents: North America, Asia, and
Europe. Thirty percent of the workforce will be video-enabled, and you are proposing XT5000s for
the large meeting rooms and XT4200 for the small meeting rooms. Using the normal 1:10 ratio for
simultaneous rooms and users, how many ports (including cascading) and Elite 5000 MCUs
should be included in the design?

A. 440 352p ports or 4 Elite 5230 MCUs
B. 280 352p ports or 2 Elite 5230 MCUs
C. 152 352p ports or 3 Elite 5115 MCUs
D. 140 352p ports or 4 Elite 5110 MCUs
E. 136 352p ports or 3 Elite 5110 MCUs

Answer: C

Explanation:

---

QUESTION 2
Your customer, Jay, is reviewing your proposal for Scopia® video conferencing. He notices that
within Scopia Management, there is a SIP Back-to-Back User Agent and an internal gatekeeper
that could be external. When would you tell him he would use an external gatekeeper instead of
an internal gatekeeper?

A. In order to work with an external Microsoft SQL database
B. When running Scopia Management (iView) on a Linux server
C. To support configurations with multiple cascaded Elite MCUs
D. To support Scopia Management (iView) redundancy

Answer: D

Explanation:

---

QUESTION 3
Your customer is concerned about the ease of use for the infrequent video collaboration user. You
explain that your solution includes Scopia' Control. What is Scopia Control?

A. An iPad app for conference control.
B. An Android mobile device app for conference control.
C. An Android mobile device app for configuring the user's virtual room.
D. An iPad app for configuring the user's virtual room.

Answer: A

Explanation:
Scopia Control is an Apple iPad application for control of Avaya video conferencing systems. The
highly intuitive user interface virtually eliminates the learning curve for a video conferencing
system. The integrated conference room calendar and enterprise directory makes it easy to join
meetings and invite others. Room system control and meeting moderation are simple through the
iPad Multi-Touch user interface.
Reference: http://www.avaya.com/usa/product/avaya-scopia-xt-video-conferencing/

---

QUESTION 4
You are meeting with your Account Team and discussing a small SMB customer. You're hesitant
to select the Scopia® SMB solution with the MCU embedded in the XT1200, because it has some
differences from a configuration with an Elite MCU and Scopia Management (iView). Select three
capabilities the SMB solution does not support that you would discuss with the Account Team.
(Choose 3)

A. Support for Scopia Mobile users
B. Support for internal Scopia Desktop Client users
C. Support recording and streaming of conferences
D. Support for encryption of conferences over 4
E. Support for external Scopia Desktop Client users
F. Support multiple concurrent conferences

Answer: D,E,F
Reference: http://docs.radvision.com/bundle/rv_solution_guide_8/soln_sg_deployment_smb_limits

---

QUESTION 5
For users who operate out of the office, Scopia® offers desktop client and mobile applications.
Your friend Oliver, another SE, calls to ask you about a statement in the Scopia marketing
materials that says that Scopia is the best meet-me client because it is more than an endpoint.
Although there are many reasons, what two would you want to tell Oliver about? (Choose 2)

A. Error resiliency for both the desktop and mobile clients uses SVC (scalable video coding) and
Netsense
B. Users can download the presentation using the slider feature
C. User features such as chat, FECC (far end camera control), and raise hand
D. Best user experience with calendar integration and one tap to join
E. Simple and secure firewall traversal using HTTPS (hypertext transfer protocol secure)

Answer: D,E

Explanation:

---

Best Avaya Certification Training and 3V00290A Exams Training 
and more 4000+ exams log in to Certkingdom.com

Sensor tech makes predicting the future easier to do

Internet of Things industrial applications designed to forecast failure gain adoption

LAS VEGAS - We no longer need seers, oracles and psychics to tell us about the future. The declining cost of sensor technology and the availability of cloud-based analytical platforms is making predictive analytics accessible to every industry and most products.

These technologies give insights into how products are performing. Sensors record vibration, temperature, pressure and voltage, among other conditions, and provide data for real-time analysis. Sensors can help lead to discovery of faulty parts in products weeks before they actually fail.

Initial deployments of sensors have been in large and expensive industrial platforms, such as electrical generation systems and jet engines. In time, sensors connected to analytical platforms will be found in nearly every product.

The belief is that this technology will make machinery and systems more reliable. Sensors and analytics will alert users and vendors to problems days, weeks and months before a problem becomes visible. This insight into performance will also significantly reduce unplanned failures.

"We will know more about when they are going to fail, and how they fail," said Richard Soley, CEO of the Object Management Group, a nonprofit technology standards consortium.

Businesses will also benefit from learning how customers are using their products, which will shape how products are made, Soley said.

Predictive analytics capability in industrial applications is not a new concept. Big machinery has long used sensors. What is new is the convergence of three major trends that will make deployment ubiquitous, say people working in this area.

First, sensor technology is declining in price as it gets smaller and more efficient; second, wireless communication systems have become reliable and global; third, is that cloud-based platforms that can be used for analytics and development are emerging rapidly. Collectively, these trends underpin the Internet of Things.

At IBM's big conference, InterConnect, this week, the University of South Carolina was showing off a sensor-equipped gear box on an Apache helicopter that is part of study for the U.S. Army. There were four sensors on the gear box collecting temperature and vibration data.

One of the big savings in the use of this technology, aside from predicting failure, is correctly planning maintenance. Many maintenance activities may be unnecessary, wasteful and can introduce new problems.

"If you can reduce improper maintenance processes and improve the identification of faulty maintenance, you can directly impact safety," said Retired Maj. Gen. Lester Eisner, with South Carolina's National Guard, who is deputy director of the university's Office of Economic Engagement.

In another area, National Instruments has been working with utilities to deploy its sensor technology. Today, many utilities have employees who collect data directly off machines, which is something of a shotgun approach, said Stuart Gillen, principal marketing manager at the company and a speaker at the IBM conference.

All it takes is one or two "catches" – preventing a failure in a large system – to justify the cost of deploying technology that can take in all the data from these systems and provide a more targeted approach to maintaining them, Gillen said.

National Instruments is working with IBM and its recently launched Internet of Things capability, which is part of IBM's Bluemix cloud platform. This platform gives developers the ability to create new ways of working with the machine data.

There is much optimism that this technology will reduce equipment failures. Having the ability to see a little further into the future and reducing the need to rely on the benefit of hard-learned hindsight is the goal. But no one is predicting that this technology will eliminate failure all together.

"There are a lot of variables" that can contribute to equipment failure, said Sky Matthews, the CTO of IBM's Internet of Things effort, but this technology "can certainly dramatically reduce them."

---

Best comptia A+ Training, Comptia A+ Certification at Certkingdom.com

How Etsy makes Devops work

Etsy, which describes itself as an online “marketplace where people around the world connect to buy and sell unique goods,” is often trotted out as a poster child for Devops. The company latched onto the concepts early and today is reaping the benefits as it scales to keep pace with rapid business growth. Network World Editor in Chief John Dix caught up with Etsy VP of Technical Operations Michael Rembetsy to ask how the company put the ideas to work and what lessons it learned along the way.

Let’s start with a brief update on where the company stands today.
The company was founded and launched in 2005 and, by the time I joined in 2008 (the same year as Chad Dickerson, who is now CEO), there were about 35 employees. Now we have well over 600 employees and some 42 million members in over 200 countries around the world, including over 1 million active sellers. We don’t have sales numbers for this year yet, but in 2013 we had about $1.3 billion in Gross Merchandise Sales.

How, where and when did the company become interested in Devops?
When I joined things were growing in a very organic way, and that resulted in a lot of silos and barriers within the company and distrust between different teams. The engineering department, for example, put a lot of effort into building a middle layer – what I called the layer of distrust – to allow developers to talk to our data bases in a faster, more scalable way. But it turned out to be just the opposite. It created a lot more barriers between database engineers and developers.

Everybody really bonded well together on a personal level. People were staying late, working long hours, socializing after hours, all the things people do in a startup to try to be successful. We had a really awesome office vibe, a very edgy feel, and we had a lot of fun, even though we had some underlying engineering issues that made it hard to get things out the door. Deploys were often very painful. We had a traditional mindset of, developers write the code and ops deploys it. And that doesn’t really scale.

How often were you deploying in those early days?
Twice a week, and each deploy took well over four hours.
"Deploys were often very painful. We had a traditional mindset of, developers write the code and ops deploys it. And that doesn’t really scale."

Twice a week was pretty frequent even back then, no?
Compared to the rest of the industry, sure. We always knew we wanted to move faster than everyone else. But in 2008 we compared ourselves to a company like Flickr, which was doing 10 deploys a day, which was unheard of. So we were certainly going a little bit faster than many companies, but the problem was we weren’t going fast with confidence. We were going fast with lots of pain and it was making the overall experience for everyone not enjoyable. You don’t want to continuously deploy pain to everyone.We knew there had to be a better way of doing it.

Where did the idea to change come from? Was it a universal realization that something had to give?
The idea that things were not working correctly came from Chad. He had seen quite a lot in his time at Yahoo, and knew we could do it better and we could do it faster. But first we needed to stabilize the foundation. We needed to have a solid network, needed to make sure that the site would be up, to build confidence with our members as well as ourselves, to make sure we were stable enough to grow. That took us a year and a half.

But we eventually started to figure out little things like, we shouldn’t have to do a full site deploy every single time we wanted to change the banner on the homepage. We don’t have any more banners on the homepage, but back in 2009 we did. The banner would rotate once a week and we would have to deploy the entire site in order to change it, and that took four hours. It was painful for everyone involved. We realized if we had a tool that would allow someone in member ops or engineering to go in and change that at the flick of a button we could make the process better for everyone.
"I can’t recall a time where someone walked in and said, “Oh my God, that person deployed this and broke the site.” That never happened. People checked their egos at the door."

So that gave birth to a dev tools team that started building some tooling that would let people other than operational folks deploy code to change a banner. That was probably one of the first Devops-like realizations. We were like, “Hey, we can build a better tool to do some of what we’re doing in a full deploy.” That really sparked a lot of thinking within the teams.

Then we realized we had to get rid of this app in the middle because it was slowing us down, and so we started working on that. But we also knew we could find a better way to deploy than making a TAR file and SSH’ing and R-synch’ing it out to a bunch of servers, and then running another command that pulls the server out of the load balancer, unpacks the code and then puts the server back in the load balancer. This used to happen while we sat there hoping everything is ok while we’re deploying across something like 15 servers. We knew we could do it faster and we knew we could do it better.

The idea of letting developers deploy code onto the site really came about toward the end of 2009, beginning of 2010. And as we started adding more engineers, we started to understand that if developers felt the responsibility for deploying code to the site they would also, by nature, take responsibility for if the site was up or down, take into consideration performance, and gain an understanding of the stress and fear of a deploy.

It’s a little intimidating when you’re pushing that big red button that says – Put code onto website –because you could impact hundreds of thousands of people’s livelihoods. That’s a big responsibility. But whether the site breaks is not really the issue. The site is going to break now and then. We’re going to fix it. It’s about making sure the developers and others deploying code feel empowered and confident in what they’re doing and understand what they’re doing while they’re doing it.

So there wasn’t a Devops epiphany where you suddenly realized the answer to your problems. It emerged organically?
It was certainly organic. If development came up with better ideas of how to deploy faster, operations would be like, “OK, but let’s also add more visibility over here, more graphs.” And there was no animosity between each other. It was just making things faster and better and stronger in a lot of ways.

And as we did that the culture in the whole organization begin to feel better. There was no distrust between people. You’re really talking about building trust and building friendships in a lot of ways, relationships between different groups, where it’s like, “Oh, yeah. I know this group. They can totally do this. That’s fine. I’ll back them up, no problem.” In a lot of organizations I’ve worked for in the past it was like, “These people? Absolutely not. They can’t do that. That’s absurd.”
"I didn’t marry my wife the first day I met her. It took me a long time to get to the point where I felt comfortable in a relationship to go beyond just dating. It takes longer than people think and they need to be aware of that because, if it doesn’t work after a quarter or it doesn’t work after two quarters, people can’t just abandon it."

And you have to remember this is in the early days where the site breaks often. So it was one of those things, like, OK, if it breaks, we fix it, but we want reliability and sustainability and uptime. So in a lot of ways it was a big leap of faith to try to create trust between each other and faith that other groups are not going to impact the rest of the people.

A lot of that came from the leadership of the organization as well as the teams themselves believing we could do this. Again, we weren’t an IBM. We were a small shop. We all sat very close to one another. We all knew when people were coming and leaving so it made it relatively easy to have that kind of faith in one another. I can’t recall a time where someone walked in and said, “Oh my God, that person deployed this and broke the site.” That never happened. People checked their egos at the door.

I was going to ask you about the physical proximity of folks. So the various teams were already sitting cheek by jowl?
In the early days we had people on the left coast and on the right coast, people in Minnesota and New York. But in 2009 we started to realize we needed to bring things back in-house to stabilize things, to make things a little more cohesive while we were creating those bonds of trust and faith. So if we had a new hire we would hire them in-house. It was more of a short term strategy. Today we are more of a remote culture than 2009.

But you didn’t actually integrate the development and operations teams?
In the early days it was very separate but there was no idea of separation. Depending upon what we were working on, we would inject ourselves into those teams, which led later to this idea of what we call designated operations. So when John Allspaw, SVP of Operations and Infrastructure, came on in 2010, we were talking about better ways to collaborate and communicate with other teams and John says, “We should do this thing called designated operations.”

The idea of designated ops is it’s not dedicated. For example, if we have a search team, we don’t have a dedicated operations person who only works on search. We have a designated person who will show up for their meetings, will be involved in the development of a new feature that’s launching. They will be injecting themselves into everything the engineering team will do as early as possible in order to bring the mindset of, “Hey, what happens if that fails to this third-party provider? Oh, yeah. Well, that’s going to throw an exception. Oh, OK. Are we capturing it? Are we displaying a friendly error for an end user to see? Etc.”

And what we started doing with this idea of designated ops is educate a lot of developers on how operations works, how you build Ganglia graphs or Nagios alerts, and by doing that we actually started creating more allies for how we do things. A good example: the search team now handles all the on-call for the search infrastructure, and if they are unavailable it escalates to ops and then we take care of it.

So we started seeing some real benefits by using the idea of this designated ops person to do cross-team collaboration and communication on a more frequent basis, and that in turn gave us the ability to have more open conversations with people. So that way you remove a lot of the mentality of, “Oh, I’m going to need some servers. Let me throw this over the wall to ops.”

Instead, what you have is the designated ops person coming back to the rest of the ops team saying, “We’re working on this really cool project. It’s going to launch in about three months. With the capacity planning we’ve done it is going to require X, Y and Z, so I’m going to order some more servers and we’ll have to get those installed and get everything up and running. I want to make everybody aware I’m also going to probably need some network help, etc.”

So what we started finding was the development teams actually had an advocate through the designated ops person coming back to the rest of the ops team saying, “I’ve got this.” And when you have all of your ops folks integrating themselves into these other teams, you start finding some really cool stuff, like people actually aren’t mad at developers. They understand what they’re trying to do and they’re extremely supportive. It was extremely useful for collaboration and communication.

So Devops for you is more just a method of work.

Correct. There is no Devops group at Etsy.

How many people involved at this point?

Product engineering is north of 200 people. That includes tech ops, development, product folks, and so on.

How do you measure success? Is it the frequency of deployments or some other metric?
Success is a really broad term. I consider failure success, as well. If we’re testing a new type of server and it bombs, I consider that a success because we learned something. We really changed over to more of a learning culture. There are many, many success metrics and some of those successes are actually failures. So we don’t have five key graphs we watch at all times. We have millions of graphs we watch.

Do you pay attention to how often you deploy?
We do. I could tell you we’re deploying over 60 times a day now, but we don’t say, “Next year we want to deploy 100 times a second.” We want to be able to scale the number of deploys we’re doing with how quickly the rest of the teams are moving. So if a designated ops or development team starts feeling some pain, we’ll look at how we can improve the process. We want to make sure we’re getting the features out we want to get out and if that means we have to deploy faster, then we’re going to solve that problem. So it’s not around the number of deploys.

I presume you had to standardize on your tool sets as you scaled.
We basically chose a LAMP stack: Linux, Apache, MySQL and PHP. A lot of people were like, “Oh, I want to use CoffeeScript or I want to use Tokyo Cabinet or I want to use this or that,” and it’s not about restricting access to languages, it’s about creating a common denominator so everyone can share experiences and collaborate.

And we wrote Deployinator, which is our in-house tool that we use to deploy code, and we open-sourced it because one of our principles is we want to share with the community. Rackspace at one point took Deployinator and rewrote a bunch of stuff and they were using it as their own deploying tool. I don’t know if they still are today, but that was back in the early days when it first launched.

We use Chef for configuration management, which is spread throughout our infrastructure; we use it all over the place. And we have a bunch of homegrown tools that help us with a variety of things. We use a lot of Nagios and Graphite and Ganglia for monitoring. Those are open-source tools that we contribute back to. I’d say that’s the vast majority of the tooling that ops uses at this point. Development obviously uses standard languages and we built a lot of tooling around that.

As other people are considering adopting these methods of work, what kind of questions should they ask themselves to see if it’s really for them?
I would suggest they ask themselves why they are doing it. How do they think they’re going to benefit? If they’re doing it to, say, attract talent, that’s a pretty terrible reason. If they’re doing it to improve the overall structure of the engineering culture, enable people to feel more motivated and ownership, or they think they can improve the community in which they’re responsible or the product they’re responsible for, that’s a really good reason to do it.

But they have to keep in mind it’s not going to be an overnight process. It’s going to take lots of time. On paper it looks really, really easy. We’ll just drop some Devops in there. No problem. Everybody will talk and it will be great.

Well no. I didn’t marry my wife the first day I met her. It took me a long time to get to the point where I felt comfortable in a relationship to go beyond just dating. It takes longer than people think and they need to be aware of that because, if it doesn’t work after a quarter or it doesn’t work after two quarters, people can’t just abandon it. It takes a lot of time. It takes effort from people at the top and it takes effort from people on the bottom as well. It’s not just the CEO saying, “Next year we’re going to be Devops.” That doesn’t work. It has to be a cultural change in the way people are interacting. That doesn’t mean everybody has to get along every step of the way. People certainly will have discussions and disagreements about how they should do this or that, and that’s OK.

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com