devopsy.kinsta.cloud

Category: Features

  • JumpCloud launches new Directory-as-a-Service offering

    JumpCloud launches new Directory-as-a-Service offering

    The cloud is a great equalizer that enables startups and smaller companies to scale quickly, and play on a more or less even playing field with larger organizations. Managed cloud services free businesses up from implementing, configuring, and maintaining the underlying infrastructure, and allow individuals to focus on the business. With all of the freedom cloud services provide, though, there is still a need for a directory service that defines who the users are, and controls which individuals have access to which resources. JumpCloud wants to move that to the cloud as well.

    JumpCloud has established itself as a leading solution for managing security across a vast, rapidly-changing, virtual ecosystem in the cloud. Today, JumpCloud is announcing a new offering that takes builds on that foundation, and applies its experience to deliver Directory-as-a-Service (DaaS). JumpCloud claims its new service will allow organizations to stop managing directory services locally, and enable them to move to a fully-managed, cloud-based alternative to LDAP (Lightweight Directory Access Protocol) or Microsoft AD (Active Directory).

    “As we have seen with the transitions from Siebel to SalesForce, Exchange to Gmail, and file servers to DropBox, JumpCloud is enabling the transition of one of the last on-premise technologies to a fully managed service: the user directory,” says Rajat Bhargava, JumpCloud’s President and CEO in a press release statement. “Directory-as-a-Service brings IT teams the simplicity, ubiquity, and security of user and device management, all from the cloud.”

    The JumpCloud DaaS services can act as the sole user store for an organization, or it can extend existing AD or LDAP user stores to the cloud. JumpCloud DaaS also integrates with single sign-on (SSO) providers so that IT admins are not forced to manage multiple directories.

    “JumpCloud understands the need for directory services in the cloud,” said Salvatore D’Agostino, CEO of IDmachines. “Building on their secure shell configuration management tools, this offer puts in place cloud-to-machine, user authentication and other directory services. At IDmachines, we see this as a big need in current XaaS.”

    JumpCloud DaaS promises to help organizations be more agile and more effective whether they’re just implementing a directory service, extending an on-premise directory service to the cloud, or migrating locally-managed directory services to the cloud.

    A cloud-based DaaS offering makes sense. No matter what size an organization is, managing the user directory through local, manual processes is an obstacle to realizing the full benefits of other cloud services. It creates complexity, and introduces reliability and security issues. Cloud-based services need a cloud-based directory service—a directory service that can keep up in terms of availability, scalability, and flexibility.

    JumpCloud DaaS—like other managed cloud offerings—takes the burden off of local IT to manage the backend of the directory services infrastructure, and places it on JumpCloud. Customers can focus on building things, and authenticate and authorize cloud infrastructure, servers, applications, users, and devices.

    JumpCloud’s Directory-as-a-Service is available immediately. Pricing plans start at $10 per user per month, and the first ten users are free forever. JumpCloud supports the LDAP protocol and works with Windows, Mac, and Linux devices.

  • Top 3 must-haves in Dev/Ops project handoffs, Part one

    Top 3 must-haves in Dev/Ops project handoffs, Part one

    There isn’t much that makes IT operations happier than receiving that brand new application neatly boxed, wrapped, tied with a bow, and outfitted with exhaustive instructions for every what-if, what-then, and what now scenario.

    Before you give the gift that keeps on giving in all the wrong ways, take these top three must-haves in developer to IT operations project handoffs to heart.

    Number One Must-Have: Define Normal and Abnormal Operational Conditions

    What does the development team consider normal operational parameters? At what point does the software break? How? If, giving an extreme example, at 20K users per server IT operations should expect ~50-70% CPU load but at 2K users per server they should not see 100% CPU load, they need to know this.

    “Development can outline similar behavior/symptom scenarios for infrastructure (CPU, MEM, DISK, NETWORK) and application-specific (USERS, SESSIONS, USE LATENCY, TIME BETWEEN ACTIONS) metrics,” says Ivo Vachkov, whose title is literally DevOps Engineer, Xi-Group Ltd (Bulgaria; www.xi-group.com). This is the kind of information that helps operations to recognize when a software component is in trouble.

    This may sound like obvious information for developers to include in an application handoff. “But many developers (if not most) will not be able to precisely define what is the normal operational condition for their software,” says Vachkov, lecturer in networking and programming security, New Bulgarian University (http://nbu.bg/entrance.php).

    IT operations needs to know about factors that affect normal operation including whether the software is CPU-bound, i.e., whether its performance is directly related to the processing power of the computer it runs on. Another such factor is whether the application is IO-bound, whether its performance is directly related to the throughput of the IO (MEM, DISK, NET) subsystem.

    Development should prep operations about other software behaviors and risks. If the application will degrade gracefully under increased load, they need to know that. If it will come to a screeching halt under load, they need to know that even more. If the software will crash when it slams up against an administrative/technology timeout, operations can deal with it, if they know ahead of time.

    “As operations people, we usually don’t expect too much. I would usually be happy to know that at 50k users per server the main process will crash. And this is OK, because I can work around it. I have the tools to prevent a breach of that limit. I would be happy to know that every night there is a batch processing that will hit the DB hard, instead of being awakened by an alarm about my DB being inaccessible,” says Vachkov.

    Number Two Must-Have: Share the Known/Collected Technical Debt

    In many cases the technical debt is not obvious, i.e., the documentation states that the component needs library X to work properly, but due to some particular reason, the developers used a specific version of the library that is not available in the default package repository of the OS. Someone needs to build it in manually and take additional care to keep the configuration in sync to make the code work. “Technical debt may have many faces, from bad/rigid pieces of code to bad algorithms to unspecified dependencies,” says Vachkov.

    Technical debt is also commonly omitted by the development team. “Pride, politics, other considerations are in play here. Many developers will just not keep track of technical debt. But this is crucial for proper operations. I want to know the shortcomings of the piece of code I’ll be dealing with,” says Vachkov.

    IT operations wants to know, for example, whether that key algorithm is O(n) instead of O(log n) because this will enable them to correlate metrics and explain what’s going on. These notations are part of Big-O Notation, which is used in mathematical and algorithmic analysis and generally represents a function that describes the upper limit of performance of a particular piece of code in relation to the number of input elements it needs to work with, according to Vachkov.

    Cliffhanger!

    This concludes part one of “Top 3 Must-Haves in Development/IT Operations Project Handoffs”. Tune in for part two when we take up with technical debt and Big-O Notation, learn more about why the Big-O is so important to operations and to corralling unwieldy software, and discover the third and final must-have in development/IT operations project handoffs. Don’t touch that mouse or touchscreen! Stay tuned to www.devopsy.kinsta.cloud.

  • Harvard Business Review Survey: IT responsiveness predicts business success

    Harvard Business Review Survey: IT responsiveness predicts business success

    Increasingly, the C-suite is finding that the speed with which companies today are able to take advantage of new technology and exploit their IT operations determines the success of the entire business. A new survey out by the Harvard Business Review and Oracle this week shows that IT responsiveness stands as a huge arbiter of overall business agility, which starts with CIO leadership and trickles down into the way organizations leverage processes and technology. The results can be seen as a testament to why DevOps practices are gaining momentum in so many organizations, as respondents report a nearly one-to-one relationship between IT’s ability to react to business demands and overall business performance.

    “Leaders are focusing on speed and broadening their view of where IT begins and ends,” the report explains. “They’re rethinking roles and relationships—and their own value proposition. And they’re making sure their company doesn’t miss opportunities because the IT department was too slow to respond.”

    However, many companies are experiencing just this pain. Nearly half of respondents reported that their companies have missed opportunities because their IT department was too slow to respond to shifting business needs. And approximately 49 percent reported that a lack of bandwidth in IT is the primary obstacle of the organization to take advantage of digital technologies.

    Conversely, when IT organizations are able to quickly move on line-of-business needs, bottom line success follows. Among those respondents who identified their companies as having responsive IT organizations 42 percent strongly agreed that their IT departments were highly successful at leveraging new technology for business advantage. Only 10 percent of those with moderately responsive IT could say the same.

    This most recent finding bolsters another study out this year by Puppet Labs, which showed that high-performing IT teams using DevOps were more than twice as likely to exceed profitability, market share and productivity goals over more traditional IT shops, and they also had 50 percent higher market capitalization growth over three years.

    The advantages of IT agility comes in many forms according to the Harvard Business Review study. For example, 68 percent of high performance IT organizations reported new technology had an impact on customer engagement, 64 percent said the same about work processes, 62 percent said new tech impacted product offerings and business models, and 59 percent reported new technology positively impacting core business operations and processes.

    According to the survey, performance is highly dependent on IT’s ability to prioritize investments, a capability that a third of organizations do not have. Similarly, collaboration within IT and with line-of-business staff is another bellwether. The survey showed that only 21 percent of respondents believe that the IT organization alone primarily drives digital business innovations. Aproximately 40 percent say that it is actually an equal mix of IT and other business input, while 34 percent say the business primarily drives the technological innovation. However, organizations have a ways to go on the collaboration front. Approximately 42 percent of organizations report that they have a poor track record of facilitating collaboration across IT and business functions.

     

  • Collaboration in Progress: Making DevOps a Reality

    Collaboration in Progress: Making DevOps a Reality

    Everything on your company’s DevOps checklist is accounted for. It’s got the vision and the talent. It’s identified the problems and mapped out a solution. It’s got a culture that allows the flexibility that such a plan requires. Now’s the time to put the plan into action and let the benefits begin.

    The truth is that it may not be that simple. A great plan won’t mean anything unless everyone understands how to achieve it. And whatever a company’s DevOps strategy consists of, collaboration is the key to making it a reality.

    Collaboration is at the heart of DevOps. It’s even conveyed in the phrase itself. No matter the size of your company, this new process of teamwork and transparency relies on combining strengths between Development and Operations to achieve goals that otherwise wouldn’t be possible.

    Breaking Silos with a Full-Circle Approach

    With one department responsible for writing code and another responsible for implementing it, silos can naturally form as each group focuses on its job. This kind of structure is what commonly gives rise to software deployments taking longer than they should and even little or no communication taking place between the two departments.

    DevOps has come about as an antidote to these kinds of siloed situations in which inefficiencies and a lack of teamwork are the norm. Yet for DevOps to take off, both Development and Operations have to participate fully and understand that collaboration requires equal cooperation from both sides. Such collaboration has to take place not just at certain stages, but throughout the life of a project. When each team is invested in the effort by providing feedback, helping identify future problems and continually learning from day-to-day deployments, a company has a great chance of seeing benefits from these new collaborative efforts. Without complete buy-in from everyone, the process will never get off the ground.

    The Evolution of Collaboration

    Just as DevOps is about moving beyond the assembly line process of software development, the concept of collaboration itself is evolving. DevOps-style teamwork can consist of more than breaking down the silos between different teams. In an agile infrastructure, team members can wear different hats and swap responsibilities depending on the demands of the day. Instead of a scenario in which people work on single specialized tasks without any interaction with the larger group, you’ll have contributors who can play multiple roles within a team and understand how this boosts productivity for the entire company, rather than just a single department. It’s possible that a team member can function as a developer one day and then work on deployments another. Through DevOps, an organization can advance beyond one-dimensional departments and one-dimensional contributions.

    Real-World DevOps Teamwork

    For many within the IT industry, DevOps is already a working reality. Breaking silos and becoming more agile are goals for companies that know how increased collaboration can help their business. A good source that lays out some first-hand experiences of DevOps practitioners can be found in the recently published Rackspace e-book, The DevOps Mindset: Real-World Insights from Tech Leaders. It features interviews with IT experts who discuss what led them to adopt a DevOps approach and recommendations for those interested in a new agile approach to software deployment.

    When discussing the importance of agile teamwork, James Kenigsberg of 2U remarks that, “To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only.” As a provider of online university programs, 2U faces a huge demand for quick, dependable deployments and underwent a transition to increase teamwork at the company. “We had to flip the model,” Kenigsberg explains, “from the idea of personal heroics and siloed responsibilities to real, cross-functional collaboration.”

    Jim Kimball of fund administrator HedgeServ reiterates this cross-departmental approach. “Repeatability and scalability are our business,” he explains. “The capabilities that DevOps gives us directly enable this by encouraging collaboration within the organization to come up with better solutions.”

    Forging a Partnership Between Dev and Ops

    Assembling a skilled and talented group that will be the envy of your industry is the ideal every company would like to have. If you’re able to gather a team that’s the IT equivalent of the X-Men, it’s not enough to just assemble that talent and assign them siloed roles. Without frequent teamwork, not only will company goals become difficult to achieve, but solving problems will be nearly impossible.

    When Development and Operations see themselves as working in partnership with each other, the foundation for greater collaboration will be in place, and company goals, such as greater speed to market, increased productivity and an all-around agile performance, will be within reach. With the right mentality, DevOps can be an evolutionary step in company functionality and reach new levels of efficiency that otherwise wouldn’t be achievable.

  • Fighting federal agencies culture shock to get over cloud and DevOps hump

    Fighting federal agencies culture shock to get over cloud and DevOps hump

    As federal agencies face budgetary pressures that drive them toward more agile IT pushes around cloud deployment and DevOps practices they must first tackle big perceptual and cultural roadblocks. Case in point is a survey out last week that showed that 89 percent of federal IT professionals still feel apprehension about migrating to the cloud, with 43 percent saying that it felt like giving their son the keys to their new convertible.

    Conducted by government research firm MeriTalk on behalf of NetApp and Arrow, the study shows that only 44 percent of agencies report having mature data governance practices in the cloud, and cite data exceptions, data integration, and collaboration and interoperability as their top challenges. Security still tops that list, though, with just one in five IT pros completely confident in their cloud vendors’ security.

    Interestingly, just a third of agencies met the June deadline this year to make sure their cloud solutions meet the security criteria laid out by FedRAMP. Among those who didn’t make the deadline, another third plan to do so within a year.

    The push to do so could present opportunity to work on the associated applications and cloud integrations with a new approach that could potentially embrace DevOps principles. For example, IT staff at the National Renewable Energy Laboratory recently used its initiative to gain FedRAMP compliance for its AWS integration as a chance to establish a DevOps pilot program.

    According to Keith Trippie, executive director for enterprise system development at the Department of Homeland Security, federal agencies’ ability to improve through DevOps, security and cloud deployments will all play important roles in improving time to value for citizens.

    “I look at the budget challenges we have today as a change agent for the government. It’s going to force us to innovate quicker than we have,” Trippie says. “It’s part of a healthy IT diet, where we’re looking at DevOps, we’re looking at continuous assurance on the security side, we’re looking at cloud in commodity IT, which will enable us to provide services more quickly than we have before.”

    On the cloud front, one of the big ways agencies can drive more safe deployments is through better governance. According to the MeriTalk survey, 52 percent of organizations don’t have well-understood data integration, 50 percent don’t have defined data owners and 49 percent have no known systems of record. The survey showed that the more mature organizations were in improving data governance programs, the more likely they were to be comfortable with turning over IT services to cloud vendors.

    The cultural stodginess and lack of groundwork laid by federal agencies to make cloud migrations possible could also potentially prove the biggest stumbling blocks for federal DevOps deployments.

    “The federal government will have to call into question some well established practices in order to implement DevOps,” wrote Mike McGarr of Netflix recently.

    A current engineering manager for the Netflix Build Tools team, McGarr previously worked as a federal government contractor. He advises agencies to avoid the sales people who will try to sell DevOps in a box and take a deep look at processes both within the agency and contractor organizations.

    “There are number of practices, rules and even regulations that inhibit government IT evolution. Government agencies need to continually ask ‘why do I really need to follow this rule?’ and keep asking,” he writes. “Get to the core goal of these restrictions, and propose a better way to solve this problem.”

  • How Change Management Serves the Developer

    How Change Management Serves the Developer

    Change management first comes to mind as a means to keep errant, untested, unapproved code from entering production. But did you know that what is good for IT operations is good for developers, too?

    Developers appreciate change management. They enjoy the change management benefits of Linus Torvald’s popular Git version control system http://git-scm.com/, which maintains successive versions of the code in question, and spawned GitHub https://github.com/ where developers share and network with their community. Perforce is another version management tool http://www.perforce.com/.

    But what are the benefits to developers from change management as taken in the former sense? How does the same change management that protects the production environment help the coder?

    Lightening Developer Workload

    Change management saves developers a lot of work. Developers benefit by focusing on the work that stakeholders agreed on when discussing and scoping the project. These are the tasks that come from their lead developer, who receives it through proper channels.

    When developers do this instead of accepting countless requests from managers for adds / changes that fall outside the scope of the project that leadership agreed on, they save themselves from potentially repeating their work to replace those unauthorized changes with the coding implementations that the team leader originally tasked them with. Developers save themselves and the customer many headaches by completing planned, authorized project items rather than the requests that undermine the corporate vision.

    “Change that is not properly managed is destabilizing. Unapproved changes send ripples through every aspect of project task assignments. The ultimate outcomes are unpredictable,” says Steve McConnell, the oft-quoted author of “Code Complete” (Microsoft Press). And by the time upper-management hears of the scope creep and project dilution, the damage is far reaching.

    Yet, even stakeholders who felt they clearly communicated what they needed will come back at a project landmark or at mid-project to say that they require some feature that the development team is not addressing. This creates scope creep and additional person-hours that are out of the development team member’s hands. Clearly, developers see enough challenges such as this without managers visiting the developer’s cubicle once the project is in full swing, seeking adjustments for their users.

    “But this duality is a specific phenomenon that I and the industry have seen. There is the official workload and then there is the unofficial plan and workload consisting of favors garnered from individual developers, which undermines the project manager, creating work that causes work to go on with the PM unaware,” says McConnell. Following change management protocols and project structure is necessary so the right hand (PM) knows what the left hand (developer) is doing.

    Avoiding the Crossfire

    “Developers get caught in the crossfire between unofficial requests and change management. The proper chain of command funnels down blame to the developer when their task X is not done. Yet that only happened because the VP of Sales came directly to the developer, saying he needed another feature,” says McConnell. Because the developer saw the VP as his superior, he felt he couldn’t say no. Suddenly, the developer has several bosses. As a result, development staff don’t get project tasks out on time. “This leads to prioritization of work that does not reflect the priorities of the organization,” says McConnell.

    When a developer remains firm, however, sending the VP to the project manager or development team leader with any new requests, that can limit some of the crossfire.

    The Joy of Completed Work

    Another benefit to the developer in following change management protocols is the satisfaction of finished work, which is possible when they are not constantly changing direction. “Developers have a high desire to complete work successfully,” says McConnell. To not have to frequently change focus and to rather get work done day-to-day and week-to-week is very fulfilling for developers. “The Holy Grail for developers is to receive clear direction throughout the course of the project,” says McConnell. Developers like their work to move in a straight line. It is frustrating to change focus so often.

    Developers are most motivated by the work itself. They are task-oriented people who enjoy the relief that comes with task completion. If the work is constantly redefined, that can be demotivating for them.

    Coming Full Circle

    “There are benefits to the developer from change management including improvements in productivity and morale. But the largest benefits accrue to the business. Change management gets things done by investing more time in moving in the right direction,” says McConnell.

  • Three essential elements to maximize business value with DevOps

    Three essential elements to maximize business value with DevOps

    DevOps is fast becoming the winning strategy needed to accelerate the continuous delivery of exceptional software without sacrificing quality and cost efficiency. With its focus on better communication, collaboration and feedback within and across development and IT operations, DevOps is gaining many fans – even in the business, where performance is seen as being directly attributable to its adoption.

    I’d be the first to agree that buzz plus a liberal dash of hype follows any new tech trend. We’re seeing this big time with DevOps. Already it’s one of the most Googled tech trends.

    Many vendors are washing and making ready their ‘DevOps products,’ while the #DevOps noise is shall we say, trending – we just love disruptive technology.  If you have read the Puppet Labs 2014 State Of DevOps survey, organizationswith high performing DevOps teams were 2.5x more likely to exceed profitability, market share and productivity goals, and had 50 percent higher market capitalization growth over three years.

    Don’t get me wrong I’m a disruptive tech fan too, but there’s a caveat – technology disruption is nothing unless it’s truly transformative– and that’s where I place DevOps.  It’s not a technical nicety, but actually a business imperative for companies to thrive in an increasingly software-driven world.

    Software applications are rewriting business. They’re no longer in the background ‘counting the beans’ and running the supply chains – they’re front and center – the mobile systems-of-engagement that shape your brand, delight your customers and, here’s really the cool part – disrupt markets.

    Sounds great you might say, but there’s a problem– the traditional fixed speed limit on the super highway of business computing.

    Enterprises have been stuck in the same gear for years maintaining large, complex/interconnected legacy systems. Mainly transactional and supporting complex business processes, the norm has been to change when only necessary (or forced to change?) – never exceeding the speed limit. Now however, consumerization of IT has dictated rapid delivery of software innovations. This requires a DevOps approach, where teams have a shared responsibility for not just keeping the lights on, but powering business.

    Being able to increase pace is important, so too nimbleness. By making IT infrastructure more flexible and the instrument used to digitally engage and interact with customers, cloud drives business agility. But it’ll never realize its full potential if IT continues operating in silos using manual processes. This is why DevOps collaboration, shared processes and tools are so critical for harnessing the cloud – or using and an analogy – if cloud is the supercharged engine of business – DevOps is the fuel that powers it.

    So with mobility and cloud computing being essential to a software-driven business, what additives do we need in our ‘DevOps fuel’ to spark agility and generate the greatest returns?

    There are three big ones:

    Agile Parallel Development

    DevOps must reduce all elements of waste. This is a tough nugget to crack because existing IT environments generate tremendous inefficiencies. Often separate dev teams have to contend for physically constrained resources, with quality compromised by poor test data, shortcuts and bottlenecks. Testing especially is seen as IT’s “angry monkey”; something to be loathed, when in fact it should be a unified process that bakes excellence (functional and non-functional) into  everything – from mobile apps and API’s to back-end systems – from dev day 1 and persisting right through to production.

    With Agile Parallel Development and shifting testing earlier in the lifecycle, teams avoid delays in the development of high-quality code. Toolsets are important here, especially service virtualization, which by removing testing constraints reduces cycle-times plus prevents bugs finding their way into production.  And, since business will increasingly engage customers across digitized multi-channels (mobile, API’s), teams will exploit real-time intelligence to test new ideas and experiments – pinpointing how functionality and performance converts to business gain.

    Continuous Delivery

    Release delays are a classic business fail.  Now, success depends on delivering a continuous flow of value from new mobile apps, APIs and software innovations. These types of services will be constantly enriched to capture new markets and customers yes, but they’ll also be operating within shorter windows of business opportunity – faster lead times mean everything.

    For IT, this ‘quick or dead’ imperative means teams must challenge a culture based on avoiding change and fear-of failure by using Continuous Delivery  processes and tools to accelerate and streamline complex, multi-tier releases; automating the testing, deployment and promotion of changes across all environments. Additionally, these processes should integrate other management requirements – for example, establish service-level monitoring and reporting with the application when released.

    Agile Operations

    Agility must extend to operations. For too long we’ve been asking questions like – “how long can we go between failures?” or “who’s to blame for this problem service?,”  but we should be asking – “If we want to increase customer conversion rates from our mobile app, what levels of performance are needed?” or “how can we detect and remediate performance problems before code reaches production?”

    This shift requires Agile Operations – shared processes and tools that optimally manage applications, but also feedback intelligence to the extended team. For example, Application Performance Management should pinpoint operational problems faster, but also ‘gift’ development rich insights they can use to improve code quality. Furthermore, teams will leverage advanced analytics (like how, where and when mobile apps are being used) to drive just-in-time enhancements –that’s a new take on end-to-end– customer ‘engagement-to-experience.’

    Business demand for software innovations is insatiable, and for good reason. Now the simplest mobile app experience or secure API can transform your business or screw it up completely.

    By establishing a rampant innovation culture with DevOps and the right processes and tools, IT will not just meet expectations – it’ll be the spark for growth and innovation.

    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

     

  • DevOps with Purpose: It’s about your culture!

    DevOps with Purpose: It’s about your culture!

    Four practical tips to fostering a DevOps culture in your organization.

    This is Part Two in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications.

    Today, we find more and more businesses putting pressure on IT to move faster, and, if their IT department struggles to keep up, they are often willing to “go around them” and invest in a cloud or other third-party solution on their own to get what they want, when they want it (aka “shadow IT”). What the business often lacks, however, is a full understanding of the many downstream implications that come with speeding the roll out of new services such as security assessments, integrations to legacy systems, the ongoing cost to administer the solution and take on support for it, etc. It’s true that Ops teams want to control the reliability and stability of software deployments and that can often slow things down, but they do this because that’s what they are paid to do: to deliver stable, reliable, and high-performing services.

    This conflict between the business’ desire for speed and Ops’ charter for security, reliability, and performance, has been brewing for several years and it’s time for some introspection and a few tips on how we can make things better. Ultimately, progress is all about culture, and that’s why defining DevOps with a purpose must include focusing on your organization’s IT culture.

    Tip #1: Recognize the cultural challenges between the business, Dev and Ops

    Because Development sits closer to the business in the IT value chain, there’s usually less conflict between the business’ desire to move fast and Development. That isn’t to say Dev managers aren’t sometimes frustrated by how fast the business wants things given the resources available to them, but they usually are motivated and compensated to move in sync with how fast the business wants to move.

    The first tip is to take a step back and benchmark your current culture for both Dev and Ops, because only then will you be able to understand how DevOps may impact those cultures. With Dev, ask yourself, for each line of business “Are we still doing waterfall software development with one release every year or eighteen months, or have we adopted agile methodologies that enable us to deliver multiple releases throughout the year?” Based on your answers, then ask, “Is that in line with what the business wants today? Is that inline with what we think makes the most sense or are there opportunities we could bring to the business if we adopted agile more broadly?” Finally, “what would be the value to the business and cultural impact of adopting DevOps principles for continuous integration of new software development?”

    Next, ask yourself, “How focused is our Ops team on stability, reliability and clamping down on change vs. accepting (and even desiring) change? And how does this vary by line of business or application area?” (see Part 1 of this series for why that matters) If you have a risk-averse Ops culture that’s supporting a fragile infrastructure or many legacy technologies, then you may need to tackle some of those challenges first in order to help your DevOps culture evolve. I also suggest looking at your Ops culture through a compliance lens. Ask yourself, “Are we in a heavily-regulated industry that has created its own cultural challenges in terms of change approvals and auditing that we need to take into account?” Finally, what would be the value to the business and the cultural impact of adopting DevOps principles for continuous delivery of new releases?”

    One of the hallmarks of DevOps is the ability to develop smaller pieces of incremental functionality, deploy them faster (perhaps even a few times a day), and quickly roll things back if there’s an issue. This is a big leap for many IT cultures on both the Dev and Ops side so understanding where your culture is today is a critical first step.

    Tip #2: Think about how you view work

    Do you view work as tasks done by individual teams or in an end-to-end fashion (e.g. from raw materials to finished goods and customer delivery)? DevOps transformation requires focusing on work in an end-to-end manner. Your goal should be to identify where your IT organization’s bottlenecks are, with the intent  of reducing pressure at those bottlenecks to increase end-to-end flow and, therefore, output that benefits the business.

    In The Phoenix Project, the bestselling IT novel (yes, indeed an IT novel) co-authored by Gene Kim, Kevin Behr and George Spafford, the character of Brent Geller in the Ops team is an obvious bottleneck. He understands his company’s IT environment better than anyone and is consumed with both solving high-profile outages and deploying new application releases, the result is that he’s constantly putting out fires and unable to get new software released that’s desperately needed by the business. The book offers a wealth of perspective on how to embrace DevOps principles and what that means for your culture. I highly recommend it. You will likely see quite a bit of your organization in the story, I know it matched my experiences in IT very well.

    Back to Top #2, ask yourself, “Is my organization optimized around end-to-end flow or are we optimizing just at the individual workstations?” If it’s the latter, then you are probably stacking up work somewhere at one or more bottlenecks and should address those first. For example, a development project isn’t done until the code is tested and deployed. So incentivizing developers to finish code without knowing when and how it will get deployed is just going to create more work in process stacking up in your IT factory. It’s just like on an automotive line where you might  see cars with shiny paint, brand new tires and cutting edge technical design, but if the cars have no seats they simply won’t be shippable.

    You might also be saddled with a lot ‘technical debt’ – where dollars and resources are tied up maintaining existing applications and infrastructure. It may be necessary for you to focus at first on reducing technical debt in order to reduce those as bottlenecks on your support and deployment teams. Ask yourself, “What technical debt do we have and who can be charged with prioritizing and reducing it?” Treat it just like credit cards and look to reduce the ‘high interest’ debt first.

    Tip #3: Incentivize your people

    Don’t assume people will change for the “greater good” – proactively incentivize them to do so.

    If you want to change your culture and create one that’s more agile – if you want to optimize for flow versus workstations then you should incentivize to initiate the cultural change you seek. Old habits are hard to break even when we want to do things differently. As executives we have the tendency to appeal to a higher business purpose and assume the folks contributing on the front lines share the same passion for the company’s success. Often they intellectually understand these goals, but you should seek to make the change relevant to how it will improve their jobs as developers, QA team members, sys admins, and architects not just how it impacts C-level objectives.

    For example, Ops folks usually take particular pride in their indispensability, but to be indispensable they have to compromise family time, working late and on weekends to push out a big high-risk deployment. They may crave the attention and recognition for such ‘extra effort’, but at the same time they are putting more pressure on themselves and more risk on the business.

    As mentioned previously, the move toward a more agile IT means deploying with far greater frequency, and that can actually help you operate with less stress and risk. Errors and fixes are likely smaller in effort, and you will be able to roll back hick-ups much faster. Sure your folks may need to stay late occasionally, but they can do their work more often during typical working hours, reclaim their weekends and have significantly less stress and pressure than via traditional large-scale rollouts where expectations are high and so is the risk of failure, re-work, and long days. Plus, with DevOps you are actually delivering on business requirements faster – instead of deploying what was needed months ago.

    Tip #4: Make it personal: everyone is different.

    Related to Tip #3, realizing that everyone is inherently different is critical to incentivizing and empowering your IT team to transform. In most IT organizations, the responsibility is on the first line manager to know their people, understand what makes them tick and channel the right talents and motivations. Some may be seeing a move to DevOps as the ideal resume enhancement opportunity. Some may feel intimidation because they are innately risk averse. Still others may not be sure what to think especially if you have one team doing DevOps while they remain on a separate team doing things “the old way”. What’s important for managers is not to stop at how to make DevOps relevant for a role, but to consider the specific individual. Ask yourself, “How will each of my team members react to this cultural change, and how can I tap into their natural motivations to make them enablers of the change not resistors?”

    From what I’ve seen, there also is a generational aspect to DevOps cultural transofrmation. Younger employees who don’t know a world without mobile phones and grew up on social media are likely more comfortable with agile, small release deployments. Those with more experience are also more likely to think about the reasons why DevOps ‘can’t work’ and it will be key for first-line managers to engage them, listen to their concerns, and work to address them in a way that benefits the organization and realizes the wisdom of their experience.

    The bottom line for Tip #4 is that if you make it personal you will build trust and that will help you to drive transformation in your organization faster. Perhaps even consider establishing a ‘Take a Developer or Ops Team Member to Lunch Day’. By working to understand each other’s worlds, challenges, pressures and goals you can unleash a swifter cultural change within your organization.

    In Part 3 of this series I’m going to tackle tool investments and how they can help you achieve DevOps With a Purpose (or stand in the way of it).

  • Conjur up some agile, automated authorization management

    Conjur up some agile, automated authorization management

    One issue that has plagued IT since its inception is adding and removing authorized users. Most network and application security rely on somehow validating credentials to confirm that an individual is authorized to access the resources, but in a rapidly changing environment it is a serious challenge to keep authorization and authentication systems up to date. Conjur hopes to solve that problem.

    What is Conjur? In a nutshell, Conjur is an API-backed virtual appliance that makes cloud infrastructure projects possible by giving DevOps teams the ability to manage permissions and authorizations in a secure, automated, and well-audited way. In other words, Conjur allows for automated authorization management.

    Kevin O’Brien, part of the founding team at Conjur, shared some thoughts on Conjur, the issues the company seeks to address, and how Conjur can make life easier for DevOps teams. “As we’ve grown into the market, we’ve seen a lot of DevOps teams struggling with the same kind of authorizations problems, either slowing or killing cloud initiatives outright. For the ones that make it off the ground, they have to build a tangled web of handwritten scripts or hacked together key/certificate/user/access management inside of toolchains that are designed for other purposes (things like Puppet, Ansible, Docker, Chef, Salt, GitHub, etc.).”

    Conjur provides a dedicated platform for conducting authorizations without relying on insecure alternatives. Rather than trying to force old authorization technologies and ideas—like Active Directory—into a radically new environment—like an agile DevOps infrastructure, organizations can leverage Conjur.

    Conjur helps simplify and automate tasks like moving SSH keys out of insecure locations such as on-disk storage, or in Docker images, or GitHub repositories, and consolidating them on the secure, encrypted Conjur server. Conjur can manage secrets, including SSL certificates, across their entire lifecycle—from provisioning to replacement—with minimal downtime. And, Conjur maintains a comprehensive audit log of its activities.

    O’Brien relayed the story of one Conjur customer. This customer provides data analytics products for healthcare organizations, and solves complex computational problems with a focus on reducing health costs. The customer wanted to integrate DevOps concepts and culture into its business model, but ran into some stumbling blocks.

    “They were running into an issue where they wanted to begin using an AWS-based clustered genomics product, which would have allowed them to automate a large portion of their analytics, but were being told by their insurance payers that moving client data into that environment would be an impediment to doing business, because they couldn’t provide sufficiently granular access rights (the product used passwordless SSH keys),” explained O’Brien. “The insurance companies saw that as an ePHI issue, and absent a more sophisticated control and auditing, it was a no-go.”

    This company used Conjur to replace the default authorization mechanism in the project with a “Conjurized” access check, which allowed it to store the relevant keys in ephemeral storage and manage permissions through Conjur rather than by embedding them in code throughout their product set. Along with the audit capabilities, this meant that it had effectively taken a show-stopping design and circumvented it in a matter of weeks, without relying on key distribution or having to spend any time building an in-house solution.

    Conjur even has a solution dedicated to “DevOps and User Enablement.” O’Brien described it, “At a macro level, we’re solving a problem that is unique to DevOps and cloud: unlike the on-premise infrastructure of 20 years ago, protected by an Active Directory/LDAP system that handled authorization, role-based access control, and so on, there’s no way to translate that to the rapidly changing infrastructure that teams deal with today.”

    User enablement, in the end, is about driving innovation and speed. Conjur claims to make that possible (and more automated), without sacrificing security or auditability, or requiring a lot of custom work to use.

  • Chasing consistency across the wild seas of enterprise IT

    Chasing consistency across the wild seas of enterprise IT

    Despite seemingly never-ending arguments to the contrary, DevOps has firmly arrived in the enterprise. No, the question is no longer if DevOps is appropriate for the enterprise anymore – the more appropriate question is to what extent has DevOps made its impact on the typical enterprise.

    But the enterprise move to DevOps isn’t a straight line. One of the steepest, and also most common, challenges for enterprises moving toward DevOps is how diverse the IT environments in large organizations tend to be. Yet, for continuous integration, continuous delivery, and DevOps to thrive – architects, developers, test, QA and other teams all need to be operating on uniform systems – but in most enterprises that not the case.

    Yet, as the 2014 State of DevOps Report from Puppet Labs found, DevOps enterprise adoption is increasing, and that DevOps adoption was accelerating, and that high-performing IT organizations that embrace DevOps are typically more agile and reliable, deploying code 30 times more frequently and with half as many failures as non-DevOps enterprises.

    However, it’s this enterprise IT inconsistency that is one of the main reasons why DevOps gets entrenched in certain departments within large enterprises, but is then slow to expand outward throughout the rest of the organization.

    “This is a huge problem in larger enterprises, especially as DevOps practices grow beyond just isolated departmental applications. Architects have one system for prototyping; developers have a different system to code on; test and QA have their own unique ‘standard’ systems; while operations have untouchable systems for production,” Andi Mann, a VP at CA Technologies wrote in this post, Making DevOps Work in Complex Enterprise Environments, for devopsy.kinsta.cloud.

    In this roundtable, DevOps Summit Power Panel | Is DevOps Changing Enterprise IT?, both JP Morgenthal, director of cloud computing practice at Perficient, Inc., and Gordon Haff, cloud evangelist at Red Hat agree that DevOps is still in its early days and that enterprise DevOps adoption will be relatively slow, as enterprises build more consistency in their IT environments. “I think enterprise needs to mold DevOps to its needs and understand the differentiation for how to deploy that in a large multi-faceted IT department,” says Morgenthal.

    This is why DevOps in the enterprise doesn’t typically move quickly. There’s so much variance between department and team languages they use, as well as methodologies, tools, and procedures they have in place that all need to be normalized. This inconsistency across the enterprise is the enemy of broad, enterprise-wide DevOps success.

    Justin Arbuckle, former chief architect at GE Capital (currently, vice president of Europe and chief enterprise architect for Chef) created an adept analogy for the enterprise journey to DevOps and consistency with Herman Melville’s classic work Moby Dick. “The whale isn’t DevOps. In my opinion, every organization has a whale called consistency. Consistency of environments, whether it be the consistency of the images running on your service. Whether it be the consistency of the IT environments, consistency of the processes, or whatever the thing happens to be: consistency is at the center of many of the organizational challenges that we have today. So driving that consistency message, in our experience, has been absolutely critical to delivering the message as to why we need to go to sea,” he says.

    That doesn’t mean there aren’t many places where DevOps can succeed, and succeed swiftly. As Arbuckle points out, regardless of the size of the enterprise you will find there will be shared problems among groups, and in shared problems there is the shared motivation to solve these problems. “It’s about getting a bunch of people who want to work on a common set of problems and together you start showing results,” says Arbuckle.

    For instance, most every large team has security, compliance, QA and other challenges. What GE Capital did, to help solve them better, was to provide regular weekly demonstrations where everyone in the organization was invited to watch and learn how applications and systems were developed being developed. And dozens of employees from throughout the organization have attended some of the larger demos, with one hitting 80 attendees, Arbuckle says.

    “We’ve evolved this process in GE Capital called “compliance by demonstration.” Compliance by demonstration means essentially instead of waiting for some form to be filled out, and we then have to spend three months explaining to people why the answers we put down are correct, we involve everyone from the beginning. And you know what happened? The amount of support that we’re getting from that is now amazing,” says Arbuckle. “They [different teams] want to do the right thing. They don’t want to get in the way of business value. So any way that we can help them see what we’re doing is awesome,” he says.

    The key to finding those shared set of problems, teams need solved is to get everyone involved in the process early. “That’s when it becomes real. What is real is not DevOps or using a new process, rather it’s a whole bunch of people around the organization saying, “Wow, they’re moving really, really quickly and we had an interesting discussion about data portability between two geographies and they [these other teams] have a really good plan for that.”

    When it comes to moving a large enterprise to DevOps, as David Mortman, contributing analyst at Securosis puts it, there’s no right or wrong. “If your enterprise is collaborating and the teams are working together on how to improve processes, or automate what can be automated, share lessons learned and just collaborate more effectively then you are essentially practicing DevOps. And there are many ways to get down this path,” says Mortman.

    That increased level of collaboration and sharing is one of the great ways that IT, dev and ops can stop being seen as part of the enterprise bottleneck, and “start being part of the story where other parts of the organization begin to see how they can change and become better,” says Arbuckle.

    The whale isn’t DevOps. The whale is the elusive goal of getting enterprises to do things consistently, and through that consistency, add value more quickly back into the enterprise – and while that storyline may never become an American classic – it’s certainly a modern narrative worth chasing.