devopsy.kinsta.cloud

Tag: devops jobs

The Scalable Path to DevOps Career Training & Development – A Premium Talent Marketplace

“Our company is a premium talent marketplace with on-demand leadership and clients mostly in the Bay Area, Silicon Valley, New York, and other metropolitan areas,” says Tomas Gutierrez, Partner, Scalable Path, a geographically-distributed network of more than a thousand software architects and developers. Scalable Path serves clients such as tech startups and product companies by helping them build software teams and fill technological gaps. Given that Scalable Path assists with software design, its clients most certainly have needs in DevOps approaches. Scalable Path’s Gutierrez informs devopsy.kinsta.cloud about DevOps career training and development priorities and building blocks.

Foundational Knowledge

At Scalable Path, a good working knowledge of the seven layers of the Open Systems Interconnect model is important for software engineers who want to work with DevOps approaches. “In order to have a full mental picture of what is happening where, software engineers must have a conversational knowledge across all these layers,” says Gutierrez.

With any application of software, you will host it on hardware, you will have an OS, and hosts will talk to each other across a network. “The DevOps engineer must know the seven layers involved in order to consider goals for infrastructure as code and to help with software releases, deployment of infrastructure, networking, and configurations,” explains Gutierrez.

Applicable Traits

On the job, a good DevOps engineer must be a good problem solver, be able to think outside the box, and have empathy for the needs of the software product and the organization, says Gutierrez. Attention to detail and a security focus are also worth accounting for.

“Even though it’s good to have formal training, college degrees, and certifications, the right personality, that of an autodidact (one who is self-taught) is key for good DevOps talent,” says Gutierrez. These engineers will examine a technical challenge globally and in its component parts and seek and assemble the tools and processes that will provide a complete solution.

Further, someone who is empathetic to the needs of the software and the enterprise deploying it will realize when they need to use a simple, cost-effective software deployment without all the extras.

The ability to direct a focused attention to the details of software engineering is another important trait for a DevOps engineer. Otherwise, programming errors occur that can create issues down the road. “If you don’t architect something correctly, you may end up with part of your architecture failing because you made some mistake in programming,” says Gutierrez. These things can propagate and scale up into bigger issues as the architecture grows.

It’s also important for the DevOps engineer to be strong in security such that their programming does not expose critical data. It’s about how the programmer constructs the data layer, how they work with the transport layer, and what the end to end route is for the data, says Gutierrez.

Certifications

Despite the emphasis on traits and approaches to challenges on the job, there are certifications of value to the DevOps engineer. “The Cisco certifications, for example, especially the ones for networking will be helpful since a lot of what you will be doing in DevOps is about data in flight,” says Gutierrez. DevOps engineers need to be mindful of how traffic is moving over the Internet and to and through the data center, explains Gutierrez. Network configuration and network security expertise especially such as is validated through the higher Cisco certifications will be important for the DevOps engineer, Gutierrez adds.

Application security certifications are also useful as are vendor certifications and courses from Chef, Puppet, and Docker as well as platform vendor training from AWS, Digital Ocean, and the like.

Individualized Learning

User documentation and “try me” opportunities for different tools such as containers and configuration management, automation, and deployment tools are helpful for self-starters and people who run into problems or have questions along the way. “People engaging in these kinds of training can simply create local laboratories for these tools on a local machine to simulate the larger application or architecture they are trying to learn,” says Gutierrez.

In order to learn how to navigate the in-depth areas between the system and application architectures, the DevOps student should consider the books in and around these subjects. Just a few examples include, “DevOps: A Software Architect’s Perspective (SEI Series in Software Engineering)”, “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale”, and “Salt Essentials”.

September 18, 2015
LinkedIn Preps Site Reliability Engineers (SREs) For Exciting Careers

Find and Fix, Sink or Swim

A few LinkedIn NOC engineers including Ariel Casas had a hand in forming what the once fledgling business / professional networking company today calls its Site Reliability Engineering organization. “The main difference between SRE and devops is that SREs are basically developers who happen to be very good at operations. So we call them Site Reliability Engineers,” says Ariel Casas, now Manager, Site Reliability Engineering, LinkedIn, explaining the choice of terminology.

In those days, circumstances such as outages would thrust Casas and his colleagues into the middle of the excitement, forcing them to devise solutions to the operations challenges at hand. This gave them opportunity to engage developers about how to work together to avoid future issues.

“Getting thrown into the middle of the storm and having to reverse engineer a service not knowing what it does, not knowing why it’s broken, we basically had to identify the root cause. We had a very, I mean, we still do, but we had a very, very complex infrastructure back when I first started. It was like descrambling an omelet,” says Casas.

Casas and crew located and scraped through log data, combed through config files, identified service dependencies, and figured out how services worked on the spot in order to understand an unexpectedly broken service. “Those opportunities were a great way for us to learn and figure out how our infrastructure worked,” says Casas, whose early training at LinkedIn was largely on-the-job, experiential learning.

