devopsy.kinsta.cloud

Tag: DevOps engineers

  • DevOps Done Right: How to Succeed in DevOps From Day One

    DevOps Done Right: How to Succeed in DevOps From Day One

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey. Join us on May 4, 2023, to learn how to get started with DevOps—and how to do it right.

    You’ll learn:

    • DevOps best practices, processes and the tools you’ll need
    • Tips and tricks from experienced practitioners sharing their real-world experiences
    • The basics of DevOps
    • How to choose the right technologies
    • Common challenges and how to overcome them
    • The benefits of DevOps as a methodology and a career
    • And more!

    As organizations face increasing pressure to adapt faster and become more agile, getting DevOps right and adopting a DevOps mindset is crucial to deliver high-quality software faster and increase business value. And that opens up great opportunities for anyone looking to start a new career or pivot from an existing role in technology.

    DevOps has become the standard of software development methodologies and it’s critical for successful digital transformation. Adopting DevOps—and doing it the right way—can benefit not only your organization but also your customers and end users by fostering innovation, reducing time to market, increasing development productivity, improving product quality and reliability and reducing costs.

    That’s why many big companies, such as Amazon, Netflix, Facebook and many others have adopted a DevOps mindset—and DevOps practices. And as more businesses are looking to move to the cloud and transition into DevOps, there are plenty of job opportunities available for DevOps engineers at various levels.

    DevOps is a growing field with a lot of opportunities for professional growth. According to a research study by Global Market Insights Inc., the DevOps market is expected to surpass $30 billion by 2028. Due to the high demand for skilled DevOps engineers and the shortage of qualified DevOps professionals in the industry, there is no better time to upskill than now.

    Whether you are diving into DevOps for the first time or trying to do it right this time, DevOps Onramp provides all the information you need for a successful DevOps journey.

    At DevOps Onramp Virtual Summit, taking place on May 4, 2023, you’ll get all the knowledge you need to get started with DevOps —and how to do it right. Join us to learn about DevOps best practices, processes and tools and get tips and tricks from experienced practitioners sharing their real-world experiences. We’ll go through the basics of DevOps, how to choose the right technologies, common challenges and the benefits of DevOps.

    One thing is for sure: The future of DevOps is very promising. The rush has started—don’t be left behind!

    DevOps Onramp Virtual Summit - Submit your talk

    If you’re interested in becoming a sponsor, please contact us. For more information, please visit the DevOps Onramp website.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    SimplyHired

    Kyndryl
    Remote
    DevOps Engineer
    $95,700 – $265,200

    Monster.com

    Randstad
    Remote
    Senior Cloud SRE
    $130,000 – $150,000

    Dice.com

    Staples
    Framingham, Mass.
    Senior Software Engineer I- CICD/DevOps
    $135,000

    Indeed

    Odyssey Information Systems
    Remote
    Senior DevOps Engineer
    $117,798 – $156,338

    ZipRecruiter

    Synthego
    Redwood City, CA
    Senior DevOps Engineer
    $113,000 to $165,000

  • How Engineers Can Contribute to API Security

    How Engineers Can Contribute to API Security

    I’m an engineer, not a security professional. I’ve worked at several startups over the years and have discovered ways to shift my engineering mindset to include a security focus and to incorporate security into my coding practice. 

    I’ve found that when you work with others, an engineering organization can significantly contribute to API security. But how we think about software makes it difficult to get started. There is an alternative perspective—a road not taken—that must be considered when it comes to securing endpoints from threat actors. 

    The Road Not Taken

    Engineers create and optimize applications to solve problems for real users. Engineering time is often in short supply, so we optimize the speed at which we can write those applications. To speed up our processes, we simplify problems and find reusable patterns or techniques. Add a bit of glue, and you have software.

    This perspective is constructive. Thoughts come first and software comes next. And when refactoring existing code for software, we need to think this way. But this utility comes at a cost: If the software works, we only see what it should do. The real story behind the scenes can be much more complex.

    A few years ago, I worked with an engineer on new endpoints for an authorization API. We were working out an issue in the implementation where I could call the endpoints out of order and bypass a challenge. We worked through the example, and he said, “But they are supposed to be called in 1-2-3 order.”

    Attackers don’t share this perspective. Instead, they want to manipulate the software to act in their own interests. They ask, “What is possible?” instead of “What is it supposed to do?” and find ways in which the system fails. To an attacker, the glue is more interesting than the design.

    While probing, an attacker may be thinking some of the following questions: 

    “The password reset endpoint is on v2? Is v1 still running?” 

    “What happens if I skip the verify endpoint?” 

    “What happens when I pass null in the challenge? Empty string? SQL injection?”

    As creators, we’ve converged on this constructive perspective. To build secure software, we need to consider the road not taken and incorporate greater security into our applications.

    Playing Defense

    When you are defending software, your limited time is a disadvantage. There are many engineers—and some have been writing software for many years—which means that you have a lot of code to defend. Each application depends on hundreds or thousands of open source projects, from libraries to deployment tools to server operating systems. 

    Security tools can help you think from both perspectives, especially those that automatically discover endpoints and track response statistics. You can use this data to understand how code maps to your public API surface. 

    In addition to tools, here are several suggestions for on the ground techniques that you could try out.

    Read the Code

    Pick an application, find out where the authentication and authorization code is and read it. Even if you aren’t a strong coder, you can learn something interesting. Better yet, try and take the attacker’s perspective and look for ways you can exploit the code and make it work for you. For instance, you may see the following:

    “SQL injection might be possible in this area. I might be able to extract information about other accounts.”

    “Authorization is complex and confusing in this area. I might be able to use my standard user account to execute actions on other accounts.”

    “Logging is very weak in this sensitive area. I might be able to hammer this endpoint without being noticed.”

    “Code or comments indicate the developer assumes the application is secure for a particular reason. Can I break those assumptions with an external request?”

    The knowledge gained in performing an exercise like this is priceless. You can use it to guide the rest of your API/AppSec work (pentesting, scan remediation, etc.). Further, you’ll often find logical vulnerabilities that scans couldn’t detect.

    Read Code Reviews

    Engineers make decisions in pull requests (PRs). Content in past PRs and review comments have tons of context and can be used to help inform your decision-making. Look through the history, then think through some security-focused review questions:

    “If the code tries to enforce security constraints, can I think of a way around them?”

    “Are there obvious security mechanisms that should be part of this change but are missing?”

    “Would unusual attacker behavior appear in logs?”

    Examining these reviews and understanding the broader context can provide you with valuable information. You might find a sensitive action without any authorization logic, ways a user account can access data owned by other users, or a path through the password reset flow without a valid challenge token.

    Work With Engineers

    If your engineers are working on security-relevant code, ask for some time to talk. Find out what they are working on (and why). Help them think like an attacker, and explain some of the techniques an attacker might use to break their app. And remember to take the road not taken while you work to ensure the security of your applications. 

  • Best of 2021 – Why DevOps Will Cease to Exist

    Best of 2021 – Why DevOps Will Cease to Exist

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the twelfth in our series of the Best of 2021.

    Nowadays I feel like there is no need to explain why DevOps as a methodology exists, as it is widely understood and accepted.

    But the reason DevOps engineers exist is not to ensure the success of its namesake methodology, nor, if we’re being honest, is the practice evolving into a role that’s viable for future progress. Rather, it’s on the verge of becoming obsolete.

    Surprisingly, in many cases having a DevOps engineer can actually get you further from the DevOps methodology objectives, rather than closer.

    How Does One Become a DevOps Engineer?

    I only recently stumbled upon DevOps courses in high-tech academies.

    Before it was an actual field of study, I’m pretty sure no one’s first step into the software development world was in a DevOps role.

    I personally started as a NOC engineer and later became a Linux administrator – developing a passion for the cloud and automation. Only years later did I dive into my first DevOps position. Others have made even lengthier journeys, starting from helpdesk support roles managing organizations’ PCs, printers and networks.

    The thing is, the starting point for people who choose a software development career starts exactly there: developing software.

    Typically, they either go to college or university or learn development online or via a bootcamp, where Linux, networking, virtualization, high availability and scaling are barely taught. And, of course, some extraordinary senior developers become infrastructure experts, but personally, I would call those folks architects and not DevOps engineers. This is probably the reason why almost every organization is in need of someone who’ll take on those responsibilities as a DevOps engineer.

    Signs of the End

    The number of cloud solutions is steadily growing every year, with cloud services becoming the dominant method of consuming business services. Gartner estimated a 40% increase in cloud services business revenue from 2020 to 2022.

    “Software as a service (SaaS) remains the largest market segment and is forecast to grow to $104.7 billion in 2020 (see table, below). The continued shift from on-premises license software to subscription-based SaaS models,” according to the firm.

    Worldwide Public Cloud Service Revenue Forecast (Millions of U.S. Dollars)

    New PaaS, SaaS and IaaS products are launched every year to make the development and maintenance of other applications easy and effortless.

    Hell, some SaaS products go as far as making it unnecessary, with platforms like WIX, Shopify, and Auth0, resulting in fewer developers being required to develop those kinds of applications. On top of that, there are already products that run almost entirely on Serverless services. Recently the term Storageless was coined and started to pop up here and there.

    At the same time, the number of developers is increasing every year. According to Statista between the years 2018 and 2019 the number of developers grew by almost a million. So, while the number of developers is growing, a big part of their responsibilities are being automated.

    This gradually frees up more time for developers to deal with DevOps challenges, which are also being automated by services like Coralogix, Datadog, JFrog, CircleCI, Gitlab and many more.

    Some companies, like Monday.com, have already acknowledged that it is not optimal to have a separate team or a single person in charge of all of the operations and maintenance of applications and that it is better to have developers responsible for their application stack from end to end.

    Although I opened by saying there is no need to explain why DevOps as a methodology exists, sometimes what gets forgotten is that DevOps evolved as a way to break down the silos between development and operations. But many organizations don’t recognize the irony of then having a separate team in charge of all operations and maintenance – that just defeats the purpose.

    Hopefully, as this trend grows, universities and coding courses will acknowledge these issues as core challenges in software development and include these subjects and principles in their curriculum.

    The Future As I See It

    This could be wishful thinking on my part, but I believe sometime in the future we will reach a point where all developers will be required to understand and practice DevOps. A developer who understands the cost of running their application, how Kubernetes assures it is always available and resilient and how to build more scalable and more secure application stacks will simply be better at their job and more valuable to their company. The opposite is also true; a DevOps engineer will be able to build better CI/CD pipelines, better monitoring solutions and cloud architectures if they are taking an active role in development and actually knows the application stack and his team’s pains and needs.

    Even if I’m wrong – and I do hope I am – I would argue that if you are a DevOps engineer or a tech lead of any sort, promoting the idea that DevOps is a part of every developer’s job is in your best interest.

    The developers who understand how to support their own environments, run internal services on private networks and understand the solutions that are available to them will simply be better at their job, enabling companies to let automated processes do their thing and focusing talent where it’s needed most to make the best use of our skill sets. Thankfully, this standard of excellence is becoming easier to reach every day; and (Do I dare say it?) perhaps, in the near future, DevOps will become less of a role and more of a service waiting for its eventual, unpreventable automation.

    Reading this, you might think that I am a self-loathing DevOps engineer who wishes to become a developer. Nothing could be further from the truth. Development Operations is my field, and I believe it’s full of talented individuals who I’m proud to call colleagues and friends. However, at the end of the day, we need to be realistic. Now that the “Operations” part of the work is mostly automated, we must focus our skills on the “Development” part.

  • Four Metrics Every Engineering Manager Needs to Monitor for Success

    Four Metrics Every Engineering Manager Needs to Monitor for Success

    Engineering managers and leaders are charged with a challenging task every day: How do they support engineers to do their best work, and how do they know if their engineers are doing their best work? 

    The former is easier than the latter. To enable an engineer’s best work, you’ll want to make sure they are clear on their goals, focused on the right priorities and have the information they need to do their work. A critical role of the manager is to eliminate any blocks that get in the way, too.

    Yet, despite those efforts, engineering managers struggle to identify if their engineers are actually doing their best work. Should they measure how many items they complete? Or how much code they write? Or the quality of their work?

    All of these are relevant puzzle pieces, yet they’re hard to objectively measure, and don’t indicate the full picture of an engineer’s work.

    One revelation from our productivity research at Uplevel is this: Instead of focusing on output, managers can find more success in focusing upstream. When we consider the conditions that support or block work in the first place, we give engineering teams the best chance to do their best work.

    Here are four upstream metrics worth tracking.

    Time to Focus

    While it seems pretty straightforward to focus, we live in a distracted world of work. Office layouts are open, calendars get filled, Slack sends notifications all day long (and thanks to APIs and integrations, you can be notified about anything from the status of a Jira ticket to when lunch will be delivered). Effective engineers need uninterrupted blocks of time—at least two hours or more—to do deep work and focus on challenging problems. A manager can help enable this in two ways: by serving as the shield so that the team is in fewer meetings, and by creating a culture where developers feel empowered to block off focus time, either individually or as a team.

    Meeting Volume and Distribution

    Managers can ensure that their teams meet when they need to, but no more than that. These meetings are needed so that people can collaborate, problem-solve and follow engineering-related rituals in the world of agile development. However, it is easily possible to have too many meetings, or ineffectively run meetings. When occurring at inconvenient times, just two meetings a day can take up most—if not all—of a developer’s deep work time. Monitor your team’s meeting levels and distribution so that there’s optimal time for deep work before, after or in between.

    Avoid Multitasking

    If your developers are going to be in a meeting, it’s important that they are focused on the goals of that meeting—and not multitasking. Managers can lead by example and keep laptops closed, unless they need to share or present. Past and emerging research points to evidence that manager behavior shapes individual contributor behavior. That role modeling can lead to new habits, good or bad.

    Too Much Context Switching

    Are your developers focused on a small number of high priorities? Or are they jumping across epics, project phases, focus areas and code bases? Keeping each developer focused on just a few areas helps reduce context switching—a costly obstacle to effectiveness. Every context switch—like, say, shifting focus from a 10-minute standup, to a cluttered inbox, to a fire-drill Jira ticket—requires time to switch out of the first context, into the new context and back to what they were working on in the first place.

    — David Youssefnia

  • Small Teams Focused on Delivering Outcomes Produce the Best Results

    Small Teams Focused on Delivering Outcomes Produce the Best Results

    The days of big team consulting are over. Technology organizations are aligning their budgets to get projects done faster and more agilely. More applications are being built by small teams of cross-functional engineers moving fast, providing higher quality code, designing away waste and cutting out processes that don’t add value.

    It’s becoming apparent that engagements incorporating smaller footprints and shorter iteration cycles are more common. The best outcomes are where an engineering team is small, lean and iterating many times faster than much larger teams. That means that enterprises get their applications to provide value earlier and at lower cost, and they cost less to maintain over time, starting right away. It means applying higher quality and better managed teams using core engineering principles. It means cross-functional technologists, not cross functional teams working in silos in their specialties

    The catch is: How do you incorporate that at enterprise scale? It’s not easy to do because there is a lot of internal resistance and inertia. And many organizations will not achieve this.

    Agility and priorities are key here. Future thinking organizations don’t waste this effort on trying to knock out backlog. They make sure they’re applying themselves in a targeted fashion and they drive velocity higher on things that matter. It’s not about providing spot fixes. Don’t start with building a CI/CD pipeline or an AWS migration. Work with your engineering team on driving down the overhead that’s slowing down the delivery of your platform.

    It’s not about using this tool and that tool, and this programming language and that platform to host it, and that it will integrate a certain way, and you are now able to say that you are delivering in a continuous integrated fashion. You should get continuous delivery set up. However, continuous deployment is one step. What you really want to do is reduce costs by 20% and reapply that to a feature that you’re looking for next quarter, instead of waiting till next year. You can restructure the conversation because from the get-go you front load the delivery strategy with those kind of performance terms. And this is real money. We are applying these processes where customers are paying for software to be delivered.

    What doesn’t work is “Let’s do some DevOps over here, and then maybe a little over there and make incremental progress.” Spend resources doing principled engineering all in the same application—not bits and pieces in various places and hope to bring it together at some point

    One way to know if you are doing DevOps—or any cloud related engineering—better is that you have a better grasp of Amazon’s APIs than Amazon does. Literally, the best companies release updated APIs for Amazon before Amazon releases their new APIs. That’s how good they are.   

    Different organizations move at different rates with an understanding of DevOps. Some people still say “Get me a DevOps engineer.” Others say “Get me a DevOps’ culture change,” which is OK. But, really smart organizations are asking for small engineering teams to build high performance, high priority platforms quickly, at the lowest possible cost, using the best engineering principles available.

    One other way to know that you are doing good engineering and DevOps is when you need DevOps engineers and you talk to a big consulting outfit and they say, for example, that you need 65 SREs with different skill expertise, four project managers, a bunch of data scientists and product people and client partners. They say it’s going to be really expensive and that they’re going to be here forever, and that this is an engineering challenge. Let’s address it from that POV. The engineers are running it, the engineers are closest to the work, they understand the issues and the opportunities, and they just need 10 really good full stack engineers.

    The name of the game now is applying engineers that clearly have a specialty, but are more importantly good engineers with software and know how to write code well. You might have a platform engineer, which is going to be like your infrastructure SRE but he’s going to be knowledgeable and know how to write code at a basic level. That will work. You might have an engineer that isn’t the best software developer, but knows platforms, what clouds are available, how to offer it across those programmatically, etc. That will work, too.

    The bottom line is moving initiatives that are focused on building revenue or saving a lot of money and driving them forward at a higher velocity, with higher quality delivery at their product launch through foundational concepts, such as continuous integration, continuous delivery and continuous deployment. Leading organizations are focused on doing that in a way that is future-forward, focused on stateless and serverless infrastructures.

     

     

    This article was co-authored by Jack Keck. Jack is a seasoned technologist leading a cross-functional engineering organization at a global investment bank. He spearheads transformative initiatives with the goal of raising revenues through the use of future forward technologies.

    — Larry Gordon

  • Earning an AWS Developer Associate Certification

    Earning an AWS Developer Associate Certification

    Studying for an AWS Certification may seem like an arduous task, especially if one isn’t expecting to take any more tests now that college is finally over. However, the certification doesn’t have to be long and tedious—it can be accomplished in as little as three months or less.

    I had started working in the middle of August as a DevOps engineer at a major financial services regulatory firm, and at the suggestion of my peer mentor, pursued the Developer certification—which I earned by the second week of November. 

    Having recently graduated from college, I had no exposure to cloud computing, let alone Amazon Web Services (AWS). However having ventured into a DevOps role, I quickly realized that in order to contribute to my job, I needed to gain a solid understanding of AWS—preferably as fast as possible. My studying time was a mixture of evenings at home, daily commutes on the train and spare time at work. In total, I would estimate a total study time of 40-60 hours. I believe that by allocating the time and following the procedure listed, anyone can accomplish a similar feat.

    I would break the procedure down into three separate stages: broad overview, documentation and exam specific details. After all, in order to learn any subject well, a broad solid foundation is essential before narrowing down to the minute details.

    Broad Overview

    As someone who was starting with almost no understanding of anything related to AWS, I needed a way to pick up as many of the different services as possible and understand how they relate. Thankfully, my company offered an online teaching environment called Linux Academy that included a course on the Associate Developer Certificate. At this point it may be tempting to assume that I passed the exam simply by following the course. However, I personally believe that although the course helped provide a foundation, it was nowhere near sufficient in covering the full material required.

    The course (approximately 12 hours including some basic labs) provided me with an overview of the major services related to the exam as well as the connection between different components. The course also came with practice quizzes and a final exam, that although were helpful, were not at the level of the AWS exam. The only questions I felt were incredibly helpful were in regards to Read and Write Capacity for RDS. There are four combinations: Read with Eventual Consistency, Write With Eventual Consistency, Read with Strong Consistency and Write with Strong Consistency. Each had a slightly different computation and I would recommend looking up example questions even if you do not use the course.

    Since the course was used more as an overview than to teach everything on the exam, it may be possible to skip this section if you already know some of the material or do not want to pay for any online courses. Simple YouTube videos may be able to provide a similar level of detail. 

    Documentation

    This is the core of the studying and the most annoying but inevitable. From my personal experience, the exam is not passable without reading the white pages. Each certification has a list of suggested white pages to review on the AWS’s provided exam guide. I recommend starting with the one titled AWS Overview, the ordering of the rest is less consequential. Although I did not have the time to, I would recommend going over each white page twice. The Basic Overview is particularly important because it describes more services than what was introduced in Linux Academy and also goes into detail on services. It also helps to differentiate between the Amazon Kinesis services.

    Knowing the Exam

    Finally, after gaining a pretty good foundation and understanding of the services it is important to focus on our objective—tailoring our studying for the AWS exam. “Well, what was everything above this for?” While it is true that it is important to understand the different services that AWS offers, the key to passing the exam is to answer the questions correctly.

    As with any exam, knowing the proper format and types of questions is important. It is important to figure out what level of detail the AWS certification expects as well as what topics are most likely to be emphasized. The easiest way to do this is to take the practice exam offered by AWS. Because the sample exam is offered by AWS itself, it is much more similar question-wise to the actual exam than Linux Academy or other sites I had looked up on the internet. For $20, it provides information that is hard to find otherwise. Furthermore, those questions make it easier to look online and find study guides with questions that will actually resemble the certification and provide answers.

    It is noteworthy to mention that the AWS practice exam only provides guidelines on percent correct for each category but does not return the correct answers. After seeing the results, I recommend focusing on the area that is weakest if only one or two categories are lagging behind. However, if all of the scores are relatively close, I would recommend focusing on the highest one, because it is the subject you most likely have the easiest time understanding. Obviously, if all scores are incredibly high then any remaining studying is your prerogative and if they are all low, then it may be necessary to go over  the material again.

    Miscellaneous

    One advantage I had while studying for the exam is that my work was related to learning AWS and I gained exposure to ECS, EC2, Lambas, Step Functions and the AWS CLI. However, although this experience provided me with a little more familiarity with the products, I would not consider this crucial to my passing the exam.

    There are questions about the correct API calls and I had an incredibly difficult time finding the APIs even on Google—the API calls are located in the documentation under actions. Also, since there are so many API actions, I would advise finding general rules and using those on the test—for example, most calls seem to be singular except list actions which are plural.

    From what I can recall, at the time of November 2019, it seemed that the questions I faced had an emphasis on serverless services such as Kinesis, Lambda, API gateway and much less on IAM which the Linux Academy Course seemed to focus one.

    Conclusion

    Final thoughts include: from what I have seen online, on average, a 70% is required to pass the exam but can oscillate according to the difficulty. If you want, it may also be good to start by taking the practice exam to provide a direction for the rest of the studying. White page reading is monotonous but critical to learning all the information required. However, thankfully the writers were quite proficient and presented the information as efficiently and casually as possible.

    Although the steps provided were the ones I used to pass the AWS Associate Developer, I use a similar series of steps on other exams, whether AWS or not. Start by skimming the entire material in order to warm your brain up to the information, effectively providing it with some reference material and footholds for in depth studying. The inevitable part of studying is the reading of denser material. Admittedly, not everyone learns best through reading but it provides a much faster and more efficient way of learning than auditory, which can take much longer. As you read the material more thoroughly, try to map out connections between different aspects and services. Also, try to find any interesting information that comes across, sometimes the examiner will also find the same information interesting and therefore it is more likely to appear. Lastly, it is important to take advantage of any practice material from the source. Even if they do not contain answers, you can probably search them and potentially learn an answer that may reappear on the exam. Furthermore, it allows you to find similar problems and helps you accustom yourself to the format and questing style of the exam.

    — Jintao Hang

  • Can We Do Without DevOps?

    Can We Do Without DevOps?

    Recently, DevOps has received so much hype and every respectable company sees it as its duty to have a DevOps team on and running. It is considered to be so beneficial to any company that a non-technician scrolling down posts at any tech website would think of it as a universal remedy for all the corporate diseases ever possible. However, given that a definition of DevOps varies from company to company and no one exactly knows what a true DevOps team should do, isn’t there some misconception between the praise that DevOps has been receiving and the real output? Let’s dig deeper and decide for ourselves.

    Yet, despite the buzz around the notion, DevOps is said to be a working thing. It guarantees a company-adopter 200 times more frequent deployments, 24 times faster recovery and three times lower change failure rates, according to Puppet’s State of DevOps Report.

    That is why, to get a non-biased view on why one should “DevOps-ize” corporate processes, in our article we give the answers to the following:

    • What DevOps is?
    • What issues is it supposed to help resolve?
    • What does a DevOps engineer do?
    • What skills does a DevOps engineer need?

    All of these questions, when answered, will help us see why the industry has adopted DevOps as a regular practice, why your company needs to try it out and why we can’t do without it the way we used to before—or can we?

    What Is DevOps?

    According to the AWS, DevOps is the combination of cultural philosophies, practices and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. Well, this definition may not be as clear as the waters of Sardinia, so we’ll clear it up for you a little bit.

    The message is that once (before DevOps) the product release was slow and troublesome, while today, with DevOps practices in place, it almost reaches cosmic speeds and high-end quality. All through maturation of work approaches and practices–merge of development and operations–along with the automation, cloud technologies, virtualization and abundance of top-notch tools. DevOps culture to a certain extent enables developers to perform the work of the IT team, and vice versa, which breaks down the operational walls between the teams, eroding a “not my task” mindset at the same time.

    What Does a DevOps Engineer Do?

    If that’s what is happening today–programmers deal with the configuration issues and the IT teams code–why is a DevOps engineer on the tip of everyone’s tongue? Why come up with a new term if you can write some more new responsibilities into the dev’s/IT guy’s contract and leave the names as they are? The thing is, the transformation of the processes and roles was so substantial, that in time they merged into a completely new position, which is neither a coding IT guy, nor a configuring developer.

    Roles Before DevOps

    Developers

    • Built features, tried to merge separate pieces of code together (usually resulted in a huge amount of errors and ended up in a long and troublesome integration).

    Integrators or Production Facilitators

    • Known to have been engaged on huge banking/insurance projects.
    • The phenomenon had a limited application within the industry and this intermediary work piece was often shared between the devs and ops with varying success.

    IT/Operations

    • Fixed the developers’ mess and squeezed the available code (often requiring a lot of massaging) into the available infrastructure.
    • Supported tech life in the offices (repairs, tech support, configuration and security, etc.).

    Roles Today, Approximate Responsibilities Breakdown

    Developers

    • Specification-based code production.
    • Software components integration.
    • Troubleshoot, debug and upgrade of existing software.
    • Creation of technical documentation for reference and reporting.
    • Integrations implementation.

    DevOps Engineer

    • Infrastructure planning, testing and development.
    • Integrations implementation.
    • Updates and fixes.
    • Build tools to minimize errors and improve customer experience.
    • Develop software to integrate with internal back-end systems.
    • Production errors root cause analysis,
    • Investigation and resolution of technical issues, Level 2 tech support.
    • Script development to automate visualization.
    • Procedure design for system troubleshooting and maintenance.

    IT/Operations

    • Install and configure computer hardware, software, systems, networks, printers and scanners.
    • Monitor and maintain computer systems and networks.
    • Service issues and requests.
    • Technical support across the company.
    • Set up accounts for new users.
    • Repair and replace equipment as necessary.

    To sum it all up, a DevOps engineer is a so-called “centaur” performing duties of a system administrator between coding sessions. His/her primary objective of the project is to find a solution that will make product deployment fast and efficient and people’s (devs and ops) lives easier.

    What Skills Does a DevOps Engineer Need?

    According to the Qulix’ practice, an ideal skillset for a DevOps is:

    • A technical graduate.
    • Intermediate or advanced English.
    • General programming skills.
    • Proficient PC-user knowledgeable about networking, Git, Linux, Docker, Nginx, Bash.
    • Strive for constant perfection and thirst for the new.
    • Curios, with inner drive to get to the bottom line, enthusiastic.
    • Strong work ethic and time management skills.
    • Open and a great team player.

    These will do for a start. At the same time, within the same company various departments may require from their DevOps engineers to have a command of different technologies. For example, another department of ours expects from their candidates to know TCPIP, DNS, Nginx, Tomcat, Git, Bash, Groovy, Ansible, Docker, Ubuntu, Debian, Macos, Gradle, Maven, CI/CD.

    As you can see, an ideal fit for the position of a DevOps engineer within a specific department is something rare. All because DevOps engineers have to have so much on their plate, both from technical and soft skills perspective. Why? First of all, as a system administrator to a certain degree, a DevOps engineer has to operate numerous technologies, that sometimes far outweigh the number of those a regular developer uses on a daily basis. In this connection, I once asked a friend of mine working in a DevOps team, “Of all the difficult things that you have to deal with as a DevOps guy, which one is the most difficult one?” And his response was “Everything.” 

    The “everything” of my friend needed further explanations, for which I headed to another DevOps engineer of Qulix Systems, Denis Golovnev. He told me he opted for a DevOps position because he wanted to get to know the whole SDLC closer and in depth, as “this position requires a 360-degree knowledge of the SDLC processes.” DevOps guys are among those few specialists who stay on the project from start to finish, to maintenance. That is why “a DevOps engineer won’t only have to dig deeper into his/her own area of knowledge, but also target adjacent spheres to see how the product is created and how his/her actions can create more value for the client,” explained Golovnev. Thus, this made the tech part clear to me.

    What about soft skills?

    “The most difficult thing about DevOps is to arrange the processes in a manner that will suit everyone; the one that will encourage the initiative and individual decision-making process, to a reasonable extent,” said Golovnev. “To achieve that, highly developed soft skills are a must to get to the root of the problem and enable an engineer to outline clearly his/her point of view to everyone.”

    On the other hand, DevOps team will inevitably face both technical and organizational issues, which should not be confused.

    “One should not try to settle human-related issues through technical means,” said Golovnev. This is another reason why a candidate without highly developed soft skills is very unlikely to get the position. Soft skills are the absolute killer thing for a DevOps candidate.

    To Wrap It Up

    We’ve been gradually migrating from slow and troublesome product releases and delivery of separate work chunks to a speedy, orderly and consistent performance. Most definitely, this transition isn’t the consequence of DevOps practices implementation alone. But without it, without the culture of speedy collaborative delivery, dynamic issues resolution and ultimate automation, which are typical of the DevOps philosophy, the shift would be impossible.

    Furthermore, the revolution starts from minds, whereas the means comes later. If a typical DevOps engineer is, as according to Golovnev, “the one in love with his/her job, insane as to automate everything within his/her reach, get to the core of any constrain that impedes fast product delivery or reduces effectiveness,” no wonder we, as consumers, and the whole industry need them. Together with the outstanding tools and technologies, a DevOps engineer is a soldier that, in 100% of cases, shoots to kill (any production constraint).

    One issue, however, remains unclear. With all the variances as to what true DevOps means even within the same company, how will we reach a unified DevOps definition? Most definitely, some unanimity would be useful for the candidates that try to land the position but end up rejected due to the above-mentioned differences in DevOps visions among the companies.

    On the other hand, lack of unambiguity is justified due to a wide range of technologies as well as different approaches used by different companies. So far, skillset variance will stay a key problem in regards to DevOps hiring. Although our main question–can we do without DevOps?–is out of the question.

    — Veronica Chizh

  • How to Transition to Become a DevOps Engineer

    How to Transition to Become a DevOps Engineer

    You’ve either heard the buzzword or you’ve seen the extensive list of rewarding aspects that come with being a DevOps engineer. Whatever the reason you’re here, this guide should help with taking the right steps toward becoming a DevOps engineer, whether this is your first job after graduating or an opportunity to reskill leveraging your prior industry experience.

    Immerse Yourself

    Learn the fundamentals, practices and methodologies. Understand the why behind DevOps before jumping into the tools. I believe the key goal of any DevOps engineer is to increase speed and maintain or improve quality across the entire software development life cycle, in order to provide maximum business value. Read articles, watch some YouTube videos and go to one of your local Meetup groups or conferences–it’s useful to become a part of the welcoming DevOps community where you’ll learn from the mistakes and successes of those that have been here before you.

    Your Background

    There are likely two key times where you’ll be transitioning into the role of DevOps engineer; either reskilling during your career or as your first job after graduating. You may have prior experience in technology, such as working as a software developer, systems engineer, systems administrator, network operations engineer or database administrator, all of which will bring broad insights and useful experience for your future role as a DevOps engineer. If you’re starting your career, maybe you’ve finished your degree in computer science or any other STEM field which will give you some of the basic stepping stones you’ll need in this transition.

    I think it’s important to breakdown the broad spectrum of what DevOps engineer roles entail. Most enterprise companies today will use DevOps engineers in three different positions.

    • DevOps Engineers, with a Dev Bias: Work in a software development role, building software applications. The key point is they leverage CI/CD, shared repositories, cloud and containers as part of their everyday work, but they are not necessarily responsible for building or implementing tooling. They will understand infrastructure and in a mature environment, will be able to push their own code into production.
    • DevOps Engineers, with an Ops Bias: Could be compared to systems engineers or systems administrators. They understand software development but do not spend the core parts of their day building software applications. Instead, they are more likely to be supporting software development teams to automate manual processes and increase efficiencies across the human and technology systems. This could mean breaking down legacy code and using less cumbersome automation scripts to run the same commands or it could mean installing, configuring or maintaining infrastructure and tooling. They ensure the right tools are installed and available for any teams that need them. They enable teams with learning how to leverage CI/CD and other DevOps practices.
    • SREs (Site Reliability Engineers): Think of site reliability engineering as having software engineers solving operations and infrastructure problems. SREs focus on creating scalable, highly available and reliable software systems.

    In the ideal world, DevOps engineers will understand all the above, which is the norm at some mature technology companies. However, if you knock on the door of top tier banks or many Fortune 500 companies you’ll realize oftentimes these roles do usually have biases towards dev or ops.

    Operating Systems

    Whichever background you’re coming from, you should start with the fundamental technologies you’ll need to use and understand as a DevOps engineer. Linux is most likely the operating system you’ll be using daily, although some of you might be using Windows. This is where everything runs, and fundamental knowledge is important. You can install Linux at home where you’ll be able to break as much as you want and continue learning along the way.

    Scripting

    Next up you’ll need to pick a scripting language. There are many to choose from, such as Python, Go, Java, Bash, PowerShell, Ruby and C/C++. I suggest starting with Python, it’s one of the most popular for a reason, it’s easy to learn and interpret. Python follows the fundamentals of object-oriented programming and can be used for web development, software development, creating desktop GUI apps and even business applications.

    Cloud

    After Linux and Python, my next pick would be cloud, where you could choose from Amazon Web Services, Azure or Google Cloud Platform. I’d start with AWS, as they have an extensive collection of free learning tools available to  take you down any track from learning about AWS as a developer to operations and even the business facing components. In fact, you might even be overwhelmed by how much is on offer when you first get setup with AWS. Maybe start with EC2, S3 and VPC and see where you want to go from there.

    Programming languages

    For those of you with a passion for software development. You should keep on improving your programming skills. Some good languages commonly used in this role include Python, Go, Java, Bash, PowerShell, Ruby and C/C++. You should also become familiar with tools such as Jenkins and Git/GitHub which you’ll be using frequently as part of the CI/CD process. Infrastructure is no longer left to the operations guys so you’ll need to have some exposure to a cloud platform such as AWS, Azure or GCP.

    Containers

    Finally, start learning about containerizing code using tools such as Docker and orchestration platforms such as Kubernetes. All the above have extensive online learning resources for free and most cities will have local Meetup groups where you can turn up and learn from experienced people in a friendly environment.

    For those of you with less experience in development, you can still get involved using your passion for automation, increasing efficiency, collaborating with others and a never-ending desire to improve on your own work. I would still suggest learning the tooling outlined above, but with less emphasis on the coding/scripting languages. It will be useful to learn about Infrastructure as a Service, Platform as a Service, cloud platforms and Linux. You will likely be setting up the tools and learning how to build systems that are resilient and fault-tolerant while writing your own code.

    Reskilling

    If you’re transitioning into a DevOps role during your career, you should start within your company to explore opportunities. Can you reskill by working with an existing team? There might be an option for you to shadow other team members, ask for advice and reskill without even leaving your current job. This might not always be possible and some of you will need to move into another company.

    If you can learn some of the practices, tools and technologies listed above, you’ll be in a good position to demonstrate relevant knowledge during interviews. The key is to be honest and to not set yourself up for failure. Most hiring managers understand you don’t know all the answers but if you can show what you’ve been learning and explain you’re open to learning more, you should be in with a good chance.

    Starting Your Career

    You can apply to direct open opportunities at companies who are hiring junior DevOps engineers. You will often find these companies say they’re looking for more experience and you should apply back in future when you’ve gained some commercial experience. It’s the typical, frustrating scenario of “we want more experience” but nobody is willing to give you the first chance.

    It’s not all gloomy though, there are a few companies focused on training and upskilling graduates directly out of the university. MThree, where I currently work, delivers exactly that. We hire fresh graduates and train them for eight weeks in our Alumni Academy. Training covers everything from theory through to hands-on projects with Python, Jenkins, Git, Ansible, Docker, Kubernetes and AWS. By the end of the training you’ll have some solid exposure to the entire software development life cycle and a good understanding of how this applies in a Fortune 500 environment. The best part is once qualified, our teams then leverage their extensive list of clients to provide job opportunities for junior DevOps engineers. MThree pays these associates on a full-time salary with benefits for the first 18-24 months before they join the client as direct employees at the end of the agreement. This is a great way to bridge the gap from university into your technology career.

    In summary, there are many ways to transition to become a DevOps engineer. This is a very rewarding career route which will likely keep you engaged and challenged as well as increasing your earning potential.

    — Conor Delanbanque