devopsy.kinsta.cloud

Tag: DevOps practices

  • 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

  • DevOps at the Speed of Business: 5 Tips for Success

    DevOps at the Speed of Business: 5 Tips for Success

    It’s an exciting time to be an engineer. With companies today moving faster than ever, engineering teams are developing and deploying new code daily, continuously improving and advancing the business. But while the pace of modern development creates new opportunities for engineering teams, it introduces new challenges as well—in particular, making sure new code releases don’t bring the system crashing down. With more code comes more opportunity for error.

    When organizations scale fast, the challenges compound. As the engineering team grows to keep pace with expanding business, it becomes more difficult to keep track of the new code being developed. This lack of visibility can frustrate even the best teams. Without a clear view into what changes are being made, it becomes more difficult to fix them when something goes wrong.

    What do you do? Here are five key DevOps practices critical for organizations scaling fast:

    Put a Premium on Collaboration and Communication

    DevOps teams, no matter their size, need to be able to share information easily and quickly. When a problem occurs, forensics and root cause analysis must be performed as fast as possible, and engineers need to be able to annotate events that occur within the product deployment stream. Most companies already have the tools to do this, but they often fail to communicate what they find. Opening lines of communication between disparate, often geographically dispersed teams enables everyone to expand beyond their own knowledge base and capabilities to help one another. When everyone can share their knowledge, it raises the collective talent of the entire engineering community, creating a more collaborative learning environment and a culture of sharing.

    Democratize the Tools

    Tools that are accessible only to a small group of power users always fail. There’s not a person in the world who wants to put hours into teaching themselves a new tool if it isn’t approachable and interesting. That’s trouble, because the fewer people that understand how to use a given tool, the more difficult it is to use it to fix a problem. For example, if the ability to query log files is limited to the three engineers who are certified on a tool, the size of your team won’t matter; you can have 50,000 of the best engineers, but effectively, it’s a team of three. This bottleneck can have serious business consequences. Imagine you’re an online retailer having your biggest sale of the year and your website crashes. Every minute you spend finding an authorized user is a minute lost, and when the internet is your business, time is quite literally money.

    Spread Recognition of Value

    No one wants their work to go unnoticed, but recognition is a learned practice and one that requires continued focus. DevOps teams and their work save their organizations vast amounts of time and money, and business leaders should take care to highlight the value of their team’s successes, both internally and externally. Not only does it encourage their teams to work harder and smarter, impacting the entire organization, but it also lifts up DevOps teams everywhere, publicizing best practices to outside teams and creating an exponential impact across the entire engineering community.

    Don’t Just Expect Change, Embrace It

    Innovation generally happens for two reasons: The tools being used to solve problems aren’t working, or the problems you’re trying to solve have changed. Every day, companies get frozen in time—the tools they use may work now, but the world around them is changing. It’s easy to get caught in a cycle of developing new products, but what if the tools your business uses to solve problems are out of date? When engineers make changes in the code, they must be in lockstep with every other department, from QA to customer service. Organizations that embrace change always will have a leg up on the competition.

    Capture Your Knowledge Base

    As business scales, their teams scale with them. What once may have been a two- or three-person DevOps team becomes a 40 person machine, and with scale comes a lack of coordination. More and more, DevOps teams are scattered across the globe, in offices and remote, and no two people have the same workflow. In this fragmented environment, it becomes imperative for companies to keep a store of knowledge their engineers can reference wherever they are, whenever they need to.

    Fostering a strong DevOps culture isn’t easy, but it’s necessary. At its core, DevOps is about collaboration and communication—companies that treat each team as separate units risk siloing their employees, creating closed information channels that are difficult to break through in times of crisis. Whether you’re pushing new code or bringing your business back online, timing is everything and engineers need to be able to move at the speed of business. These five tips won’t fix your code or craft new features, but they’ll certainly ease the process.

    — Dave McAllister

  • Best Practices for DevOps in the Cloud

    Best Practices for DevOps in the Cloud

    DevOps is commonly defined as a methodology that combines software development with IT operations. The goal is to shorten a system’s development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives. Putting DevOps into practice is an ongoing experiment for many organizations.

    Developers often struggle with continuous integration (CI) or continuous delivery (CD) performance, testing delays and other bottlenecks. In fact, one survey reported that only 34% of projects finish on time and only 42% come in on budget. Security and development teams must collaborate to keep up with the rapid development life cycle without sacrificing security with every update.

    Enterprise SaaS apps are not distributed like traditional software—they are continuously running services. So, CD is all about updating the service with a set of changes. In public clouds such as AWS and Heroku, this is done through pipeline stages (e.g. dev, test, staging and production). In platforms such as Salesforce, stages become sandbox environments, ephemeral scratch orgs and production instances.

    How can development teams shorten the development life cycle without sacrificing the integrity of the features and updates? In this article you will learn key DevOps practices to achieve predictable, reliable release management.

    Advanced Planning Ensures All Boxes Are Checked

    Agile planning is now de rigueur for enterprise development. It is best used if:

    • The product itself will most benefit from flexibility.
    • Regular face-to-face interactions and collaborations are needed between team members.
    • The end product requires regular updating, monitoring and continuous delivery to the client throughout the life cycle.

    For CD, ensure your user stories are sized correctly and that each story rolls up to an Epic that represents a standalone feature. This enables your team to release bite-sized pieces of functionality that are consumable by users and traceable back to your release plan. Also, define acceptance criteria for use in the verify stage so you know when something is done-done.

    Manage the Source Code, Especially When Working in a Shared Environment

    There are a few practices of app creation that impact CD. First, source code is not the only element of an enterprise solution. Schema, user interface, access control rights and static resources such as icons and images are all part of the creation process and should be managed just as diligently as source code. They should all be checked in to a version control system (VCS) as a single source of truth.

    Second, ensure that developers are making changes in a segregated environment. In some low code platforms, such as Salesforce.com, this becomes a challenge, but even in a database, multiple database administrations (DBAs) can step on each other’s changes when working in a shared environment.

    Functional Testing

    Automated quality processes are difficult to implement, but essential Selenium is a great tool for testing functionality and should be part of your DevOps practice. But there are several verifications that should be made before you get to functional testing. Static code analysis tools, such as PMD, are essential to ensure your development team is coding against a single style.

    Define a team style and enforce its use. Unit test coverage is also essential—incorporate them with a coverage of at least 75%. Finally, after these automated tests pass, implement a manual peer review. Old hands are able to spot opportunities for performance improvement where automated tools may not.

    Changes Should be Released in a Defined Pipeline with Strict Quality Gates

    Packaging for CD is about capturing changes that can be incrementally released into the next stage or environment. Development teams should dedicate a branch for each stage and bundle incremental changes into a promotional branch to leverage the merge conflict detection in your VCS.

    Changes should be released in a defined pipeline with strict quality gates that ensure the verification steps and enforce the order of release stages. Developers should not be able to bypass key stages throughout the development cycle—for example, moving from development to production.

    Focus on making smaller changes, which result in reliable, predictable releases. Finally, be sure to automate promotions. This enables your team to validate the promotion scripts in integration, test and staging before releasing to production, which decreases the likelihood of an unhappy surprise.

    Automate Configuration, Especially for End User Access Rights

    Make testing for proper configuration part of your verification process. Platforms such as Salesforce have powerful profiles and permission sets that enable user access to only the right information. Improper configuration can expose personally identifiable information (PII), credit card numbers or medical health data.

    Monitor for More Than Just Service Availability and Performance

    Most SaaS companies monitor service availability and performance. But excellent companies also monitor data access to detect improper configuration changes and monitor end user feature usage, which gives product managers visibility to their usage.

    — David Brooks

  • Survey Sees Need for More Consistent Approaches to DevOps

    Survey Sees Need for More Consistent Approaches to DevOps

    DevOps is arguably one of the most disruptive forces driving transformation of IT processes in recent memory. But a new survey finds that while IT organizations are making progress, adoption of DevOps processes remains uneven at best.

    A survey of 2,419 IT professionals conducted by OverOps, a provider of code analysis tools, finds that 82 percent of organizations have partially adopted DevOps practices, while only 17 percent of respondents claim to have fully adopted DevOps. Obviously, not every workload requires an organization to embrace DevOps processes to manage it.

    But OverOps CTO Tal Weiss said the survey shows that as organizations increase the rate at which application workloads are being deployed, a fair amount of chaos is starting to reign. According to the results, more than 90 percent of companies deploy code at least once a month, and more than 60 percent release code at least once every two weeks. Nearly 40 percent, however, indicate that moving too quickly is a primary reason errors make it into production.

    Worse yet, more than 50 percent say they rely on customers to tell them about errors in production, even though 60 percent of respondents say they use automated tooling for error notification and to ensure application quality.

    Not surprisingly, IT teams are still spending an inordinate amount of time troubleshooting their environments. More than a quarter of respondents say they still spend at least roughly one full workday per week troubleshooting errors. Another 42 percent of respondents spend 10 percent to 20 percent of their time troubleshooting.

    The good news is that IT is increasingly being viewed as a team sport. A full 67 percent of respondents believe their entire team is to blame when an application breaks or has an error, and 73 percent said both developers and operations are equally accountable for ensuring the overall quality of an application.

    Weiss said more organizations need to implement a more structured approach to DevOps based around the same continuous integration/continuous deployment (CI/CD) platform. Too many organizations today are adopting DevOps processes from the bottom up when it’s become clear that top-down initiatives for driving consistent adoption of best DevOps practices are now required. One of the biggest challenges facing IT leaders, however, is identifying and implementing the metrics that will be employed to identify those best practices, he said.

    Change, of course, comes hard to any IT organization. It may take IT organizations years after acquiring new tools to define their processes. Inertia surrounding existing waterfall and ITIL-based processes can be incredibly high. But as the amount of software that needs to be deployed and updated continues to increase, risk levels associated with deploying applications also are starting to increase. Many organizations are now essentially experimenting on their end customers. How much tolerance customers have for trial-and-error approaches to applications development and deployment remains to be seen. In the meantime, IT organizations would be well-advised to resolve to do DevOps better in 2019.

    — Mike Vizard

  • There is No Magic Recipe to Adopting DevOps

    There is No Magic Recipe to Adopting DevOps

    Over the past five years, we have seen more and more organizations of every size trying to adopt DevOps practices. However, we’re still expecting adoption rates to continue to rise—we have not yet reached “peak DevOps.” The motivations behind this comes from the need to reduce time to market, deliver better quality software, reduce operational costs and, ultimately, improve productivity and stay competitive.

    More enterprises are changing their business models by digitizing their business processes. We’re also seeing increased adoption of cloud technologies, agile frameworks and disruptive technologies. But these factors will not lead to an accelerated software development life cycle if organizations don’t prioritize better collaboration between people (no matter what area they belong to).

    Successfully implementing DevOps practices is not easy. Depending on the company’s size, it can take several months or even years. Most of these enterprises are learning what it takes to transform their organization. From our experience it takes several elements, but most importantly, engaged leadership is one of the most essential aspects for successful DevOps transformations. This leadership support will help organizations create dynamic and flexible business processes that eliminate traditional silos. This means that multiple teams can work together in a collaborative way, making seamless workflows that accelerate the software development life cycle and improve ongoing product maintenance. Such workflows bring tangible benefits, such as being able to rapidly respond to changing customer demands and developing better quality software, faster.

    Implementing DevOps is Unique to Every Company

    However, when talking about what it takes to adopt DevOps, we have to understand that there is no magic recipe that works for all. Every company has its own unique history, culture, and way of working, and thus will implement it differently. This is particularly the case because DevOps is really an amalgamation of different factors, from technology and automation to creating lean work processes and creating a culture of sharing between teams and individuals that traditionally were siloed.

    In 2019, Organizations Will Look to Scaling Initial Initiatives

    Very similar to what we have seen with the adoption of Agile development, most organizations have experimented with DevOps or have launched a small-scale pilot. They are aware of DevOps and the benefits it can bring. The challenge going into 2019, for the vast majority of businesses, is how to scale these pilots enterprise-wide. For example, in its 2017 survey, Forrester Research found that while just 13 percent of organizations had fully implemented DevOps, 50 percent had started their implementation and were expanding their use.

    We’re very much still on the journey to implementing DevOps practices. For example, many of the organizations that we work with are now using automation tools to get closer to continuous integration and continuous delivery capabilities, but there is still potential to use automation to a greater extent.

    There also exists a split in the types of applications that organizations are currently using DevOps for. Again, an interesting study by Forrester Research showed that in 2017, while 68 percent of organizations stated they were already using such practices for building and deploying mobile applications, this percentage dropped to 56 percent for ecommerce websites. I also believe that organizations need to improve how they measure DevOps success: Can they create metrics, such as level of level of innovation, or tie success directly to product revenue or process efficiency?

    As we look forward to 2019, more than ever business leaders will find value in looking at the best practices that companies have already developed on their DevOps journey. But we can’t forget that while two organizations may use the same automation tool, they will have very different cultures and way of working, with different goals and objectives. That’s why DevOps takes so long to implement, and represents a fundamental shift in how most organizations create, deliver and maintain software.

    — Gabriel Vasquez

  • 9 Ways DevOps Success or Failure Is Like Baseball

    9 Ways DevOps Success or Failure Is Like Baseball

    The baseball season is in full swing. There are 30 major league teams competing for a playoff spot, but, as I write this, only five of them—or 16.67 percent—qualify as elite performers with a winning percentage over .600.

    The number is strikingly similar in DevOps, where, according to one survey, just 17 percent of organizations say they have fully embraced it. Most of the rest have only scattershot teams immersed in DevOps or only recently began adopting it company wide. Fifteen percent are saying, “Wait ’til next year” and have yet to undertake this agile methodology.

    In baseball, teams struggle because of weak hitting, lousy pitching, poor defense, inept managing or all of the above. But why do some DevOps initiatives fail, who is at fault and what can be done to right the ship?

    Baseball and DevOps: More Similarities Than Differences

    Let’s dissect the differences between a DevOps program that hits the ball out of the park with a truly collaborative effort to build, test and release software faster and more reliably, and one that swings and misses.

    Is It Understood There’s No “I” in Team?

    Most DevOps initiatives fail because they are undertaken by a single practitioner within a single team. This is a strong personality who bulldozes the team to DevOps success, either out of career growth ambitions or genuine belief in DevOps tenets, only to have the team revert to their old ways when the practitioner leaves.

    Ironically, many if not most successful DevOps initiatives also begin with a practitioner on a single team. The difference in the latter case is that the leader doesn’t operate in a vacuum but shares lessons and best practices across the organization. They understand that if you are going to do something transformational, you cannot do it in the shadows or within a silo. They consider the long term. They lead by example and demonstrate the way forward to others.

    Are the Top Leaders Onboard?

    Just as the best baseball teams tend to have smart, supportive, quality-minded owners, the most successful and sustainable DevOps initiatives have top-down leadership support or mandates.

    Clear, consistent direction from the C-suite is necessary to motivate and incentivize people across the company and move DevOps initiatives from a patchwork of projects to an organizationwide philosophy.

    “Without executive support,” a Forrester report warns, “agile transformation is limited to grassroots initiatives—a very slow and difficult road.”

    Are the Danger Signs Recognized?

    There are two telltale signs that a companywide program is floundering. One, success is occurring only in a single team. Two, no one outside the team knows much or anything about that success. DevOps can’t grow within an organization if it’s an isolated black box.

    Starting DevOps is kind of like an entrepreneurial act. Startups become something bigger when the entrepreneur is successfully able to extend their vision. DevOps is the same: You need to infect other teams with your success. Winning begets winning.

    Another indicator of failure is if a company claims to be adopting DevOps but clings to traditionally organized and siloed teams. You can’t have it both ways. DevOps personnel need to be aligned by product, outcome or value stream—not by specialized work function.

    Is Success Measured?

    How does a baseball team know it’s winning the game if no one is keeping score? Same in DevOps. If you can’t objectively measure success, you don’t know if your program is meeting its goal of accelerating the software life cycle.

    Figure out how to measure the value of what is being done and delivered now so you can demonstrate its impact objectively. Examples could be application deployment frequency and time, error rates and mean time to detection.

    Is Seeking Outside Help a No-No?

    The DevOps community isn’t especially fond of vendors and consultants, but outside experts can bring fresh perspectives. No one tries to cure an infection or solve marriage issues by themselves, and solving DevOps challenges should be no different. Don’t be afraid to ask for help and if you have the budget pay of it.

    Can the DevOps Advocates Speak Business Language?

    DevOps folks often stumble when pitching for leadership support because they are unable to articulate their proposals in the dollars and cents language that business leaders understand. But if they can talk that way, practitioners may find leaders are much more willing to play ball than they realize.

    Is the Blame Game in Fashion?

    The biggest mistake organizations can make is bearing the classic IT coat of arms: arms crossed and fingers pointing. Don’t fall into the blaming trap. DevOps, after all, espouses the concept of learning from failure. So instead of pointing fingers, evaluate, consider, learn and move on with the lessons learned.

    As legendary New York Yankess manager Casey Stengall said, “All blame is a waste of time. No matter how much fault you find with another, and regardless of how much you blame him, it will not change you.”

    Does Failure Breed Success?

    Not to sound harsh, but if you start an initiative and it fails, it is your fault. Sure, many company cultures aren’t ready for DevOps, but others are succeeding where you have failed. If your team lost the World Series, another team won it. Why? There is always something that can be done differently. Determine what went wrong, accept responsibility and learn from it.

    Do People Bounce Back?

    If your initiative wasn’t successful, don’t be discouraged. Pick yourself up and try again. Being a DevOps leader requires courage and persistence. You’ll get ‘em next time.

    “Every day is a new opportunity,” Hall of Fame pitcher Bob Feller said. “You can build on yesterday’s success or put its failures behind and start over again.”

    — Scott Willson

  • Maturity Models Help Measure the DevOps Journey

    Maturity Models Help Measure the DevOps Journey

    DevOps professionals often encounter clients who struggle with sorting through the “what”s and “how”s of where they are in their journey, and how they can either get started with—or improve upon—their current practices.

    As a project progresses, we often find that diving into a technical solution up front without taking a holistic view of where our clients are in the aforementioned journey will result in undesirable outcomes. That’s because no two projects or clients are alike, and there are a surprising number of dependencies within DevOps practices that must be satisfied before overall success is achieved.

    For example, a client who wants to jump right into a microservices-based architecture will have trouble without first implementing CI/CD practices and utilizing infrastructure as code. That’s where a measurement tool can come in handy, especially one that can help to identify a logical progression in these cases.

    Having seen more than a few clients facing this challenge, we set out to create a Maturity Model to provide an easy way to determine reasonable next steps in both helping clients improve practices and quickly assessing where they currently stand.

    To begin, we took a comprehensive look at the many ways we’ve helped clients with their DevOps practices, searching for common patterns that would help guide and characterize how an organization performed. Additionally, we examined our internal practices and procedures, using numerous projects we have done to self-evaluate the effectiveness of our teams and approaches. From there, we gleaned what we considered to be five distinct realms that constitute a comprehensive view of DevOps maturity and developed appropriate questions within the realms to evaluate performance.

    So who can benefit from engaging in a maturity evaluation?

    Anyone, really, at every level of an organization. To see where you are in your DevOps evolution, log on to answer a few questions and they receive easy-to-understand recommendations. We can discuss results in-depth with anyone who wants a more thorough understanding of where they are in their practice or more personalized advice. Or, just enjoy the exercise. Either way, the questions will help expose certain ways in which your practices can incrementally improve.

    About the Author / Matt Brewster

    Matt Brewster is DevOps Team Lead for Seattle-based Base2 Solutions. His proficiencies include deployment/build/test automation and infrastructure, systems integration and analysis, performance automation and analysis, infrastructure virtualization and containerization, aerospace information technology, software quality assurance and rapid prototyping. Matt’s DevOps/Infrastructure knowledge includes VMWare, AWS, Virtualbox, Docker, Vagrant, Ansible, Chef, Linux, Nginx and Jenkins.

  • DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    DevSecOps and DevNetOps: New Heroes in the DevOps Saga

    The evolution of DevOps is by no means done, but it’s safe to say that there is enough agreement and acceptance to declare it a hero. DevOps has helped glorify IT to the point where it’s no longer preventing business, nor a provider nor a partner of the business.

    Often IT is the business, or its vanguard for competitive disruption and differentiation.

    Splintering the success of this portmanteau hero, we now hear more and more of two trusty sidekicks: DevSecOps and DevNetOps. Lesser known in their adolescence, these tots are still frequently misunderstood, are still forming their identities, and still need a lot of development if they’re to enter the IT hall of fame like their forerunner.

    Just as the terms look, DevSecOps and DevNetOps are often assumed to be about wrapping DevOps principles around security and networking: operators hope to assuage technical debt and drudgery by automating in proficiency and resiliency. For networking, I’ve covered how there is a lot more to that than coding, but to be sure, these sidekicks certainly espouse operators learning how to do develop while DevOps was equally, if not more, about developers learning to operate.

    The Shift Left: SecDevOps and NetDevOps

    As if it wasn’t hard enough to tell what DevSecOps and DevNetOps want to be when they grow up, we’ve gone and given them alter egos: SecDevOps (aka “rugged” DevOps) and NetDevOps. Think about them exactly as the words look—it’s about the shift to the left. Left of what?

    Traditional DevOps practices focus on business-specific applications development. The development timeline is known as a concept to cash, and with all the superpowers of DevOps we try to reduce our enemy—the lead time and repeatable processes between code and cash.

    Security and building infrastructure, like networks, were considered supporting tasks, not revenue-generating nor competitive advantages. Thus, security and networking were far to the right on the timeline with concerns that deal with operational scale, performance and protection.

    Today’s shift left propels security and infrastructure considerations earlier down the timeline, into coding, architecture and pre-production systems. It’s a palpable penny-drop amid daily news of security breaches and infrastructure outages causing technology-defined establishments to bleed money and brand equity.

    Fill the bucket with cash, but don’t forget to forestall the leaks!

    DevOps and Infrastructure: Challenge and Opportunity

    Automation sparks have flown over the proverbial wall into the camp of I&O pros. Operators trading physical for virtual, macro for micro, converged for composed, and configuration for code is proof that the fire has caught security and networking. Controlling the burn now, is key, so that healthier skills and structures arise in place of the I&O dogma and duff. Fortunately, this is precisely the destiny for our newfound heroes, DevSecOps and DevNetOps.

    However, doing DevSecOps and DevNetOps, embracing security and networks as code, we mustn’t be so credulous as to forget the formidable DevOps practices and patterns that need transforming along the ultimate automation journey. Testability, immutability, upgradability, traceability, auditability, reliability and other you-name-it-abilities are not straightforward to achieve.

    Discounting “aaS” technology consumed as a service, a fundamental challenge to innovating SecOps and NetOps, compared to application ops, is that applications are crafted and built; security and networking solutions are mostly still bought and assembled.

    Security and network infrastructure as code is something that needs to be co-created with the vendors. Other than in the cloud, it will take a while before security and networking systems are driven API-first, and redesigned to offer simulation, finer disaggregation into microservices, and orchestration with scale and resilience.

    While this will land first in software-defined infrastructure, there is still a way to go to manage most software-defined security and networking systems with continuous practices of artifact integration, testing and deployment. Hardware and embedded software will be even more challenging.

    Finding Strength in Challenge

    So on one hand, DevOps is evolving with security and networking shifting left. On the other hand, traditional security and networking ops are transforming with DevOps principles.

    Is the ultimate innovation to squeeze out those traditional operations altogether? Does NetDevOps + DevNetOps = DevOps?

    There is a parallel train of thought and debate, with success on both sides. Purist teams cut out operations with the “you build it, you run it” attitude. Other companies such as Google have dedicated operations specialist teams of SREs. While the SRE reporting structure is isolated, SRE jobs are very integrated with that of development teams. It’s easy to imagine the purist approach, subsuming security and networking into DevOps practices, but only if we assume the presence of cloud infrastructure and services as a platform. Even then, there is still substantiation for the SRE.

    Layers below, however, somebody still needs to build the foundations of the cloud IaaS and data center hardware. As they say, “Even serverless computing is not actually serverless.”

    Underpinning the clouds are data centers. And then there’s transport, IoT, mobile or other secure networks to and between clouds. In these areas, it’s obvious there is a niche for our two trusty sidekicks, DevSecOps and DevNetOps, to shake up ops culture and principles. These two heroes can rescue software-defined and physical infrastructure from the clutches of so many anti-pattern evils, like maintenance windows and change controls (ahem, it’s called a “commit”).

    We may not require rapid experimentation in our infrastructure, but we would warmly welcome automated deployments and updates, failure and attack testing drills, and intent-driven continuous response. They will boost resiliency and optimization for the business and peace of mind for the builders.

    Teams operating security, networks and especially clouds, need to honor and elevate DevSecOps and DevNetOps, so that on the journey now afoot, our teams and our new heroes may realize their potential.

    About the Author / James Kelly

    James Kelly is a lead expert architect on cloud and software-defined networking at Juniper Networks. He also serves as a private yoga instructor, and previously, he founded a capital management firm in Ottawa, Canada. Connect with him on LinkedIn and Twitter.