Category: Enterprise DevOps

  • How Not to Sabotage Your Multi-Cloud Strategy

    How Not to Sabotage Your Multi-Cloud Strategy

    The immense pressure for enterprises to deliver new applications and insights that exploit new business opportunities has been a driving force for digital transformation. This, in turn, has led IT leaders to embrace a multi-cloud strategy—whether that’s deploying a combination of cloud platforms such as AWS, Azure and Google, or extending private data centers to the public cloud—to achieve greater agility, optimized performance and cost savings resulting from deploying workloads across multiple cloud platforms.

    However, maintaining multiple cloud platforms and services adds complexity and even confusion to enterprise IT environments already crowded with a range of technologies, applications and processes. While a recent Forrester study shows that enterprises are increasing investments in using multi-cloud strategies for business-critical applications and workloads, the majority of these enterprises also report that they experienced issues with deploying and using multi-cloud environments.

    The difficulty in managing IT environments made more complex by multiple cloud services involves three major issues: ignoring the importance of cultural transformation, not addressing the widening skill set gap and implementing a DIY approach to cloud management.

    Here are three ways to deal with these challenges, so you don’t end up sabotaging your multi-cloud strategy.

    Make Culture Change a Priority

    The cultural transformation required to support digital transformation and to fully take advantage of multi-cloud’s power is more than shifting the organizational mindset from capex to opex. It’s also more than picking one or a combination of the big three cloud providers and simply saying, “Let’s do this.” It requires building trust and breaking down the silos of technology knowledge—whether vendor, legacy or emerging technologies—across disparate IT teams to achieve the business goal of speedier application development and faster time to market.

    Specifically, this culture change requires better collaboration between teams and arming central IT with up-to-date processes and management platforms that are focused less on managing infrastructures and more on achieving a balance between visibility and resource control, the linchpin for IT, and creativity, the true north for developers. It will have parameters in place for provisioning resources while helping developers get the resources they need—compute, storage, network services and more—as quickly as possible.

    Culture change also enables the maturing of DevOps processes toward streamlining and bringing order to the clutter and smooth partnerships with other IT teams, especially security and operations. These include processes to eliminate bottlenecks in workflow, to advance automation and self-service, to consolidate resources and to make security integral to—rather than an afterthought in—the development process.

    Invest in Building Expertise in Multi-Cloud and Emerging Technologies

    The more cloud environments an organization has, the more skills and tools are needed to be able to deploy and optimize these environments efficiently. Despite increasing commoditization in the industry, there are still differentiators between cloud vendors and their services, and ways to leverage these to align with an organization’s specific needs. To do this, it is crucial to train the internal DevOps team or hire experts in multi-cloud environments and in key technologies for advancing multi-cloud such as containerization, microservices and serverless computing.

    Additionally, a cloud management platform that provides self-service IT and enables any user to provision, manage and orchestrate IT resources, will allow both end users and admins more time to focus on getting high-quality work done.

    Select a Cloud Management Platform that’s Right for You

    Cloud management platforms address the complexity of hybrid and multi-cloud environments by providing a central platform that allows a selection of the clouds and services that best fit an organization’s needs. They also enable IT to connect to any third-party resource, whether that’s VMware on-prem, AWS in the public cloud or container orchestrators such as Kubernetes, to gather the inventory of cloud computing resources and to provision new resources to be used by anyone in the organization from one place. Self-service IT can also be enabled when appropriate.

    In addition, by ensuring cloud management platforms are built on a single pane of glass, IT can gain a holistic view of hybrid and multi-cloud environments. It also allows effective monitoring of resource utilization across those environments, thus ensuring that cloud spend is not only reined in but also optimized.

    Finally, a cloud management platform should connect both legacy and new technologies within cloud environments. Although the complexity will not go away, it gets easier to manage. Instead of having multiple teams from different departments managing and accessing resources in separate environments, a central team handles complexity with enterprisewide visibility and control.

    The way to succeed is to embrace the complexity by configuring it and managing it behind the scenes, so developers and end users consume IT resources from one consistent way, regardless of where it comes from. Leave the complexity to the cloud and IT architects and let your end users and developers get to work.

    — Brian J. Kelly

  • RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX Eases Oracle Database Migration to PostgreSQL on AWS

    RDX this week launched a set of tools designed to make it easier to convert applications running on an Oracle database to Amazon Aurora, an instance of an open source PostgreSQL database running on the Amazon Web Service (AWS) cloud that is compatible with Oracle databases.

    Announced at the AWS Summit event in Washington D.C., the clckwrk Refactoring Service for Oracle promises to reduce the amount of manual effort associated with refactoring applications for the Amazon Aurora platform by automating as much as 60% of the database schema conversion process.

    James Ball, chief strategy officer for RDX, said in addition to reducing costs, many organizations want to shift applications to open source databases in the cloud to further their DevOps ambitions. Each time an application needs to scale, an organization will incur additional Oracle licensing fees. In contrast, an open source database enables DevOps teams to scale database instances as required automatically, he said.

    AWS has been making a concerted effort to convince customers to give up proprietary databases in favor of open source databases running on its cloud platform. That competitive pressure is a driving force behind new alliances that previously would have been considered unimaginable. Oracle, for example, recently partnered with Microsoft to promote the integration of the Oracle Cloud platform with the Microsoft Azure cloud. Oracle would prefer its database run on its cloud, but through the alliance is signaling its willingness to work with Microsoft to deploy Oracle database on Azure, a cloud platform that is the leading industry alternative to AWS. Microsoft, of course, has its proprietary database to adopt in the form of Microsoft SQL Server.

    Ball said RDX not only provides tools to accelerate the conversion to Amazon Aurora, but it also provides managed services for customers that want to outsource the management of Amazon Aurora to RDX.

    It takes most organizations several months to migrate a legacy application on to a public cloud. AWS has a vested interested in helping accelerate that process whenever possible. But many organizations that have embraced best DevOps practices find their efforts are hampered by reliance on proprietary databases. In fact, one of the reasons so many developers tend to favor open source databases is to avoid all the headaches associated with getting approvals for new database licenses.

    It’s unclear to what degree the rise of DevOps in the enterprise will ultimately shift database allegiances. Oracle is trying to maintain as much control as possible by making its databases available as a managed service that eliminates some of the purchasing overhead associated with spinning up new instances. However, the cost of an Oracle database license is still buried in the cost of the managed service.

    Not every organization is looking to transition away from a proprietary database, but there is now enough momentum around the “open source first” movement to make it worthwhile to build tools that automate the refactoring of legacy databases not just to reduce costs, but also to make IT a lot more agile.

    — Mike Vizard

  • Akamai Extends Reach to the IoT Edge

    Akamai Extends Reach to the IoT Edge

    Akamai today unveiled a strategic initiative to extend the reach of its global network out to applications deployed on the network edge.

    Announced at the Akamai Edge World conference, the Edge Cloud portfolio will consist of a mix of existing, new and forthcoming offerings. In terms of new offerings, Akamai launched IoT Edge Connect, which provides access to the Message Queuing Telemetry Transport (MQTT) protocol that gives internet of things (IoT) applications access to a publish-and-subscribe service. Akamai claims IoT Edge Connect will scale to support hundreds of millions of endpoints and is capable of processing 10 times more messages than other IoT or in-app messaging cloud solutions. Those capabilities not only will optimize data delivery, but also should also reduce the amount of power devices will need to send messages, according to the company.

    Scott MacGregor, senior director of engineering at Akamai, said IoT Edge Connect will join Akamai Over The Air (OTA) Updates, an existing service for updating applications using a wireless cellular network, in the Edge Cloud portfolio. Those two offerings will be joined in the future by a key-value store that will make it possible to store data on a local IoT gateway and a tool for running functions on an IoT endpoint, he said.

    Akamai intends to provide the same capabilities it makes available to web applications to a new generation of edge computing applications that need access to a global network, MacGregor noted. In some cases, the data those applications need to access will be stored on local gateways. In other cases, the data being accessed will be stored within the network managed by Akamai. DevOps teams tasked with building IoT applications would view the Akamai network as just another platform they need to push code to from whatever continuous integration/continuous deployment (CI/CD) platform they choose to employ, he said.

    In general, MacGregor said many organizations underestimate the challenges associated with building and deploying distributed IoT applications at unprecedented levels of scale. IoT applications that span global networks are challenging to build, and the processing occurs at the edge, on local gateways and in the cloud.

    Akamai, of course, is not the only provider of a global network looking to entice organizations to leverage their infrastructure to deploy edge computing applications. Everyone from carriers including AT&T and Verizon to cloud service providers such as Amazon Web Services (AWS) and Microsoft are making similar cases. It’s too early even to hypothesize which platform providers might ultimately triumph. Akamai, however, is counting on its relationships with developers to become an edge computing force to be reckoned with, said MacGregor.

    Akamai made its mark in the enterprise by providing a global content delivery network (CDN) that web developers leverage to extend the reach of their applications by leveraging cache memory Akamai makes available on a global network. Since then, the company has been extending the service to include a range of security services that isolate web applications from various potential threats. If Akamai has its way, those same services soon will be pervasive across a broad range of edge computing applications.

    — Mike Vizard

  • The Human Value in Automation-Driven DevOps Testing

    The Human Value in Automation-Driven DevOps Testing

    Enterprises are embracing DevOps underpinned by automation to ensure the quality of software across all digital touchpoints. In fact, automation has become the crux of continuous integration and delivery, the vital DevOps testing goals. Without automation, DevOps would become a distant dream, and businesses would struggle to keep pace with seamless delivery and integration. However, DevOps entails more than the implementation of the latest automation tool and demands a more holistic approach. It does so by bringing together processes, people and technologies under a shared vision. As defined by Microsoft, DevOps is the coalition of products, people and processes to facilitate the seamless delivery of value to the end customers.

    DevOps is considered to be the latest advancement of the agile movement. It includes a greater number of stakeholders in the process of delivering value by linking the silo-based teams. It may not be the best practice, but it’s a discipline of people-centric management. Continuous delivery is the technical foundation of DevOps automation, which extends to the agile foundation as well. The close collaboration between the operations and development teams is known as DevOps, which is used to automate the delivery pipeline.

    Role of Automation in DevOps to Increase Productivity

    Since digital transformation has taken over the current business model, more and more companies are embracing the DevOps practice to drive the automated deployment of software. We are shifting toward an organizational culture in which development and testing take place simultaneously, quickly and more often. This helps maintain consistently high ratings on the quality of software with faster turnaround time. The main agenda of DevOps testing is to derive quality outcomes all along the software development life cycle (SDLC) and beyond. So, with the help of DevOps culture, a new code of development, testing and delivery is introduced in the overall SDLC.

    The automation in DevOps empowers companies to:

    • Enhance the reliability, re-usability and quality of all components.
    • Save costs of upgrades and maintenance.
    • Improve the rate of success for standardized processes to ensure the rapid delivery of applications.

    Automate Everything — Is It Even Possible?

    With the help of the DevOps approach, developers automate and accommodate operational activities, from the source code commit to operational productivity. The primary goal of DevOps automation is to remove bottlenecks in the pipeline by implementing automation in a single level of development. However, DevOps is not a fully automated process and is not operational without human intervention. It is the DevOps testing specialists who are responsible for the process to run flawlessly. Governance at every stage of DevOps testing is still indispensable in various processes undergoing automation. Importantly, human administration is still crucial in handling exceptions to complete the tasks of automation.

    The Strategic Role of Humans in DevOps to Ensure a Continuous Pipeline

    Remove the Boundaries of Roles

    The primary feature of DevOps automation culture is about an enhanced collaboration between the operations and development teams. It has led to a cultural transformation at the organization’s level and inside the teams as well, to encourage continuous delivery. Since shared collaboration is an important aspect of the DevOps culture, it strengthens the collaboration within teams. Before the DevOps approach, the perceived lack of interest by the development team regarding maintenance and operations used to affect DevOps testing and business goals. However, this scenario has since changed due to an organizational shift toward automation and DevOps testing.

    The gap between the silos of operations and development no longer exists with the arrival of DevOps. It has removed the boundaries of several organizational roles. Teams are required to focus on the shared goals of DevOps to enhance the end user experience, so the team members need to rethink every investment and decision around this shared goal, which requires human intervention. Automation cannot substitute the decision-making process of humans, for the latter has become vital across the organizational ecosystem as, and when, needed.

    Omit One-Size-Fits-All Approach in DevOps Testing

    Automation cannot be viewed as the eliminator of roles. The organization still requires expert knowledge and skill set inside your team. The focus should be on developing agile and cross-functional teams that are recognized for removing long-established stumbling blocks between the operations and development teams, and for facilitating collaboration. Developing efficient and functional teams would ensure the delivery of superior quality products.

    Continuous Monitoring, Testing and Improvement

    One of the key agendas of DevOps testing is to carry out a deeper level of monitoring. Since rigorous monitoring is needed at every layer of the testing process, from integration to infrastructure and transactions to components, it has become a crucial part of the road map of the DevOps approach. In this digitally connected world, monitoring and testing are no longer distinguishable. Continuous monitoring by testers offers a positive response to the user experience while eradicating pre- and post-production obstacles.

    Conclusion

    With the impetus in the growth of DevOps and agile practices in the past few years, testing has taken a new structure and form. It has evolved into a crucial discipline, and it’s not restricted to a phase of the development cycle anymore. It has become an essential part of the operational activities of production. So, is the role of a tester transformed radically from only a checkpoint to a crucial active participant in the DevOps testing? Teams need to cooperate based on the shared vision of enhancing augmented user experience. We need to understand the fact that automation is not an elixir to deliver on DevOps goals, but merely a part of the DevOps strategy.

    — Komal Lopez

  • Scalability in the Age of DevOps: A Must for Success

    Scalability in the Age of DevOps: A Must for Success

    DevOps seems to be an emerging topic “du jour” in the world of software development. And like it or not, it is showing no signs of slowing down. If used correctly, DevOps can be helpful—from making teams (developers and testers) work seamlessly to automating routine tasks, DevOps has proved its awesomeness in just a few years. So what is helping make DevOps a huge success? Scalability!

    Technically speaking, scalability is something that defines the exact capability of the system, and it has to increase frequently to accommodate the ever-changing needs of the world. As customers rely more heavily on your services, achieving hyper-scale is becoming more crucial. To ensure scalability, you may need to redesign or rethink, your different processes and systems.

    Say, for instance, customer demand seems to have reached its apex. Preparing comprehensive strategies that focus on scalability has become prime importance.

    To get the most out of your application, invest in DevOps-related time and dollars. With the introduction of the cloud, developers are focusing on building features and products while ops (operations) are making sure everything stays in sync. At the same time, many traditional ops functions have been outsourced to cloud providers.

    Scaling DevOps    

    Here are some best practices that can assist you in creating scalable, secure and high-performance deployments.

    Be Vigilant

    With the increase in the adoption of visualization, networks are more complex and heterogeneous, and so are the security risks associated with them. The only way left to manage these networks is by automating key management functions. Here is when DevOps comes into play. But for that, the method must be included with security as a key component, or the volume and pace of network would eventually change—several technologies such as SDN and virtualization will skyrocket the level of IT risk like never before. Another challenge is that security is still considered as an afterthought. And so-called business inhibitors are seen advising an organization on what can’t be done instead of how to do things securely. This is an area where security, developers and operation teams must foster a level of trust, or collaboration won’t exist. The only way to do this is incrementally and with vigilance.

    Watch Changes Carefully

    Considering DevOps as a collaborative mindset enforces professionals to come up with faster and more efficient ways to deploy, operate and upgrade applications. When new releases are delivered, several tools can ensure consistent configuration of infrastructure and software components. These tools also can be used to remediate security concerns by constantly validating the proper application of security’s best practices and taking automatic countermeasures.

    Ease of Use

    Automation and repetitiveness are what DevOps is all about. Fortunately, there are a few tools that are capable of automating the building and configuration of VMs. However, make sure you have the adequate horsepower to run this capability, either in-house—which is trickier to scale dynamically—or in the cloud, if your product is amenable to that. At the end of the day, it’s all about how you make your product installation and configuration easy.

    Managing Gateways

    While building any new goal or coming up with the best culture between development and operation teams, keep certain gates between functions to ensure that the production environment remains stable. Try to structure it in such a way that operations include development discussions and daily scrums. By doing this, operations teams simultaneously will understand what changes will be made in future releases. By integrating automation in both testing and operations, you will be able to find issues before they reach production. In addition, you’ll realize cost efficiencies and better quality operations.

    Conclusion

    In today’s fast-paced development environment, a well-thought preparation strategy for mass scalability is a must to make the entire process smooth and easy. DevOps reduces lead-up anxiety by getting a head start on planning, so you have more time to enjoy the fruits of your labor. Adding scalability in your strategy enables you to experiment and try new things without fearing failure. Testing new approaches ahead of time to see what does or doesn’t work will only help you learn and make your scalability efforts that much more effective for the future, as your company continues down the path of hyper-growth and hyper-scale.

    — Herman Morgan

  • Acquisitions to Fuel Programmable Analytics

    Acquisitions to Fuel Programmable Analytics

    Now that Tableau Software has agreed to be acquired by Salesforce and Looker is set to become a part of Google, the rate at which analytics will be embedded within almost every application is about to accelerate.

    Tableau today is relied on by more than 86,000 organizations to surface business intelligence via data visualizations created by professional analysts and line of business executives. That user base accounts for why Salesforce is willing to spend $15.7 billion to acquire Tableau.

    Competition within the analytics software space, however, has always been fierce. The rise of the cloud has resulted in several analytics startups challenging incumbents for a piece of one of the fastest growing sectors of the enterprise software market. One of those startups is Looker, which created a cloud-based analytics platform that Google is now set to acquire for $2.6 billion.

    Google has already signaled its intent to make Looker a part of its expanding Google Cloud Platform (GCP). As such, Google Cloud CEO Thomas Kurian last week noted one of the primary reasons for the Looker acquisition is to add a software-as-a-service (SaaS) offering that will enable developers to embed analytics within their applications by invoking a set of application programming interfaces (APIs) exposed via a cloud service. Today that analytics service runs on GCP alongside the Google BiqQuery data warehouse. Google, however, has also signaled its intent to make Looker available on multiple clouds alongside the rest of its software portfolio.

    Tableau, which will continue to operate as an independent arm of Salesforce, is playing catch up in the cloud. Tableau is deployed widely in both on-premises and public cloud computing platforms, including as a managed service provided by Tableau through which the company manages a dedicated instance of its software on behalf of customers. The merger with Salesforce will create an opportunity for Tableau to add a full software-as-a-service (SaaS) application instance to its portfolio that leverages the same infrastructure that Salesforce employs to deliver customer relationship management (CRM), marketing and customer service applications. Salesforce CEO Mark Benioff this week said going forward, Salesforce fully expects analytics generated by Tableau to drive a raft of digital business transformation initiatives.

    Most of the analytics that will be embedded within applications will manifest themselves in three forms. The first is embedded software that will be updated continuously as new data is entered in an application. The second is embedded predictive analytics modules that will invoke big data repositories and machine learning algorithms to surface recommendations on how to optimize a business process or customer experience. The third—and more ambitious—goal is an embedded prescriptive analytics capability that automatically optimizes business processes and customer experiences in real time based on events occurring, for example, within an internet of things (IoT) application.

    Every provider of analytics capabilities, from traditional Tableau rivals such as Qlik Software and Microsoft to TIBCO Software, IBM, MicroStrategy, SAP, Oracle and host of others, is pursuing all these emerging use cases for programmatic analytics. Most recently, Information Builders revealed it has embraced Docker containers and Kafka messaging platform as a means for achieving that analytics goal.

    The arrival of programmable analytics platforms will, of course, make implementing best DevOps practices all the more challenging. It’s hard to think of a business process that will not benefit to some degree from embedded analytics. The challenge DevOps teams will face is embedding and then continuously updating all the analytics modules embedded within the applications they deploy. The good news is that as organizations move to embed analytics everywhere increases, so too does the need to embrace DevOps to manage it all.

    — Mike Vizard

  • DevOps Tools Democratize the View From Both Sides

    DevOps Tools Democratize the View From Both Sides

    How modern product decisions platforms marry the key metrics of features changes to organizational KPIs

    In 1967, Joni Mitchell released one of her most iconic songs, “Both Sides Now.” The song was inspired by the book, “Henderson the Rain King,” in which author Saul Bellow writes about flying to Africa and looking out the plane window, “Look at those clouds down there; it’s very strange to look at the clouds from up above them. I remember as a boy having dreamed up at clouds a lot and having seen the cloud from both sides now, I suppose I shouldn’t really be amazed by anything.”

    Although not her intention and slightly before its time of popularity, the song speaks quite accurately to the tensions between idealized DevOps and the reality on the ground that many organizations are struggling through. On paper, the core tenant of DevOps is about cooperation, seeing problems and processes from multiple team members’ perspectives from each side, but this is easier said than done.

    “But now old friends they’re acting strange
    They shake their heads, they say I’ve changed
    Well something’s lost, but something’s gained
    In living every day.”

    The Unicorns and the Rest of Us

    Some of today’s most successful and disruptive companies—including Google, Netflix and Facebook—have taken their market-leading positions precisely because they have developed strategy and culture around DevOps. It has been part of the company DNA since the beginning and every employee is bought into it. This means fast, agile development and experimentation is part of the culture.

    While many companies would like to capture some of the benefits that unicorns have realized from implementing these development methodologies, for many, this simply is not an option. There is legacy infrastructure, processes and people—who are sometimes the hardest to change. Often DevOps is embraced in small pockets of a company, by teams with newer members working on new projects. The mindset shift that needs to happen to have DevOps—and everything that comes along with it—become part of a company’s culture takes time, commitment and perseverance. However, a good way to start is by demonstrating the fresh, diverse perspectives that can be gained through experimentation and progressive exposure to encourage wider adoption.

    Leveling Up

    One of the ways modern app delivery, operations and business management teams at organizations all along the adoption spectrum are achieving governance, operational awareness and control at speed is by wrapping new code deployments in feature flags and using a centralized platform to control progressive exposure to users.

    By themselves, feature flags are not new. What is new is the centralized and externalized control plane as a service and, newer still, the idea of observing system and business KPIs at the user session or request granularity level for feature flag-controlled decisions.

    When something is rolled out to 5% of the users, it is not likely to light up global ops or business metrics dashboards, even if it is a bit broken—and that makes people cranky. If instead, tools are in place to monitor the KPIs within that 5% population and compare it to the other 95% looking for divergence, you have a much more powerful early warning system.

    These new centralized platforms also extend observability to stakeholders beyond the few wizards driving orchestration and ops teams watching dashboards. An anti-pattern to the local control autonomy spiel modern DevOps patterns call for, this wider visibility protects against local optimization traps in which one team improves its KPI while degrading other KPIs it doesn’t know or care about.

    It can be beneficial to have the idea of key metrics tied to a feature and organizational metrics that look after larger organizational concerns. This inspiration can be traced back to what LinkedIn does with its XLNT experimentation platform, where it calls the organizational metrics “guardrail KPIs.” By always tracking a set of metrics that are critical to the business as a whole, organizations gain a clearer view of the impact that both the granular updates and the larger rollouts are making to the business.

    As Joni said in all her wisdom:

    “I’ve looked at life from both sides now
    From up and down, and still somehow
    It’s life’s illusions I recall
    I really don’t know life at all.”

    No team or organization can know everything all the time, but we can build in visibility to the process of rolling out functionality to our users and create a shared vision of our intentions and the results we achieve. I would argue that if you do look at DevOps from both sides, up and down, you will know the benefits.

    — Dave Karow

  • Successful Digital Transformation Starts With Developers

    Successful Digital Transformation Starts With Developers

    Digital transformation (DX) continues to be a primary focus as companies both large and small look to become more agile, improve and accelerate the delivery of product and service offerings and enhance data-driven business decisions. The C-suite typically leans on IT departments and developers to champion such transformations, designing the software and tools that will lead the experience both internally with staff and externally with customers. The challenge often lies in the fact that most organizations lack the software resources to drive a successful transformation. In addition, research has found that 45% of executives don’t know where to start with DX projects, resulting in added pressure on the developers who hold the technical knowledge but may lack the managerial expertise for a successful rollout.

    So, with IT having the opportunity to be the hero or the scapegoat of a DX initiative, where should development teams start? Typically, digital transformation requires development transformation, so you can start at home, by modernizing the way you develop and deliver software. Doing this also significantly improves the odds of a successful digital transformation and puts development in the driver’s seat.

    Here are four factors to prioritize before kicking off a DX project:

    Buy vs. Build

    A DX initiative requires a number of digital tools and software applications, some of which can be purchased through third parties while others may need to be built in-house, depending on the desired goals of the program. Organizations must determine whether they want to build or buy new software solutions, and the answer is almost always mixed. Most developers believe that each application can be built in-house, while the C-suite often encourages purchases from a third party to accelerate adoption. Before starting to code, ask yourself if the solution you need should be bought or built. Oftentimes, the same goal can be achieved through a purchased solution, empowering you and your team to spend more time customizing those solutions rather than starting from scratch while focusing on the projects that will have the biggest impact on the business—ultimately accelerating time to completion.

    Accelerated Rate of Change

    Once applications are built and available to the public, you can expect bugs to be identified and requests for improvements to be made at an accelerated rate. Developers are constantly making software updates, but when applications are being used to support DX, the rate of change for business requirements is going to speed up, especially when those applications are customer-facing. Developers will need to learn fast and iterate quickly, so it’s important to establish an agile culture within your team.

    Adopting a DevOps philosophy often will be the most successful approach, as it enables your team to test and troubleshoot quickly and enact change across the platform. This approach also assists the rest of the organization in adopting DX practices, delivering a more seamless experience and universal data-sharing. Developer teams must be wary of traditional quarterly or annual planning cycles that create silos, slow agile processes and hinder successful implementations. By breaking down these silos, your team will gain better insight into what is and isn’t working and enable swifter improvements, creating a culture that embraces the changes that come with DX.

    Modular Software Architecture

    Software architecture is incredibly important, as it directly impacts the team’s ability to react to rapid change. A more loosely coupled, modular architecture puts the developer team in the best position to evolve quickly with fewer dependencies, enabling them to make updates and replace components over time to meet business objectives and customer demands. The ability to reconfigure or replace components without having to recode the entire system also assists in build-versus-buy decisions, with developer teams purchasing add-ons to incorporate into a system and solve problems quickly.

    DX Outside of Organizational Barriers

    We work and collaborate in a digital ecosystem. External APIs, third-party data-sharing and interoperability are all requirements as organizations roll out new tools as part of a DX initiative. DX comes down to building a digital ecosystem that flows outside of the organization, whether it is employees working remotely or customers integrating your tools into their existing solutions. Your company’s software needs to accommodate these capabilities to enable a more seamless and well-rounded DX approach.

    DX is a Journey, Not a Destination

    A successful DX initiative should be seen as a culture shift, not an end result. The digital world is not static, and DX is a practice that enables an organization to learn fast and be lean and nimble. As soon as you’ve reached one milestone, there’s a whole new set of rules to play by to get to the next, requiring the developer team to recalibrate. By taking a realistic, process-oriented approach, the developer team will have the mindset and tools necessary to make DX successful.

    — Jeff Fried

  • DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    Adopting DevOps means changes from how you build software to organizational processes and cultural behaviors. Large enterprises have even greater challenges to overcome, including supporting a large number of applications and addressing technical debt while also taking on new development initiatives like digital transformation.

    What can we learn from experienced DevOps practitioners?

    In this DevOps Chat we spoke with Mark Levy, director of strategy, software delivery at Micro Focus, covering seven keys to successful DevOps implementations at large enterprises.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with DevOps.com, and you’re listening to another DevOps Chat podcast. Today, we’re tackling the topic of large enterprise adoption of DevOps—no small task, for sure.

    I’m very happy to welcome Mark Levy from Micro Focus. Mark, welcome.

    Mark Levy: Thank you, Mitch, and glad to be here.

    Ashley: Would you just tell us a little bit about yourself and what you do at Micro Focus?

    Levy: My name’s Mark Levy. I am a director and working in the product marketing organization, and I focus a lot on strategic marketing initiatives as an evangelist, a DevOps evangelist. I develop and write content and commentary about the DevOps market. I’ve had a 25-plus-year career, and like many people, I’ve had many positions. I started out as like a sysadmin and was a developer and managed dev teams.

    But, in 2007, I started to focus exclusively on application delivery. And so, that has been—this whole area of application delivery, software delivery is something that I’ve been really focused on for the last 10 or so years.

    Ashley: Well, tell us briefly, a little bit about Micro Focus. Not all of our listeners might know what you all do.

    Levy: So, Micro Focus has also gone through this major transformation over, I would wanna say, the five to eight years or so. You know, we’re a global enterprise software company. We were established in 1976, we have 14,000 employees and 40,000 enterprise customers, about 4,800 software engineers, and we really focus on large enterprises, helping them run and transform their business. We have sort of focused on four key areas of how do we support our customers through their digital transformation journey, and enterprise DevOps is one of them.

    Ashley: I imagine that our folks, listeners that are from large enterprises are gonna be particularly interested, and I’m sure there are learnings and information that will be useful to other folks as well.

    So, you talked about playing in the space with large enterprises. I imagine that’s probably some global international companies, maybe some that are both European or U.S.-based as well. How would you describe how you differentiate what you do as Micro Focus as compared to other folks? There’s a lot of companies, of course, working to try to help enterprises adopt DevOps.

    Levy: Yeah, of course. And that’s sort of what I’d like to do first maybe is just sort of set the stage, because I always look at this, especially in the enterprise IT world, it’s so interesting. You know, Gartner made this sort of—you know, their strategic assumptions. And they said something like, through 2021, at least 80% of the DevOps initiatives will fail.

    Ashley: I have not seen that, no. Interesting.

    Levy: I don’t know if you’ve heard that, but—yeah. So, it’s interesting. What does that tell me—tell us, I believe? One is, the business is already in the fight. The enterprise, the business side is already in this digital economy and fight. We see that on the streets.

    And the other thing is, you know, IT is sort of behind the curve. And the reality is that our customers, the IT customers, the IT organizations have this incredibly complex hybrid landscape, it spans mainframe, mobile, on-prem, off-prem, and while the principles—the main DevOps principles—are similar to what the unicorns, so to speak, are delivering, that it’s really a whole different challenge.

    Because what’s critical is that there’s this above the line mandate to drive new digital revenue, but at the same time, you know, optimize the enterprise. And, you know, I sort of—I like one of my colleagues, his reference. It’s like, redesigning a jet plane while you’re flying it, you know? And so, I think that’s how, you know, what’s critical with large enterprises is that they’re trying to transform themselves and at the same time run the business.

    Ashley: Yeah, I would almost describe for a large enterprise, it’s like trying to build or transform the entire fleet of planes while you’re building it.

    Levy: Yes! Exactly.

    Ashley: Talk a little bit about—I mean, we all, I think, can appreciate in every business, especially large enterprise, they’re saddled with technical debt; they, of course, are working on operational efficiencies; they have applications that they’re trying to support and maintain.

    How do they take on something like a DevOps initiative successfully, as you were pointing out earlier, so that it doesn’t just stop at one group and kind of fall off from there, they really wanna be able to transform their part of their business? How do you do that?

    Levy: Right. So, I think one of the key things that we focus on enabling our customers to build on what already works, okay? They have all these core investments, and how can they take their core investments and leverage the ROI that they’re already having today, but implement new technologies and DevOps practices and capabilities? And I think that’s critical. I mean, how do they implement and scale DevOps practices, for example? It’s very, very important, and it’s hard.

    And so, we look at it from the basis of, how can our solutions and our products help them really get from point A to B? What is their current state now? Which is what they really need to understand. And it’s amazing how many companies really don’t have a current understanding, detailed, of their current state.

    Ashley: Mm-hmm, or a common one. [Laughter]

    Levy: Or a common one, because, you know, it changes a lot, but how do they deliver value to the customer? You know, what are their value streams, and what are the processes and the flow of artifacts? And so, they need to understand their current state.

    And then, they need to do a number of things that I know the people that are helping the DevOps community, the DevOps community have been evangelizing for a while—I think critical, especially in large organizations and enterprises, you know, they need to first really create this culture of continuous improvement. I think that’s critical.

    Ashley: Okay.

    Levy: You know, they need to enable, motivate and empower the teams, and the leaders really need to get on board, right? Without the leaders, it just will not work.

    Ashley: Yeah, I can speak from personal experience—instituting a continuous improvement culture is no small task in and of itself.

    Levy: Right, and you know, the thing is, the leadership style must also change, right? I mean, command and control really doesn’t work, decisions—it’s about empowering your product teams to drive as much decision making as possible. And that sort of has gone contrary to, you know, the organizational structure of the large enterprises.

    Ashley: Mm-hmm.

    Levy: So, that, I think, you know, is one of the critical challenges that these companies are faced with. Edward Deming made a great quote, “A bad system will beat a good person every time,” right?

    Ashley: Mm-hmm.

    Levy: And when I think of a bad system, I think, in its largest sense, the system. And this is where I think Micro Focus can help quite a bit is, anyone wanting to change this culture really needs to define the actions and behaviors that they desire and then design sort of the work processes that are necessary to reinforce those behaviors.

    So, you know, systems, processes, tools, help with and enforce good culture. But you know, if you have a bad system, it’s not gonna work. So, I think, you know, these are areas that we can help on the cultural side. I come back to thinking about the idea that, you know, sort of the general friction between dev and ops teams, where ops teams are really, initially, only measured by mitigating risk, and dev teams are only measured by delivering change. You know, there’s the conflict that has to be resolved. That’s critical.

    Ashley: You’re talking about culture; the other thing that occurs to me is, there can also be inherent or built in incentives that are counter to the culture that you’re trying to create. That friction is a good example for one. But, you know, there may be past punishment for failures or, you know, emphasis on down time, so the answer is always minimize change or whatever it might be. You’ve gotta take those things head on.

    Levy: Exactly, yeah. And so, I think, you know, you ask sort of where people start. I think, you know, you need to start—and everyone, a lot of people talk about this, and it is true. You really need to start instituting this culture of change, because DevOps drives a lot of change. It’s a transformational journey in the enterprise.

    Ashley: When you said, the number one thing you said was, “Leverage what works.”

    Levy: Yes.

    Ashley: What do you look for? What kind of things are you trying to say, “That’s a practice you do well, and let’s keep that, or let’s build upon that”—what do you look for?

    Levy: Well, you know, I think about, there’s a lot of legacy systems, core investments that these large enterprises have had and invested lots of money and time into it. And take, for example, COBOL, okay? That language, I think people are not necessarily aware how invasive it is. There’s still about 250 billion lines of COBOL around, right?

    Ashley: Mm-hmm, mm-hmm.

    Levy: It drives 70%, they say, of all business transactions—still, in the world.

    Ashley: That’s amazing.

    Levy: It is amazing.

    Ashley: [Laughter]

    Levy: And so, you know, I’ll give you an example of sort of what we’ve done and we’re, you know, we are very good at managing and understanding those environments. We have, you know, that’s a big part of our business. So, we can, you know, lift—if we can lift and shift, you know, COBOL workloads off of, you know, sort of the more legacy platforms into, let’s say, AWS, you know, that’s a big win for our customers.

    As an example, we had one customer that basically had—it was a major global insurer, had about eight different IT environments with a back end COBOL app sitting on the mainframe and then front end and WebOps. And basically, each environment cost about $3 million a year. And, to request that environment, to provision that environment, took six weeks.

    Ashley: Mm-hmm, mm-hmm.

    Levy: And so, we built, through our solutions, we were able to lift and shift that workload to AWS and reduce the cost from 3 million to 120K and reduce the provisioning time from six weeks to two hours.

    Ashley: And I wanna mention, too, to our listeners, too, we just had a webinar in the last week talking about mainframe APIs and frameworks specifically to mainframe environments to make it a little bit easier to adopt WebOps. So, though it doesn’t get the kind of sex appeal that necessarily new technology does, it is a huge, huge issue for enterprises and how do you bring the mainframe environment with the rest of the cloud and everything else.

    Levy: Right, it’s—you know, back to the theory of constraints. I mean, in your value stream, if—you know, you can develop and you can be an agile team, but if it takes six weeks to provision, you know, your mainframe environment?

    Ashley: Where do you suggest people get started? Is it go pick a new, from scratch greenfield project, or pick something that’s, you know, reasonably mission critical so we’ll get the support?

    Levy: Yeah. Well, I think one is, I like, initially, to set up a lab, like taking a greenfield. You need a place to learn. A lot of these things aren’t easy, or they’re not, people are not, the teams are not used to. So, like, I love the idea of what a lot of the community’s doing with DevOps dojos and building sort of a team level, maybe CI/CD, have a place to experiment and take that.

    But then, you know, ultimately, in large enterprises, they’re gonna come up. They might get easy wins early, right, but the challenge is, once they scale, they’re gonna run into some of the more challenging times. And that’s where, back to what they have to really start doing is taking this broader, system level view of the enterprise.

    So, you know, if they understand how they’re delivering value to their customers—and in enterprise, there’s many ways to do that—then they need to understand and prioritize according to the business objectives. Let’s say one business objective might be, we need to recapture value. Maybe our IT budget isn’t really growing, but we need to drive for more innovation. So, we need to—our objective is to recapture that value and redeploy it into delivering value and innovation. And so, that would drive a lot of your decisions in where you optimize.

    Ashley: Speaking of budgets being flat or not growing, digital transformation is all the rage, that’s what many, many companies are taking on, not just in customer experience, but across the enterprise, bringing them into the digital world. How does that fit on top of this if you’re trying to introduce DevOps?

    Levy: I don’t see how they can really run their digital transformation without DevOps. I mean, software today—you know, I talk about this a lot where business innovation and software innovation are generally becoming one and the same, right?

    Ashley: Mm-hmm.

    Levy: And going quick, innovating faster with less risk is critical. And so, IT is, you know, it’s imperative to really deploy DevOps practices to support the digital transformation of the business. So, I think, you know, the IT organizations that implement DevOps, those people are the drivers.

    Ashley: Well, and it’s hard to imagine how you were gonna transform systems and applications you already have as well as ones you might leverage as SaaS services or create yourself without an environment to integrate those altogether due to continuous integration testing, etcetera, as well as be responsive to the business.

    Levy: We’ve seen enterprises, they will typically start out, right, with their team level implementation and they might do really well, and it might be a greenfield app. Maybe it’s a new growth app, which is great, and they may get some early wins, which is super, but it’s still not their core business.

    Ashley: Mm-hmm.

    Levy: And so, they have to, ultimately, really transform their core business in order to be competitive in the market.

    Ashley: Mark, what’s the one thing organizations should not do when they’re looking to adopt DevOps—don’t make this mistake?

    Levy: I think the idea that they can just automate their way out of it, I think, is something that could get them in trouble. Because, you know, really leaving out the whole cultural aspect of it, it really is—you know, it’s interesting, if you read Jeff Bezos’ letter to shareholders every year, he just provides some incredibly insightful, you know, insights on how Amazon runs. He talks about this accelerated decision making process that they run, and they make these decisions, really, based on only 70% of the information that they need, basically. Whereas, large enterprises wait until they typically have 90%.

    And so, they are able to make decisions earlier because of the agility that they’ve built into their system and their culture of change. And this allows them to not only, you know, get earlier into the market, but it allows them to—everyone, it allows them that if they make a mistake, they can recover from their mistakes faster, and the cost of making a mistake actually goes down.

    Ashley: Mm-hmm.

    Levy: But this whole idea of organizational agility and providing that—there’s more than just delivering value faster to the customer, because it’s never a straight line, right, to success. So, we make a lot of mistakes and wrong turns in our journey, and being able to identify that quickly and have the agility to correct that quickly is actually more of a differentiator than just delivering fast.

    Ashley: It’s certainly required for any kind of agility. It’s not just getting things and getting decisions made faster, but changing when things aren’t headed in the right direction—or change.

    Levy: Right, right. And so, this is where, you know, if people are looking at DevOps, they’re saying, “Okay, well, we’re just gonna automate the deployment pipeline and we’re done?” No, there’s no “done,” it’s about really, ultimately, improving as an organization, right, and having that continuous improvement, the Kaizen kind of mentality of the organization. And that, to me, is what is so transformative as a company.

    Ashley: Going back to what you said in the beginning about having a culture of continuous improvement.

    Levy: Yeah, absolutely. And that, it would be, you know, frankly, the most powerful thing leaders can do—is that change. Because it really just changes the whole business. The business, then, gets more confidence, which is critical, right? With all this change, sometimes they’re not confident to make business decisions, but if you can provide them the confidence to go out there and really be aggressive, you know, that’s—you’re gonna see, you know, a whole bunch of positive results on the revenue side, on the public side of the business that’s been driven from, traditionally, the back office IT organization.

    Ashley: Well, Mark, I’d like to thank you. I’d like go for another 30 minutes, [Laughter] but I’d like to thank you for the time on the podcast. You know, I walk away with several things from our conversation. The things you shared that I heard were leverage what works, define your current state, create a culture of continuous improvement, command and control doesn’t work—you’ve got to empower product teams. Start with a lab or a dojo, some learning environment. I think your premise of, you can’t do digital transformation without DevOps is pretty intriguing. And last but not least is organizational agility, being able to make decisions quicker, get out ahead of things without having to have 100% of the information, kinda the Amazon model.

    Well, and that should wrap things up. I’d like to thank Mark Levy from Micro Focus for joining us. This is Mitch Ashley with DevOps.com, and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • Getting the Enterprise Digital Core in Shape

    Getting the Enterprise Digital Core in Shape

    While enterprises rush to transform their business digitally, most are taking tactical steps rather than building a comprehensive digital core that can be improved over time. Very few are taking a thorough view of their entire technology portfolio and looking for ways to create a cohesive core—their digital core—to provide them the strength and stability to move forward swiftly in their digitization efforts. The enterprise digital core essentially is the vital set of technologies and employee skill sets that enable the organization to deliver its digital services. These services are both consumed by customers and internally by staff and others.

    How do enterprises get their digital core into shape?

    Emphasize Talent Over Technology

    While a strong digital core includes the technological platform, it is also a people-platform. “The heart of digital transformation isn’t technology but the mindset and skill sets of your staff,” said Andy Lin, senior vice-president of strategy and consulting at Nexient. Digitization, he said, means enabling customers to transact and interact with you anytime they want, from anywhere, using any device. The only way to get there is if leadership makes it clear to staff why digitization is crucial; otherwise, they will struggle to adapt, he said.

    If the staff does understand the reasons behind the transformation, they will—instead of just following rules for the sake of rule-following—be much more likely to adopt a digital mindset. They’ll also be more likely to embrace the training and skill set development they’ll need to make the transformation a success, Lin added.

    Scrum.org CEO and product owner Dave West agreed that the digital core starts with the customer. “There needs to be a clear line from the mission and strategy of the business with the outcomes the customer wants,” he said. Teams need to understand clearly how their work helps deliver the organizational mission digitally to the customer, no matter what that mission may be. That means everyone needs to be clear on the nature of the business, or organizational business, as well as what success looks like

    West also advised organizations that seek to improve their digital core to look both inward and outward for support. From within the organization, of course, support should come from leadership, who must set the course and ensure efforts are going in the right direction. “Externally you need to build a network of support from people and organizations that have done it before,” he said.

    Put Cloud at the Core

    Of course, a strong digital core must have a strong technological foundation. In today’s typical enterprise, that may very likely mean more about subtraction than addition. While emerging technologies, such as internet of things (IoT), artificial intelligence (AI)/machine learning (ML) and others are recommended to be integrated within enterprise software, “Many of them are not generally suited to run on legacy IT infrastructure,” said Maxim Ivanov, CEO at enterprise software development firm Aimprosoft. “The digital core relies on intelligent automation scalable platforms that are integrated in the cloud and prepares data for next-generation technologies.”

    Gabriel Salazar, digital solutions manager at systems integrator Enstoa, agreed that building a cloud-based infrastructure goes a long way to improving the digital core. “It’s important, however, not to simply carbon-copy the business processes used prior,” said Salazar. “Look to take advantage of all automation, machine learning and analytics offered by converting and folding them into your updated business process.”

    Finally, if organizations want to have a strong digital core, they are going to have to work to maintain it. “Due to the speed of technology change, getting your digital core in shape is a continuous process. Start by understanding what is preventing you from supporting business goals, what is causing ongoing stability or performance issues and what reduces your time to market,” said Nick Polachek, senior principal of strategy and transformation at Maven Wave Partners.

    To do so, Polanchek recommended building the digital core iteratively while maintaining the focus on delivering business value or resolving current issues. It’s also important, he said, to have a thoughtful future vision for your digital core and ensure that each delivery is at least aligned, if not an improvement, over core technology already in place.

    After all, keeping that digital core in shape is an ongoing process that will require ongoing work and practice.

    — George V. Hulme