Early team members like Casas received a lot of hands-on exposure to the various stages in LinkedIn’s application lifecycles, from conception to design to maintenance. Team members touched the application stack at many points and worked with developers to help them understand how the code they wrote would affect the infrastructure that the NOC had to support.

Playing With Fire

Speaking of particular fires he and his co-workers had to extinguish, Casas recalls an early example when only a few engineers were on hand as they watched the site, waiting for something anomalous to happen. And something did. “We had a company widget go down,” says Casas.

The widget served data that LinkedIn collected about specific enterprises that external media outlets were reporting on. In this instance, the CNN news service’s application of the widget stopped working. “We had no idea about the service or how the widget served that data, we simply knew it was broken and causing a poor experience for the customer,” says Casas.

The team used a Firebug debugging tool to determine the context path for the widget. They connected the dots from there to the service and the port that it was listening on. Then with some log mining relative to that service, they found errors that confirmed that the service could benefit and perhaps fully recover with the aid of some additional memory resources. “We increased the memory for the service, deployed it, restarted it, and it was really rewarding to see the widget behaving the way it should,” says Casas.

On With the Formalities

With more than 150 engineers at LinkedIn now, the company has fewer fires to put out and more need for formal training, including external trainings such as conferences and internal trainings at LinkedIn. SREs attend yearly conferences like Velocity, a WebOps-focused event where speakers flock from different organizations to share on topics where they have subject matter expertise. SREcon is another conference and SREs come to seed knowledge and training in their fellow workers there. LinkedIn also sends speakers to each of these conferences as well as attendees. “We also go to Python trainings to learn how to better code and to understand new concepts that we can use to improve our tooling,” says Casas.

For internal training at LinkedIn the company’s SREs who support select services, such as the internal SaltStack will provide education about developments in those areas. Other training includes Java programming, as the LinkedIn software stack is formed with Java. LinkedIn’s Java SMEs also contribute code back to Java.

LinkedIn also trains SRE staff on Kafka, the messaging system that supports much of that group’s data streaming. “We have some pretty smart engineers who support, own, and develop Kafka here. They provide good training around how we implement and use it,” says Casas. LinkedIn sends Kafka SMEs to meet-ups to train other enterprises in its use.

An Open Door to the SRE Career Advancement Ladder

LinkedIn offers internal trainings with an open door to any high-performing NOC engineer or developer in SRE who wants to attend. “We also have more general trainings called TechTalks and these are high-level and open to anyone in the company,” says Casas.

September 10, 2015
Webinar: How Hired helps DevOps engineers discover new opportunities

Rails v. Recruiting: How engineering is changing the way you’ll get your next job.

In an ideal world, your job search would be efficient, transparent, and flexible in scope. You would have a good idea of your value on the job market and you’d be able to leverage that to find the best opportunities available. The traditional job search methods—job boards, recruiters, and web forms—have left a lot to be desired.

Hired decided to tackle this problem with technology and innovation. They created a web application that powers the world’s first career marketplace. On Hired, software developers & DevOps engineers are introduced to over 2,000 companies in just one week. And here’s where it gets interesting—in the marketplace, the companies apply to the candidates. They’ll make introductory offers to users that provide compensation numbers upfront. The open marketplace encourages transparency and leverages the market’s demand for talent, meaning candidates get insight into their value and the most competitive offers. And the efficiencies created by this software-supported marketplace allow job seekers get more support, more services, and more opportunities.

Do you have questions about the job market for DevOps engineers or technical jobs in general? Interested in learning more about Hired and how it can help you on your job search? Join us on March 31st for a webinar and Q&A with the Hired team. And in the meantime, check out the all new devopsy.kinsta.cloud job page, powered by our friends at Hired!

Video

Slides

