staging-devopsy.kinsta.cloud

Category: Features

  • Enter at your own risk: DevOps isn’t for everybody

    Enter at your own risk: DevOps isn’t for everybody

    There’s always a sexy new tech buzzword flying around, and it’s easy to fall into the trap of assuming that if a concept or technology is hot you need to hurry up and jump on board so you don’t miss anything. DevOps is hot, and seems to be almost ubiquitous these days. But that doesn’t mean that every organization should rush out and embrace DevOps.

    Defining what it is exactly that you think you’re embracing can be a challenge. The concept of DevOps is a bit broad and ethereal in the first place. The number of vendors calling their products or services “DevOps” just because it’s sexy marketing muddies the waters and makes it more difficult to figure out what DevOps is, and how it’s supposed to benefit your organization.

    Even if you think you have a fair grasp on what DevOps is, though, it still isn’t necessarily right for every organization. It CAN be right for most organizations, but there’s some introspection, and due diligence that has to come up front. More precisely, it isn’t necessarily right for every organization without a solid foundation of the right skills and resources, and an understanding of what you hope to accomplish, and how you plan to get there.

    Nathen Harvey, community director at Chef, shared some insight on this topic. “Through immense feedback from our community, customers and contributors we’ve learned a lot about how and when an organization should begin a DevOps transition. In short, everyone should not immediately jump on the DevOps bandwagon.”

    Harvey added, “DevOps is full of big ideas and big changes and therefore development and operations teams need to be prepared to work together through challenges and to collaborate toward a common goal.”

    James Bottomley, CTO of server virtualization at Parallels, cautions, “DevOps processes are supposed to be accessible to anyone. However, since current DevOps lifecycles are based on virtual machines, they are really only accessible to those with the skills to manage virtual images and, to make use of the live VM, administer base systems and platforms.”

    Bottomley explains that larger organizations often have the necessary skills available, and just have to marshal them toward a DevOps strategy. Small and medium businesses, on the other hand, often lack the appropriate resources.

    “If you are a SMB you should consider carefully whether you have the necessary Ops skills in-house and if not, how you are going to obtain them (whether from a [service provider] or other form of management). Ongoing Ops skills are vital to proper VM maintenance (fixing security issues and the like), so you have to make sure you have an ongoing Ops capability, not just a one-time one when the virtual system was created.”

    According to Chef’s Harvey, there are three specific areas organizations need to consider before embarking on a journey to embrace DevOps. They are the “Three C’s”: Character, Communications, and Community.

    · Character requires trust, respect, empathy, learning and perseverance.

    · Communication is meant to align objectives—such as setting metrics for everyone, and sitting close enough to easily collaborate with one another.

    · Community can take many forms, whether engaging in podcasts, conferences, sharing code and more.

    Don’t make the mistake of jumping on the DevOps bandwagon prematurely just for the sake of jumping on the DevOps bandwagon. It will be a frustrating experience almost doomed to fail and leave a bad taste in your mouth. Instead, take the time necessary to understand what DevOps means to you, figure out what you hope to accomplish by embracing DevOps, consider whether or not you actually have the skills and resources to make it happen, and develop a plan that includes the “Three C’s” so your DevOps journey can be a successful one.

  • Five essential Ops strategies that help make DevOps the real deal

    Five essential Ops strategies that help make DevOps the real deal

    With its roots in Agile and Lean thinking it’s not surprising that DevOps is often looked at through a development lens. After all, it’s proving absolutely essential to support accelerated delivery times; providing a much needed jolt of velocity to protracted development cycles. But of course with the increased need for speed there’s always the danger that quality can be compromised – so much so that faster time-to-value can very quickly become faster-time-to-failure.

    In what seems like a byzantine age of enterprise computing, IT operations tended to call the shots when it came to delivering quality. Sure, a transactional system might suffer a glitch or two, but since constituents were largely internal and customer’s generally one step removed from the application and business process, the impact could often be controlled. Ah, so much for the good old days.

    But as we know this model hasn’t just changed, it’s been completely disrupted.

    Quality is now a different headed beast that bites hard in many places. It bites when customers engage directly with your brand during discrete mobile moments – like when they compare your goods in the shopping aisle with a mobile app, or assess car insurance based on your ability to provide usage-based policies from their in-vehicle software system. Yes, speed is important in the application economy, but it’s also a high quality customer experience that shapes the winners from losers.

    The fabulous thing about DevOps is the fundamental premise that teams can collaborate in real-time to establish, maintain and continuously improve the quality of software systems and applications. For operations this doesn’t mean waiting for applications to reach production stage before enacting performance management processes. Rather, it involves instantiating best practices throughout the development cycle – that way teams resolve quality issues much earlier in development (where they are cheaper to fix), while also preventing a cumulative buildup of crippling technical debt.

    So with application quality and customer experience being essential for DevOps success, what are some of the ops related strategies we can employ to support better business outcomes?

    I see five essential, ‘rubber meets the road’ strategies ops can use to help DevOps become the real deal:

    1. Focus collectively on the user experience – too often organizations become detached from business reality by looking inside-out from a silo’d technology and diagnostic perspective. DevOps practitioners put themselves in the shoes of the customers by constructing, visualizing and managing end-to-end user-centric service views that traverse functional boundaries. Additionally, user-experience management will involve gaining deeper insights into real-time performance of externally facing applications and mobile services, bringing to the forefront analytics to guide decision making and drive continuous improvement.
    2. Give Developers a clear view of how code works in the real world – operational intelligence shouldn’t wait until applications are moved into production. Rather, it should be instantiated across every stage of the lifecycle – whether that’s during regression and unit testing, or pre-production. Many teams recognize this by for example activating monitoring during release automation; giving developers critical insights into both functional and non-functional code behaviors. Others go further, taking user-experience to another level by exposing key behavioral and usage-based intelligence – especially for newer mobile apps, APIs and digital services.
    3. Create a single source of the truth using a common framework – to be fully effective, developers and operations should reference a single version of the truth when it comes to problem triage and resolution. Traditionally this has proved difficult with teams having discrete tools providing diagnostic insights into one aspect of technology. This however falls short due to the complex interdependencies across technologies and results in finger pointing and blames games when problems can’t easily be pigeon-holed. To address this, operations teams use a common unified framework that quickly discovers and exposes infrastructure and application configurations, and importantly the relationships and interdependencies that exist between them. Now, root-cause can be quickly established from either an application or infrastructure perspective, but always prioritized according to business and customer impact.
    4. Define common goals across teams and use shared metrics – traditionally development and operations teams have been incentivized according to separate goals that are often diametrically opposed (e.g. speed of producing code –v- resilience and availability). By using shared customer and business-centric metrics, developers and operations build a ‘common language’ for evaluating progress and understanding the impact of change and continuous delivery. My advice here is quality over quantity; building out metrics that are actionable by all stakeholders. For example, this could include lead and cycle times to pinpoint operational bottlenecks and waste during deployments, or transaction response monitoring in pre-production to pinpoint code deficiencies and avoid technical debt associated with provisioning unnecessary capacity.
    5. Converge around a common understanding to transcend organizational boundaries – a collection of diagnostic based monitoring and alerting provides little more than vanity metrics and feel-good green lights. Sure, they can alert operations to when something is broken, but they do little to drive the more essential element of DevOps success – feedback. Therefore common understanding involves operations automatically correlating performance information end-to-end so as to expose far more beneficial insights that developers can use to improve the code base.

    At the recent Gartner Data Center, Infrastructure and Operations Management Conference in Las Vegas in December, I presented a session – Unified Infrastructure Management is Critical to Enhancing the Ops in DevOps – that further described these strategies together with supporting use-cases. It was certainly a dynamic and lively session, highlighting the viability of DevOps. As organizations look to increase speed to market of new applications while both lowering cost and increasing quality, DevOps will continue to gain traction, and I can’t wait till everyone truly understands its transformative power.

    About the Author

    ravichandran arunaAruna Ravichandran is vice president of DevOps Solution Marketing and Management at CA Technologies, responsible for cross-portfolio solution marketing for DevOps across all product lines. Before joining CA Technologies, Aruna held several management positions in product marketing and engineering at Juniper Networks and HP. Aruna earned an MBA and master’s degree in Computer Engineering from Santa Clara University and holds a bachelor of science degree in computer science from Bangalore Institute of Technology. Ravichandran is  on twitter @aruna13 and on linked in

  • Optimize app performance with the help of real-time monitoring and analytics

    Optimize app performance with the help of real-time monitoring and analytics

    Back in 1980 there was a movie called Nine to Five—referring to the commonly held perception of a standard work day. Of course, that work day evolved to be more like eight to six (or seven), and now it seems like the concept of a work day—or work hours at all—is a distant memory. In order to keep up with the instantaneous, always-on, connected 24/7 pace of today, companies need to be able to understand how their apps are used, and proactively address issues in real-time.

    That’s where companies like MixPanel come in. MixPanel offers an advanced analytics platform for Web and mobile apps so that developers can keep tabs on when, where, and how apps are used, and any problems that might arise.

    I spoke with Tim Trefren, co-founder of MixPanel. He proclaimed, “It’s easy to build a product. What’s hard is building a good product.” I assume that wisdom applies both to MixPanel itself, as well as to the customers that employ MixPanel to monitor and improve their own products.

    Trefren told me that MixPanel provides a very flexible system that enables customers to track and monitor the metrics that matter most to them. It allows for custom metrics, so companies can choose to monitor elements of apps and app functionality that are completely unique. Customers can also implement A/B alternatives and compare metrics between the two to determine which is most effective.

    Monitoring performance metrics, and analyzing that data to fix or improve apps fits into the broader concept of agile development, and rapid iteration that define DevOps. Trefren explained that some customers also employ MixPanel in an innovative way that also applies to DevOps—to actually monitor operational data.

    Trefren says MixPanel may not be the ideal tool for monitoring operations, but it does enable admins to monitor everything from a single display, and it can be used to alert IT personnel when issues arise. For example, if MixPanel starts logging metrics that show an app is not being used at all, that could indicate that a server is offline.

    MixPanel also recognized that it was in a position to do a little more. It offers a service that analyzes captured metrics data, and enables MixPanel to help companies understand who their customers are. Understanding the audience, and the actions they take (or don’t take) with an app provides valuable demographic data that companies can use to target marketing efforts with greater precision.

    Trefren also told me that he is exceptionally proud of the engineering team at MixPanel. While the volume of data being analyzed has tripled in each of the last two years, the engineering team has only doubled over those same periods. That means that the MixPanel engineering team is working more efficiently, and getting exponentially more done in order to keep up with demand, but that’s another story for another day.

    “The combination of power, flexibility, and performance set MixPanel apart from competitors. We’re able to do more, and do it more quickly,” said Trefren.

    That may be true, but MixPanel isn’t alone. I wrote a while back about similar services from AppDynamics, including its DevOps War Room feature. Clearly, the rapid pace of development, and the sheer volume of apps have created a market for being able to monitor metrics, and measure the performance of those apps in real-time.

    MixPanel offers its analytics as a freemium service. Paying customers are billed for metrics per data point, so the overall cost ends up being a reflection of the volume of data being analyzed.

  • Deliver faster, but don’t sacrifice quality

    Deliver faster, but don’t sacrifice quality

    Developing applications, and deploying servers faster are great goals. Being agile and streamlined can give an organization a clear competitive advantage. However, faster does not equal better, and being speedy for the sake of being speedy can lead to avoidable mistakes. Faster is only better if you can achieve greater speed without sacrificing quality.

    At the same time companies are racing to be faster than their rivals, they’re also dealing with an increasingly complex IT infrastructure. IT environments are becoming highly heterogeneous—merging physical, virtual, and cloud platforms, and combining legacy systems with cutting edge technologies. The challenges of managing such a diverse IT infrastructure simply add to the potential issues that can arise as organizations try to work faster.

    That is where DevOps plays an important role. DevOps tools and technologies establish a process chain between development and deployment. It enables organizations and IT admins to reliably track and understand the components in use, and any changes or updates that occur. In order to achieve speed without sacrificing quality, it’s important to maintain as consistent an environment as possible, and to know exactly what has been changed.

    “For hypervisor based virtual images, this depends on the strict process around handling the images, but for container based virtual images depending on a cascading snapshot mount namespace, where there are layers of images built one on top of the other, strict handling becomes unnecessary because everyone can see transparently (via the image cascade) what changes at each stage of the process,” explained James Bottomley, CTO of server virtualization for Parallels. “This gives everyone in the DevOps chain the ability to verify each step and see the changes for themselves, leading to much higher assurance that the resulting deployment is correctly tested and released.”

    Ken Cheney, VP of business development for Chef, describes another way that DevOps helps boost speed without affecting quality. “Automation turns infrastructure into code. For example, Chef recipes automate all facets of management and orchestration—from provisioning bare-metal and cloud servers to automated configuration and application deployment. You can replace manual, slow, error-prone procedures with code that is versionable, testable and repeatable.”

    “When infrastructure is code you can test it just as you would applications—using automated tests that find problems early, before you release to production,” added Cheney.

    In its 2014 State of DevOps Report, Puppet Labs drew an interesting correlation between speed and quality. Essentially, Puppet Labs found that speed and quality become a self-feeding circle.

    “There’s a virtuous circle at work here: As stability improves, IT performance improves. This improved performance helps to create a better-functioning business that can pay attention to the communications and processes that enhance and improve stability.”

    The converse is also true. Poor quality results in issues, and necessitates allocating resources to troubleshoot and resolve problems, which impedes the speed at which an organization can function.

    DevOps tools and technologies enable organizations to streamline development, and work more efficiently without sacrificing quality. Businesses that attempt to work faster, without also working smarter by using DevOps are putting themselves at a disadvantage.

  • DevOps Transforms Copyright Clearance Center

    DevOps Transforms Copyright Clearance Center

    Copyright Clearance Center (CCC, www.copyright.com) works primarily with business, academic, and medical institutions, enabling them to access the vital content that supports their work. CCC manages fee payments to the license holders and content creators who own the content. DevOps approaches have transformed CCC, a global leader in content rights-licensing solutions, resulting in expanded service to an increasing market.

    “In production, CCC is already processing millions of dollars in transactions. This came to life within a year of the inception date for the DevOps project. For a startup that would be fast. For a medium-sized enterprise, I think that is outstanding,” says Babis Marmanis, CTO & VP of Engineering, Copyright Clearance Center.

    The DevOps transformation that took place in the internal structure of CCC’s engineering department continues today, allowing the organization to respond to the massive disruption in the publishing industry, which is due in part to digital content and the Internet. Using DevOps, Marmanis and CCC have accelerated product development, sped time to market, and provided a stronger consumer experience with the product.

    Accelerated Product Development

    “The Copyright Clearance Center vision is to create the most comprehensive portfolio of global licensing and content solutions (products) that make copyright work for everyone. My product platform strategy stems from that,” says Marmanis.

    CCC has multiple software-based products, each performing the same or similar functions and acting on the same or similar data. “There are certain fundamental things that we must abstract appropriately and encapsulate into common components to make development work optimally,” says Marmanis.

    But when Marmanis came to CCC, there were no common components. And what is more the internal systems lacked interoperability, skills were different across internal teams, and there was no cohesiveness to the development approach. These factors slowed software product development.

    A DevOps mindset was crucial to changing the status quo, to treating infrastructure as code, and to bringing in automation, says Marmanis. A DevOps approach would help to speed the delivery of software projects into the marketplace.

    “Now we use Jenkins (www.cloudbees.com) to glue together elements of the continuous integration process. We have Jenkins build jobs that retrieve the source code from GitHub (https://github.com). We publish software artifacts to Artifactory (www.jfrog.com),” says Marmanis.

    For each release, Marmanis’s teams use Jenkins to execute Chef (www.chef.io) recipes. They deploy artifacts from Artifactory onto a pre-specified execution environment. “In addition, and this is key to the overall scheme, we execute the schema updates with Liquibase (www.liquibase.org), and everything is coordinated with Jenkins,” says Marmanis.

    Further, CCC built its cornerstone platform from the ground up using DevOps-related tools, build detection software, and software libraries. The infrastructure that CCC added is based on best-of-breed open source libraries.

    “Using programming languages such as Java (www.java.com) and Groovy (http://groovy.codehaus.org), Gradle (www.gradle.org) scripts, postgreSQL as the relational database, Liquibase for database objects, Tomcat (http://tomcat.apache.org) as a servlet container, Apache Camel (http://camel.apache.org) for messaging and enterprise integration, and countless other tools including Apache Directory Studio (http://directory.apache.org/studio) and Bootstrap (http://getbootstrap.com/)—the list is very long—we were able to create a harmonious ecosystem,” says Marmanis.

    Stronger Consumer Product Experience

    CCC offers its consumers a better product experience through DevOps approaches and through a homogeneity of standards and technologies, which is available when using open source tools.

    “When we’re building the product platform, these initiatives allow us to embody timeless design principles such as crisp abstractions, but also allow us to scale in a number of dimensions including the number of works that we can represent, the number of publishers we can admit and manage, the number of customers that we have, the number of applications that we can build and deploy, and the number of market verticals that we can occupy,” says Marmanis. This is crucial to customer satisfaction.

    One product that is a prime example of how CCC keeps customers happy is RightsLink for Open Access. “Using RightsLink for Open Access, we facilitate fee collection for articles published under an Open Access license, mediating between the publisher and the author to collect those fees,” says Marmanis. Then CCC aggregates those transactions and presents them to the publisher.

    “Obviously, we give the money to the publisher, but we also create reporting for the authors, publishers, and institutions as well as the founding agencies that gave the money to the author or the institution respectively for funding that research,” says Marmanis. The RightsLink for Open Access product keeps transactions simple, integrating with publisher workflows to expedite publication.

  • Equalizing IT infrastructure with DevOps

    Equalizing IT infrastructure with DevOps

    IT is getting more complex. Managing on-premise servers, cloud servers, and hybrid environments that span various operating systems and standards creates challenges for IT admins. DevOps technologies and platforms, however, can be an equalizing force among the cloud chaos—making it easier for organizations to deploy servers and applications quickly and consistently regardless of platform or environment.

    Once upon a time most organizations were fairly standardized. Servers were located on-premise in some sort of closet or data center, and IT admins knew exactly what operating system they were working with. Now, those servers may be physical or virtual, on-premise or in the cloud, Windows or Linux, Azure or Amazon, and in many cases IT admins are dealing with an infrastructure that amounts to an all-of-the-above approach.

    As the name implies, the core of the DevOps movement is to remove the barriers between developers and operations. Many of the tools and technologies that comprise the DevOps movement, however, also have the added benefit of providing a consistent, modular approach to developing and deploying applications and infrastructure. Those technologies also reduce friction between on-premise and cloud environments, and allow organizations to streamline operations across different platforms and operating systems.

    “One of the biggest reasons for the increased interest in DevOps tools and practices is because businesses have to move and iterate faster today than at any other time in history,” declared Tim Zonca, director of product marketing for Puppet Labs. “So IT teams are pursuing DevOps flows, where development and operations practices, systems, and tools work in lockstep.”

    As IT infrastructures become more complex, DevOps becomes more crucial. Expansion of IT across physical, virtual, and cloud environments make even minor inconsistencies into critical issues as organizations grow, and brings additional burden to address those problems.

    Many DevOps technologies revolve around using virtualization to deploy applications inside pre-built environments, or modular blocks that can be deployed and re-used across various platforms and environments. These tools remove most of the chaos, and enable organizations to simplify deployment across virtually any infrastructure.

    Docker is a great example of the impact DevOps is having. Docker containers enable developers to package an application, and transport it anywhere Docker containers are supported without modification to the virtual environment. As Docker continues to spread influence across Azure, Parallels, and other cloud and virtual platforms, it is asserting itself as an equalizing force that eliminates the need to even care what the underlying infrastructure or operating systems are.

    Puppet Labs is another illustration of the equalizing force of DevOps. Zonca explained, “Puppet makes it easy to standardize and add consistency to your infrastructure so you can make fast, repeatable changes across physical and virtual machines, on premises or in the cloud. Because these tools create a predictable environment, you don’t have to worry about a simple update taking down an entire system your business relies on.”

    James Bottomley, CTO of server virtualization for Parallels, suggests that even DevOps has its limitations, though, and that it could eventually get in the way of advancing productivity. “However, one cannot help thinking that DevOps, while a leveler, is also a separator because it is only accessible to developers with the Ops skill, not to all developers. Additionally, the utility of DevOps depends upon the availability of Infrastructure and, while IaaS is clearly the dominant Cloud technology today; it won’t be forever. At that point, one might imagine that the DevOps technique might impede rather than assist the next paradigm shift in the cloud.

    For now at least, DevOps technologies enable developers and IT admins to take a modular, platform-agnostic approach to many aspects of applications and infrastructure to simplify and streamline regardless of the underlying environments or operating systems.

  • Top 5 DevOps and Operations Challenges in 2015

    Top 5 DevOps and Operations Challenges in 2015

    DevOps and operations teams are under increasing pressure from tech-savvy, app-centric business users to collaboratively solve complex business problems with IT. Adding to the battle, the pursuit for the perfect synchrony between software development and IT operations is still ongoing, and striking the balance won’t happen any time soon. New tools, technologies and processes change and grow at a problematic pace – leaving us with no option, but to accept and address all upcoming challenges.

    Teams must keep up the pace to succeed, but operations teams cannot handle it solo and must work closely with DevOps.  The operations group is responsible to drive flawless, organization-wide execution – this was a straightforward request when the systems were configured and maintained by operations. However, recently, development became more collaborative, with involved users demanding more, using the newest tools and making the process harder to manage. Additionally, the product environment of business users has rapidly moved to portable devices, which are self-contained and hungry for enterprise-wide cloud services. This shift has created five principle challenges. These are my top 5 DevOps and Operations challenges for 2015:

    Challenge 1: Building the DevOps Culture

    Culture is an abstract group of ideas and behaviors, which makes it hard to identify a standard collection of requirements. It is much easier to decide which tools to use and how to use them in the most efficient way. Tools are material objects, but the people who use these tools are much more complex and difficult to change. As DevOps is all about continuous change – including reconfiguring a company’s core culture – there is a steep hill to climb.

    Replacing traditional development and operations silos with cooperative teams of people from both camps can only get us so far. While DevOps is supposed to intentionally foster collaboration and results-driven effort, it needs the support of operations. Until operations can identify how to embrace the new mentality of culture-fostering activities into its daily regimen, there is no way to help this aspect of DevOps grow.

    Challenge 2: Meeting the Quick-Fix Tool/App Mentality

    While most end users now rely on a wide palette of tools to get their job done, they often circumvent the IT department to get the tools they prefer. As many are open source or offer initial trial versions, unsanctioned tools can be adopted without any internal oversight – leading to major issues down the road.

    Making matters worse, business users believe everything can be solved with an app, but that is often untrue. While it is the overwhelming consensus that every tool should have an easy-to-use app, making the app a useful, secure one is much more complex. Even if there is an “app for that,” it must be properly integrated to back-end systems as part of the cohesive enterprise infrastructure. DevOps must balance tool delegation and management early on.

    Challenge 3: From Legacy to Cloud

    Technology-savvy business users may want to use the latest tools, but that is a tall order for operations. When it comes to DevOps tooling and configuration management, there is still a lot of confusion as to which tools do what, and how they play with each other – if it all. Tools need to be compatible with existing solutions and technologies used by the company, and that is becoming increasingly complex with the rise of hybrid environments.

    New hybrid environments include on-premise tools, IaaS tools like Amazon, Google or Azure, PaaS compute services, and SaaS business applications. Somehow, DevOps must ensure that they all work well together and deliver a seamless experience for the business user.

    Challenge 4: Networking

    Network engineers – if they are applying automation at all – are either doing ad-hoc scripting or tap a dedicated software engineering team to build homegrown systems for their use. Inflexible networks run rampant in today’s IT environments.

    Looking for an example? Even vLANs have a spider web of interdependent IPs, ports, routers, routing tables and perimeter networks. Changing, breaking, moving or replicating any part of that intricate web often seems impossible.

    Challenge 5: Marginalized and Changing Budget

    Taking another perspective: Will customers pay more for network automation tools from the equipment vendor to make the networking user experience better? If a networking customer is spending a lot of money on the physical equipment, they often do not want additional software tools from the vendor, even if the network engineers do. The gap between the network engineering teams that need the tools and the decision makers who pay for them is widening.

    While capital expenses may be separate from operational ones, CAPEX spends are now often mirrored by OPEX ones. Trying to quantify spend on an on-premise project management tool with a SaaS application is a major headache that can no longer be left solely in the hands of the CFO. This shift impacts the structure of IT budgets – it could even take away IT’s control if OPEX spend becomes more distributed.

    What can be done to overcome these growing problems? Taking the following five steps should help you start off 2015 in the right direction.

    Collaborate Wisely:

    It might seem to get a little tense at times, but open forum discussion is well worth it. Collaboration allows teams to learn from each other and suggest possible solutions. It also encourages critical thinking and creativity. When you have different people working together on a project, you get more expansive creative input. To manage the potential leadership glut (i.e., the excess of people trying to lead the group and not that many willing to slow down and focus on a specific task), break the traditional decision-making process chain and turn it into a continuous flow of fresh thinking and ideas.

    Empower Users:

    Let your business users pick their own tools, but make sure that they report them to you. It’s a good idea to consider a library of vetted tools available for them to pick from. Encourage business users to suggest new tools so they have a sense of decision power. However, keep the tools current and make sure they actually address user needs.

    Speak Accounting:

    Try not to let OPEX issues become obstacles in tool adoption. If IT can help finance understand what is going on in the world of technology licensing vs. cloud service, it can fast track the inevitable shift, and ease budget reporting and bottlenecks.

    Break the Immutable Network Infrastructure:

    With immutable network infrastructure, you run the risk of being locked into vLAN and physical devices. What is the solution then? Leverage advanced virtualization tools (i.e. converting legacy systems to virtual machines) and take Software-Defined Networking (SDN) on board. With a centralized, programmable network that can automatically and dynamically address changing requirements, you can reduce both CAPEX and OPEX by enabling algorithm control of the network and use ASIC-based networking hardware supporting pay-as-you-go models. Deliver agility and flexibility by helping organizations rapidly deploy new applications.

    Prioritize Analytics:

    Analytics should make IT’s life easier. Build analytics and monitoring into everything from the start and think about it as “making sense” of the data or logs being collected. This information helps IT determine the true business impact of a performance issue to better prioritize where and what to troubleshoot. A strong analytics platform, where all application and tools data can be stored, gives operations the systems visibility it requires. Become a facilitator while maintaining all needed operations practices.

    There will always be challenges ahead as we work to get smarter/ faster and develop better systems and applications. However, the right analytics tools and collaborative processes designed for cloud-enabled, distributed environments can make 2015 much easier than years past.

    About the Author

    trevor-parsons-300x300-304xx300-200-0-26 copyTrevor Parsons, as chief scientist and co-founder at Logentries, Trevor Parsons is responsible for product strategy and direction. He works closely with customers and partners to continuously understand what they need, and to validate product market fit. Trevor also leads the product management and UX teams and assures the best possible user experience. Trevor enjoys speaking at local dev ops meet-ups and events, and is always looking for how log data and analytics can be applied in more and more powerful use cases. Trevor was a post doctoral researcher and member of the Performance Engineering Lab at the School of Computer Science and Informatics in University College Dublin, Ireland. He received a PhD from University College Dublin for his thesis titled “Automatic Detection of Performance Design and Deployment Antipatterns in Component Based Enterprise Systems.”  You can follow Trevor on Linkedin and Twitter at  https://www.linkedin.com/in/trevparsons and https://twitter.com/trevparsons.

     

  • How DevOps Eases The Holiday Shopping Experience

    How DevOps Eases The Holiday Shopping Experience

    “I have been building retail software for 15-years,” says Harper Reed, CTO, Modest, CTO emeritus, Threadless, and former CTO, Obama for America. “With the advent of DevOps, development is now about how we can make the online experience better for the customer,” says Reed. It used to be about taking care of the systems.

    Today, the infrastructure is in software with Amazon and the Cloud, with what DigitalOcean is doing with Docker, and with what CoreOS is doing with server deployments. Before cloud-based infrastructure, the enterprise used the data center, which was a fortress that operations had to protect. It wasn’t as easy to think about the customer with those kinds of concerns to look out for. Now everyone has time to think about the customer.

    “With the cloud, you can start to have the same lifecycle with infrastructure that you had with the software that actually ran your ecommerce,” says Reed. Teams can leverage a uniformity of tools for measuring performance. Because everyone is using the same tools, it becomes easier, more uniform, to test the software. “We can all be thinking about the user,” says Reed.

    With DevOps, infrastructure in software is making the online Holiday shopping experience easier by scaling up in the cloud using very simple scaling rules. “In 2007, 2008, I was CTO of Threadless and we had very good software, but we had to plan months ahead in order to scale things up during the Holidays,” says Reed; “today we don’t have to think, what is our capacity going to be, how am I going to add 15 more servers? We just turn up the budget on Amazon and away it goes.” Of course, scaling keeps shoppers from experiencing server time-outs and slothful transactions.

    Because scaling is already addressed, teams can focus on development efforts on the front end, on making the user experience better. The time teams would have spent scaling the back end they now spend ridding bugs and adding and improving services and features, and doing it all much more quickly thanks to continuous deployment.

    As a result of a stronger commitment on the front end, efforts become possible such as you see today where stores like Everlane , an online clothing retailer has partnered with Postmates, an on-demand delivery service to drastically cut order delivery times, including same day deliveries http://blog.postmates.com/post/104856354257/powering-on-demand-logistics using Postmates API.

    “I visited a pretty well-known ecommerce startup in the Valley a couple of weeks ago. I can’t name the company, but their technology team had zero ops people because they are able to manage all of the ops that they need through software,” says Reed. This retailer hires developers who handle the ops and they don’t have to split their team up, which means more people are building better features.

    They’re not spending their time managing hardware sitting in a data center somewhere. They don’t have to manage their bandwidth consumption as much. “They can do it through a control panel in software rather than by making calls to a data center,” says Reed.

    And the faster the ecommerce site is, the better the conversions will be. “If your site is very quick, which goes hand in hand with scaling and how you handle capacity, the better the experience will be for everyone from the consumer who is purchasing the products to the retailer selling them to the shipper shipping them out,” says Reed. This all adds up to increased customer satisfaction.

    Through continuous integration / deployment, DevOps is able put customer feedback into action very quickly, creating and testing fixes to customer experience issues, which teams can then immediately deploy. “Since we started using DevOps concepts in development, the product development cycle has decreased the time it takes to get things done and into the marketplace,” says Reed.

    Before if you were a user and you reported a bug, the enterprise might well have said, “well, okay, we’ll get to it after the Holiday season because we don’t want to change anything at this critical time for fear of introducing more issues”. “Now,” says reed, “we’re able to do some testing and make sure it works and that it’s the right path for us. We’re able to get there very quickly and then we can make a more educated decision on whether now is the right time to make the change.”

    Further, the online retailer has the opportunity to consider whether making the change immediately might save a significant amount of sales that would have been lost.

  • Clearing through the app backlog clutter

    Clearing through the app backlog clutter

    Development and operations teams today are under more pressure than ever to develop apps the business needs to make its workforce productive, its partners connected to the resources they need, and to deliver the apps to the marketplace that will make it competitive.

    The number of production hours for development is at a precious premium as demand for apps soar and resources remain tight. According to Gartner, the demand for enterprise mobile apps alone will be a $40 billion market by 2016.

    Of course, the inevitable happens and the list of designed applications gets backlogged. They get caught-up in budget requests that drag on, and then they get caught in the long list of requested apps in the development queue. A recent survey commissioned by PaaS provider OutSystems found that 85% of enterprises surveyed had an app backlog, with about half having backlogs of 10 to 20 apps.

    App Backlog, agile and DevOps

    Sure, development and operations teams move as quickly as they can to meet the enterprise demand for new applications, but when there is any deep app backlog, there is the potential for business costs when it comes to lost opportunity, untimely product development, and future missed sales. In a time when agile IT means competitive advantage, any amount of latency that can be cleared from the application backlog is crucial.

    Agile development approaches and agile IT departments tried to remedy some of these issues, but didn’t go far enough. Fortunately, DevOps picks up where agile left off in the evolution of enterprise development. And in the face of agile IT, continuous integration, continuous deployment, and the rise of DevOps – operations, development, and infrastructure bottlenecks become minimized – and infrastructure and applications move more quickly, and existing applications are iterated more swiftly.

    Of course, DevOps itself, can help to accelerate app deployment, in addition to continuous integration and continuous deployment efforts. And all of the associated deployment automation tools and deployment processes are essential to eliminating manual waste so teams can focus on pressing business demands. This waste can include time burnt on manual process, manual testing, and the configuration of the software development environment.

    DevOps-driven organizations have shorter app backlogs. A recent CA Technologies study in fact found that organizations embracing DevOps report a 17 to 23 percent improvement in certain business outcomes, such as increased revenue, and faster time-to-market.

    Cloud architectures and easier to master development languages also help, not just infrastructure services, but also platforms that help to free up operations teams and developers to focus on the applications that need to get out yesterday.

    Even with DevOps practices in place and automation running full throttle, the business development teams still find themselves having to make difficult choices about which apps to build and deploy. Not all of these apps will survive, in fact, many apps will go unused and dormant. This means that a lot of time can be lost developing apps people don’t want to use, or are too cumbersome to bother to use.

    Turning to the Minimum Viable Product

    In addition to DevOps, development teams are also turning to approaches such as the Minimum Viable Product (MVP) as a way to help identify apps that have real user demand and those that do not. Essentially, the MVP app is an app that consists of only the essential. The MVP provides the essence of the app and what users need to get done and no more. The MVP is a potent way to provide the essential attributes of an app to see if users embrace it before building the app out further. If the app is used, new features can be added over time.

    Not everyone is convinced that the gains made against app backlog aren’t necessarily illusion. David Mortman, distinguished engineer, says “DevOps and MVP both have the ability to create the impression that you are solving backlog issues. This is because in both cases you are enabling the development organization to get that first release as early as possible and then to keep iterating it and adding features as the dev group goes,” he says. “This however may not get you to a particular defined endpoint any faster since regardless of the organization there are always resource limitations.”

    Still, “One advantage of DevOps and Agile is that they let you interweave development cycles so multiple apps can be worked on faster and each can be incremented more quickly. They also make it easier to adjust priorities between apps more quickly and more quickly identify apps that aren’t meeting the business needs and either deprioritize or eliminate the app before overinvesting in its development,” Mortman adds.

    There’s no doubt, based on my discussions with enterprises, app backlog repeatedly comes up as a serious challenge to competitiveness. But by embracing continuous integration, deployment, and MVP development, organizations can go a long way to help clear through, at least the initial stages of their app backlog. What is your organization doing to help clear app backlog? We’d like to hear your experiences and lessons learned.

  • Four strategies for supporting DevOps collaboration

    Four strategies for supporting DevOps collaboration

    As we’ve discussed before, the ever elusive DevOps culture doesn’t form magically. Rather, it is fostered by building a collaborative environment. While there are many ways to skin the cat in terms of what kind of tools organizations use to start collaborating more effectively, the tool set and the process they enable should revolve around some key principles. The following strategies can help guide organizations to choose the right infrastructure to foster a transformative DevOps culture and support DevOps collaboration.

    Centralize And Unlock Knowledge

    One big mistake some organizations make as they embrace DevOps is they consider their automation tools as knowledge repositories. But things like recipes, manifests and YAML files are great for automation, not collaboration, explains Alan Sharp-Paul, CEO of ScriptRock.

    “They are an awful way of storing desired state,” he says. “Desired state should be visible. It should be easy to understand and simple to modify by any stakeholder. If the systems that define your desired state are not open and accessible then collaboration will suffer. When knowledge is locked up, collaboration breaks down.”

    Sure, there may not be a super platform for everything, but centralize documentation with pointers out to the right details, says Chris Clarke, senior vice president of product management for CollabNet, who suggests that this place should show how work is spawned and what is being asked of whom, where work is being outputted, where to find all of the tools being used across the development and deployment lifecycle and visualizations, diagrams and step-by-step details about important processes.

    “It’s almost like a mall map. ‘You are here,’” Clarke says.

    Enable Timely Communication

    Of course, knowledge doesn’t stand still and there are always day-to-day snags that come up, so constant communication is fundamental to the collaborative process.  Many DevOps and Agile leaders find the success they see in speeding up iterations stems around the experimentation they’ve done in developing a communication channel that work for their teams.

    This usually starts with using a chat platform like HipChat, FlowDock, or Slack, and frequently continues by pairing that with task managers like Trello, Asana or Basecamp.  Many organizations are also integrating IT-specific tools like Git, PagerDuty and Raygun into this mix.

    And, increasingly, DevOps teams have been up-leveling that by implementing GitHub’s open source side project, Hubot, a chat room automation bot that helps teams share scripts,  automate tasks and enable simple deployment tasks and keep everyone else apprised of deployment.

    The sky is the limit for creative combinations—the key is that the overall stack facilitate timely and meaningful communication across the team.

    Find Ways To Visualize Technical And Process-Based Interdependence

    So, what about SharePoint to accomplish these goals? The problem with SharePoint, says Matt Selheimer, chief technical evangelist for ITinvolve, is that it really isn’t designed around the workflow and the dependencies of IT-specific work. As he explains, most organizations never get beyond the stage of using SharePoint as a glorified file share.

    “That’s not going to help you understand risks and relationships and dependencies and nobody has time to go and read through all those documents and try and parse them anyway,” he says, explaining that a collaboration platform should be able to help various employees track activity around applications, policies, servers and what have you that they have a stake in. When someone else is touching those specific objects, they should be alerted and connected with the resources necessary to look into potential issues, resolve any problems that arise and potentially suggestion improvements on current progress.

    Componentize Knowledge

    Centralization is important, but that doesn’t mean that knowledge should necessarily be consolidated.

    “You need to componentized it correctly—in other words, you don’t try to write a 40-page document, you use a wiki or something that should change pretty frequently,” Clarke says. “I’m a huge fan of continuous improvement in everything, including this.”

    Selheimer agrees.

    “We don’t think that trying to capture everything in one giant, massive document and have it be reviewed by a committee is effective because it’s never going to get published  It’s going to be outdated,” he says. “Whenever I ask people about what diagrams do they have to use to manage their environment, they always say, ‘Oh, we got Vizios.’ But they’re all six months out of date, right?”