devopsy.kinsta.cloud

Category: DevOps Practice

  • Repeat Warning: There is No Silver Bullet in DevOps

    Repeat Warning: There is No Silver Bullet in DevOps

    As the cycle of DevOps is repeated in a growing list of organizations, I feel compelled to reiterate the warning that this is not the pinnacle. Anyone who has been around for a while knows that the current fad is not the last fad.

    [[Cue DevOps people screaming at my choice of the word “fad”]]

    Of course it’s a fad. DevOps (and to a much lesser extent, agile) is the cool toy in the midst of Gartners’ (in)famous hype cycle. That doesn’t mean nothing will come of it; it means that people freak out when you tell them it doesn’t solve every problem.

    All of the process/solution fads that have come along have offered some benefit to IT. DevOps promises to offer more, and in many environments it does. But grabbing your broadest brush and screaming, “DEEEEVVVVVOOOOOPPPPPSSSS!” while painting everything in sight is not problem-solving; it is thinking there is only one path to quality and it flows through the Chosen Process.

    The reason DevOps is different from previous hype cycles is obvious: It has the built-in assumption that this is not the end state. It assumes you will keep moving forward and things will change. Previous “new way of doing things” ideas have assumed that there was some nirvana you would get to and everyone would relax there, sipping ambrosia and enjoying immortality. DevOps makes no such claim. About as close to a final state as it gets is increased communications between the various parts of the DevOps life cycle. And that is because there is only so far you can go with increased communications before you’re flooded. And even that leaves room for new tools such as Slack to augment communications.

    But don’t look at every problem with DevOps blinders. This is the real world, and while some will (possibly correctly) claim that every software dev/deploy cycle can benefit from DevOps, the real question is not “Can it benefit?” but rather, “Is the cost/investment/risk less than those benefits?” And to the chagrin of those who live and breathe DevOps/agile, I’m afraid the answer to that question isn’t always a resounding “Yes.”

    I’m undeniably a fan of both agile and DevOps. What I’m not a fan of is finding the nearest round hole and cramming everything—including square pegs—into it. Look at each project/process objectively. As a simple and blog-length example, let’s examine standalone app that does some important back-end process and is only updated once or twice a year: Why ever would you rip the process for that apart, invest man-hours to bring it into the DevOps and agile folds, then … only update it once or twice a year?

    If you are building a new project, and you have DevOps processes in the building, it would take a convincing argument to not use them. The same should be true the opposite direction. If there is an existing project that doesn’t have delivery delays, it should take a convincing argument to move it to a whole new development/deployment methodology. Choose wisely. Invest resources where they’re required, not where ever the broad brush falls. IT has enough work to do, don’t add to it, just so you can say “We’re a DevOps shop.” Better to say “We’re a right tool for the job shop.”

    And keep kicking it. Business doesn’t run itself, IT runs business. Keep making it work.

    — Don Macvittie

  • What’s the Impact of DevOps on Business Continuity?

    What’s the Impact of DevOps on Business Continuity?

    Organizational requirements change rapidly. The strategic plan you created in the past and previously only updated annually is now out of date within a quarter.

    Agile and DevOps practices have been adopted to help resolve complex business issues in these times of flux through technology improvement, providing organizations with an increased certainty of intent, quality and safety.

    However, integrating the potential impact of Agile or DevOps into business continuity practices isn’t always considered a sound and highly valuable idea. The continuity of an organization is often considered important only after a crisis has occurred—the proverbial closing of the gate after the horse has bolted.

    Below are a few ways that business continuity capabilities need to change in light of the impact of Agile and DevOps.

    First, a Business Continuity Primer

    Maintaining business continuity in your organization:

    • Provides the ability to adapt as required to meet competitive, regulatory, organizational, technology or new market opportunities.
    • Provides your stakeholders, suppliers and, most importantly, customers and staff with the assurance the organization will remain a sound, going concern.

    For example, many organizations have a data repository in an application such as SAP, Oracle or SharePoint. This repository is saved into the cloud or other media daily or as needed.

    That is great. But if you mapped the processes used inside a department, you might find that employees download this data into Excel or some other tool and manipulate it for their own purposes. This is where the real work is being performed, and if this data is lost, the business continuity impact could be quite severe.

    DevOps and Business Continuity

    Agile and DevOps methodologies suggest that you design, create, test and release your technology changes in rapid cycles of two weeks or less, with any technology change introduced probably having a business process—and thus business continuity—impact.

    Therefore, whatever you release must always be ready for production. But how can you provide this level of assurance? This is how:

    • All “epics”—high-level business needs that are broken down into smaller stories—should also have a simple statement highlighting the impact of request.
    • All user stories should have tests to confirm the work being performed is as requested but also that they would be usable no matter where needed.
    • Feedback is provided to the development, infrastructure, cloud provider and product owner regarding the success of the tests.
    • Any issues need to be resolved before the work/change is released.
    • Issues and other lessons become part of the backlog of new work.
    • If a continuity test was not performed, then this user story is prioritized for completion in near future sprints.

    DevOps and Business Continuity Maturity Assessment Questions

    There’s a relatively simple way to understand how your organization’s business continuity capabilities stack up: Ask a number of focused questions (to the people who should be able to provide suitable answers).

    Start by asking:

    • How often do you test your code as you create it? (“Oh yes, we do that.”)
    • Do you always test before you go live? (“Oh yes, we do that.”)
    • How many of you create your code—be it infrastructure virtualization, new applications, internet, etc.—in environments that replicate, as close as possible, the production environment? (“Oh, hmm, no our environments are all different.”)

    Step it up with the “killer” questions:

    • How can you ensure that what you’re about to release is safe?
    • How can you ensure that the work you’ve done is not a waste?
    • How do you know that your organization can be kept “in business” and will not be exposed to an adverse effect from the change, or a business continuity situation?

    Understand How the Organization Relies on Technology

    As mentioned, business continuity is ultimately all about keeping your business in business, and thus there’s a need to understand how technology is employed to maintain:

    • Regulatory compliance.
    • Competitive advantage.
    • A safe place for your people and suppliers to work.
    • The needed access to your products or services.

    And thus, you will need to:

    • Map the various value streams of work performed.
    • Map the technology used at each step, down to workstation applications.
    • Quickly assess the impact of that stream being blocked or unavailable by a facilities, people or technology issue.
    • Create a plan to make that value stream as available as required.

    Organizations that have mature business continuity practices will, of course, also use technology to automate these activities. But they will also ensure that changes needed are tested as soon as possible in the product life cycle.

    If your tests are not performed in a production-like environment continuously, then how do you know you are ready and safe to go live? Go-live should not just encompass the new code but also the processes, training, security, continuity testing, organizational change and supplier update, if needed.

    Fortunately, the DevOps tools that support these capabilities are readily available and thus need to become part of any development, testing framework or infrastructure.

    Ultimately, it’s important to sufficiently invest in keeping your business in business. DevOps practices are another element to factor in to your organization’s business continuity management policies, processes and practices.

    — Sarah Lahav

  • 4 Bad Habits DevOps Administrators Fall Into

    4 Bad Habits DevOps Administrators Fall Into

    The concept of DevOps is central to any organization’s ability to deliver applications and services quickly and efficiently. As it gains traction in many high-profile organizations, DevOps administrators must work to integrate DevOps practices, tools and techniques into a wide range of teams, from development and support to operations and management. Completing this implementation seamlessly leads to better productivity and a smoother overall workflow.

    Bad Habits Derail DevOps

    But along the way, administrators tend to fall into bad habits that affect their ability to deliver these services effectively and efficiently. Here are a few of the most common habits that need to be broken.

    Working in Silos

    Some DevOps teams work in silos, in which development isn’t just one team but many. Think about a group project where everyone divides and conquers on tasks and at the end comes together to integrate different parts, which in turn have different formats, styles, etc.

    This is a bad habit that needs to be broken as it produces an additional level of complexity, with everyone working to solve their own issue at hand in their silo. Operations then struggle to unify the activity into a consistent process. This, coupled with occasional tensions between development and IT operations over different approaches to infrastructure and competition for resources, creates opportunities for failure. As the growing emphasis on DevOps places an added burden on infrastructure teams already struggling to cope with the digital transformation of their organizations, unification will be key to success.

    It is also true that DevOps can find success in small organizations where teams of people are focused on smaller, one-off IT projects, rather than the enterprise as a whole. These smaller teams have the luxury of sticking to themselves and the allowance to work on sequential projects, while their projects don’t scale up to the enterprise stage because they don’t have to. But smaller organizations such as these also likely won’t see much of a difference if they were to adopt a DevOps approach.

    That difference will be most noticeable in substantially larger organizations that see software release cycles rapidly changing on a daily basis. It is imperative for these organizations to avoid silos and to instead have pronounced team roles, better communication and the ability and willingness to break free of old habits that only cause chaos and confusion in the rapidly evolving delivery cycle.

    Planning Too Much, Too Soon

    Success requires continual improvement and refinement, rather than an initial push for certain changes without an overarching plan. The focus of administrators looking to implement DevOps should be on doing all things continuously by starting small.

    Early focus should be on selecting one or two new DevOps teams that start a new initiative. Then, with these new teams in place, you can build on successes and work through challenges slowly, and begin to scale this through the organization. In the beginning of the process, it’s also important to identify one person such as director of operations or chief planner who can be responsible for seamlessly integrating DevOps into your project. This lead owner can then work project by project, setting goals and showing the rest of the team the results in real time. Insight into the progress will allow the team to see their work paying off, and in turn, make it possible for them to realize the benefits of scaling up slowly.

    You need to know what the business problem is and the anticipated benefits, therefore measuring every factor that contributes to DevOps success. DevOps promises an array of automation. This can’t be achieved in a single attempt or overnight. Enterprises have to focus efforts on continuous integration, following it with continuous delivery and eventually continuous deployment.

    Believing Implementation is Easy

    After admins are finally swayed by the promise of DevOps, a belief often held is that the implementation of the practice is smooth and easy. And while DevOps can often lead to a simpler life for specific jobs in IT, the reality is that in many instances, the ease of deployment comes at a cost. It can shift an imbalance of responsibility for production control and quality management to the operations side, and burden the team rules and processes if IT departments fail to understand how to adapt.

    As with any process in any organization, the amount of effort required to support software delivery is a constant. Often, administrators fall into the habit of believing DevOps will handle itself. But if you are managing a large enterprise, you will have teams accountable for quality, performance and change management. The difference with DevOps is the way in which automation is leveraged to place control in the hands of application development teams and redefines the relationship between operations and development. This is a good thing, but the administrators need to be there every step of the way in the process.

    Failing to Take Full Advantage of Continuous Integration and Delivery

    Continuous integration and continuous delivery (CI/CD) are key to successful DevOps teams. However, a bad habit many DevOps teams can fall into is failing to take full advantage of all the CI/CD benefits. The process must to be fast and efficient, as anything that slows down any part of the process increases the cycle time and slows down delivery. To break the habit, DevOps teams need to focus on eliminating bottlenecks in their pipeline to then facilitate agile development processes.

    Your CI/CD pipeline allows for the chance to administer efficient automated testing into your process, but shouldn’t stop at continuous delivery and continuous integration. Another step in doing all things continuous is continuous improvement. DevOps teams and administrators are constantly evolving to fit the needs of the pipeline, and it is imperative that teams spend some time every day discussing and hashing out the small things that can be improved upon. Over time, these changes—no matter how small—will have a profound effect on the enterprise and overall quality of morale between administrators and their teams.

    — Matt Geddes

  • What Google’s ‘Digital Wellbeing’ Means for Every App Developer

    What Google’s ‘Digital Wellbeing’ Means for Every App Developer

    One of the big themes to emerge from Google’s recent I/O conference was Digital Wellbeing—the notion that technology should be a positive force in our lives, and that we need ways to disconnect from apps when they suck up too much time or distract us in other ways.

    Google is taking the idea seriously, and developers should, too. The fact that the company is encouraging people to spend less time with its services should be a wake-up call that every developer needs to think carefully about how they design, build and test their applications.

    To understand why Google’s digital wellbeing initiative is significant for all developers—not just those building for Google platforms—it’s helpful to look at some of the features announced in support of digital wellbeing, many of which are coming in the next version of Android.

    The first is the app dashboard, which will allow users to see at a glance how much time they spend on their phone, how frequently they use different apps and how many notifications they get. Android also will provide new options for silencing notifications, and easier ways to turn on do not disturb mode.

    Another new feature is an “app timer,” which allows Android users to set limits on how much time they spend in an app. When you reach your daily limit, the app icon is greyed out to remind you not to use it again. Google’s YouTube app is getting a similar timer that reminds you to take a break after an hour’s continuous viewing, or however long you choose to set it for.

    It was unthinkable a year ago that Google would encourage people to take a break from their smartphones, since mobile ads are one of the primary ways it makes money. But times have changed, and Google’s digital wellbeing initiative reflects a wider public awareness that technology is not an unbridled force for good.

    “We’ve reached an important inflection point in computing,” CEO Sundar Pichai said at Google I/O, “and it’s made us even more reflective about our responsibilities.”

    Microsoft CEO Satya Nadella expressed a similar sentiment at Microsoft Build, calling for greater responsibility in the technology industry. “None of us want to see the future that Huxley and Orwell imagined,” Nadella said, referring to dystopian authors Aldous Huxley and George Orwell.

    So what does this mean for developers? It means we need to have a greater awareness of the impact the technologies we build will have on users, and to provide the best possible experience with everything we do.

    That means we can’t bombard people with alerts and notifications just to make them spend more time in our apps. People are tired of the constant nagging, and those tricks now work against you. We also need to maximize ease of use, so users can accomplish what they need to do quickly and move onto the next task. Don’t be the app that makes people think, “I waste too much time in this software; I’m setting the timer.”

    Most of all, developers need to provide the very best user experience they can. There were 3.5 million apps in the Google Play store at the end of last year, so there’s no shortage of choice about which to use. If your software is buggy or unintuitive or triggers too many alerts, your app will be among the first to be silenced or uninstalled.

    Google’s focus on digital wellbeing has raised the bar for all of us, and that’s a great thing. But it means developers need to redouble their focus on the user experience. People don’t unquestioningly love their phones anymore; there’s greater awareness of the downsides that constant app usage can bring, and developers need to think about this changing environment as they design, build and test their software.

    — Fred Stevens-Smith

  • Scrutiny of the Bug Bounty

    Scrutiny of the Bug Bounty

    Tips on building an internal bug bounty program

    As a programmer, have you ever felt pressured to ship a release with lots of new features, while you knew that there was still a technical debt stability improvements and bug fixes that you wanted to address but didn’t have the time or scope to address? This happens all the time, along with the worry that a bug could cause problems for users leading to churn, revenue and reputation costs. Even the best software faces this challenge, balancing road map velocity with software stability, with each release. These imperfections can delay new software and feature releases at a time in which speed has become a powerful competitive advantage.

    Developers and their organizations are challenged to bring products to market faster without impacting their stability and reliability. To be successful in this regard, organizations need a culture and resources to detect instability at multiple inspection points.

    Enter the Bug Bounty

    Of course, development teams are responsible for the quality and stability of the products they build. But those products often act differently in distinct environments. This problem isn’t new. Developers have always faced unknown issues prior to a release. However, dealing with such problems can be improved by considering the cultural solutions and tools used to reduce the bugs and increase stability.

    Many organizations are creating internal bug bounty programs to promote security and application stability by reducing software bugs. These organizations promote a proactive culture of ownership and empowerment through internal programs that allow a variety of employees to assume the role of bug hunters. If the proper tools are available, bug detection responsibilities can be shared by development teams, operations and executive management.

    Bug bounty programs enable teams to harness problem-solving skills to reduce bugs in application and software releases. Detection tools enable multiple teams to track and prioritize bugs that have the greatest business. This involves multiple teams and viewpoints in tracking and fixing bugs to prompt a variety of strong ideas and solutions.

    A companywide bug bounty program can also promote awareness by involving participants outside the development process in a fun and challenging way. It creates an opportunity for people throughout the organization to improve product quality. It’s a good way to promote application stability awareness while encouraging employees to explore applications and software development.

    Internal teams of engineers and developers are inherently well-suited for these types of projects because they know the infrastructure better than anyone, including its strengths and the weaknesses. By codifying the internal search for bugs, organizations can learn from mistakes and strengthen products while building intellectual capital. An internal program has the added benefit of identifying vulnerabilities before customers or users experience them.

    How to Begin

    To launch a successful program, consider the nature of the program along with the process and workflow for prioritizing where to allocate team resources. Specifically, an organization must define the business objectives that determine the kind of program you want to run, what the rewards will be and the scope of what will be tested. And with that information, determine the culture and tools that make it all possible.

    It’s important to keep in mind that the two pieces (culture and tools) are not exclusive and don’t have to come in a certain order. You can use the right tools to build the culture, or you can create the right culture and right tools help codify and amplify that culture.

    Considerations for a Successful Internal Bug Bounty Program

    Business Objectives

    What are the business goals and objectives that determine how the program is administered and what solutions will be used to achieve your desired outcomes?

    Rewards

    To attract the talent and attention needed to run a successful program, setting the rewards in line with your business objectives is an important step.

    Scope

    Detailing the scope of the program is essential to specify what the program intends to investigate, where to explore and what measures are allowed.

    The more detail that can be supplied the better.

    What Participants Need to Know

    Internal teams need to know what they are signing up for when they choose to participate in the program and how anything they uncover will be utilized. Be clear for all involved, both the organization and the program participants.

    It is crucial to point participants in the right direction and establish boundaries around where activities are expected and allowed and where they will be most beneficial. One tactic may be to keep a running list or dialogue detailing important targets. These targets will likely be a mix of web, mobile, IoT and API and can be prioritized in running lists.

    Once acceptable targets are established, the best way to achieve a lasting impact is to have the tools in place that allow teams to build better software. Through culture and tools, it’s important for teams to be empowered to capture errors and diagnostic data in any app, prioritize the errors that have the greatest business impact, reproduce and offer fixes for the errors, all in clear metrics that multiple teams can understand and put to use.

    Finally, ground rules are needed. This step will vary among organizations based on objectives and scope. But programs should detail how tests can be carried out, who specifically is authorized conduct them and how adjustments will be communicated as the program evolves.

    Businesses may find many reasons for implementing an internal bug bounty program ranging from security to quality and even professional development. Whatever the reason, take the time to define the program clearly to keep it within the scope of your goals and pay close attention to the culture you promote and the tools that are implemented to be sure the program can achieve maximum results.

    — Chuck Dubuque

  • Attaining Continuous Testing in DevOps through a Templated Approach

    Attaining Continuous Testing in DevOps through a Templated Approach

    The continuous demand market for flawless applications is being addressed through advanced software development techniques along with continuous delivery. As such, many organizations adopted the shift-left approach and agile best practices—which suggests the motto, “test early, test often,”—through which they get to imbibe QA practices and testing early in the software development pipeline. That also includes continuous testing for many organizations.

    Continuous Testing in DevOps

    Continuous testing today is the most preferred practice by leading software companies. Continuous testing implies testing through the whole software development pipeline, from product design to product release, by integrating the complete product cycle. Even after the product release, companies test to troubleshoot customer complaints to further improve the product.

    Continuous testing in DevOps involves encouraging the development engineers and operations to practice testing as well, and also makes them a part of the whole cycle instead of being a separate team. Continuous testing involves testing not just from an earlier stage but also through each and every single process. Its goal is to automate almost all the processes as possible.

    A Templated Approach to Continuous Testing in DevOps

    A perfect approach to continuous testing in DevOps should be a right balance between manual and automation testing, and to achieve it, organizations must practice virtualization to plan out the whole product development pipeline successfully. Many organizations are not yet ready to risk it all with continuous testing, as big errors are still a possibility if they don’t really know how to execute it. But, errors in the continuous testing method can be easily rectified as it is practiced through each process.

    Errors are common when it comes to product development; hence, the right set of tools to automate testing can be critical to finding and rectifying errors, since manual testing can miss certain errors. Manual testing also takes a considerable amount of time, which is a huge drawback. A well-planned but carefully structured templated approach can be practiced by companies to make a full transformation toward continuous testing.

    Continuous testing is achieved through imbibing multiple use cases over certain parameters to determine the strength of this methodology. Some of those parameters that would prove to be a sure-fire way of determining whether continuous testing is worth it are distribution, technology, scale and load, environments and security and release.

    Checking the Parameters

    The parameters to completely check a dimension such as continuous testing can be done to create readings based on elimination and weighted scoring to derive results from a use-case scenario. Let us see a brief application of running a hosted public-facing service through these parameters:

    Distribution – The distribution areas and the geographical location of this product are considered.

    Scale and Load – The number of test cases (3,500 automated cases in this scenario, by way of an example), the suites that are used based on the browsers, cloud test platform and the numbers of users are considered in this category.

    Environments and Security – Varied device uses, cross-browser testing, secured cloud environment and approval of releases are considered in this parameter.

    Release – The number and frequency of release and the technology stack are considered in this parameter.

    The tools that are used for this scenario are Selenium web driver, Selenium GRID, Jenkins, Sauce Labs, Sauce On-Dand Plugin.

    The process through which checking the parameters is done is by triggering automated test cases from Bitbucket automation repository using Jenkins during deployments, and the execution of automated scripts in Sauce Lab cloud, as parallel threads are done by interfacing Sauce Lab Plugin with Jenkins.

    The control mechanisms first include testing through smoke, regression and integrated automated tests execution. Then, the test evidence for all of the test cases is captured. Later, as the tests are completed and the screenshots which are captured by automated tests are validated, UAT sign-off is done.

    Some parameters for test automation framework are compared within Selenium and tests completed over various categories, their scores are compared and then they are passed onto the test environment. Some suite, regression suite and integration test suites are carried out during Dev and QA stages, later when the changes from these two environments are deployed. Smoke suite is carried out during pre-production, editorial and the production stages. Finally, the proven results of these stages are derived successfully.

    The proven results of this use-case scenario through these stages are:

    • Parallel testing visibly reduced regression hours from 150 hours to 15 hours.
    • Enhanced test coverage matrix addressed varied device and OS fragmentation, as well as browser combinations.
    • Quality gatekeeper for code promotion to production.
    • Reduced regression issues in production.

    Conclusion

    The example of going through such a use-case scenario helps us better understand how continuous testing can be integrated gradually into a product development pipeline through careful observation, planning and deployment through such parameters.

    Engrafting continuous testing in a DevOps eEnvironment needs careful execution to avoid errors and future defects. And with the right set of tools and a perfect execution, it can be achieved to successfully experience faster time to market and reduction in time and cost.

    For more information on how a templated approach can be applied in different scenarios, watch this webinar.

    — Niranjani Ramesh

  • New to DevOps? Resources to Help You ‘Get With the Program’

    New to DevOps? Resources to Help You ‘Get With the Program’

    Resources to help put you on the right DevOps career path

    The demand for DevOps solutions is set to achieve an annual compound growth rate of 16.5 percent in North America for the 2017-2023 period, according to KBV Research. Globally, the DevOps market size is expected to reach nearly $9 billion in five years. That we’re facing a tsunami of skills shortages goes without saying.

    Yesterday’s view of IT operations tended toward the “Dev” side being the “makers” and the “Ops” side being the people that deal with the creation after its birth. The realization of the sheer amount of inefficiencies that occur when these siloed concerns work at cross purposes became a main core driver behind DevOps.

    So What is DevOps, Really?

    Jez Humble, co-author of “The DevOps Handbook,” defines DevOps elegantly as “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly changing resilient systems at scale.”

    DevOps can be described in many ways. The Agile Admin blog claims it simply as:

    “… the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support. DevOps can be interpreted as an outgrowth of Agile – agile software development prescribes close collaboration of customers, product management, developers, and (sometimes) QA to fill in the gaps and rapidly iterate towards a better product.”

    Education and Training  

    There are plenty of resources available for wannabe practitioners to cut their teeth, starting with Lynda.com courses on the LinkedIn Learning channel.

    It is even possible to earn professional certification. For example, certification for a DevOps engineer from Cloud Academy comprises more than 32 hours of interactive content (including 16 video courses and 11 hands-on labs) to help you learn the DevOps ropes. Courses include content on networking, security and deployment.

    The DevOps Institute is another great resource, offering a range of courses to help DevOps practitioners of all competencies gain education and experience. The organization curates its members and the DevOps community in general to track and trend the latest and most innovative approaches to DevOps, and offers certification and “digital badging” to its members.

    But what if you don’t want to, or can’t take the steps needed to earn certification?

    Kaushal Amin, CTO at Atlanta-based KMS Technology, an outsourcing services provider with 500 developers in Vietnam, said it takes some studying, networking and, above all, people skills. Talk with IT professionals outside of your organization who are already established in DevOps, as experience can be one of the most valuable resources available. Amin proposes three helpful steps for IT professionals looking to learn about DevOps:

    • Gain a highly focused understanding of DevOps via low-cost online courses offered by Udemy such as Modern DevOps and Mastering DevOps.
    • Talk with friends and colleagues in different roles from your own. Devs should reach out to systems administrators to discuss job responsibilities and tools used. Attend conferences and training sessions to meet people in different DevOps roles.
    • Talk with QA test engineers. They’re the people at the end of the DevOps process responsible for executing quality assurance.

    Amin suggests that after you’ve gained familiarity with DevOps, try out popular cloud-based app development platforms such as Heroku. These providers often offer free versions that can help foster an easy learning path while showcasing cloud services that can help DevOp teams create business process apps and avoid headaches typically associated with assembling or managing platforms and IT infrastructures.

    Suggested Reads

    Tracking the entire software development life cycle is fraught with complexity. Rookies can take comfort in scanning through a glossary of commonly used DevOps terms and concepts.

    No collection of resources is complete without a reading list. At the top of most DevOps-related booklists is, “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win,” by stalwart veterans Gene Kim, Kevin Behr and George Spafford. Other notable reads include:

    • “Building a DevOps Culture,” by Mandi Walls
    • O’Reilly Media’s “Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale,” by Jennifer Davis and Ryn Daniels
    • “The IT Manager’s Guide to Continuous Delivery: Delivering Software in Days,” by Andrew Phillips, Michiel Sens and Adriaan de Jonge

    And beyond this website, which offers a plethora of DevOps-related content ranging from articles to videos, podcasts to webinars, another helpful resource is DevOpsLinks.com, a learning community of professionals looking to share tips and best practices. As its founder Aymen El Amri, puts it, “For evangelists, DevOps is a culture and a transformation. For some engineers, DevOps is a set of agile tools and techniques. For managers, DevOps is probably a methodology. For other people it is just a buzzword and for recruiters, DevOps is a job.”

    — Victor Cruz

  • DevOps is Old News. DevProd is the Future

    DevOps is Old News. DevProd is the Future

    DevOps has been widely embraced and isn’t going away. However, there’s a new software movement emerging that deserves headlines of its own. Let’s call it DevProd.

    In a recent Harvard Business Review article, “Agile at Scale,” the authors point out that “conditions are ripe for agile teams in any situation where problems are complex, solutions are at first unclear, project requirements are likely to change, close collaboration with end users is feasible, and creative teams will outperform command-and-control groups.”

    To understand why DevProd may be the next big thing, some perspective on the DevOps movement will first be helpful.

    DevOps Addressed a Huge Pain Point

    At one time, software was often created by a single person. By 2008, teams of hundreds or more were needed to meet the accelerating complexity of software development. We hit an inflection point, triggering an organizational need to streamline and fuse development (code) and operations (IT infrastructure).

    Companies were scrambling to “go agile,” but silos between these constituencies became roadblocks. In response, DevOps, which was coined at the 2008 Agile Toronto Conference, broke down those silos and had a profound impact on a company’s ability to move faster and more efficiently.

    Waves of companies and products soon enabled streamlined processes between developers and operations. Some became successful, such as AppDynamics (acquired by Cisco Systems), Splunk, Chef and Puppet.

    Today, while there remains room for improvement, this challenge is largely resolved. Companies have added DevOps experts, while DevOps tools are embedded in development and operations processes.

    History Repeats Itself

    As part of my job, I often speak with leaders of software development organizations. Once the conversation turns toward development speed, app deployment or even features management, executives will invariably mention the product manager—that is, if she isn’t already in the meeting.

    When I realized this was happening with startling regularity, I began to wonder, Why involve the product manager in a conversation around development and deployment?

    Just like with DevOps years ago, organizational leaders from various disciplines within the same enterprise are suddenly working closely together. There is a movement underway, with the purpose of creating feature-based teams that are organized around a single aspect of a product. The purpose of the teams is meant to break down silos by bringing together disciplines such as engineering and product management. A great example of this is Spotify, a company that created the ultimate #squadgoals approach to enterprise agility by breaking down core organizational units into smaller, autonomous product development team with no more than eight people. Each team or “squad” is accountable for a discrete aspect of the product, from cradle to grave. The company shared some fascinating videos on their engineering culture.

    Why DevProd? Why Now?

    Of course, organizations require speed and agility. Product management requests changes and technical staff implements them. It makes sense they would need to work in close proximity.

    Even though that’s been true for years, there’s still been a dramatic uptick in that collaboration.

    With DevOps, companies increased deployment agility and reduced version release times dramatically, allowing them to stay competitive and react more quickly to the market. Yet, the DevOps movement retains a focus on an engineering unit: “the version.”

    However, software versions are no longer as significant as they once were since full application distributions are no longer needed. Instead, every change to the application can now be considered a feature and can be rolled out separately and in more granularity. DevProd is to continuous software delivery what DevOps is to version updates.

    Developers and product managers have different priorities. Developers think about impact on the broader application and compliance with technical requirements. Product managers think about impact on business KPIs and how to determine that impact. If either group works in a silo, the other group can’t achieve its goals. Instead, they’ll need to work together much more often. That’s DevProd. I’m confident DevProd will have the same, if not more, impact as DevOps did. I know this because the pattern is the same:

    1. Companies try to solve a burning issue and spend resources on developing the solution in-house (e.g., what IT did with log management before Splunk).
    2. They continue to spend resources on evolving and maintaining that solution.
    3. The solution has a real impact on the company’s ability to meet its business goals
    4. The C-suite in that organization buys into the vision and is willing to take ownership of it and assign resources to it.

    It Won’t Be Easy and May Not Be Enough

    It’s an exciting time to work in software, and the fusion of development and product will deliver immense benefits for organizations. However, the DevProd movement is not without its challenges.

    Regardless of how closely they work together, project managers still need the development organization to create experiments and custom experiences. They cannot simply wish them into existence. Because developers will run experiments of their own (improving application performance, using new tools, etc.), it won’t be easy to juggle the business and development-focused experiments.

    All experiments need to be well-coordinated and carefully planned. That will become a necessity as organizations respond to a market that is feature-centric, not version-centric. Features need to be easily controlled and managed in production, by both developers and product managers, without overstepping each other’s actions. Moreover, the need for speed requires product managers to manage features with a click—without creating additional work for developers. At the same time, developers need to be assured that changes don’t break the application or hurt performance.

    Developers and project managers working closely together is necessary step toward solving these challenges. But it may not be enough. In fact, almost every company I talk to has either developed or is contemplating a single system that will allow both developers and project managers to run some level of experimentation.

    Larger companies such as Facebook, Uber and LinkedIn even have developed highly sophisticated experimentation systems in-house.

    What This Means for You

    It’s an exciting time. It is not that often that you witness a movement that gives rise to a new product category that will evolve over time and create a substantial impact.

    For companies to stay competitive, they will need to:

    • Create a DevProd virtual/actual team to align their feature deployment plans as well as share ongoing insights from current deployed features.
    • Implement a feature management platform that provides both control and visibility into the feature deployment and impact.
    • The platform should be implemented by engineering and used by both Engineering and Development.

    Thanks to DevProd, software development is about to take another quantum leap forward.

    — Ronit Belson

  • How DevOps Helped One Firm Get GDPR Right

    How DevOps Helped One Firm Get GDPR Right

    There has been a lot of press about how many, if not most, enterprises are still unprepared to comply with the European Union’s (EU) General Data Protection Regulation (GDPR) just days before it takes effect.

    However, executives from Cybric, a security platform provider, said their company has been ready for some time—and they thank DevOps for that. Their case study also shows how firms that are still struggling to get started before GDPR takes effect can do what is necessary as they integrate compliance with their operations.

    As soon as GDPR appeared on Cybric’s radar screen more than a year ago, the firm began to prepare. GDPR quickly became a compliance and data management process discussed among others on a regular basis and, as part of its DevOps, it involved the participation of all the stakeholders involved.

    “One core part of the culture of DevOps is about collaboration, sharing and communications and making sure you have automated processes in place,” said Mike D. Kail, chief innovation officer at Cybric. “That is, in part, how we were able to do what had to be done for GDPR.”

    Standard Procedure

    Before GDPR was announced, Cybric already had its data flow management processes in order, Kail said. This included keeping transparent records of data sources and the corresponding geographic locations of the individuals in the databases. “We were already analyzing how we processed our data and knew where it was going,” he noted. “We were also always looking at all the ways we could automate how we handled data flows.”

    The different infrastructure, development and business teams, of course, have also played a collaborative role in Cybric’s data flow management processes and resulting GDPR compliance. “Each team figures out how they how they can help, which goes back to the collaborative culture of DevOps,” Kail said. “It’s everybody’s responsibility and not just one team’s concern in the company. In the case of GDPR, the fines and levies can be significant, so everybody should take this seriously and not put it off and say ‘that’s not my problem.’”

    In this way, Cybric was in a position to respond to the demands of GDPR compliance long before the deadline.

    “One result of DevOps is you always take care of where the data is and how it’s being processed in an automated way,” Kail said. “The wrong way consists of manual, out-of-bound efforts for processes and tasks that people ultimately screw up or forget to do on a regular basis. And when that happens, you now have potential compliance issues.”

    GDPR’s Long Arm

    Some firms may be led to believe they are not concerned by GDPR if they do not store customer data from European customers. What they may not realize is that any data—whether it’s personal data for vendors, sales leads or general third-party business contacts for individuals based in a EU country—is protected by the GDPR mandate.

    Cybric, for example, outsourced its customers’ personal data. However, the firm still must comply for individuals who visit its website and submit personal information to download marketing collateral.

    “I think marketing is an area that a lot of people don’t think about too much,” Kail said. “They are like, ‘I don’t have any personal data directly,’ but indirectly, they do have personal data and must be GDPR-compliant.”

    Many organizations have not yet prepared for GDPR since they have not fully understood the regulation and whether it applies to them or not. But although some of GDPR’s terms are opaque, organizations still should not delay compliance just because they do not completely understand what is involved. “I think a lot of people are trying to delay their compliance even though the GDPR deadline is just three weeks away,” Kail said. “And sadly, their databases are just not ready since they have not thought about the complexity of GDPR compliance and certainly not in a DevOps way.”

    Small-to-medium-sized enterprises should also not be concerned about having to invest a disproportionate amount of resources to become compliant compared to what large firms will have to spend. Cybric’s small size—with fewer than 20 full time employees—has actually played to its advantage, Kail said. Additionally, Cybric’s story offers a look at how a small-to-medium-sized enterprise can use DevOps for GDPR.

    “As a small company, putting together a collaborative process with all of the different departments made it much easier for us,” Kail said. “That is also the approach people have to take.”

    — B. Cameron Gain

  • The Role of DevOps in the Financial Services Industry

    The Role of DevOps in the Financial Services Industry

    We are living in a fast-changing environment where unexpected technological, economic and political changes can be expected and where it is necessary to adapt quickly to these changes. This statement is especially true in the financial services sector, where there is a greater need to exceed the expectations of customers and provide uninterrupted service.

    From small trading firms to the financial industry players—big banks and exchanges—all are racing to deliver features and content to customers more quickly, and opting for DevOps tools, practices and ideas to solve the problems arising in financial systems.

    In DevOps methodology, the development and operations engineers work together in the entire service life cycle, starting from design via the process of development to production operations, maintenance and support. A DevOps approach is helpful for the adoption of various technologies such as blockchain, which is the technology behind cryptocurrencies such as bitcoin wallet. In this article, I will discuss the applications of DevOps methodology in the finance industry.

    How DevOps is Transforming Financial Services

    As said earlier, financial services companies face new challenges in their day-to-day operations in meeting the standards laid down by the unicorns. To support today’s digital age, many financial services companies are modernizing their back-end systems and processes.

    In addition to using legacy systems and code, they can face difficulties in meeting governance requirements, complying with regulations and alleviating risk for better security. These concerns make the software innovation a slow and complex process.

    But, over the past few years, the financial services sector is leading the transformation when it comes to adopting latest technologies and modern software delivery practices including DevOps, continuous delivery (CD) and Agile.

    Finance executives view DevOps as a way to bring value to the market in a more safer and efficient way. DevOps allows financial services to enhance the quality and cadence of application releases while addressing compliance, security, risk and governance strategies. Now, let’s dig deeper into the ways in which is transforming the finance landscape.

    Mitigating Potential Security Threats

    In the financial services industry, compliance and security are major concerns and have been the major setbacks in replacing legacy practices of software development and delivery. In the initial days, DevOps practices were seen as major risk to security and the enhanced velocity of software releases it allows was viewed as a threat to security, governance and regulatory controls.

    In spite of the initial setback, some enterprises that adopted DevOps have shown consistently that these practices actually reduce potential security problems and help companies locate issues and tackle threats more quickly.

    Due to this many companies have embraced the automation practices that enable and enforce compliance, security and audit requirements. Today, financial services companies view DevOps as a resource for security.

    Automating all the Processes

    Automating the processes all through the software delivery pipeline is another essential to enhancing resource utilization, product quality and developer productivity, and allow cross-project and enterprise-scale management and visibility in financial services. For any continuous delivery or DevOps initiative, automating all the processes is becoming a major requirement for enabling scalability and speed, ensuring compliance and achieving higher product quality.

    DevOps offers enterprises with an efficient approach to alleviate risk from software releases and aid the ever-evolving demand for frequent application updates. By managing all the release processes in a single centralized platform and automating the complete end-to-end pipeline, these companies gain visibility into the progress of all DevOps processes and releases and make sure they can optimize, govern and control their delivery pipelines even as they evolve.

    Driving Cultural Transformation

    DevOps focuses on creating an environment and a culture where the business, operations, quality assurance, development and other stakeholders work collaboratively toward a shared goal. While optimizing the technology and tools to scale DevOps adoption, embedding security practices and automating the life cycle are the major steps. DevOps is a mindset and any change in culture takes time.

    This change takes time and even the financial services industry that is regulated heavily is implementing DevOps and leading the change from both the cultural and technology standpoint. Thus, the financial services companies have what they need to keep pace with the unicorns, modernize their benefits and completely harness the benefits of DevOps.

    Orchestration

    For many financial services companies, the four basic software delivery pipeline stages (release, deploy, test and build) consist of numerous processes that hold within them millions of jobs and thousands of tasks executed by a large number of people. These toolsets, processes and the people are often present in silos, making things even more challenging.

    While existing in silos, these people may become skillful at understanding and enhancing their part of finding the solution, but from an organizational perspective, there is no end-to-end visibility and orchestrating the complete pathway is impossible. This leads to a lack of governance, errors, delays, manual handoffs and fragmented processes.

    As the IT operations and development teams are often geographically distributed in these large organizations, it is important to enable shared visibility and control into the different processes, tool chains and infrastructures. Optimizing the process of software delivery shouldn’t be attacked as a separate set of problems but viewed as utilizing a system-level approach, much as the manufacturers of cars apply lean manufacturing principles all through their production lines.

    The implementation of DevOps is spreading rapidly in financial services sector due to the value that this global, systems-level approach enables. DevOps accomplishes this by scaling the latest IT process across the entire organization in order to enable an end-to-end, robust pathway to production.

    Eliminating friction between teams and breaking down functional silos by orchestrating every aspect of the software delivery pipeline to create repeatable, predictable processes that can operate frequently with minimal human intervention prevents many of the challenges distributed companies face.

    Conclusion

    Even facing strong opposition in the beginning, many organizations took a risk implementing DevOps and have benefited substantially. Today, many technologies such as big data analytics are evolving rapidly and are implemented by many organizations around the world. According to a Peoplehr post, data analytics is used to enhance various organizational activities. Those companies that embraced analytics as part of their activities have gained huge benefits from it. In the same way, any new technology such as DevOps has to be embraced by organizations in an effective manner to enhance their overall productivity.

    DevOps implementation eliminates the security problems before they become a major threat and scales the IT processes across the whole enterprise, thus allowing an end-to-end and vigorous pathway to production. Every day, more organizations are switching to DevOps and not looking back. The change to DevOps culture may take time, but it will revolutionize the activities of an organization, including financial services.

    — Sujata Rani