[seoslides embed_id=”6c907fb7a8bf” script_src=”https://devopsy.kinsta.cloud/embed-script/hired-slides/5972/” overview_src=”https://devopsy.kinsta.cloud/slides/hired-slides/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”hired-slides” /]

Scott Bacon, Talent Advocate

When Scott is not fundraising for his stealth salted meat startup (Bacon as a Service), he works as a Talent Advocate at Hired—the leading marketplace for engineering and sales talent. Prior to joining Hired, Scott worked onsite at Google as a technical recruiter and toured as a professional musician. Scott graduated from Columbia University with a degree in Anthropology or, as its informally known, “the gateway to sales and marketing jobs”.

Kyle Brett, Software Engineer

Kyle Brett was born with only five fingers on each hand. Despite this, he has become a reasonably talented software engineer. He has five years of professional XP and his first company, Virtrue, was acquired by Oracle. Today, he ships more bugs than any other engineer at Hired. Kyle prefers mechanical keyboards and emphatically believes that cats are better than dogs.

March 2, 2015
You can’t automate relationships

As an organization sold on the idea of DevOps what’s your first step in the journey?

Despite a constant deluge of well-reasoned guides for implementing DevOps the most prevalent step most companies have made is simply contributing to a proliferation of DevOps job titles.

Most likely it’s in no small part because asking the HR department to add “DevOps” to the latest sysadmin job posting title and “Chef” or “Puppet” to the requirements is easy. This is a woefully low bar to set for DevOps implementation. Compounding this further, afterwards when the CIO gets a survey asking about DevOps adoption, they gleefully indicate the company is well on their way and join many others as they artificially inflate industry statistics of a very worthwhile but nonetheless major undertaking for large companies.

Surveys can contribute to confused starts. Any survey that does not include questions on specific practices and draws its conclusions from simply asking if a company is doing a practice that has positive buzz in the industry is worthless. A welcome contrast is the Puppet Labs 2014 State of DevOps report which is quite a beneficial collection of supporting information covering various practices, recommendations and nuances of organizational structures.

Even actually making progress on an individual automation project, whether with newly titled DevOps members or from a grass roots effort in an existing engineering or operations team, does not fulfill a complete implementation strategy nor is it the best way to start. Automation is certainly vital to reliably and repeatably managing environments, but groups shouldn’t rush to tackle automation first only because it’s comfortable to start hacking away at a problem they think they can deal with on their own.

These isolated and well-intentioned practitioners may find that without buy in and solid trust and relationships across groups they may not be given access to automate and orchestrate certain key areas.

You can’t automate relationships!

There needs to be a holistic understanding of the value streams driving engineering work and how best to make improvements. Instead of diving headfirst into automation work on identifying common goals, shared pain, and potential wins across organizational groups. Starting either with collaboration between group members directly or through management level alignment can work provided the other quickly follows. Buy in is required from both engineering and management or progress will stutter.

Taking people through a story can bring support more readily than just listing bullet points. People need to feel emotionally engaged and connected to the pains of the culture and process prior to DevOps and how they can be realistically mitigated. For a large company audience, seeing a story from another large company with timeframes and phases that shepherd the transformation in bold, yet manageable steps can be helpful. The story of SAP Global IT is a candid and useful case study.

Once the stage is set then tackle automation together in a cross-functional group with shared measures of success leading your focus. Depending on the complexity of your process it may be beneficial to collaborate on a smaller application or time boxed simple proof of concept to vet new ideas and working relationships.

Despite the potential for rocky or inefficient starts, the transformative power of a meaningful DevOps implementation contributes to incredible innovation speed and satisfaction. What has worked to keep your organization keeping the long view in mind regarding DevOps?

Many companies are misappropriating the term DevOps to get attention, headcount, or perceived leverage in internal turf wars instead of building a cross-team continuous improvement engine. Is this a sign of the early peak of inflated expectations in the hype cycle?

Are we heading for a serious backlash? Is the tireless promotion of proper practices from prolific thought leaders enough to make failures clearly misguided implementations and not fundamental flaws in the movement?

I’m eager to hear your thoughts in the comments.

July 9, 2014
Defeating the irrational DevOps jobs displacement fear

People are generally resistant to change, but when that change comes accompanied with the whiff of potential for job loss down the road you can count on gentle inertia to snowball in to out-and-out opposition.

Unfortunately, as early misperceptions swirl around the DevOps philosophy, many in the ops world have gotten their backs up in fear that the automation that’s tied to DevOps will endanger their jobs.

“I think it’s almost impossible to overstate the amount of angst that DevOps creates in operations,” says Gene Kim, author of The Phoenix Project. “The big fear in operations is that in order to get to lead times not in months, not to weeks, but to days, you can’t be manually configuring servers, you can’t be manually reviewing things all of the time. And so there’s a deeply held fear that these configuration management tools are going to automate everyone’s job away.”

Now, to the degree that some within IT operations ranks rely solely on large vendors to set the course of their career track, maybe there’s some jeopardy there, Kim says, but competent and capable ops staff needn’t fear the automation reaper.

“It’s a reasonable fear, but it is ridiculous at the same time because we all have so much more work that we could get done if we had the time,” agrees David Mortman chief security architect and distinguished engineer for Dell Enstratius. “Doing things manually is negative value for most organizations.”

And that negative value is having a direct impact on how IT services the business. In the mind of Shridhar Mittal, general manager of application delivery for CA Technologies, one of the big DevOps value propositions is that it helps IT from CIO on down to finally start to meet the pent up demand that the business has been clamoring for from the IT department.

“I’ve yet to see a CIO tell me that they have more supply than demand. Why do you think the business is heading out to directly work with cloud vendors and doing their own thing? It’s not because the IT said no so that 10 people could sit on the sidelines,” he says. “It’s because these projects are added onto the list of 1,500 other things they got asked to do at once.”

Mittal says that CIOs who are gung-ho for DevOps should be proactive about potential resistance from the trenches. This starts with open communication.

“The first thing is start to educate staff that this isn’t about eliminating jobs it is about reducing that gap between demand and supply,” he says.

And as IT leaders do garner more buy in, both they and operations staff will find that these workers actually become more indispensible rather than expendable through automation. DevOps allows workers that might have seemed lackluster to shine as rock stars because they’re more frequently doing higher value work.

“Once you get rid of the garbage work or manual work, which is very time consuming and error-prone, you’re going to find that your engineering team is allowed to perform better,” says Nick Galbreath, vice president of engineering at IPONWEB.

April 22, 2014