devopsy.kinsta.cloud

Tag: technology

  • Debating the Future of DevOps

    Debating the Future of DevOps

    Change happens at an astronomical pace in the DevOps world, and I constantly see organizations shifting in their needs as the weeks and months go by. One week, the most essential need will be a specific configuration management tool and the next, it will be an urgent requirement to work on containerization.

    Many companies forget that simplicity often is the key and the focus should be on transferring to engineers the requirements of the business and product owners. It’s not always about implementing every new tool just because another awesome engineering team is using it—they might have different business needs and end goals than yours.

    Whether you are consulting for another client or working on your own internal applications, is your focus on how exciting the new container management system is or how to build the best possible end product that the business requires? Your DevOps organization should be focused on understanding these needs as well as the needs of every team across the technology function and more. So how, then, do we find the line between leading, following or resisting trends to create the most competitive advantage for our organizations?

    The DevOps movement will continue to break down silos and increase collaboration. I see DevOps and big data coming closer together; for example, our DataOps teams will have the usual deep understanding of infrastructure, the ability to automate processes, write scripts, build CI pipelines and continuously deploy new code. However, there also will be increasing demand to work with the likes of Splunk and Hadoop to process large sets of data as well as monitoring and logging.

    The cultural idea of bringing our teams closer together, to understand each other and to increase productivity will drive such shifts in skill sets. Other technology touchpoints such as containerization and serverless architecture will continue to spread deeper into organizations, while security and privacy may creep further up our list of priorities as we continue adopting more technologies into our organizations. However, it may take some tough learning curves before we really understand the implications caused by not taking SecOps seriously.

    Every organization has different needs based on the stakeholders, the tech stack, the infrastructure architecture and more. DevOps will continue to shift, take on other aliases and functions, but the truth is that the future of DevOps is simply the future of your organization.

    Understanding what that future holds, however, is up for debate. That’s why we’re hosting an event designed to push DevOps thinking beyond current boundaries among practitioners of varying backgrounds. The Future of DevOps Debate, an invitation-only event, is happening Nov. 10. Salt, host of the event, plans to share footage of the event as well as posting further blogs and articles, providing everyone a glimpse into the day’s conversations and, well, debates.

    The day includes a dedicated session discusses the pain points, experiences and successes leaders have had in their past and current positions. The day’s conversations will be in debate-style format so that everyone gets their opportunity to share thoughts and contribute. The core focus is to work toward the future of DevOps.

    This is the first Future of DevOps Debate, and Salt plans to run a series of events on a quarterly basis. It also contributes to the local New York DevOps community, sponsoring events such as DockerNYC and hosting ServerlessNYC, to name a few.

    It’s clear we are at an inflection point in DevOps, as new technologies and processes strive for attention. Together, we can help shape the future of DevOps and push the industry well beyond its current boundaries.

    About the Author / Conor Delanbanque

    conordelanbanqueConor Delanbanque is managing consultant and head of DevOps USA at Salt. Previously, he was supporting and consulting clients across Europe with their DevOps transformation efforts. Connect with him on Twitter at @ConorDevOps.

  • Every Business Has Become a Technology Business

    Every Business Has Become a Technology Business

    Contributor: ITSM ACADEMY-Drew Lapatin

     

    Every business has become a technology business.

    Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog), and when should we retire them (retire).  We literally could be an app away from becoming irrelevant.

    It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often.

    By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer requirements more effectively. Normally projects will start with a given set of requirements.  In an Agile project (yes, we are going to use an Agile project format to continue the theme of blending ITIL and DevOps) the product backlog will contain these requirements as user stories, but as we all know those stories/requirements/attributes can change very rapidly. One tool that could help us rank these attributes and ensuring the delight of customers is the Kano model.

    A Kano model shows us there are three different factors in customer satisfaction.

    They are as follows:

    • Basic factors are aspects of the service that have to be in place for the customer to receive the service. They may not offer any obvious value, but if they fail, or are not delivered, customers will become very dissatisfied. These factors are sometimes called ‘must-have utility’ or the very least the service provider can deliver for a particular service.  Basic factors are not responsible for high levels of satisfaction, unless they alone fulfil the customer’s requirements completely.
    • Performance factors are factors that enable a customer to get more of something that they need, or a higher level of service quality. These are the factors that customers are interested in and the price they are willing to pay is directly impacted.  These factors result in customer satisfaction when delivered and customer dissatisfaction when unfulfilled.
    • Excitement factors are attributes of a service that are generous, and which customers do not expect. When they are offered (within reason) they cause higher levels of satisfaction. The service provider is seen to be ‘going the extra mile’. While excitement factors result in the quickest and highest levels of customer satisfaction, they are expensive to maintain, since the service provider is offering more than necessary at the same price. These factors may be exciting, but they are not essential to the service, and are therefore also referred to as ‘nice-to-have utility’. Internal service providers should be careful of introducing excitement factors in the interest of ‘customer satisfaction’ without doing a proper business case to justify the additional costs.

     

    Drew Bio

    — Alice Acedia

  • The Persistence of Enterprise Tech Failure Rates

    The Persistence of Enterprise Tech Failure Rates

    During a recent dinner conversion with a CIO friend, I was surprised to learn that his organization was having challenges delivering the applications and IT services on a timely enough manner that the business needs. The business is taking too long to approve the budget for major tech projects to start, then develop and deploy, and the CIO expressed frustration how it is always behind the demand curve and following where it should likely be in the market. His level of frustration as he described the situation was painted all over his brow.

    Hearing this was surprising to me; after all, we’ve been writing about how such problems delivering with speed and agility are challenges that are designed to be solved by DevOps, agile development methods, microservices and all of the things we focus on here at devopsy.kinsta.cloud and Container Journal.

    The discussion we had got me wondering how common this situation remains. How many companies are still struggling with their ability to retool themselves into more agile developers? In the late ’90s it was common for tech projects to fail. I recall surveys I reported on that found 60 percent, or higher, failure rates of large projects. But back then software rollouts were truly big bangs. There were years of development time and hundreds of physical servers and thousands of endpoints that had to all be managed. There existed layers and layers of committees and bureaucracies between the developers, IT admins and business leadership. IT is supposed to have moved beyond all of that.

    Unfortunately, however, if recent surveys are any indication, it still seems very common.

    A survey conducted last year by portfolio management provider Innotas found that more than half of tech projects are not well aligned with the goals of the business. The survey, the annual “Project and Portfolio Management Landscape survey,” also found that more than 61 percent of IT professionals questioned did not think that they have adequate resources to manage demand for tech projects in their organization.

    Part of the challenge may be that there’s inadequate project management in place at many organizations. The survey found that 38.7 percent of respondents didn’t have a project management office at their organization; however, 16 percent are building such offices. Additionally, 25 percent of those surveyed said they don’t have a formal methodology to prioritize projects.

    Other areas of concern ranged from project prioritization (26 percent) and alignment (13.8 percent). Attaining benefits and finding the appropriate budget were also challenges at 12 percent or fewer of organizations surveyed.

    This is concerning, as more enterprises are doing everything they can to move more swiftly (or, at least say that they are). As we covered in “Digital Transformation Strains Traditional IT,” according to a recent report published by Salesforce’s “2016 State of IT,” IT leaders are focusing on mobile apps, migration to the cloud, building adequate cybersecurity/incident response, customer-facing digital apps and productivity apps.

    The Salesforce report found that 68 percent of respondents are increasing their tech budgets on mobile apps, cloud and security. The majority (63 percent) of respondents also said they plan to increase their budgets allocated to cybersecurity, while 62 percent will spend more on employee productivity apps.

    Some of the things that has come up, repeatedly, in my conversations with other CIOs is that those companies that are struggling have poor business-to-IT relationships and ongoing feedback. This creates a lot of distrust and poorly aligned priorities.

    We covered a lot of this earlier in a number of posts, which are available here:

    Five often expressed obstacles to enterprise IT innovation

    Enterprises still struggle to leverage IT as a tool to innovate

    The IT mandate: Be a catalyst of business innovation

    Driving Innovation with DevOps

  • New Faces Of Devops

    New Faces Of Devops

    RECORDING

    SLIDES

    [seoslides embed_id=”77abd5e6ff38″ script_src=”https://devopsy.kinsta.cloud/embed-script/new-faces-devops/15682/” overview_src=”https://devopsy.kinsta.cloud/slides/new-faces-devops/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”New Faces of DevOps” /]

     

  • Choosing a Mobile Test Automation Solution: What You Need to Know

    Choosing a Mobile Test Automation Solution: What You Need to Know

    Organizations today rely more and more heavily on mobile apps to drive their business. In fact, many companies are already seeing more than half of their web traffic coming in via mobile devices. In some cases, their mobile app is the only way customers interact with their products.

    It’s no surprise, then, that developing, testing, and releasing quality mobile apps quickly and efficiently is a high priority for most organizations—as it should be! Fortunately, mobile development tools are evolving to meet these needs, with modern dev teams having access to better test automation than ever before.

    Of course, the effectiveness of a mobile testing process is only as good as the technology behind it. This makes it even more crucial for organizations to know what factors are most important to take into account when choosing or building a robust mobile testing solution. Below, we outline some key things to consider:

    Native, Hybrid, and Mobile Web Support
    Modern mobile applications come in three different flavors: native, hybrid and web. Native apps are built using the vendor-provided SDKs. Hybrid apps run some or all of their functionality inside a webview embedded in a native app. Finally, mobile web apps are simply mobile-optimized website that users access through their mobile browsers. While there is a growing trend towards mobile web and hybrid applications (rather than native), to ensure maximum flexibility and impact of your QA solution, it’s important that you choose a tool that supports all three kinds of apps.

    On-Demand Cloud Testing
    With QA teams becoming more and more distributed, it makes sense to ensure that your mobile application testing solution includes a cloud component. Leveraging an automation cloud enables teams to use organize around a single implementation of test architecture, with devices and test result data accessible from anywhere in the world. You can spend your time worrying about your testsuite, not the cost and maintenance headaches associated with keeping up multiple home-grown device grids and architectural patterns.

    Automation
    When it comes to mobile testing, automation is essential. Choosing the right automation frameworks (Selenium, Appium, etc…) and test tools (languages, test runners, etc…) can be a challenge, and it’s important to think about all the factors involved in getting a solid mobile build process going, relative to the expertise your QA team possesses. What kinds of user flows will you need to automate, and can the automation tool support them? Do you want automation code mixed in with your app code or cleanly separate? Is automation support available for the languages and tools you know best? Think about building a testsuite with the same level of architectural foresight as you would building an app.

    Integration with Key Support Systems
    It’s also important to consider what level of integration is needed with support systems in your environment – whether it’s a test management system, a CI server, or defect tracking system. A strong solution will be able to easily integrate with all of these other systems, perhaps all the way down to the IDEs your developers are using.

    Cross Platform Support
    With the majority of applications being developed for iOS and Android, it’s a minimum requirement for your mobile application testing solution to support automation on both platforms. Of course, this will no doubt expand as you consider other devices and operating systems such as Windows, FirefoxOS, etc…, based on your customer base.

    Scalability
    As the number of device types and operating systems being tested increases, it becomes increasingly important that your test architecture is able to scale automatically based on the number of tests you want to run and the amount of time you want your build to take. Building your automation on a framework like the open source Appium project is a good architectural investment; Appium’s client/server architecture makes it easy to build a testsuite than can automatically utilize a cloud service as your need for more emulators, simulators, and real devices grows.

    The proliferation of web and mobile applications across a myriad of devices and operating systems is fueling a demand for faster and faster delivery of software experiences, without any sacrifice of quality. Today’s leading software companies know that successful apps are built on the foundation of their mobile application testing processes and tools. By keeping in mind the key features mentioned above, organizations can work towards building and identifying the best testing solution for them. The QA process should be a breeze, rather than a hassle.

    About the Author/Jonathan Lipps

    jlipps Jonathan Lipps serves as the director of ecosystem and integrations at Sauce Labs, where he leads a team of developers to ensure that the open source ecosystem surrounding the company’s core products is always maintained. He is a frequent speaker on automated web and mobile app testing, and holds advanced degrees in Linguistics and Philosophy.  Reach Jonathan on twitter.

     

  • The 3 practical change elements in enterprise DevOps

    The 3 practical change elements in enterprise DevOps

    Culture, Technology & Ecosystem

    Most enterprises approach DevOps adoption in a singular fashion: they use a bottom-up approach that is typically technology-driven and groups all considerations like, culture, metrics, processes and communication into a single stream of work that is often led and implemented solely by technology-oriented champions.

    However, this singular approach presents a few issues:

    (1) First, it leads to poor planning on the change aspects of DevOps that are not (and should not be) technology driven – although we (DevOps Evangelists) are not change experts, we believe we can properly assess impact & lead organizational change just because we are the subject matter experts on the technical topic (DevOps). Accordingly, we miss the wider context and relationships with non-IT functions that would be impacted by DevOps.

    (2) Second, it naturally focuses the efforts on the areas inside our comfort zone (technical aspects) and potentially disconnects the DevOps program from the Enterprise priorities. If it didn’t, it limits DevOps to a technical change of tools and automation.

    (3) Third and most important, it contributes to the absence of realization that the changes in areas outside of IT is critical to the success of DevOps adoption and that specialist (internal or external) help in these areas may be required and better yet, often acts as a catalyst for change.

    The consequence of the 3 points above is that post the initial phases, enterprises reach an incomplete point of “DevOps Equilibrium”; this is the state that enterprise IT reaches after installing some automation tools, setting up a basic practice and changing some behaviors. It takes a lot of effort, dedication and pressure on the organization’s DevOps evangelists to make this initial launch and bring the beginnings of DevOps into their Enterprise. By the time they reach that point, energies are depleted, the bigger challenges of enterprise politics and ecosystem become apparent and the thought of another push to bring in more teams, departments, tools and stakeholders on board becomes a burden.

    The question then becomes, why is it a struggle and why is it difficult to adopt DevOps in an Enterprise? The reason is that the singular, technology-driven approach that “considers” the soft aspects of DevOps fails to leverage the value it delivers by transforming it into executive sponsorship and political influence; and the reason this happens is because executives consider a bigger enterprise view that stretches outside of their departments and outside of IT but the technology-driven, singular approach has a narrower view and fails to address the ecosystem of the enterprise that surrounds the technology and the culture, and accordingly all the executives’ concerns.

    In my experience, one of the main reasons DevOps evangelists in Enterprises fail to move beyond their point of equilibrium is because they approach DevOps as a singular, technology change not as an enterprise change.

    What I have seen from multiple enterprise DevOps journeys is that Enterprise DevOps adoption should be broken down to 3 main “Change Elements” and DevOps Evangelists should plan for each “change element” separately under a single program umbrella:

    1st Change Element is “Technology” – Enterprise IT landscapes are typically diverse with bespoke and packaged products. Having the technical expertise to understand what DevOps tools fit the enterprise landscape and how to integrate them into bespoke and packaged products is key. Also, understanding what does “implementing DevOps” mean to different IT systems is crucial; for example, do you need to automate the release of revenue-assured systems where speed is not as important as quality or is it enough to implement quality inspections only? Also, which systems do you start your journey with and based on what criteria did you choose these systems/projects?

    2nd Change Element is “Culture” – This is looking into how the IT teams would change the way they work, for example, developers need to check-in more frequently, business analysts need to learn to write behavior-driven requirements and operations should start understanding more about what developers do. Another example is how the developers’ (or testers … etc.) objectives will change to become more DevOps-Friendly? (For example, objectives should focus on the handover points between teams rather than team-specific activities). This is more focused on internal IT rather than the rest of the enterprise. Challenges arise here when adoption is phased without change planning – when developers potentially are required to change their approach when testers and operations teams are not. In this scenario, frictions arise.

    3rd Change Element is “Ecosystem” – This is the core of the message and it is about how to plan for organizational change outside of IT. This element is about how DevOps impacts the enterprise outside of the IT space and how to position DevOps to the rest of the enterprise. Here are a few examples of what should be done in this space:

    (1) Finding a Context: DevOps evangelists need a context for their initiative and it needs to complement other efforts in the organization. For example, evangelists should choose an organizational pain point like “poor customer experience driven by poor product quality”, and position DevOps as the IT solution among a wider enterprise program to tackle the issue – this helps evangelists take a benefits-driven approach to DevOps adoption, which goes along way in navigating the politics of the enterprise.

    Another example is the “lean initiative” – in most organizations I’ve seen, there is usually a process improvement or lean initiative going on in non-IT functions; evangelists need to hook into these relevant initiatives, present DevOps as aligned with the organization’s direction of becoming lean and position DevOps as the IT part of that lean journey.

    (2) Second, evangelists need to understand and assess the impacts of DevOps outside of IT. For example, as they change the culture by changing developers’ objectives (see above), how does that impact the overall HR strategy of the enterprise that places roles in bands and have a clear definition of a “Star” and how to promote this “Star”? Similar to HR is financial governance: how does a DevOps lifecycle work with the budgeting and financial governance process of large enterprises that releases budgets in gates/phases that are typically not iterative?

    Another example is how do evangelists link their DevOps metrics with the wider organization performance KPIs and business objectives? How do evangelists deal with the enterprise’s managed service providers and system integrators who may very well be located oversees and get them to work in a DevOps way without breaking existing contracts?

    (3) Finally, evangelists need to understand the political landscape and how to gain IT and non-IT support to their DevOps journey. Activities in this space should address the following questions: how do evangelists gain IT and non-IT Executive sponsorship to get non-IT teams to support their journey?

    Answering all of these questions above requires partnerships and help from other non-IT enterprise departments – but how do evangelists build these bridges?

    Because of all these Ecosystem challenges, I believe DevOps adoption in the enterprise should be approached as an enterprise change not a technology change. DevOps evangelists should dedicate separate plans for the 3 change elements above under a single DevOps program and they should not be shy of reaching out for non-IT help (external and internal).

    In the next few blogs, I will discuss each change element separately. Then I will answer the question that probably most of you are asking by now (continuing with the analogy): So what happens if the enterprise passes this “DevOps Equilibrium” and reaches a point of “DevOps Escape Velocity”? The point when DevOps is an established and acknowledged enterprise standard. What benefits will the enterprise reap? And why isn’t the point of equilibrium enough?

    About the author/ Tarek Negm

    tarekTarek is a DevOps and Lean IT enthusiast with a specific interest in the change aspects of the movement. He is a founding partner at Do Consultants where he helps enterprises adopt and realise the business value of DevOps and Lean IT. Before that, Tarek spent his career in global organisations in the UK and Europe working in IT leadership and Technology roles in a wide variety of industries including Telecoms, Financial Services, Hospitality and F&B. Tarek’s experience spans all the technology lifecycle starting with Linux kernel development to Enterprise Architecture and IT Strategy, in addition to IT change where he previously led a global IT transformation program across 5 European countries. Tarek holds an MBA from London Business School focused on change management in technology.  Reach him on LinkedIn:

  • DevOps – what does “good” look like?

    DevOps – what does “good” look like?

    I’ve blogged a lot about my definition of DevOps and what it means to me.

    I’ve always thought it much larger than “Dev” and “Ops” and that there isn’t really an end state – it’s an ever changing idea that will adapt to meet the needs of the business.

    That said, I’m asked quite often what “good” looks like?  How do you know you are on the right path?

    For me DevOps is a primarily a cultural idea.  If the culture is right then the technology and people will follow.  I talk to a lot of people who see this word “DevOps” and reach out straight to technology.  DevOps isn’t another word for automating Cloud servers…

    In order to an effective “DevOps” organisation I think you need 4 main pillars:

    1. Culture – does the culture of your company promote collaboration, self improvement etc?
    2. Process – you need to have processes that support different silo’s working together to achieve a fast pace of change
    3. People – if you don’t have the right people then it doesn’t matter how great your technology is.  People and culture are very linked but I’ve tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
    4. Technology – what are the building blocks you need to be a mature DevOps enterprise?

    The following is very much my view of what “utopia” looks like.  The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve.  For example, you absolutely don’t need to use public Cloud to achieve DevOps.  However, I do think it’s a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.

    This is where I want my company to get to…

    Culture

    • Measure everything, always
    • Individuals have empathy for the rest of the team (i.e. they don’t pass the buck)
    • Shared goals and incentives
    • Don’t reward the fire fighter, reward the fire preventer
    • Reward innovation and challenging the status quo
    • Don’t punish people when they try something new but fail
    • There is no IT and “business”.  IT as much “the business” as the sales people.
    • Seeking to break down silo’s
    • “It’s not my job” doesn’t exist
    • “Its my server/code/network/database” doesn’t exist
    • Individuals are empowered to make decisions
    • Top-up management rather than top-down

    People

    • Restlessnes (relentlessly looking to improve themselves, others, processes etc)
    • Good technical ability across a broad skill set (understand as much of other people’s jobs as possible)
    • Everyone can code and use version control
    • Everyone understands the test triangle
    • Dev-test pairing
    • Organised in small product focused teams rather than technology silo’s (align teams to the business not the technology)
    • Common incentive schemes
    • Favour automation and repeatability above anything else
    • CIO/CTO are DevOps biggest guardians & SME’s and seek to destroy anything that affects that  culture
    • Natural face-to-face influencers rather than endless emailers
    • Natural sharers of information
    • Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)

    Process

    • Agile
    • Continuous Integration
    • Continuous Delivery
    • Lean
    • Fail-early, fail often
    • Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
    • All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
    • Knowledge sharing and “just enough” documentation is part of the process
    • Measuring success and failure is part of the process
    • Retrospectives are part of the process

    Technology

    • TDD/BDD everything (including Puppet etc)
    • Everything is in version control (code, automated tests, server config etc)
    • Release automation tooling
    • Convergent desired state tooling
    • Cloud (private or public but the ability to spin servers up on demand)
    • The same trending, monitoring & alerting solutions available through nonprod & prod
    • Application Performance Management
    • Service Virtualisation
    • Continuous Integration
    • Continuous Unit tests
    • Continuous Service level tests
    • Continuous GUI tests
    • Performance testing

    If you can get half way to delivering all of that then I think you should be in a very good place indeed.

    It’s a long hard journey if you are a traditional Enterprise.  Nothing worth achieving was ever easy though!

    I’m outta here for what proved a fantastically successful 2014 (personally and work).  2015 is a massive year too for me but good luck in whatever you have planned ahead.

    Happy New Year to you all!

    J
    xx