devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Guess Who’s Coming to JFrog swampUP?

    Guess Who’s Coming to JFrog swampUP?

    The annual DevOps gathering and JFrog user conference, swampUP 2019, is going to be here before we know it. It’s happening June 17-19 in San Francisco, providing easy access for everyone (it’s just 30 minutes away from SFO airport).

    What’s swampUP? For the thriving DevOps community, swampUP is the must-attend event where developers, engineers and business leaders from top companies and industries network and share best practices for software delivery success.

    While conference promotions can certainly be full of fluffy cheerleading at times, one thing I’m especially excited about is this year’s swampUP guest keynote speaker, Dr. Nicole Forsgren.

    Dr. Forsgren, described as “snarky” by Forbes—a label she readily owns, if you ask—is the co-founder of DevOps Research and Assessment (DORA), which was recently acquired by Google Cloud. DORA quantified customers’ unique needs and DevOps processes to deliver custom paths to DevOps growth.

    Coming to swampUP as herself—not that she could come any other way, but not as a representative of Google—to talk about her unique research and the overall landscape. She’s planning on covering many of today’s hot topics, including DevSecOps, cloud and hybrid, tooling trends and DevOps culture in a special keynote aptly titled, “DevOps: It Only Works When You Do it Right.”

    If you don’t know Forsgren or haven’t seen her speak, her style and unique perspective perfectly blend data and statistics with understanding of realities that companies face. A bit about her specifically: Forsgren is co-founder, CEO and chief scientist at DORA. She is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been a professor, sysadmin and performance engineer. Her work has been published in several peer-reviewed journals. Nicole earned her PhD in management information systems from the University of Arizona, and is a research affiliate at Clemson University and Florida International University.

    Once attendees get knowledge laid on them from Forsgren, there are some intriguing sessions available in the recently released full swampUP agenda around Cloud Native DevOps, Enterprise DevOps, DevSecOps and even some really cool-looking stuff around IoT. While this may be a JFrog user conference, there are some heavy hitters involved that make this a holistic DevOps gathering, including Andy Glover of Netflix, Aaron Schlesinger of Microsoft, Jayne Groll of the DevOps Institute, Carl Quinn of Zoox, Seth Vargo of Google, Jessica Deen of Azure and John Willis of Botchagalupe, among many other powerhouse speakers.

    Of course, you’ll also see the expected lineup of JFrog experts, staff and visionaries swampUP attendees have come to know, including JFrog co-founder and CEO Shlomi Ben Haim, co-founder and CTO Yoav Landman, co-founder and chief data scientist Fred Simon, CPO Dror Bereznitsky, VP of business development Kit Merker and many more. There will be a few special additions this year, including former CEO of recently acquired Shippable Avi Cavale and JFrog VP of technology Ido Green.

    From hands-on training to inspiring keynotes and practical technical breakout sessions, swampUp is seen by alums as a premier opportunity to learn about DevOps, DevSecOps and cloud-native delivery. There’s also a full day of training and certifications for practitioners of all levels to take advantage of!

    Click here to register and join JFrog and the DevOps community at swampUP 2019.

    — Jens Eckels

  • Different Organizations, Different DevOps Outcomes

    Different Organizations, Different DevOps Outcomes

    The main motivation behind inventing DevOps platform was to help close collaboration between developers and IT operations. Basically, DevOps emerged as a great platform to bring closer together developers and beneficiaries of the app development process. DevOps initiates a cross-disciplinary practice spanning across development and operations.

    The ultimate benefit of the DevOps approach is removing the barrier between development and deployment of software applications in specific business processes. Regardless, not all businesses reap the benefits of DevOps platform.

    Does DevOps really suit all businesses of different sizes and niches? What are the key considerations for utilizing DevOps platform? These are the questions we will try to answer through this article.

    Do All Businesses Require DevOps?

    The common and widespread consensus is that any software development company geared for innovation must embrace a DevOps environment. Any business that considers innovation and smooth deployment in the software development process—a key factor in their long-term growth strategy—should take advantage of the benefits of a DevOps platform. Whenever any service provider needs to adopt new strategies to keep pace with the evolution in the software space, DevOps will come as an irreplaceable platform choice.

    Despite this consensus and widely accepted perception, there are different opinions in the market. Many industry experts believe that to reap the benefit of the platform you need to have a dedicated DevOps team in place. If you have a DevOps culture and in-house DevOps team in your company, you can gain a competitive advantage.

    The Key Benefits of DevOps

    The main benefit of DevOps is faster delivery of software with much-improved quality. There can be several other benefits depending on the industry.

    While some companies refer to the huge reduction in downtime since they adopted DevOps culture, there are still many others who simply give credit to the platform because of its integrated approach that makes the process more agile and fast-paced.

    For most companies, the domino effect of getting better software at a faster speed ends up delivering sustainable growth and revenue opportunities.

    Here’s a look at the role of DevOps platform across three types of businesses: small companies and startups, midsize companies and large business houses.

    Small Companies and Startups

    In smaller companies and startups where resources and human capital remain under-supplied, the responsibilities ascribed to developers, engineers and deployment professionals often tend to get blurred or overlap. Because of the scarcity of human resource, developers and engineers are often assigned multiple responsibilities. Naturally, in such companies, it is common to see cross-functional teams ready to engage into various development projects with ease. This makes them ideal business organizations to embrace and grow with DevOps culture.

    Midsize Companies

    As the companies tend to grow bigger in size and resources, they have a bigger (and often unbreachable) divide between verticals such as operations and development. In such organizations, staff are less likely to be open to cross-functional responsibilities, as many have been in the same job doing the same tasks and feel settled. This brings in a stagnant organizational process, where strong departmental divide rules the business process outcome.

    This stagnant work culture makes such companies less appropriate candidates to implement DevOps environment. For these companies to reap the benefits of a DevOps platform, mass organizational changes should be brought in the team structure. Building a separate cross-functional DevOps team to handle some focus projects can also be good practice for them.

    Large Companies

    Large companies enjoy the luxury and abundance of resources, and this makes them much better-placed compared to other organizations. Companies such as Amazon, Facebook, Google and Microsoft have the diversity, huge experience and robust abilities to bring together cross-functional specialists from development and operations to work on ambitious projects. These organizations are known for having product-oriented units, comprising specialists from both development and operations.

    Apart from their cross-functional expertise, product-focused approach and abundance of resources to roll on new projects, large companies also can make a big difference to the teamwork and motivation through a highly unified vision and strategic long-term objectives shared by every member of each team. This is why large companies always stand as suitable candidates to embrace DevOps approach and environment for their projects.

    Fixing the Right DevOps Strategy: 3 Things to Consider

    Beyond the organizational differences and core strengths and weakness for embracing a cross-functional DevOps approach, we must look into the key aspects that make a right strategy for any organization to incorporate DevOps into their scheme of things. Question is, despite the shortcomings and lacking, how can you embrace DevOps environment and reap the benefits? Here we provide some clues:

    • Making Change a Habit. Some strategists believe that any organizational change will face a lot of friction, causing substantial harm to the immediate business outcome. But there should be no reluctance to change for this. Rather, by bringing constant changes, people get used to the friction and pain and it becomes normal. This is one way to replace traditional IT mindset with DevOps.
    • Starting Small with a Neat Team. Obviously, finding the appropriate and credible skilled employee for your DevOps projects is not always easy. This is why it is advisable to create small startups or units, in which sharing the common vision and embracing a cross-functional approach becomes the order of the day. On top of that, do your best to bring out the best from your team and hire some experienced ones with knowledge of DevOps.
    • Continuous Development Mindset. We all know how the DevOps platform always focuses on continuous development approach. It is easier for the software developers to embrace such approach, but for operations staff, you have to slowly make them think of infrastructure as evolving and slowly building components. That’s something challenging but not impossible.

    Conclusion

    DevOps has emerged as the most promising development approach for modern software developers. Though for many development companies the friction emanating from strict role divides is becoming an obstacle, the positive push by DevOps for cross-functional approach looks indomitable.

    — Atman Rathod

  • The Key to Multi-Cloud Success

    The Key to Multi-Cloud Success

    In the era of cloud-based architectures, companies have implemented multiple cloud platforms but have yet to reap the full benefits. Whether it’s Amazon Web Services (AWS), Google Cloud or Microsoft Azure—or some combination thereof—a recent Forrester study found that nearly 86% of enterprises have incorporated a multi-cloud strategy. Not only does this strategy take companies out of the business of hosting their own applications, it also leads to benefits including avoiding vendor lock-in, reduced costs and optimized performance.

    While it’s clear that a multi-cloud strategy offers many benefits and flexibility for an organization, there are more moving parts to track (with the added challenge of hybrid, multi-generational infrastructure), making it all the more critical that businesses have a solid monitoring strategy in place. Luckily, the collection of monitoring data is essentially a solved problem; instead, businesses today are faced with an endless cycle of day-two operational challenges such as avoiding downtime and maintaining visibility.

    As Andreessen Horowitz so aptly put it, software is eating the world; every company is becoming (or has become) a software company. Software is not only ubiquitous, it’s powerful, enabling us to solve a wide range of problems. This emphasis on software within companies has led to the emergence of multiple cloud providers such as Amazon, Google and Microsoft, which all recognized the trend and seized the opportunity by building cloud computing platforms.

    Because companies no longer have to build their own data centers, they can focus on their core business of delivering value to their customers. With the public cloud, they’re able to achieve far greater time-to-value than they would if left to build their own data centers and cloud platforms.

    Today, companies can build a portable software stack that is DevOps-driven, free from vendor lock-in and capable of delivering a superior set of capabilities than can be gained from a single provider. Although we’re now consuming infrastructure from cloud providers (which has its own inherent risks), we have better tooling to enable multi-cloud strategies, minimizing the risk of being reliant on any one provider for cloud services.

    The Missing Piece: Multi-Cloud Monitoring

    In this software-dependent world, availability is critical, and downtime is not only expensive but also damaging to business reputation. As a result, monitoring systems and applications has become a core competency, crucial to business operations. To fully reap the rewards of a multi-cloud strategy and thrive in this cloud-based world, implementing a unified monitoring solution is critical for success. In addition to the existing benefits multi-cloud offers, a unified solution gives operators constant and complete visibility into their infrastructure, applications and operations.

    Surviving as a Modern Enterprise

    Improved operational visibility through monitoring is often cited as a top priority among chief information officers (CIOs) and senior operations leadership, and good monitoring is a staple of high-performing teams. Yet, too often it’s implemented as an afterthought in reaction to changes in the mission-critical systems that power businesses. When this happens, organizations can struggle to reap the benefits of multi-cloud because they lack sufficient visibility to detect and avoid problems or recover from expensive downtime.

    Further complicating this underlying challenge is the fact that ephemeral infrastructure platforms such as Kubernetes are the new normal, while digital transformation, cloud migration, DevOps, containerization and other initiatives are compelling movements in the modern enterprise. Although they vary in scope and overlap or intersect in practice, they are unified in purpose: To deliver increased organizational velocity, empowering organizations to ship more changes faster.

    While they are a boon to business initiatives and developer productivity, these practices can increase exponentially the number and duration of day-two operational challenges. Delaying adoption of the solution to these challenges only increases risk exposure and cost.

    Be Prepared for the Cloud Gold Rush

    According to Gartner, the number of cloud-managed service providers is expected to triple by 2020. While this gold rush is good news for analysts, investors and operators alike—everyone (except Amazon?) benefits from a competitive market—it suggests that the multi-cloud trend will only become more diverse moving forward. Given the already complex landscape and this forecast, it’s impractical to expect turnkey monitoring solutions to provide enough coverage—a different approach is needed.

    The good news is that the solution is surprisingly simple: Treat monitoring and observability like we do the rest of our DevOps toolchain—as a pipeline. When containerization gained in popularity and we incorporated Docker and Kubernetes into our multi-cloud strategy, we didn’t have to replace our CI pipelines; we simply shipped containers instead of RPMs, essentially making our CI tools future-proof.

    For monitoring and observability, that future-proof solution is the monitoring event pipeline. At the end of the day, there are only so many mechanisms for observing systems (APM and observability client libraries, Prometheus-style /metrics or /healthz endpoints, logs and good old-fashioned service health checks are a few great examples). Once we start to think about these as workflows that can be automated via monitoring pipelines, we’re empowered to continuously adapt and thrive (maintaining visibility and avoiding downtime) in the ever-evolving and increasingly multitudinous cloud world of IT infrastructure.

    — Caleb Hailey

  • How to Improve DevOps Visibility

    How to Improve DevOps Visibility

    DevOps, by design, works quickly and accomplishes deadline-driven projects rapidly. With a high amount of project turnover, visibility into key operational data is easy to mismanage and can lead to simple mistakes, lack of optimization and organizational misalignment. To examine the effect of DevOps visibility, SmartDraw commissioned the “2019 DevOps Visibility Report.” The results were decisive: Each company surveyed is seeking ways to better DevOps visibility, and 84% of respondents list it as somewhat to extremely important to their organization. But achieving DevOps visibility is not always simple.

    Roadblocks to Achieving DevOps Visibility

    Respondents identified that visibility reports take skilled workers away from their other priorities. In a small, fast-moving lean team, removing a skilled worker from a key deadline-driven task can cause performance and timeliness to suffer.

    Further, the reports often are visually complex and not useful. If the team member creating the visualization is unable to design it in a simple fashion, the report is often wasted effort as it provides no actionable insights.

    Finally, and potentially the most harmful, the reports are static and do not accurately represent the current state of information. DevOps teams are meant to be agile, and poor report updating practices can lead to stale data. When that stale data is used to make decisions, organizations lose productivity and quality.

    So, what should DevOps managers do to improve this process?

    Key DevOps Visualization Recommendations

    The “2019 DevOps Visibility Report” uncovered four insights to improve operational visibility and efficiency with expanded real-time DevOps data visualization:

    • Avoid building static reports in spreadsheets: Spreadsheets, while effective at data analysis, are not the correct medium for visibility reports. The static data quickly become out of date and useless. In today’s modern business landscape of rapid change and competition, any manual work becomes a risk to an organization’s decision-making ability.
    • Present common DevOps information in an easily comprehensible manner: Respondents reported challenges in reporting data in a way that a variety of audiences could comprehend. These reports are designed to be consumed by multiple levels of the organization, with varying degrees of technical knowledge. The most successful respondents focused on visualizing data in an easy-to-understand way.
    • Adopt low or no-code solution for visualizing unique relational data: By utilizing a solution that is fully or mostly automated, organizations allow their skilled team members to prioritize deadline-driven work. Further, this automation allows for improving real-time information and lessens the likelihood of stakeholders making decisions based on old, outdated data.
    • Create self-service reports that enable non-engineers to visualize DevOps data without submitting change requests to engineering: It’s crucial to be able to remove DevOps team members from the update process. Key stakeholders should have the ability to generate a report easily and without input from DevOps. Additionally, this report should be based on existing source data, and should allow for anyone to drill further in to see the raw numbers that the visualization is drawn from.

    Conclusion

    A good DevOps process improves quality, lowers cost and saves time. Yet, poor visibility can limit DevOps success and lead to misalignment. Organizations should adopt an automated real-time DevOps visibility solution to allow team members to focus on the crucial pieces of their role, provide relevant information to managers and create digestible visualizations.

    — Joshua Platt

  • 5 Mistakes to Avoid When Chasing DevOps Transformation

    5 Mistakes to Avoid When Chasing DevOps Transformation

    In less than a decade, DevOps has become a buzzword of the IT industry, and enterprises are already reaping its benefits.

    But the implementation part still remains a question for many firms, considering the key mistakes that many organizations report in their very approach to DevOps. Most firms are also unsure about what outcomes they want to see from the process.

    Wondering if you’re making the same mistakes? Here are the five most common mistakes that can be included as part of a checklist to successful DevOps implementation.

    Misaligned Focus

    While automation and tools are the elements that steer DevOps, most firms believe that DevOps is all about tooling and automation. In reality, tools are mere enablers and automation takes off the burden of manual work. This collaboration helps firms to realign focus, eliminate process repetition and effectively manage the available software.

    Ultimately, the value of tools lies in what people achieve through them and hence, firms should focus on utilization to achieve expected goals.

    Faster = More Value

    Time-to-market is another key aspect of DevOps that needs a different viewpoint. In general, most firms think of DevOps as a process to increases the pace of the software process.

    But it has to be understood that DevOps takes a lean movement. By developing software on an exponential pace, DevOps process lets you have products delivered more frequently.

    The lean manufacturing process achieves success in software delivery by breaking the chunks of code into manageable units, which naturally results in continuous delivery. Moreover, if you need to alter one component, you can do it simultaneously without impacting the other. This allows you to deliver at optimum speed and still maintain business agility.

    Lack of Continuous Improvement

    As you learn more and get better, you’ll find better ways to improve or cut down steps that add no value. But this will require some amount of effort and investment.

    DevOps delivery pipeline consists of feedback loops, which allow you to inspect, reflect and decide if you are going in the right direction. The faster you improve, the sooner you benefit from the improvements in the process.

    It’s just not about reviewing the process twice a year or every quarter. Continuous improvement demands that every individual part of the DevOps process should get better all the time.

    Dishonesty About Your Progress

    It is important to be clear about goals and timelines as an individual contributor in the software development process. A delay from an individual contributor can lead to a delay on everyone’s part in the process. This also adds to the lack of trust on a team’s potential.

    Whether it is about building features or changing processes, make realistic estimates. It is important to break your tasks into smaller pieces, making it easier for estimates.

    Change Comes Easy

    Change is a part of the growth process and it’s inevitable. But most people fail to adapt to change and continue with familiar patterns, especially when change is difficult.

    It is important to keep adapting to changing trends in the industry, processes and technological advancements including the software delivery lifecycle to evolve and grow, even when it is tough. Increased success will always bring more willingness to change.

    Conclusion

    DevOps is a process that drives innovation and business growth at a faster rate, provided you keep a check on the pain points that hinder the successful DevOps implementation.

    — Veritis

  • Digital Transformation: Measuring What Matters

    Digital Transformation: Measuring What Matters

    As enterprises strive to digitize their organizations, whether it’s digitally transforming aspects of sales and marketing, customer interactions or supply chain, they’re undergoing a wholesale revamp of traditional businesses into digital business models. While some companies are just getting started, as we covered earlier this month in Digital Transformation: Coming from Behind, the bulk of those enterprises that have already embarked on digital transformation efforts—70% according to some findings—fail to meet their objectives.

    How do enterprises flip such statistics around? We reached out to a group of experts to find out, and collected their thoughts on how organizations can attain better digital transformation results through better quantification of their efforts.

    It sounds simple enough, as Cyril Attia, CEO at BeMyApp puts it: Success should be measured in alignment with the key performance indicators (KPIs) of the business. He said, when advising his customers, he makes certain “one of the main focuses is to identify if these efforts are directly related to bringing in or maintaining clients which ultimately have an impact on the bottom line.”

    Stay Focused on Core Business Objectives

    Not staying focused on core business goals is at the essence of the challenge. “One of the reasons that digital business transformation is so ambiguous, and in an overall sorry state, is that the objectives are not clear,” said AgilePoint CEO Jesse Shiah. Organizations should make themselves clear about their desired outcomes and what it is they specifically seek to improve, he said, adding this is best achieved by tying digital transformation initiatives to key performance indicators that can best determine the health of the business.

    “Through your efforts, are you making progress against those goals, do you need to adjust course? Once you’ve found a successful formula, think about how that success can be replicated in other areas of the business,” he said.

    Kyle Hutchins, a senior director at business and technology consulting firm West Monroe Partners, agreed. The key to initial success is identifying the right KPIs, starting small, and proving out the viability of the idea, he said.

    “Success metrics should be tied to your overall business strategy and not live as a standalone set of KPIs. Once you have a short list identified, ensure you are tracking the progress and able to measure the impact,” Hutchens noted. “When you have a win, share the success broadly within the organization, tie (it) back to your digital vision and use that as an entry point into other areas of the business.”

    Shift to Value-Based Measures

    Dave West, CEO and product owner at Scrum.org contended that, when it comes to measuring digital transformation success, traditional motion metrics such as velocity, as well as efficiency on time and budget measurements, should be replaced with external value-based measures that will establish the baseline that the effectiveness of change will be measured against. “For each value stream or customer aligned team, the measures will be unique. For instance, value for one customer might be a net promoter score; for another, it might be direct revenue. However you measure value, there are three types of things that should be considered: current value, time to value and innovation,” he said.

    West defines current value as to how one directly measures the current value of your product and can include measures such as numbers of users, revenue, profitability and brand. While time to value ratios, how long it takes to deliver from an idea to its implementation? When it comes to measuring innovation, West says, innovation should be measured as the percentage of new stuff versus fixes/infrastructure being changed when a release is made.

    Attia added that such effective KPIs will indicate if outputs are being achieved faster or cheaper, ultimately decreasing overall costs and improving profits.

    Hutchins said there isn’t a single list of magical KPIs, and points to a set of questions (suggested by Gartner firm) designed to help create digital KPIs:

    • What is being measured?
    • Where are we today?
    • What is our target goal?
    • What is the desired business outcome or benefit?
    • What is our balance point?

    Craig Besnoy, program director and digital strategy consultant at Mindtree, has a straightforward way he suggests companies look to track their success. That’s by the internal popularity of the program. “Companies should track their success based on the number (of) departments in the organization that are requesting access to the digital transformation program,” he said. “Once the organization experiences the increased efficiencies and revenue that digital transformation can bring, managing the requests will be the biggest challenge.”

    — George V. Hulme

  • What Can Automation Learn From DevOps?

    What Can Automation Learn From DevOps?

    A recent Capgemini survey revealed that while enterprise-scale automation is still in its infancy, IT automation projects are moving along. IT is starting to view automation less tactically and more strategically.

    IT leads automation implementation (respondents were asked to select all that apply: “In which of the following functions has your organization implemented automation initiatives?”). Capgemini Research Institute, Automation Use Case Survey; July 2018, N=705 organizations that are experimenting with or implementing automation initiatives.

    The Capgemini survey also showed that IT automation can be responsible for several quick wins, including self-healing, event correlation, diagnostics, application releases, cybersecurity monitoring and storage and server management tasks. These projects not only lead to massive IT cost savings but, more importantly, to an increase in reliability and responsiveness to customer demands and business services. That would indicate that while automation is a great solution for manual work, it’s also a part of a high-level, strategic IT plan to innovate the business.

    As DevOps practices such as agile methodology, continuous deployment and optimization start to take hold within the modern enterprise, it stands to question: Can automation be agile as well? This is the promise of artificial intelligence (AI) for IT operations, or AIOps, but if that’s not a possibility for your IT organization today, it’s important to make sure that your automation practices are continuously optimized to fit the task. Setting and forgetting was a practice of the server era, and in a world of on-demand infrastructure, automation ought to be continuously optimized and evaluated for maximum benefit.

    The New Expectations of Automation

    IT automation projects can have serious ramifications if anything goes wrong because when the machines execute a policy, they do it in a big way. This is perhaps the chief argument as to why it’s critical that progressive steps are used to define and evaluate both the process being automated and the automation itself—they mitigate the seriousness of any issue that can arise. This is why it’s important to consider the following:

    1. Is this a good process, and is it worth automating?
    2. How often does this process happen?
    3. When it happens, how much time does it take?
    4. Is there a human element that can’t be replaced by automation?

    Let’s break down these steps and see how it can provide the basis for an iterative approach to automation:

    Is this a Good Process?

    This may seem like a rudimentary question, but in fact, processes and policies are often set and forgotten—even as things change dramatically. Proper continuous optimization or agile automation development will force an IT team to revisit existing policies and identify if it’s still right for the business service goals.

    Some processes are delicate and automation may threaten their integrity, whereas others are high-level and automation neglects the routine tasks that underlie the eventual results. A good automation engineer understands what tasks are best for automation and sets policies accordingly.

    How Often Does this Process Happen?

    Patching, updating, load balancing or orchestration can follow an on-demand or time-series schedule. As workloads become more ephemeral moving to serverless cloud-native infrastructure, this process’s schedules will change as well. An automation schedule ought to be continuously adapted to the workload need, customer demand and infrastructure form. As the business continues the march toward digital transformation, the nature and schedule of particular work may become more dynamic.

    When It Happens, How Much Time It Takes?

    This also depends on the underlying infrastructure. Some legacy systems require updates that may take hours and some orchestration of workloads will be continuous. Automation must be tested to be efficient and effective on the schedule and frequency of the manual task.

    Is There a Human Element that’s Irreplaceable?

    As much as you may want to, it’s difficult for automation to shift left (to more experienced tasks and teams) without the help of AI or machine learning. Many times, there is a human element involved in deriving insights, creating new workflows, program management or architecture that take place. When building an iterative automation practice, make sure you identify where human interaction must occur to evaluate and optimize. In our lifetime, technology has advanced at lightning speed, with robots now completing jobs that were once held by people. However, there are times when a machine just cannot deliver the same quality a human can.

    Automation for All

    Automation is perhaps one of the most defining signatures of the future of IT operations management. It relieves teams of routine work and helps improve overall efficiency, all while driving quick wins that turn an IT team into heroes. But don’t let automation be the end goal. Instead, consider it a tool that can drive action from data. And until AI is an everyday option, it’s inherent on the IT professional to continuously optimize the data that drive that action.

    — Bhanu Singh

  • DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    DevOps Market Consolidation Gets Real: CloudBees Acquires Electric Cloud

    You may have already seen the news today: CloudBees has acquired Electric Cloud in a move that marks a true market consolidation in the DevOps space. I had a chance to speak with CloudBees CEO Sacha Labourey to discuss the acquisition. We discuss the motivation for the deal, what the combined entity may look like going forward and more. The video of our conversation is at the bottom of this article.

    In my mind, this acquisition represents true consolidation of the DevOps tool vendors market. My reasons for this are as follows:

    1. Until now, many of the acquisitions in the DevOps space have been by large, established public companies such as CA, HP or IBM. Typically, these kinds of deals are not as much consolidation as they are large companies using M&A activity in place of R&D. CloudBees is not a large vendor—this isn’t R&D dressed in an acquisition.
    2. Electric Cloud is not your typical venture-backed startup that is looking for exit opportunities. The company has been around for many years. It has a large base of enterprise customers and an enterprise-tested product.
    3. With the recent changes in the DevOps vendor market involving CA (now Broadcom), HP(E) now Micro Focus and IBM preoccupied with Red Hat, there is a vacuum for enterprise leadership. The combination of these two vendors of scale is really a consolidation move.

    Best of luck going forward and congratulations to our friends at CloudBees and Electric Cloud. It will be interesting to see what repercussions this deal brings to the rest of the DevOps market.

    For more details on the acquisition, check out Mike Vizard’s article in devopsy.kinsta.cloud today. In the meantime, enjoy the video and conversation with Sacha. Also, let us know what you think about the acquisition—and other M&A activity in the DevOps space—in the comments section below.

    — Alan Shimel

  • CloudBees Acquires Electric Cloud to Advance Continuous Delivery

    CloudBees Acquires Electric Cloud to Advance Continuous Delivery

    CloudBees announced it has acquired Electric Cloud as part of an effort to extend the reach of its DevOps portfolio further into the realm of continuous delivery and application release automation (ARA).

    Announced at the CloudBees Days event in San Francisco, the deal follows CloudBees’ acquisition of Codeship, a provider of a cloud-based continuous integration/continuous development (CI/CD) platform, last year.

    CloudBees CEO Sacha Labourey said both deals are part of an effort to start rolling up many of the smaller companies providing DevOps tools that have not been able to achieve the critical mass required to operate at scale. As organizations of all sizes realize how much they depend on software to differentiate their company from competitors, he said, they are looking for a single vendor that can address all their requirements end to end. At the time of the acquisition, which closed earlier this month, Electric Cloud had 110 employees.

    Labourey added the acquisition of Electric Cloud is also notable because it extends the reach of the CloudBees Jenkins and Jenkins X CI/CD platforms to the realm of application delivery for both legacy applications and emerging modern applications based on cloud-native microservices architectures.

    While application development teams have largely embraced continuous integration, getting IT organizations to successfully implement continuous delivery has proven more challenging. The next phase of DevOps, Labourey said, will need to focus on applying machine learning algorithms to automatically discover the environment in which an application is to be deployed. Armed with those insights, it should be much easier for organizations to continuously deploy and update applications across diverse IT environments, he noted.

    As DevOps continues to evolve, it’s apparent that legacy categories such as application release management are going to be subsumed into larger software development lifecycle frameworks based on best DevOps practices. The debate many organizations are currently engaged in is determining how much they need to change their IT culture before acquiring the tools and platforms required to successfully adopt DevOps. However, Labourery said this “chicken and egg” debate overlooks the importance of getting the tools to the teams that need to make the transition to DevOps occur. Otherwise, IT leaders will find themselves advocating for a theoretical cultural change without creating the opportunity for anyone to gain hands-on DevOps experience, he noted. In short, there’s no substitute for on-the-job DevOps training.

    A consolidation of DevOps vendors is underway. In some cases, those acquisitions will be driven by leaders in a category, such as CloudBees. In other cases, providers of software development tools commonly used in legacy application environments will need to extend their reach further into the realm of DevOps. IT leaders, going forward, will need to consider carefully just how and where they want to place their bets, at a time when DevOps teams tend to add and discard DevOps tools, often with little to no regard for any larger IT strategy.

    For more insight on the CloudBees/Electric Cloud acquisition, check out Alan Shimel’s video conversation with Sacha Labourey.

    — Mike Vizard

  • Python’s Popularity Continues: Examining the Top Use Cases

    Python’s Popularity Continues: Examining the Top Use Cases

    Python continues to be one of the most popular coding languages in use. In fact, the TIOBE index of programming language popularity named it the 2018 Language of the Year. Its usage and adoption continue to grow and proliferate into additional use cases.

    Python’s popularity and growth are in part because it’s flexible and easy to use. Python has grown from a scripting solution for sysadmins to web development for programmers to the driving force behind machine learning. We’ve observed this growth since 1999, when we began to build engineering Python distributions. As we’ve seen the use cases grow, we’ve examined the top use cases by customers ActiveState has observed.

    Let’s look at the three most popular Python use cases within the traditional tech space: infotech, software and hardware.

    Infotech: IT modernization

    The IT team of a state legislature is challenged to be able to remotely manage thousands of user desktops. Its 147 representatives, as well as its hundreds of supporting personnel, work on-premises and/or remotely. One of the key tools that empowered the team was Windows Powershell. Unfortunately, Powershell is unsupported and no longer works under newer Microsoft operating systems.

    Rewriting any application that’s a cost center is always difficult to justify. As a result, rewrites are rarely budgeted, planned and resourced appropriately. But the alternative was much costlier in terms of capital and resources: dispatch IT personnel to physically install, update and manage each user’s desktop, on an on-call basis.

    It’s famously easy to get started and develop with Python. While there was no way around a rewrite of the desktop management scripts, the IT team could at least minimize the time and resources required. Python allowed Powershell script rewrites to be done incrementally in IT’s spare time. This translated into a significant lowering of costs, and reduction in the risk of a “big bang” rip and replace project.

    Software: Adding Extensibility to Legacy Applications

    A U.S.-based public company has a 30-plus-year history of providing a suite of electronic design automation (EDA) tools to their more than 5,000 customers worldwide. Its suite of tools historically was built in C++ and is packaged for deployment on-premises.

    Because each customer has their own instance, it’s natural for the customer to want to customize the suite of tools to their needs. The U.S. public company used Python to wrap some of its C++ APIs to expose key functionality, making their software solutions more extensible by customers. Ensuring Python was deployed properly at customer sites required including Python within their existing installer, rather than relying on their customers to install Python correctly.

    The company used an OEM distribution Python that added a standard version of Python within their application and deployed it, so all teams can customize and leverage the EDA tools as required. Plus, by deploying a standardized Python version across all customer sites and developer desktops, the company can decrease support costs and speed time to market by eliminating the need for legal department reviews. Further, using a third-party-standardized Python version eliminates the opportunity cost of managing one’s own Python build and can facilitate the discovery of issues, bugs and performance issues.

    Hardware: Automating Network Administration

    A Silicon Valley-based American technology leader develops, manufactures and sells networking hardware. A key enterprise demographic for the company is network administrators, who often are confronted with managing the vendor’s multiple devices across extended corporate networks.

    The challenge: Network admins aren’t typically developers. Yet, they want to improve their efficiency by being able to programmatically make configuration changes to multiple network devices at once. While sample scripts are easy for any network admin to use and modify, the vendor did not want to be held responsible for creating all the scripts its user base might require.

    Python was the solution because it is simple enough for any technical person to learn and start using effectively. The company chose a version of Python that allows their customers to quickly create sample Python scripts to cover the majority of typical network admin use cases.

    This choice also allows network admins to create Python libraries they can leverage to create their own custom scripts to manipulate the configuration, operational state or event data from network devices. Most importantly, the cost of administering enterprise networks is significantly lowered and network admins are dramatically more efficient with programmatic access to physical networking devices and virtual network resources.

    Looking Outside the Tech Space

    Other examples that round out the top 10 use cases for Python include:

    • Consulting services: Bespoke web development.
    • Insurance: Creating business insights with machine learning.
    • Finance: Data mining to identify cross-sell opportunities.
    • Retail banking: Flexible data transformation and manipulation.
    • Aerospace: Meeting software system deadlines.
    • Business services: API access to financial information.
    • Health Care: Predicting disease prognosis.

    Ongoing Innovation

    Python’s usage continues to grow due to its simplicity and flexibility. Developers clearly want to use it for a variety of reasons that surpass its creator’s original intent. To support this usage, organizations need to ensure their developers can do so securely, by overcoming open source vulnerabilities while still iterating quickly. It seems that use cases for Python are limited only to the imaginations of its growing, enthusiastic user base.

    — Bart Copeland