staging-devopsy.kinsta.cloud

Category: Enterprise DevOps

  • The Role of Soft Skills in Building Strong DevOps Leads

    The Role of Soft Skills in Building Strong DevOps Leads

    As an industry, we spend a lot of time talking about the process and technology that make up a good DevOps practice. We have a strong focus on the development, IT operations, QA” and security roles. We debate tools and automation strategies. We wax philosophical about DevOps culture.

    What is either lacking entirely or simply glossed over in that conversation is what I would consider the backbone of any good DevOps team–the people. 

    You might assume by “people” I mean their skills with the technology or their expertise with a certain process. Those two things are important, but all things being equal, the people aspect of DevOps I am referring to is really more simple–or even more basic–than that. It all starts with the culture that is defined by the lead.

    As with any cross-functional discipline, teamwork is essential to the adoption and success of your DevOps practice. At its core, DevOps is about collaboration among people from a variety of teams and departments. It brings together multiple disciplines, people and processes with the common goal of high quality and high efficiency output. DevOps relies so heavily on teamwork that without strong leadership, your DevOps culture and the success of your practice are destined for a rocky road at best.

    A strong DevOps leader will need to bring together people in roles that have either been traditionally siloed or are now being done by fewer people. This is no easy feat, however building trust, earning respect, communicating effectively and motivating everyone toward the common goal is paramount to the success of the DevOps team.

    These traits–trust and respect, communication and the ability to motivate–are not unique to DevOps leads, rather they are the key characteristics that make up any strong leader. By putting them in the context of DevOps, the importance of each in the process and culture is irrefutable. 

    Trust and Respect

    Paul Zak, the founding director of the Center for Neuroeconomics Studies and a professor of economics, psychology and management at Claremont University, led a study to better understand the neuroscience of trust. His team found that the effect of trust on work performance, engagement and loyalty were huge. Respondents indicated that employees with high trust had 106% more energy, were 76% more engaged and 88% said they would recommend their company as a place to work to family and friends. 

    The numbers might not come as a surprise, but how you achieve high trust might. First and foremost, be vulnerable. Do not be afraid to ask for help. This not only exhibits the trust you have in the people on the team, it also demonstrates the sign that you are secure in yourself as a leader. 

    The trust factor for a DevOps lead is multifaceted. The team must trust the lead enough to also trust his/her vision for the process. By showing vulnerability and leaning of the subject matter experts from each discipline for input, you start to build rapport with the team and the process becomes owned by the different functions involved. By asking for help, you invoke the natural tendency to cooperate. That cooperation leads to mutual trust. And by earning trust, you also earn their respect. 

    Communication

    As with any cross-functional team, communication should be viewed as critical an element as your DevOps tools. A successful DevOps lead will be able to understand and speak the languages unique to each discipline. By understanding the nuance and meanings of the words used by the IT operations teams, QA, security and development, the lead can easily help communicate goals, set expectations and establish rules of engagement. Through daily communication, the team will be able to reduce friction and become far more effective as a group. 

    Motivating Toward a Common Goal

    Former Boston Bruins coach Harry Sinden said it best, “Putting on the same jersey doesn’t make a team. You’re still a collection of individuals until you find a common goal.”

    The DevOps lead who motivates the team toward that common goal will find success. But how do you do that? To find out what motivates the people on your team you need to talk to them and get to know them. Involve them in developing the overall strategy. Seek their input and make sure they feel they have ownership of the outcome. 

    Set milestones and celebrate accomplishments. Reward success. Provide feedback and coaching in the moment–both good and bad. 

    The team that feels like they are part of something are no longer a collection of individuals.

    In the end, when you are assessing your DevOps practice and culture, make sure you take a long hard look at the people. They are truly the backbone of any DevOps practice. The need to technical prowess and experience should not be underscored, however, make sure you look for someone who has those skills plus all of the necessary attributes of a true leader. The success of your DevOps practice may depend on it.

    — Sara Faatz

  • Collaboration Over Competition: How Companies Benefit from Open Innovation

    Collaboration Over Competition: How Companies Benefit from Open Innovation

    More and more technology companies are adopting open innovation initiatives. This is largely due to the realization of the benefits of working with outside experts to gain external perspectives and insights. This situation wherein an organization thinks beyond its internal resources for innovation and collaborates with external resources is known as open innovation. Open innovation is an opportunity for the company to utilize those external ideas and use them to develop innovative products and services. It may seem simple, but there is more to the collaboration process than just brainstorming.

    Open innovation is not easy, but the benefits are well worth the effort. Large technology organizations can establish a competitive advantage by partnering with promising startups. The startups benefit from this partnership by gaining access to venture capital resources, networking opportunities and the opportunity to reach a broader customer base, typically tied to a large company.

    Larger companies that typically change at a glacial pace can learn from their small yet evolving partners. Startup founders who are new to an industry can form valuable relationships and gain mentors with seasoned veterans.

    Overcoming Obstacles

    Technology organizations, large and small, should be prepared to make some changes in order to benefit from an open innovation environment. Indoctrinating an attitude of information sharing can be difficult in companies that have historically kept their intellectual property under wraps, and in many companies, even developing a collaborative environment across various departments can be an uphill battle.

    Breaking down barriers and overcoming this predisposition toward secrets is the only way to cultivate a collaborative environment. Ultimately, this effort begins in the boardroom. Once a large company has executive buy-in, the idea will begin to trickle from the top down, and over time it will take hold.

    The following steps will serve as important guidelines to tackle obstacles and sustain this synergy.

    Create Ecosystems Around Intellectual Property

    It is common for both parties to feel the need to protect their intellectual property, but that closed mindset defeats the purpose of an open innovation initiative. To overcome this obstacle, it is critical to emphasize the greater value and benefits that come from an open innovation ecosystem. All parties must realize that sharing their intellectual property into the ecosystem can accelerate the pace of innovation.

    Several companies have demonstrated the value of this approach. Tesla, for instance, made the decision to open source its patents a few years ago, recognizing that the company couldn’t make electric cars fast enough to slow the global carbon crisis. Elon Musk also pointed out that patents represented a small protection indeed against a determined competitor, and he thought the decision to open source would strengthen the company’s position.

    Assess Your Partners

    Adding a collaborator to your open network should not be a decision that is made lightly. The organization should be patient and cautious when selecting a potential partner. Weigh each company’s skills and capabilities and consider any disadvantages as well. Just because a partner is not perfect does not mean it is not the best choice, but knowing its weaknesses will help you address them before they become a problem.

    An organization should be assessing several prospective partners. Establish processes that ensure each potential collaborator is examined fairly, but critically so that the end goal to identify the companies that will not be a good fit is achieved. This practice is not just for your benefit alone—an unproductive collaboration can incur in heavy costs and wasted time to all parties involved.

    Adjust Business Models as Necessary

    Business models are designed to maximize benefits and minimize risks, but they should allow for some flexibility. In the real world, changes arise frequently, and business models must adapt. For instance, many partnerships established around open innovation initially began between two companies. Over time, it is a reasonable expectation to anticipate other players be added to the mix.

    A multi-dimensional ecosystem demands a different business model than a version that is two-dimensional because it may involve a different set of risks. It also has a more complex intellectual property pipeline where contributions and evolutions are more difficult to track and manage. As long as each partner is prepared to adjust business models, these changes can be effectively addressed.

    Foster a Collaborative Culture

    For the vast majority of companies, open innovation is not an organic process. Even within an organization, some departments tend to be closed off about their projects or even sharing information outside the company. An attitude of open innovation comes from internal change, and people are naturally resistant to change. To encourage a culture-shift, start from the top down.

    Support from leadership is critical for developing a culture that is compatible with open innovation. It is also important to identify the soft skills that a team needs to accomplish its goals. Open innovation itself is a skill that can be taught—problems arise when company executives expect it to be a trait that employees are inherently born with.

    There are numerous benefits of open innovation. Technology companies can produce more ideas in a shorter span of time mutually benefiting all businesses involved. There is an opportunity to create markets that did not exist prior to the development of the initiative.

    Of course, obstacles are also inevitable and more so because sharing valuable intellectual property outside the confines of a research and development department is always looked down upon. People, and business models, are naturally resistant to the significant change that comes with the open innovation approach. Whether a company can overcome these obstacles and see the many advantages is a matter of determination and a desire to adopt company-wide changes so that there is innovation across the organization.

    — K.R. Sanjiv

  • Red Hat Extends Runtimes Middleware Portfolio

    Red Hat Extends Runtimes Middleware Portfolio

    Red Hat has made available the latest instance of Red Hat Runtimes, a suite of lightweight open source components and frameworks that makes it easier to discover the middleware most appropriate for building a specific type of application.

    James Falkner, product marketing director for Runtimes at Red Hat, said as organizations embrace cloud-native application architectures based on microservices it’s become increasingly challenging to determine what middleware to deploy optimally and where. Red Hat Runtimes not only makes it easier to navigate all those options, Falkner said, but all the components and frameworks are certified to be pre-integrated.

    The latest version of Red Hat Runtimes adds support for Open Liberty, a lightweight runtime for building Java applications developed by IBM. Red Hat was acquired last year by IBM.

    The latest installment of Red Hat Runtimes also provides access to what has become a standard distribution of Node.js based on Red Hat Software Collections that will be implemented across all Red Hat offerings.

    Finally, Red Hat has also added support for Red Hat Single Sign-On, an access control framework based on the Keycloak project.

    Falkner said Red Hat Runtimes also serves to reduce the total cost by providing a single subscription through which organizations can access everything from container runtimes to the 3Scale application programming interface (API) management middleware, which Red Hat acquired in 2016.

    Very few IT organizations these days are standardized on a single class of middleware, especially as they embrace microservices-based applications built using containers. Most IT teams for the foreseeable future will need a flexible way to access multiple runtimes in support of everything from monolithic applications based on Java to applications built using Node.js code deployed using Docker containers.

    Rather than a piecemeal approach to the middleware infrastructure required to build, deploy and integrate all those applications, Falkner said Red Hat Runtimes provides a more holistic approach.

    It’s not clear how much or even whether IT organizations are centrally managing middleware in the age of DevOps and the cloud. Historically, many IT organizations preferred to standardize on a single application server platform to deploy various classes of middleware. However, many developers today are deciding what middleware to include within their application stacks without much input from a central IT function.

    Via Red Hat Runtimes, Red Hat is trying to make a case for providing developers with the flexibility they cherish in the form of a subscription service that provides IT teams with a modicum of control over what middleware gets employed.

    Tensions between DevOps teams and central IT organizations have arguably never been higher. In fact, many DevOps teams are operating within lines of business that are outside the direct control of centralized IT. As such, the level of standardization that can be imposed by central IT organizations has become more constrained. Many centralized IT organizations are now trying to influence middleware platform decisions rather than outright make decrees that might get ignored anyway.

    Regardless of the middleware platform choice that ultimately gets made, however, the one thing that most centralized IT teams will have to come to terms with is finding a way to support it.

    — Mike Vizard

  • A Developer’s Task: Minimizing Challenges Created by Fragmentation

    A Developer’s Task: Minimizing Challenges Created by Fragmentation

    Over the past decade, there has been a wellspring of apps, services and platforms to help developers build custom solutions for businesses. Some are great, some not so much. Regardless of quality, the quantity of options and each one’s varying level of sophistication has made it difficult for developers to separate the wheat from the chaff.

    A recent survey from IDC supports this notion. It contends that the current landscape of software development languages and frameworks is highly fragmented. Having too many options—as opposed to a single, unified environment—leads to holes and disconnects in the development process, not to mention the potential for significant complications in the long-term support of today’s apps.

    Here are some ways developers can navigate the challenges created by this high level of fragmentation. 

    Don’t Be Afraid of Low-Code (or No-Code) Solutions

    The IDC survey found that less than half of developers—44%—have used low-code development tools professionally at one point or another. As one would surmise, low-code programming brings with it a host of advantages, such as easy-to-use and intuitive interfaces, and the ability to deliver applications faster. 

    Some low-code platforms also enable developers to build applications that can be used on any device while also reducing dependency on outsourced IT. A built-in script builder can allow even relatively inexperienced developers to turn complex business logic into functional workflows—such as automating a repetitive task—within a matter of minutes. Even after apps are launched, workflows can be updated and customized to fit specific business needs nearly instantly.

    Achieve Scale with Serverless Applications

    When building on a serverless platform, developers prevent infrastructure maintenance from inhibiting applications from scaling globally. This also allows developers to build mobile apps without managing the backend infrastructure. Cloud computing using public clouds typically involves renting virtualized servers across the technology stack. But when looking to scale, the onus is on developers to deal with the operating system and database while also managing necessary updates. This can lead to a work-intensive process on the app infrastructure level.

    A serverless infrastructure, on the other hand, abstracts databases and file servers, shifting focus to the app logic level. This allows developers to build and manage microservice-based apps that integrate with other services, making it easy to scale applications.

    Make Things Easy on Your Team

    According to the IDC survey, just 20% of developers claim they are “extremely familiar” with containers and microservices. With such expertise hard to find, using flexible tools that allow teams to quickly deploy code in scalable, compartmentalized components is vital.

    Organizations should aim to help their developers focus more on designing top-class user experiences of serverless applications, rather than spending (or wasting) time and resources on setting up and maintaining components on the server side. This gives developers the ability to focus on doing what they love—developing—as opposed to other tedious and mundane activities such as manually managing servers and storage solutions, or tweaking the underlying infrastructure of their microservices.

    Of course, making things easier for developers means deploying a powerful tool built on a stable foundation that can offer SDKs and APIs for both mobile and web apps, the ability to test early and often in a sandbox environment and analytics that monitor and report performance in real-time.

    Developers know just how challenging their jobs can be, and the fragmentation that can occur due to the vast number of options on the market can make it even worse. There is nothing wrong with using multiple solutions, of course, but having a sturdy and unified underlying infrastructure goes a long way toward avoiding unnecessary headaches.

    Finally, organizations should look to those who know best when deciding which company-wide tools to implement: the developers themselves. As the IDC study states, developers should be viewed as key stakeholders in IT purchasing within any organization moving to the cloud accompanied by an internal digital transformation.

    — Raju Vegesna

  • Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Today, modernizing systems is more than simply moving technology to a new location. It requires an IT stack of a new generation of technologies and tools to work.

    As we head into the new year, let’s take a look at the top eight trends that will shape how we will develop and deliver software. 

    Kubernetes

    Yes, it’s big and getting bigger. The pace of enterprise adoption of this leading container orchestration solution will only gain momentum in 2020. Look no further than the 2,300% attendance increase from KubeCon 2015 (500) to KubeCon 2019 (12,000). As more companies begin to see the direct financial and operational benefits to the flexibility, scalability, automation, high availability and portability of Kubernetes, the demand for developers and engineering experts in this complex software will grow accordingly. Case in point: A 2019 national job search on LinkedIn turned up 16,744 open positions for Kubernetes-related roles. Given the already large and still developing Kubernetes community, we should also see an increase in the speed and volume of feature releases. 

    Microservices

    It’s predicted that by 2022, 90% of all apps will feature microservices architectures. The growing business imperative for software engineering teams to produce and release software in ever shorter cycles—continuous delivery—has paved the way for a huge surge in microservices, the ideal architecture for CD. As enterprises continue their accelerated move to the cloud in 2020 and beyond, they increasingly prize the flexibility to try out the new technology stacks that microservices provide. All businesses want to optimize resources, minimize downtime, reduce infrastructure costs and avoid technology or vendor lock-in. In 2020, microservices architectures will continue to offer up more and better of all these benefits as the migration from monoliths picks up speed. 

    Service meshes

    The rise of microservices has led to a parallel boom in service meshes. This will only accelerate, given how integral the current class of service meshes—Istio, Linkerd, Consul, Envoy—is to the successful functioning of microservices. As a software designed to enable the thousands of microservices that make up an application to talk to each other, it’s quickly become an essential component with a vendor ecosystem poised for substantial growth. Feature-rich Istio, backed by IBM, Google and Lyft, is the leading Kubernetes service mesh, and that shows no signs of changing in 2020, especially given the relative ease of setting up and running it. If your enterprise has embarked on the journey from monolith to microservices, it will soon be crossing paths with service meshes. 

    Observability

    In the recent past, the sheer complexity of modern distributed systems has outstripped the tools designed to allow teams to see into them. Enter observability—which isn’t monitoring. Like good helicopter parents, software engineers, application developers, SREs and DevOps teams want to know and understand what their systems are doing at all times. LightStep, Datadog and Honeycomb, to name a few, are vendors poised to offer logging, tracing and metrics solutions to the rapidly growing number of enterprise teams building cloud native systems. Keep a close eye out for OpenTelemetry, an open source observability framework currently a member of the CNCF Sandbox. 

    SRE

    One of the great challenges ahead for this still-emerging field is for enterprises of varying sizes and work cultures to find a form of SRE that works. What succeeds at Google may not be the recipe for SRE implementation at smaller tech enterprises or startups. The role of SRE and the expectations that go with it remain fluid. The SRE’s constant imperative to automate will only add to the profile of critical SRE and DevOps tools such as Terraform, Ansible and Jenkins. Ponder Amazon’s Prime Day 2018 losses of up to $99 million for a clear understanding of the business-critical importance of SREs in the years to come. The job market reflects this new reality. 

    Security

    The shift-left movement in the software development lifecycle is on. The days of bolted-on post-production security are rapidly fading. DevSecOps, though still a buzz term, is here to stay, with more practice and use cases added to the theory. There are huge opportunities here for automated application security tools that support the software development workflow. 

    Then there’s privacy. The GDPR took effect last May and the California Consumer Privacy Act takes effect January 1, 2020. On top of these, there’s HIPAA and the regulatory compliance pressures on businesses in the area of security, which are already enormous—plus the immense challenges of cloud security. A 2019 Symantec survey on cloud security threats reports that 65% of businesses in the cloud still aren’t using multi-factor authentication. The same survey also notes that an astounding 85% of Symantec’s cloud customers aren’t employing security best practices. Look for businesses to tend to security earlier in the process. 

    Serverless

    It’s a boom time in serverless, with Google’s Functions, Microsoft’s Azure Functions and IBM’s OpenWhisk all offering their serverless solutions following the 2014 rollout of AWS Lambda. Look for more businesses to adopt a serverless-first approach as they upgrade legacy systems and see the substantial cost saving and application development benefits. Startups, too, will see the cost-cutting upside and the agility that serverless brings. The changes in application development and architecture in the cloud as a result of serverless are hard to overstate. With the vendor solutions now on offer, developers are freed up to do what they most like to do: run code and add functionality to their application, faster, without worrying about scaling and availability. Like microservices, serverless will see a huge upsurge in usage as the age of the monolith fades. 

    DevOps

    With the demands of cloud computing and far greater enterprise investment in dedicated teams, DevOps in 2020 is poised to make the transition from policies and principles to actual practice. The addition of baked-in security to the DevOps realm—DevSecOps—adds urgency to the automation of building, provisioning and deploying secure software. ML- and AI-driven apps have arrived, and DevOps practices will play a large role in the development workflow. The goal of zero-touch automation looms large, and this adds urgency to the need for clean data, organizational buy-in and more integrated systems. AIOps, though getting plenty of attention, is still young and its benefits to IT operations are still more theoretical than actual–but stay tuned.

    As we head into 2020, it will be exciting to watch these trends unfold. DevOps teams can expect the way we develop and deploy applications–in any architecture–to continue to evolve. By keeping a pulse on new developments in Kubernetes, microservices and other new technologies, they’ll be well prepared to bring their businesses into the new decade.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Kelsie Pallanck

  • The Use of Feature Flags in Code: Too Many Flags?

    The Use of Feature Flags in Code: Too Many Flags?

    It is interesting to watch the growth of an idea over time. The idea of using flags in code to do different things is as old as programming itself. Old-school configuration files used them, and they worked, so they were adapted.

    Thing is, given an idea that works, humanity inevitably takes it too far, and flags to control software behavior seem to have reached that point. If you are using one set of flags for A/B testing, another to segregate code in development at runtime, another to turn functionality on for some users but not others and yet another set of flags to hide data based upon user…You’re buried in unnecessary code branches. If your organization isn’t great about cleaning up after flags are no longer needed, you are building spaghetti code that future developers will not thank you for.

    The best answer to this growing burden is focus. What is the best use of feature flags/toggles in your environment? They certainly speed the delivery process by having the code there, in nightly builds, just not executed until the flag is flipped. This helps in rollout also by allowing operators to turn a feature on when it is ready by changing config rather than redeploying the application.

    For A/B testing, in many cases it makes more sense to handle switching at a load balancer, where again it is a config, but separate instances serve the UI in question. This, like all decisions regarding flags, should be based upon the volume of change. Changing the contents of a list is likely easier to test with flags, but large volume of change is probably better run separately and switched off of a load balancer.

    The same is true with the volume of change in source. A rollout might be the best option for handling large volumes of change, and feature flags may simply create more complexity.

    As with everything, approach the problem with a plan that works best, in this instance, in your environment. There is no denying that the ability to turn on a new feature and then turn it off if something goes wrong is appealing, just use the idea judiciously. And clean up after yourself. No shop that uses flagging extensively will say “yeah, we don’t clean it up,” because the mess of nested checks for flags would slow the code and make it passingly difficult to even read, let alone maintain, over time. So approach it from the beginning with “It is a tool, and when it no longer serves its intended purpose (the feature is fully live or abandoned), we remove it.”

    And keep rocking it. You are the engine of business, and this is what you do. Make it great and keep it running.

    — Don Macvittie

  • Survey Sees Massive Adoption of Microservices

    Survey Sees Massive Adoption of Microservices

    Under increasing pressure to innovate faster, a majority (84%) of organizations taking part in a recent survey have already embraced microservices.

    The survey, conducted by Vanson Bourne on behalf of API management platform provider Kong, polled 200 senior IT leaders in organizations with more than 1,000 employees. Among the results, 89% of technology leaders agree that companies that are not able to effectively support microservices will be less able to compete in the future.

    The report also finds on average organizations are running 184 microservices, with 60% of respondents running 50 or more. The primary reasons cited for adopting microservices are improvements to security (56%), increased development speed (55%), increased speed of integrating new technologies (53%), improved infrastructure flexibility (53%) and improved collaboration across teams (46%).

    Kong CTO Marco Palladino said the report makes it clear that just about every organization is on a journey to making a transition to microservices as part of an effort to reduce reliance on inflexible monolithic applications. Initially, that transition involves lifting and shifting monolithic applications in the cloud before decoupling functions using microservices, he said.

    As part of that journey, Palladino noted, the survey also finds significant microservices challenges remain, including ensuring security (36%), integration with legacy applications (32%), the complexity of management (31%) and updating API documentation (31%).

    Despite these concerns, however, more than 80% of survey respondents who have adopted microservices report that their organization performs well against metrics for development efficiency, the ability to use new platforms, collaboration across teams and sharing of services across applications.

    Overall, a full 90% of respondents said securely connecting applications and ensuring performance at scale collectively represent one of the greatest technical challenges of the 21st century. Also, 71% said they believe that organizations would be out of business within six years if they fail to keep pace with innovation in their industry. For public companies, the urgency is even greater, with 39% reporting they believe organizations will be out of business in less than three years if they fail to keep pace with innovation. Overall, 57% of technology leaders feel organizations are concerned that they are at risk of competitive displacement.

    Pressure on IT leaders is high as a result. Nearly three-quarters of respondents (74%) agree that a failed digital transformation effort will result in a missed promotion, lost bonus or even termination. The report identifies the top three priorities for IT leaders as improving efficiency (47%), reducing cost (41%) and increasing security (40%).

    Technology leaders, however, continue to place the highest importance on the availability (75%), security (74%), performance (65%) and scalability (64%). At the same time, technology leaders are focused on faster development speeds (95%), increased collaboration (94%) and reduced deployment risks (93%) as key desired outcomes for adopting any new technologies.

    The challenges most cited in terms of achieving those agility goals are the complexity of using multiple technologies (35%), lack of automation (32%) and reliance on legacy technologies (29%).

    The survey also notes 83% of organizations are relying on open source software to become more agile. The most commonly used open source technologies are databases (64%), containers (48%), API gateways (41%), infrastructure automation (40%), container orchestration (37%) and continuous integration/continuous delivery (CI/CD) tools (36%).

    In terms of cloud adoption, Microsoft Azure (43%) narrowly beat Amazon Web Services (AWS) (42%), with Google Cloud Platform (GCP) coming in third at 27%.

    On the plus side, 78% of respondents said their organizations are increasing IT budgets in the coming year, with 27% of public companies expecting their budgets to grow 26% or more. Nearly 90% of companies will also be increasing headcount, with 56% hiring internally and 31% relying on more freelancers and/or outsourcing to meet hiring goals.

    Hopefully, with that increased funding more organizations will be able to strike that elusive balance between stability and innovation.

    — Mike Vizard

  • Privileged Access Management at the Speed of DevOps

    Privileged Access Management at the Speed of DevOps

    Privileged access management (PAM) is clearly a very important element of effective cybersecurity. PAM has been ranked number one on Gartner’s Top 10 Security Projects for two consecutive years, and it is number four on the CIS Top 20 Critical Security Controls. The struggle for many organizations, however, is they have also embraced DevOps culture, and the traditional approach to PAM clashes with the principles of a DevOps environment. Thankfully, it is possible to effectively manage privileged access in a DevOps environment—it just takes a new approach.

    Challenges of Privileged Access Management

    Despite advances in identity and access management and the existence of things like two factor or multi-factor authentication and biometric authentication, most organizations still rely on a simple username and password to authenticate an individual and grant access to network resources, applications and data.

    The concept of least privileged access—ensuring that users only have access to things they really need access to—has been preached since the dawn of cybersecurity and, when done right, can be an effective strategy. The problem is it’s tedious to do right and it’s very easy to lose track of who has privileged access to what.

    That’s where a PAM solution comes in. The whole point of privileged access management is to provide a way to track and manage who has access to what—to grant access when it is needed and revoke access when the need no longer exists. Unfortunately, there is a lot of confusion about PAM and the effort to manage privileged access is challenging for many organizations.

    Enterprise Management Associates (EMA) conducted a survey on the state of privileged access management. The survey included responses from companies representing different company sizes and industries around the world and focused on IT and cybersecurity professionals—most of whom are familiar with PAM and are directly responsible for managing or granting privileged access to users.

    There were some concerning findings from the survey regarding the perception of PAM. Twenty percent of organizations that reported using a dedicated PAM solution believe it somewhat or greatly reduces user productivity. Many respondents also expressed frustration about the amount of time required to manage privileged access. Half of the survey participants cited manually granting temporary privileges as either very (29%) or extremely (21%) time consuming, and half also said manually revoking temporary privileged access as very (33%) or extremely (17%) time consuming.

    PAM and DevOps

    As challenging as traditional PAM solutions might be for businesses around the world, they pose an even greater hurdle for organizations that have embraced DevOps. A recent episode of the Defense in Depth podcast, hosted by David Spark and Allan Alford, focused on some of the challenges of PAM. A listener had written to complain that “the traditional approach to PAM breaks everything that is DevOps. Regardless of what your PAM provider says about their ability to scale with your dev cycles, they’re lying about the real level of effort.”

    That seems like a fair assessment. Pretty much every company is somewhere on the cloud journey—and working within a DevOps framework on some level. Companies often face backlash from the DevOps team—with some going so far as to boycott efforts to introduce security tools that can’t keep up with the pace of DevOps in the cloud.

    DevOps developers express frustration about trying to build an automatic scaling, horizontal infrastructure and being dragged down by demands from the security team to install agents and change authentication modules. They complain it often means rewriting all of the scripts, resulting in significant and unnecessary effort for a solution that ultimately can’t scale properly in the DevOps environment.

    That is, unfortunately, true when it comes to traditional PAM solutions. Next generation PAM solutions, however, are built with the cloud and DevOps in mind. They are lightweight, automated, scalable and capable of integrating seamlessly with common tools and platforms.

    Rethinking Privileged Access Management

    Based on the survey, organizations understand the importance of privileged access management, but they struggle with finding a way to implement it effectively. The question from the podcast illustrates how PAM is also a significant issue for DevOps environments because traditional PAM solutions do not integrate or scale effectively.

    At the same time, we all know that PAM is a crucial element of effective cybersecurity. It’s not acceptable to just not manage privileged access, but it also doesn’t make sense to suffer through the headaches and frustration introduced by traditional solutions. Organizations need to find new privileged access management tools that work in the cloud and can scale automatically to provide PAM at the speed of DevOps.

    — Tony Bradley

  • How to Implement an Effective CI/CD Pipeline

    How to Implement an Effective CI/CD Pipeline

    DevOps bridges the gap between development, operations and IT services teams efficiently. To foster a DevOps culture, implementing the right DevOps tools with the right DevOps process is essential. Continuous integration/continuous delivery/continuous deployment (CI/CD/CD) help developers and testers ship the software faster and safer in a structured environment.

    Unlike the traditional software life cycle, the CI/CD implementation process gives a weekly or daily update instead of monthly or quarterly. The fun part is customers won’t even realize the update is in their applications, as they happen on the fly.

    A Brief Insight About CI/CD/CD Terminology

    • Continuous Integration: CI is a process in which developers integrate new codes into a shared repository several times a day. This is a better approach than the traditional one, where the developer will build new codes in isolation and then integrate into the main repository at the end of the project lifecycle. The primary goal is to detect any integration bugs at the initial stage so it can be rectified quickly. It triggers a new build whenever a new code merges with the existing main repository. Test runs are performed against these new builds to check for any breakage.
    • Continuous Delivery: At the end of the CI, CD comes in. CD ensures to automate the software delivery process and commits to deliver the integrated code into the production stage without any bugs or delay. CD in the DevOps implementation process, helps developers merge the new code with the main branch consistently so they can build an instant software-ready product. It is responsible for checking the quality of the code and performs tests to check whether it can release the functional build to the production environment.
    • Continuous Deployment: The most critical part of the automation occurs at this stage of the delivery pipeline. Whenever there is an important change in the code, the corresponding build and deployment occur simultaneously. It is achieved through continuous deployment process where it allows to perform live deployment changes for every code modification that passes through the CI stage. During this stage, there is no manual intervention right from the initial code until the code is in the production stage.

    Benefits for Implementing CI/CD

    The ultimate aim for any software application is to reach its potential customers faster than ever before. This is exactly what the CI/CD pipeline offers to any business model that leverages a software process which reduces the risks in each build and helps the end product to reach the customer quicker.

    • Achieve Faster Feedback Through CI Tools: For every committed code, the corresponding tests are run simultaneously to avoid any link breakage at later stages. Faster feedback helps to check the quality and impact of the code.
    • Greater Visibility: With CI/CD pipeline setup, the whole process of new builds, test results and any issues with new builds can be analyzed. This transparency allows the developers to know which changes in the build led to the brokerage and to avoid them in the future.
    • Early Bug detects: Conducting various types of automated testing allows to identify any bug issues at an early stage without any last minute surprises. These automated tests along with few manual test runs, help to fix any issues that may arise.

    The Different Stages of CI/CD Pipeline Implementation

    To get the full benefits of the modern DevOps environment, embarking on a scalable CI/CD DevOps implementation is important. It lays a strong foundation for building an agile DevOps for your business.

    Tools for the CI/CD Process

    Tools are the magic wand that help automate a successful CI/CD pipeline and ensure a faster software delivery.

    • Open-Source Tools or Proprietary: Depending upon the budget and the client’s requirement, business can opt for open-source tools such as Jenkins for automating the CI/CD process.
    • Cloud or Self-Hosting Services: To self-host your CI/CD application, tools such as Jenkins and Cruise Control help to setup, configure and monitor the application effectively. Otherwise, you can get SaaS providers to host on cloud services.
    • Build Status: Choose a tool which embraces the transparency and visibility of the entire process through appropriate notifications, through email or other type of communication.

    Possible Challenges of CI

    • You might need a discipline strategy to address an issue by the CI/CD pipeline, otherwise the whole fast feedback is in vain. 
    • Slower builds eventually take place as newer builds keep adding to the product.
    • Failure to train the resources to adapt to new tools and patterns.

    Wrapping Up

    In this era of faster software shipping and building quick releases on the fly, adopting a more robust project cycle that accelerates the delivery pipeline is crucial. Implementing DevOps services is the optimal way to get the effective collaboration between cross-functional teams through the CI/CD process.

    — Jay Elango

  • The Secret to Digital Transformation is Human Connection

    The Secret to Digital Transformation is Human Connection

    We know digital transformation is no longer an option for today’s organizations–it’s a requirement. End-users have come to expect an easy, digital-native experience, whether they are ordering a pizza or automating an entire network infrastructure, which is why businesses and governments are throwing trillions of dollars at new technologies and related services.

    Organizations must build and deliver exciting new software applications, faster than ever before. They must continuously innovate, adapt and stay ahead of the never-ending demands of digital data, experiences and channels. These demands have contributed to the meteoric rise of cloud computing, DevOps methodologies, open source technologies, predictive analytics, AI and many other innovations.

    However, even with all these investments, more than half of all new software or IT projects still fail. In fact, according to a study by Forbes Insights, 75% of executives say they’re still waiting to reap tangible benefits from disruptive technology. Here’s why: Technology alone does not solve digital transformation. It doesn’t address some of the most fundamental issues that inhibit or enable transformational success nor the most critical dependency, which is people.

    To truly transform, organizations must go beyond just technology to embrace the human elements of this evolution. We’ll look at six factors driven by the human side of the business, and how each of these can help, not hinder, digital transformation when properly addressed.

    Organizational Culture

    One of the biggest challenges for companies as they embark on digital transformation is the needed cultural change. The technology decisions, while daunting, are easier compared to the cultural shift organizations must undertake to truly become digital leaders. Top down mandates won’t work, because for it to be successful, digital transformation needs buy-in from all involved. People need to connect to the change and feel they can have an impact, or at the very least, know their job is safe amid the change. Also, to achieve the speed of change and innovation, organizations need to empower everyone to make decisions, not just a select few.

    Embracing an open culture can help with this. In an open culture, digital leaders look at their organization more like a community of individuals, all contributing to something bigger than themselves. Anyone can participate, lead and suggest a change or improvement. This methodology helps for the best ideas to win out, regardless of where they come from. Employees feel part of the process and ultimately, it empowers them to work toward the shared goal. Let me be clear, this isn’t a democracy or a lack of clear decision making power. However, it is using more open decision frameworks that move everyone toward a common goal, which brings us to the next big human factor.

    An Inspiring Vision with Metrics of Success

    It is often said to start with the end in mind. With digital transformation, this is absolutely true. For digital transformation to be successful, everyone in the organization needs to understand, and ideally agree with, the destination. Visions are not just words—they are driving the priorities, investments and decisions made by every team and employee. Without a clear vision, organizations can’t create an executable business strategy. The key is to make sure you have a vision that clearly describes what your organization will be like in several years–and then make that vision measurable.

    All good visions come with goals attached to them. Yet according to research from Gartner, 50% of organizations have no digital transformation metric or way to measure progress for digital transformation. Set up clear, ambitious targets–stretch goals the entire company can work toward. These metrics allow organizations to clearly check on how they have progressed and where they still need to get to.

    Cross-Organizational Teams and Processes

    Another cultural barrier to digital transformation is siloed behavior and workstreams. Often, teams refuse, or just don’t know, how to break out of their silos. Digital transformation requires collaboration and breaking down boundaries, as data, insights, applications and processes need to flow seamlessly throughout an organization. It all goes back to having a vision and an open culture. Without a culture of trust and a shared agreement on the end goal from across the organization, you won’t be able to break down these silos.

    With the vision and culture in place, adopting DevOps and agile processes is a great way to initiate this. It helps bring together business, technical and other people from across an organization to solve a specific problem or figure out how to better work together. Often, this takes a courageous leader, who doesn’t measure their value by the power or budget they hold, to broker these cross-organizational relationships and new teams.

    People Development

    In talking to IT and business leaders all over the world, they are faced with a common challenge: skill set gaps. This includes both soft skills, such as communications or management, and hard skills, such as technical capabilities. According to Red Hat’s survey on Global IT Trends & Priorities Research, the biggest blocker to an organization’s digital transformation efforts is people. More specifically, the survey found IT talent or skills gap was preventing organizations’ efforts from being successful. Technology and digital processes are changing so quickly, it’s hard to keep up. This is creating a digital skills gap in organizations across industries and around the world.

    Rather than hoping to hire people with the skills and talent you need, I encourage organizations to develop the people you have. Take your loyal employees who already fit your culture and believe in your vision and invest in them. Also reward them for taking risks. Digital disruption does not happen by standing still or encouraging small moves–it takes big bets. Leadership must also be willing to stand up for employees who try new ideas and push the boundaries.

    User Experience Focus

    According to CareerFoundry, which manages a Web UX design school, the cost of a bad user experience is high. Really high. Its research estimates bad user experience costs e-commerce companies $1.4 trillion in lost revenue.

    As we focus on the human connection part of digital transformation, user experience takes the front seat and is a top priority. We need to start with the user. What are they trying to do? What is the pain we are hopefully solving? Too many times organizations start with the cool technology and slap on the user experience as almost an afterthought. By starting with the user, projects are more likely to give users the feeling they are interfacing with a human being rather than a digital thing—and ultimately, will succeed because of it.

    Personal Connections

    One of the downsides of the digital era is we don’t have enough face time. We believe video conferences provide the same benefits as face-to-face meetings. We put our trust in digital handshakes instead of the real thing. However, to succeed at a company-wide digital transformation, you can’t rely on digital communication alone. Ironic, right?

    One key reason for making face time is to build trust. As humans, we need to see someone, look them in the eye, shake their hand, respond to their cues. All of this helps us trust the other person. To put your organization through a major transformation takes trust–across the organization, but especially of the leadership. This means leadership needs to get out there and talk to employees, customers, partners and users. Take the time and the effort to make your transformational efforts relate to the humans doing the work and buying your products or services.

    The Bottom Line

    The most common mistake organizations make is believing technology alone can solve their problems. Technology is still needed for a successful digital transformation. In fact, I am not in any way advising we all sit around and have a lovely conversation and hold hands to solve these massive technology issues. However, technology must be combined with human connection.

    In other words, it’s not just what you use to transform, but the how and the why of your transformation. The human elements require hard work across culture, hiring, people development, leadership and communication.

    Human connection is the killer application for digital transformation.

    — Margaret Dawson