Tag: cloud

  • Transforming with the Cloud: If Not Now, When?

    Transforming with the Cloud: If Not Now, When?

    The question of whether to move to the cloud is no longer relevant for most organizations. Migrating workloads to the cloud has already become an inevitable requirement for a vast majority of companies regardless of their sizes, and if your organization isn’t doing that already, then it is simply the question of when and how you’ll consider doing so.

    The agility, redundancy and elasticity with regards to scaling compute resources present a compelling need to move to the cloud sooner than later, let alone other factors such as reduced overall capital expenses associated with managing a robust on-premises infrastructure. The finance sector is usually a little behind in embracing major changes in IT operations because of their strict regulatory compliance requirements and the complexity in their application portfolio as a result of several mergers and acquisitions. These restrictions are quite common, especially with insurance companies, but surprisingly there are several major insurance companies that have made significant investments to modernize their traditional applications and migrate them to the cloud for efficiency, agility and cost reasons.

    To effectively support the business that constantly strives to be highly competitive and to reduce the time-to-market, most applications development efforts are planned in an Agile fashion with short sprints that produce usable deliverables within a few weeks. When development teams go Agile, it is important that all other associated services operate in a similar manner.  Without agility in infrastructure provisioning and other support services, it is simply impossible for the development teams to be successful in producing deliverables at high velocity. A commonly heard complaint from most of the application development teams is about the delays from infrastructure teams on provisioning servers. Provisioning a virtual machine (VM) takes more than three weeks in many companies, even today. This is due to a variety of factors such as work backlog, complexity in approval processes, compliance requirements, lack of automation and several others that are organization-specific. IaaS and PaaS offerings from cloud leaders such as Microsoft Azure and AWS address these issues to a great extent. Even if companies are not ready to migrate their existing applications to the cloud, they should seriously consider IaaS and PaaS from well-established cloud providers for new applications being developed.

    There are several factors that could influence IT leaders’ decisions on their strategy regarding cloud and some of the areas that certainly cannot be overlooked are discussed here. The purpose of this article is to provide a general high-level overview, especially for companies that have been hesitating to migrate their workloads to the cloud. It should be noted that we are barely scratching the tip of the iceberg in this discussion.

    Complexities in the Application Stack and Infrastructure

    It is not uncommon for organizations to be overwhelmed by complexities and issues with their current infrastructure setup and get bogged down dealing with their day-to-day operational challenges. Due to these ongoing issues, one might develop a false notion on the actual effort involved in migrating to the cloud and may even wonder whether it is an achievable target state. It is important to map out the current infrastructure that supports the business applications and have a clear view of the complexities, dependencies and licenses that are in play. The application servers, database servers, storage arrays, enterprise messaging bus, document management systems and several other key components that work together to power your key business applications need to be taken into consideration. This will not only help decide the right applications that are suitable for the cloud, but will also help pick the right cloud provider to suit your needs. You can notice the convergence of IaaS and PaaS as it is becoming difficult to separate one from the other. Most leading providers are offering these services as a package.

    It is better to categorize your applications based on their level of complexity and shape up your cloud strategy accordingly. Standalone applications that simply require a web server, application server and database server are ideal candidates for your first phase of migration efforts. You can ensure that with the right architecture on the cloud, there will be better availability, load balancing and performance and less maintenance overhead for your standalone applications.

    Amazon Elastic Compute Cloud (EC2) provides availability of 99.99 percent and its auto-scaling feature allows automatic scaling of the fleet up or down depending on the needs to maximize performance and minimize cost. Similarly, Microsoft Azure offers VM Scale Sets that can be configured for your applications to scale automatically. If the requirement is to develop brand new applications for the cloud, the options are endless. As an example, .net based web applications to be hosted on Azure can be developed to be run as Docker containers.

    Containers and the management of a cluster of container nodes have come a long way since their inception. Docker Swarm and Kubernetes have drastically simplified the management, load balancing and scaling of containerized applications. Containers are not only for your new applications; they also come in as a great solution for modernizing your legacy/traditional applications and migrating them to the cloud.

    Storage

    Identity and access control used to be prevalent challenges in the past, but cloud providers have greatly simplified identity management services such as application authentication, user management and single sign-on by providing rich features to support the information security and compliance requirements of organizations. Microsoft Azure offers Azure Active Directory and provides a few different protocols such as WS-Federation, SAML-P and OpenID Connect to authenticate the user. It also supports multi-factor authentication. For brand new applications that are developed using Visual Studio 2017, it is extremely simple to integrate the application for authentication and authorization workflows on Azure AD using the above protocols.

    Databases play a vital role in the decision-making process when it comes to migrating to the cloud. Senior IT managers are usually highly concerned about the security of data while technical personnel are worried about ensuring storage, performance, recoverability and availability. Application developers and DBAs end up spending a great deal of time fixing code or other application configuration parameters even when databases are simply migrated from one server to another within the same data center. Cloud solutions address such concerns. Microsoft Azure, for instance lets you migrate your native on-premises SQL databases to Azure SQL Database Managed Instance by providing the native virtual network (VNET) support. You don’t have to change your applications as a result of this migration. The Managed Instance offered by Azure is quite promising and it is certainly a great solution for migrating large numbers of on-premises SQL Server databases to Azure. Similarly, managed database services are offered by AWS for both relational (RDS) and NoSQL (DynamoDB) databases. Amazon EC2 service is integrated with Amazon RDS and Amazon VPC to provide a complete, secure solution for computing, query processing and cloud storage including, but not limited to, a wide range high-performance web applications, DB servers and batch processing needs.

    Disaster Recovery

    Cloud providers offer data centers in several regions around the world. It requires a major investment for any organization, both financially and operationally, to match the redundancy and recoverability provided by major cloud providers. Even organizations that have a highly virtualized infrastructure setup have physical infrastructure for some of their mission-critical applications. The reasons for having such a setup could be argued, but the costs associated with setting up a disaster recovery environment for such infrastructure would be significant. To ensure comparable performance and capacity, the disaster recovery environment is typically a replica of the production environment that is underutilized most of the time, consuming significant investment.

    Planning for setting up a disaster recovery site involves considering several factors such as, ensuring compute capacity and scalability (servers and storage), networking (bandwidth, load balancers, switches, routers), identity management (directory services, authentication, authorization), facility to host the DR site (location, floor space, power, air conditioning) and operational aspects (personnel, monitoring, alerting, break-fixing, hot-hands support). Cloud providers give you the option to choose the location of your DR site anywhere in the world. Depending on the contract you have with your cloud provider, you could either quickly deploy compute resources on your DR site on the cloud or utilize the necessary automated processes to switch over to an already running replica of your application environment on the cloud DR site.

    There are numerous features that AWS offers to address each of the above-mentioned aspects that need to be considered for setting up a disaster recovery site. Amazon Machine Images (AMIs), for example, lets you preconfigure images with the operating system and your application stacks. It is also possible to configure your own AMIs to allow the recovery process to launch these images automatically in the event of a disaster, saving a significant amount of time.

    Microsoft also provides highly dependable DR alternatives on Azure. You can use Azure as your secondary site for DR purposes or completely eliminate the need for data centers by picking different Azure regions as primary and secondary sites. Azure offers the Active-Passive and Active-Active topologies. In case of the active-passive topology, all user traffic flows to the primary region while preparing the secondary region to take over at any point since the database runs in both regions with a synchronization mechanism implemented between the regions. Active-active topology ensures running of cloud services and databases on both the primary and secondary regions and user traffic goes to both the regions. In the event of a failure at primary, all the user traffic will be directed to the secondary by simply disabling the DNS at the primary region. Auto-scaling features of Azure will allow the scaling up of compute resources in the secondary region as needed.

    DevOps Maturity

    Any discussion on migrating to the cloud would be incomplete without highlighting the significance of a solid DevOps practice to complement the cloud strategy. From a technical standpoint, companies that settled on Linux environments used to have a slight edge over those that went the Microsoft route, especially with regards to implementing open source solutions and technologies that support DevOps and cloud initiatives. This is highly arguable now as Microsoft has not only opened its gates wide for several major open source tools but also allowed for better integration of several leading open source products such as Docker, Jenkins and Puppet with ALM tools such as Microsoft TFS 2017.

    Depending on the goals of an organization with regards to its cloud strategy, the level of maturity required from a DevOps perspective needs to be analyzed. DevOps can be looked at from infrastructure as well as applications development perspectives. If your goal is to use cloud services only for IaaS, it will be extremely valuable to develop strong, infrastructure-focused DevOps capability, practices, processes, tools and automation. Through proper scripting and integration with IT services management (ITSM) tools such as Service Now, the entire process—from requesting infrastructure through having them provisioned with all the patches, hardening, etc.—can be fully automated by leveraging tools such as Chef or scripting via PowerShell. Features such as metered billing and quotas that are already offered by cloud providers can be leveraged and integrated with organization units’ budgets, approvals and other processes to establish a well-managed, fully automated infrastructure provisioning process.

    Organizations considering leveraging the cloud for applications development are definitely at an advantage compared to those considering development on-premise. Microsoft, for example, offers IaaS at a highly competitive price and provides Visual Studio Team Services (VSTS), a cloud version of Team Foundation Services (TFS), on Azure. The PaaS services offered by Azure are also quite extensive, along with integration with a variety of open source tools. With this combination, developers have a complete, end-to-end solution to address all their requirements without losing time in waiting for environments to be set up. DevOps can play a significant role here. With a fully integrated continuous integration (CI) framework, the developers could commit code to a managed Git repository on the cloud, and automated continuous integration can be kicked off via VSTS, which handles the build, automated testing, code quality control, building container images, automated spinning up of infrastructure needed for an environment and deploying code or containers on the environment following a fully integrated change control process and quality gates. Developers can focus fully on developing code and enjoy the freedom of being able to deploy code on a transient environment on the fly to test their code before it goes through other phases of testing. In highly competitive business environments, this provides the ability to perform multiple production deployments in a single day if need be.

    Organizations with a high level of maturity in DevOps are the ones most likely to leverage cloud to its fullest potential. Similarly, those that are striving to attain this level of maturity are likely to get there sooner by moving to the cloud. Developing the expertise, building the process framework, and implementing the right DevOps tools will make it easier to solidify your cloud strategy.

    Compliance & Security

    Several organizations have refrained from migrating to the cloud mainly due to the strict compliance and security requirements that are mandated by the industry. Companies that are still hesitating to embrace the cloud are those that are skeptical about the security of their data on the cloud. Irrespective of the cloud provider or the strict SLAs and contractual terms that you may have with them, you are still accountable for the data that you own. So, it is extremely important to understand more about the security setup and the features offered by your cloud provider to secure your valuable data on the cloud.

    As the owner of your organization’s data, you have to know where your data is going to physically reside, what kind of encryption will be applied to your data at rest and in transit, who will physically have access to your data, how your data will be segregated from other tenants’ in a multi-tenanted environment, what recovery processes exist, what the regulatory compliance certifications that the provider has obtained are and answers to many more questions. Security experts highly recommend classifying your data based on risk levels and devising a strategy accordingly. You may decide to host your most critical data on-premises and use the cloud for other types of data.

    Microsoft offers a very comprehensive checklist and reports to help you assess the risk to your organization in moving to the cloud. Both AWS and Microsoft are certified by almost all major regulatory bodies with regards to data security and compliance. However, as outlined earlier, while your provider can take the responsibility to host your data in the most secure manner, you as the owner of the data will still be accountable for its integrity and security. So, this is an area that requires thorough analysis before you decide on your workloads that need to migrate to the cloud.

    To Make the Long Story Short …

    While savings on capital expenses is a given, this is not the prime motivator for most organizations to migrate to the cloud. As stated in the Gartner report, “Cloud Computing Primer for 2018,” the role played by cloud in this decade is way beyond simply setting expectations and providing a platform for better economic models. Digital initiatives such as artificial intelligence (AI), internet of things (IoT) and several other technological innovations and disruptions are fueled by digital platforms that cloud offers. Agility, scalability and flexibility, on the other hand, are certainly some of the key drivers that would encourage companies to migrate to the cloud. Furthermore, reducing your time to market can be better accomplished by moving your development workloads to the cloud. The combination of IaaS, PaaS and a solid DevOps practice to automate deployment of infrastructure and application stack makes cloud far more superior to running applications development on-premises. Companies that haven’t invested much in DevOps should seriously consider doing so before it is too late.

    Containers, the tools and practices to orchestrate, load balance and scale microservices add a completely different dimension to how cloud services could be further leveraged. They help ensure seamless, defect-free, repeatable deployments, and with the necessary automation to spin up transient environments, it is difficult to match the benefits of using containers on a fully automated IaaS in an on-premises setup.

    The auto-scaling features offered by cloud providers make cloud a far more superior alternative compared to hosting internally. The elasticity provided by cloud helps with scaling compute power, storage, load balancing and several other infrastructure services as needed, without having to make massive hardware investments.

    Cloud providers offer solid disaster recovery options and support. Implementing an active-passive or active-active primary and secondary sites is a lot more straightforward and easier to set up on AWS or Azure than doing it on-premises.

    Compliance and security are also important factors that could drive the cloud strategy. It is important for decision makers to evaluate the risk factors and then decide on the type of data that could reside on the cloud as opposed to staying internally.

    NetworkComputing provides interesting statistics on public, private, and hybrid IaaS adoption in their article, “IaaS Cloud Adoption Trends.” The article further refers to research from Interop ITX and InformationWeek on how organizations are moving and managing workloads to the cloud. Per their findings, several companies are expected to deliver over half (67 percent) of their IT and business services through the cloud in the next year. Of all the companies they surveyed, 31 percent plan to allocate over 50 percent of their budget to cloud initiatives.

    With a clear strategy, budgets, categorization of applications, prioritization and staff with the right expertise, you can be sure that your journey in moving your workloads to the cloud will be a pleasant one.

    — Sridhar Asvathanarayanan

  • Red Hat Aims to Push IT Management to the Cloud

    Red Hat Aims to Push IT Management to the Cloud

    Red Hat at the Red Hat Summit 2018 conference this week showed a technology preview of an instance of Red Hat Insights, a predictive analytics IT management application capable of identifying operations issues before they become a problem, running as a software-as-a-service (SaaS) application.

    The instance of Red Hat Insights will be extended to apply analytics to any infrastructure platform. Red Hat plans to eventually make the rest of its IT management portfolio available as a cloud service.

    Joe Fitzgerald, vice president and general manager for management at Red Hat, said the goal is to enable management of virtual machines, container, infrastructure-as-a-service and physical servers all from a single pane of glass.

    Cost analytics also will be embedded in those services, adds Fitzgerald. Cost is now a much bigger issue because cloud service providers bill customers based on actual consumption. Previously, a virtual machine left running on an on-premises server might result in someone being yelled at, but no additional cost, notes Fitzgerald. Now, however, if an IT organization doesn’t turn off those virtual machines, it will end up paying more.

    Fitzgerald noted that management of IT operations is becoming increasingly automated. Red Hat is now adding integrations with the agentless Ansible framework it acquired in 2015 at rate of 50 a week. There already  are 1,600 integrations with Ansible. He said the fact that Ansible presents IT operations teams with a declarative approach to automating IT using YAML files makes IT automation much more accessible. Other frameworks require IT operations teams to learn how to program, which becomes a significant barrier to adoption, but YAML files allow IT operations teams to make use of familiar shell scripts.

    Many organizations now are moving up the IT management curve as applications become more distributed, Fitzgerald said. Every platform they have comes with its own management tools. But the need for a control plane through which multiple platforms can be centrally managed is now becoming more evident, he said, especially as IT organizations realize they will be running many different types of platforms for many years to come.

    Other benefits to shifting IT management into the cloud is that the move eliminates the need to deploy a local server just to run IT management software and all updates to the IT management platform are provided by the applications provider.

    Obviously, Red Hat is not the only IT vendor building a centralized, cloud-based approach to managing distributed computing environments. But as Ansible becomes more widely adopted, the opportunity arises for Red Hat to engage in a broader IT management conversation with IT organizations.

    Most enterprise IT organizations are rapidly approaching something of an IT management crisis. Each platform adopted creates yet another silo that makes adopting integrated DevOps processes even more challenging. While most organizations are not likely to abandon the management tools from the vendors that built those platforms, IT organizations are demanding thet underlying infrastructure exposes an application programming interface (API). In fact, it’s the proliferation of all that software-defined infrastructure that now makes it feasible to centralize the management of IT in the cloud.

    — Mike Vizard

  • Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle Adds Low-Code Tool to Autonomous Platform

    Oracle this week extended the scope of the cloud services it manages on behalf of customers to include a low-code application development platform based on the company’s Visual Builder development tools.

    Jeff Price, vice president of product Management at Oracle, said Oracle Autonomous Visual Builder (VB) Cloud makes it possible to employ a tool based on JavaScript to build applications that might be written, for example, in Java or, going forward, Jakarta EE. Autonomous Visual Builder Cloud is available via a managed service that can easily integrated with a variety of back-end services managed by Oracle or running on-premises.

    To complement that effort, Oracle also announced the availability of Oracle Autonomous Analytics Cloud and Oracle Autonomous Integration Cloud. Oracle Autonomous Visual Builder comes with tools for accessing back-end services, while Oracle Autonomous Integration Cloud provides a raft of additional connectors for accessing a wide variety of other Oracle and third-party services, Price said.

    Oracle also committed to delivering additional autonomous services later this year to address mobile and chatbots, data integration, blockchain, security and management and additional database workloads such as online transaction processing (OLTP). Those services will complement existing Oracle autonomous database and platform-as-a-service (PaaS) environments.

    Price said interest in low-code development tools is accelerating as organizations look to extend business processes that have been automated using either packaged applications running on-premises or in a software-as-a-service (SaaS) application. Rather than trying to achieve that goal using low-level application programming interfaces (APIs) that are fragile, Price said low-code tools such as Oracle VB make it simpler for even citizen developers to construct applications leveraging code developed by professional developers.

    Organizations need to decide for themselves when to customize those application environments versus taking advantage of them in a turnkey manner, Price said. Organizations tend to heavily customize customer experience and customer relationship management (CRM) applications, while relying on best practices that have been coded into enterprise resource planning (ERP) applications. Oracle is changing the way it supports those applications—base-level support for these applications is now free, but Oracle will continue to charge for premium services.

    The need to customize applications at scale is driving many more traditional enterprise IT organizations to adopt DevOps processes that now need to span multiple IT environments, Price said. He added Oracle now provides integration with multiple continuous integration/continuous deployment (CI/CD) platforms to facilitate that transition.

    As Oracle assumes more responsibility for managing the underlying platforms, organizations in theory should be able to devote more resources to developing applications. To achieve that goal, however, many of them will need to figure out how to extend their DevOps processes to include Oracle as a managed service provider.

    Oracle also provides access to unmanaged infrastructure-as-a-service (IaaS) and (PaaS) services in much the same way Amazon Web Services (AWS) and Microsoft do. Oracle has been late to the cloud game, but this week announced a slew of new cloud customers, including Atomitech Inc., Edith Cowan University, Future Robot, Barrick Gold Corporation, C’s NEXT, Colegio de Bachilleres, Contribute NV, DP World Ltd., Dubai Airport Freezone Authority, Emirates Flight Catering, Hytera Communications Ltd., Ildong Pharmaceutical Co. Ltd., Konyang University, Land O’Lakes Inc., Leshan City Commercial Bank, McDermott, MCore Group, New Hope Liuhe Co. Ltd., Promata, Stallion Oilfield, Ornua Co-Operative, RecVue, Saga d.o.o Beograd, TCI, TaskUs, University of Wisconsin Hospital and Clinics Authority, and Zeneral Heatpump Industry Co. Ltd. All told, Oracle claims to be processing 55 billion transactions a day on its cloud.

    It may take a while for Oracle to catch up to AWS. But if it doesn’t achieve that goal it won’t be for a lack of development tools.

    — Mike Vizard

  • The Reality of Cloud Migration: It Gets Worse Before it Gets Better

    The Reality of Cloud Migration: It Gets Worse Before it Gets Better

    The IRS dominated headlines last month when a computer glitch arose—on Tax Day—that prevented the agency from collecting millions of tax returns and forced a deadline extension. But beneath the bevy of predictable, “embarrassing government snafu” stories lies a greater, more systemic problem: IT modernization. Specifically, the potential consequences of not modernizing.

    The advantages of modernization are well-understood: agility, flexibility, innovation, scalability. But it’s also understandable why organizations—particularly large organizations such as the IRS—would be hesitant about modernizing. The organization has been relying on the same computers and systems for decades. And for the most part, those computers and systems have been working for decades. With change comes risk and uncertainty, not to mention extensive time and effort. Though tech vendors say modernization is “seamless” and “easily attainable,” we know that’s not the whole story. The truth is, it gets worse before it gets better.

    A Harsh Reality

    Cloud migration is a prime example. A CIO I once worked with compared legacy applications to the Egyptian pyramids: massive, complex and everyone with knowledge of how they were built is long gone. On top of that basic skills challenge, you and your teams have to work double duty to keep the lights on with existing operations while migrating to the cloud. The harsh reality is that when you migrate traditional applications to the cloud, the total size and complexity of your workload will increase before it decreases.

    Successful cloud migrations begin by confronting the following facts head-on so you’re prepared for what lies ahead.

    The Job Will Be Bigger Than It At First Appears

    Much like the pyramids, you begin with excavation and inventory. You need to get inside your applications and understand their dependencies as well as their current role within your business. This is time-consuming work—you pull on a thread and it typically doesn’t end until you’ve inventoried most of your applications. The thread quickly gets long, looped and wrapped around you. All you have are knots.

    Untie the knots one by one. In time the thread will straighten and you’ll have new insight into your systems. This is valuable with or without the cloud. After inventorying your portfolio, look for quick victories by finding systems that are self-contained yet important to the business and clearly in need of improvement. Tackle systems with complex dependencies after you have some practice and success with important but self-contained applications.

    The Day-to-Day Gets Flipped on Its Head 

    Teams are often initially eager, but will push back when change actually begins. People don’t like altering their responsibilities, there are initially many unknowns and, of course, double duty means more work than ever. Don’t segregate teams working on cloud migration because they will find it difficult to enlist the broad support they need. Make migration everyone’s duty. At this state, leadership is critical. Transparently and specifically communicate objectives and potential barriers. Get feedback and adjust, but don’t lose sight of the ultimate target. Lead by example, whether it’s attending more meetings with direct reports or holding office hours. Keep the flow of information steady to make sure everyone knows “why” as much as “what.”

    You’ll Straddle Two Worlds for a While

    Successful “big bang” transformations are a myth. In the real world, you can’t just shove your legacy technology aside for the newer, shinier versions all at once. Nor can you make your traditional applications act like cloud-native apps with a few tweaks. You’ll need to maintain the status quo as you modernize toward a new approach. Understand that you won’t become a cloud-native continuous delivery shop overnight. Accept time and cost in maintaining what you have as you modernize toward what you want to be.

    Done well, migrating and modernizing in the cloud will improve efficiency, clean up cruft and speed innovation. To realize those benefits, however, you must first understand what you have today then lead your organization to change. Since no business can simply start over, you must plan to maintain existing systems in parallel with cloud migration and modernization. Start your effort assuming you will find unexpected dependencies, unwilling participants and inconsistent security postures of your own systems. Expecting these problems will prepare you and your teams to handle them. Don’t grab a cloud-hammer and treat everything like a nail—use the right solution for each application. The ultimate goal is not to get into something but instead to get ahead of business demands. There is no single route to successful cloud migration, so keep your options open and let your goals dictate your technology decisions. Plan for life to get more difficult before it gets better and the payoff will be well worth the investment.

    — Brad Schick

  • Morpheus Data Extends DevOps Reach

    Morpheus Data Extends DevOps Reach

    Morpheus Data signaled it will pursue a more open strategy when it comes to enabling DevOps teams to manage multiple cloud platforms.

    Brad Parks, vice president of marketing and business development for Morpheus Data, said updates to the company’s namesake platform will make it possible for DevOps teams to swap in third-party modules and components even when Morpheus has already provided that equivalent functionality in the platform. This more open approach is being driven by a recognition that in many cases DevOps teams are being required to implement a specific corporate standard, Parks said.

    The latest edition of the Morpheus cloud management platform adds support for Kubernetes container orchestration software, Terraform configuration management software developed by HashiCorp and Microsoft Azure Resource Manager. Morpheus already has its own JSON/YAML scripting framework. But it’s clear more declarative approaches to managing cloud resources using, for example, Kubernetes or Terraform are starting to gain traction, Parks noted.

    At the same time, Morpheus is adding connectors to cloud services from Oracle and T-Systems.

    At its core, the Morpheus cloud management platform enables DevOps teams to consolidate analytics, reporting, governance, monitoring, logging and data protection within a single platform. Most organizations today either already are or expect to soon employ multiple clouds. Each of those clouds will be running different classes of workloads as IT organizations move to keep their cloud service provider options open. At the same time, Morpheus Data is betting that, rather than mastering separate management consoles for each cloud, organizations will move to centralize the management of multiple clouds as much as possible, Parks said.

    Parks noted Morpheus Data is also starting to see DevOps teams hooking up their preferred continuous integration/continuous deployment (CI/CD) platform to the Morpheus cloud platform. That approach provides them with a platform to manage applications starting the minute a CI/CD pipeline finishes pushing them into production, he said.

    CI/CD platforms and other DevOps tools are great when it comes to building and deploying applications, but currently a gap exists between how those applications are built and deployed versus managed when deployed in a production environment. Morpheus is designed to provide an open flexible approach to closing that gap, Parks said.

    Interest in various approaches to automating the management of IT is clearly on the rise. Most organizations simply don’t have enough IT staff to manage large numbers of applications being deployed at scale. In fact, Parks said Morpheus Data is seeing a marked rise in the number of managed service providers focused on DevOps and cloud management services.

    Regardless of how the integration of DevOps and cloud management is achieved, it’s clear IT processes are being transformed. The day when silos within IT organizations implemented various levels of IT automation based on various capabilities of platforms is starting to give way to a more comprehensive approach. The real challenge now is figuring out how to achieve that goal with the least amount of reasonable disruption to the culture of the IT organization as possible.

    — Mike Vizard

  • Enterprise Infrastructure:  Adapt or Face Extinction

    Enterprise Infrastructure: Adapt or Face Extinction

    In my previous blog, I explored how new ways of working—DevOps, Agile, cloud and startup thinking—have brought in a tectonic shift in the ways of working of enterprises. For infrastructure leadership and management, this is nothing short of a perfect storm that they need to navigate.

    While these new ways have impacted every aspect of technology including development, testing and project management, infrastructure and operations have remained the last bastions of traditional thinking, practices and approaches. Even with the rapid rise of DevOps practices in the recent years, we have just seen pockets of change in the infrastructure space, be it adoption of infrastructure-as-code practice, cloud in its numerous variants (private, public or hybrid) or containers and cloud-native technologies. But these changes all fall short of an enterprise-scale change that matters. What is missing is a systemic view of infrastructure as a value stream and transformation that ventures beyond the skin-deep changes limited to a few front-end digital capabilities.

    Infrastructure Transformation on the Horizon

    However, this is changing now; one by one, the barriers to infrastructure agility are breaking down. To put it simply, there are four dimensions of this change, based on various enterprise transformation initiatives that I have been involved over the years

    Radical new Operating Models

    New operating models are emerging to meet the business demand for infrastructure agility. There are primarily five patterns or a combination that enterprise are espousing in the operating model space:

    1. Shared service: This typically involves applying lean, value-stream mapping and Kanban techniques—in simple terms, the emphasis is on transparency, business-aligned prioritization of work and limiting work in progress.
    2. Responsive shared service: In this model, specific infrastructure members are “seconded” to application squads for more responsive service. However, there are limits to secondment model, in the ability to scale beyond a few iconic programs of work.
    3. Cross-skilling: This model involves infrastructure and application team members learning skills across each other’s disciplines with the goal of making delivery teams self-reliant.
    4. Disrupting with cloud: As the name suggests, enterprises are disrupting their own traditional infrastructure capabilities by aggressively pursuing private, public and hybrid cloud capabilities.
    5. Insourcing: Increasingly, there is a trend to insource responsive cloud and DevOps-based services to near-shore locations. “Almost twice as many CEOs are intent on building up in-house technology and digital capabilities as those plan on outsourcing it (57 percent and 29 percent, respectively),” according to Gartner’s survey of CEOs in 2017.

    Reimagining the Legacy Technology Stack

    Legacy systems based on technologies such as the AS400 or mainframes have been the bedrocks of technology for decades, but they also have been blamed for constraining agility. Many organizations have realized that replacing legacy systems with open system stacks is not an easy feat. Consider the fact that IBM continues to report an increase in mainframe sales over the last few years, including Q4 2017. This points to the fact that legacy will be part of the enterprise landscape for years to come—as such, incumbents need to be able to leverage the legacy stack to compete with digital challengers who are unencumbered by similar technology constraints.

    However, it is not all somber. There is a new wave of optimism driven by old guards, including CA and IBM, and new, including Compuware and ARCAD, that are bringing modern engineering practices such as continuous integrationcontinuous delivery (CI/CD), automated code analysis, virtualization, lightweight integration and test automation to these platforms. These new practices not only give these systems a new lease on life, but they also enable modern enterprise systems to be built iterative and incrementally—and not be handicapped by legacy constraints anymore.

    Intelligent Enterprise Resource Planning Software

    ERP software such as SAP/R3 are the backbone of many enterprises across industries. Historically, ERP software products have not kept up to speed with modern engineering practices and flexible architecture, which are fundamental to agility. The good news is that the ERP landscape is changing as product vendors are embracing cloud and API-led integration—IDC calls this “intelligent ERP” or “i-ERP.” Consider this: In 2025, SAP/R3, the largest ERP product in use, will no longer be supported officially, and enterprise planning programs (albeit, in a waterfall way) will move to SAP HANA Enterprise Cloud, the company’s new generation ERP platform.

    Culture and People

    Years of the drumbeat of Lean, Agile and DevOps ways is yielding results, especially in those organizations that see this as a people change as much as technology change. People in the infrastructure world are changing  from operating being behind a queue toward being customer-focused, collaborative and value-seeking. Organizations need to address the structures that restrained it from moving forward on the journey. Traditional organizational structures don’t account for team strengths, nor do they give everyone fair input in regards to overall direction. Rather, structures should be set up that allow managers to empower teams instead of teams living to carry out management demands.

    Ultimately, the key to creating agile and responsive infrastructure in organizations starts at the top, from the CXOs who need to realize the scale of change and inspire their teams on the need for change—or face extinction.

    — Aditya Vadaganadam

  • DevOps Chat: The CEO’s View with Derek Langone, XebiaLabs

    DevOps Chat: The CEO’s View with Derek Langone, XebiaLabs

    This DevOps Chat features “the CEO’s view” as seen by XebiaLabs CEO, Derek Langone. Derek is one of my personal favorite CEOs in the DevOps space because he is very articulate, to the point and sharp. I think all of these characteristics come through in this DevOps Chat. As CEO of XebiaLabs, Derek is leading one of the leading companies helping transformations in enterprise DevOps. In this chat, Derek talks about with us about cloud and cloud migration.

    As usual, the streaming media of our conversation is below. The transcript of our conversation follows below that.

     Audio

    Transcript

    [su_pullquote align=”right”][su_custom_gallery source=”media: 122032″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Derek Langone
    Derek Langone has been the Chief Executive Officer of XebiaLabs, Inc. since April 21, 2015. Mr. Langone served an Executive Vice President of Global Sales at Telerik, Inc. since February 2014. Prior to Telerik, he served as the Chief Executive Officer of 5nine Software where, in less than a year, he significantly increased revenue, lead generation and conversion rates. He served as the Chief Executive Officer, President and Chief Operating Officer of SmartBear Software, Inc. (also known as AutomatedQA Corporation). He served as the President and Chief Operating Officer of SmartBear, Inc. He began his career on Wall Street focused on technology investing. For over 15 years, he has focused on building and scaling Technical Sales Organizations. Prior to SmartBear, he served as Vice President of Sales at Quest Software and IMCEDA Software. He held senior Sales Positions at Vality Technology, (now IBM), Embarcadero and SAP America. He is an Industry Veteran, has more than 15 years of expertise in cultivating enterprise IT and application development adoption. He has been a Director at XebiaLabs, Inc. since April 21, 2015. Mr. Langone holds a Bachelor’s Degree in Business Management from Boston University.[/su_pullquote]
    Alan Shimel: Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps chat.  Happy to be joined today on DevOps chat by Derek Langone, CEO of Xebia Labs.  Hey Derek, how are you

    Derek Langone: Alan, I’m excellent, thanks very much for having me today.

    Shimel: Thank you. Just a heads-up to our audience, I had been working on this for a long time. Derek’s agreed to be sort of a regular guest here on DevOps Chat and we’re looking forward to hearing from him, oh, maybe once a month or so on topics that are of interest to hopefully our whole audience so you know they’ll be around DevOps and related to technologies.

    So, this is the first one we’re doing and we were going to talk today a little bit about cloud and whether you already are a cloud customer or new to the cloud, how can DevOps and related technologies help you.

    But before we do, Derek, in case there’s anyone out there who maybe is not familiar with Xebia Labs, you want to give them a real quick kind of pitch on Xebia Labs and what you guys are doing?

    Langone: Sure, here’s the 30-second commercial. So, Xebia Labs is entirely focused on enterprise DevOps. We provide a software platform for large enterprises that encompasses three primary components, released orchestration so basically create your pipelines in our technology that are templated, repeatable, standardized, use our automated deployment engine which is a model-based agentless engine.

    And then lastly, we have a machine-learning and AI-oriented reporting engine that collects all the data associated with your journey from development to production. It allows you to report on that for things like compliance purposes, regulatory purposes, security, and just a good old-fashioned scorecard – am I going faster? Is my quality up? Are my customers happier?

    Shimel: Couldn’t have asked for more than that in 30 seconds, Derek, thanks. So, here’s the deal, we are approaching I think this year a threshold in cloud adoption where it’s something like 50 percent of enterprises will have significant infrastructure in the cloud, not just a toe in the water or an R&D project, but significant infrastructure in the cloud.
    And that’s big, right?That means half of all enterprises have a large investment in cloud. But it also means half, don’t, right? And that’s always the flip side of the coin. I want to talk today to both of these audiences but let’s first start with the half that already has, right?

    They’ve invested a lot time, a lot of money, probably a lot software or tools and personnel, but maybe they’re not getting everything they need out of their cloud deployment? How can DevOps help?

    Langone: Well, DevOps by principle is sort of an accelerate opportunity, right? And if you look at a cloud investment, it’s a similar value proposition that you don’t have the requirement to manage this infrastructure, you’ve got less administrative overhead, you’ve just got on-demand, scalable infrastructure. So, that’s all oriented around speed.

    The challenges we see with our customers that are generally large enterprises, the biggest banks, insurance companies, airlines, in the world represent our customer base. They’re moving aggressively to the cloud because it’s just generally less expensive and certainly much less administrative overhead.

    But the consequences, the applications they’re trying to get there are very complex and don’t necessarily lend themselves to moving to the cloud very neatly. And what I mean by that is if you use an example like a large bank might have a money transfer application, core to every business that’s a big financial institution.

    That application lives in many places; the back-end horsepower may be a mainframe, there’s referential databases that do some validation every time there’s a query. You’ve got distributed architecture, maybe a containerized front end that gives you your mobile banking access and things like that.

    Moving all of that to the cloud is not simple, it really requires an incredible amount of orchestration, some very sophisticated deployment functionality. And we see most of our customers when we get engaged, them trying to do that with either the simple tools that come with the cloud platform providers, you know, the out-of-the-box Amazon or Azure tool portfolio.

    Or in most cases, just using the good old- fashioned, using extremely talented valuable developers to write tons of scripts to try to move these components around and shift them to the cloud. Neither of those initiatives are generally successful.

    Shimel: And I think you just hit it, Derek. Those are the two ends of the dumbbell if you will, right? One is to use the vanilla tools that the cloud providers give you and not to bang anyone but AWS is notorious for this, right?

    They give you 60 percent of the functionality at a really low, low price of some of the best __ tools but it comes bundled. Or you go the other way, right, just totally customize the heck out of things, which is not scalable usually, nor repeatable.

    Langone: No, it’s not, that’s the challenge. And just to hit those two ends of the dumb-bell as you said, the tools that come with the cloud providers, I mean, look, they’re sort of minimalistic by nature because it’s not the core business that they’re trying to provide. They’re infrastructure providers, they’re really not deployment technologists, right?

    So they’re gonna give you a little bit to get some basic applications there but anything complex is really gonna fall down. And like you said, the other side of it is, and the more traditional approach, is just using your engineering assets to write a ton of scripts to provision infrastructure, to migrate applications, to request instances.

    You know, it’s just an incredible amount of plumbing code that gets written that is super low-value and basically comes at the expense of much higher value activities that those engineers could be participating in, things like building new features and fixing bugs and just basically delivering more customer value.

    Shimel: And with that approach, Derek, to me it’s always been, well, what happens next month when I have to do this again? I’m gonna rewrite all the scripts, waste all that time? It just doesn’t make sense. But you hit on this with your opening, the reality is that most of these organizations who may already have significant infrastructure in the cloud are not totally in the public cloud certainly.

    They still do have mainframes, they have stuff in the closet, they have stuff in the data center. They’re living in a hybrid world, right, Derek? And so for whatever reason, and I’ve heard this from numerous, they hate the idea of using one tool for their public cloud stuff, one tool for their on-print stuff, one tool for their private cloud. They want one throat to choke, right? They want one tool.

    Langone: Well, I think they want one platform that can kind of account for the migration and IT landscape that they are going through, right?

    Shimel: Yes.

    Derek Langone:And that’s sort of what we’ve tried to build at Xebia Labs. We work with the legacy infrastructure and give you velocity, repeatability, standardization for your mainframe deployments in the exact same way that we will accelerate your journey to containers and leveraging Kubernetes and Docker as well as, you know, getting onto what is generally hybrid cloud infrastructure.

    We definitely see large organizations leveraging things like Amazon but in most cases, they’ve got some combination of a data-center cloud that they’ve got under their own control, as well as the sort of less mission-critical applications or the things that don’t represent the family jewels if you will in true public cloud infrastructure.

    And when I talked to CIOs in these organizations about their aggressive shift to the cloud, they look at me and say, look, we’re moving to the cloud with a lot of new development and some of the less mission-critical applications but the five apps that we run the bank on are gonna be running on mainframes five years from now.

    That’s not changing. We can’t break them up into micro-services and they don’t lend themselves to refactoring. We’re gonna continue to just add, you know, additional workload front ends but for the most part, they’re gonna stay intact. And that just represents I think the reality in enterprises.

    Shimel: And that is dead on the reality. And I just want to make sure we’re talking about tools like Xebia actually give these organizations the ability to use one platform across these multiple infrastructures.

    Langone: Yeah, I mean, look, I don’t want to just plug our platform because there’s others out there, there’s others out there, but at the end of the day, yes, what we’ve tried to do is basically build the technology that can accommodate the mission-critical requirements of a large enterprise. So, not only have we baked in the ability to deploy any technology from any starting point to any destination including public cloud, private cloud, hybrid, containers, you name it, right?

    We’ve also baked in all of the things that enterprises need to account for, like the compliance steps, the security steps, the who did what and when to the software reporting, so that all of these standards are met if you’re migrating to infrastructure that’s off of your own premises.

    None of those business requirements go away. In fact, in most cases, they get a little bit more stringent as the security team start to understand that if you’re gonna move applications outside of the firewall of the organization, then we need to put even more validation steps and security procedures in place.

    And again, if you’re doing this manually with engineers, they need to script for all of that activity and maintain it every time there’s a slight change in the application.

    It just becomes 50 percent of an engineer’s day managing these scripts that were built to move applications around when they could be using that 50 percent of their day to do things that are much, much more interesting for them and much more valuable to the organization.

    Shimel: Sure, I mean, and again, we’re not tooting Xebia’s horn here but you know what, Derek, from a manager-executive point of view maybe listening to this, knowing that there are tools like that that will allow them to go across these different infrastructures, single platform, is important. I mean, that was always one of the big inhibitors.

    Langone: No, you’re absolutely right, and look, what we’re tried to build into our platform is this templated approach. We have a model-based architecture, it’s agentless so you create templates and every single application that you have to move from development to production follows one of maybe three or four templates.

    And we’re talking 3 to 4 templates account for 500 different applications, whereas the alternative is you’re basically hand-scripting 500 different paths to production. So it’s much easier to maintain, it’s centralized, it’s controlled, there’s reporting, there’s visibility, there’s sort of all the things that you need to be able to score your process for migrating applications, whether it be to the cloud, the containers, or just frankly, to an existing data center.

    So, that’s really an important consideration. The other piece to consider, and again, a place where we’ve put a lot focus in our platform is leveraging what you’re doing already. So, we are a part of the process but you’ve got provisioning tools, like Puppet and Chef, you’ve got service ticketing, like Service Now or Gira, Jenkins on the CI side.

    A lot of technologies are required to move applications from one destination to the next, so we integrate with all that infrastructure that’s already running right out of the box, and we basically allow you to pick best-of-breed components so that you’re not locked into one specific vendor. And that’s been a lot of the feedback that we get from our particularly big financial services customers.

    They like the fact that if they want to switch cloud providers on the fly and move from Amazon to Rat Space or from Rat Space to Azure, they can do that with changing one configuration file in our product rather than having to rescript everything from scratch to reach a new destination.

    So, it really comes down to you avoid vendor lock-in, but when you want to make a pivot, that pivot in our technology and our platform takes five minutes versus months of scripting. 

    Shimel: Months, exactly. So, Derek, let’s make our own pivot, let’s talk about the other 50 percent of companies that aren’t moving major infrastructure to the cloud, or big parts of their infrastructure to the cloud. Let’s first of all say should they? Should they feel they’re getting left behind? Is it fatal to their business? What’s your feeling?

    Langone: You know, I think every IT organization makes choices that line up to the business objectives of their firm. I wouldn’t say that the shift to cloud is mandatory. There’s certainly a strong value proposition associated with it. It’s very, very expensive to keep technology infrastructure fresh. That’s always been the issue.

    You could build the data center but then, you know, 18 months later, all the technology in there is sort of out of rev, right? So you’re forced to buy it over and over and over again versus the cloud providers. You’re certainly paying the rental fee and that rental fee can be steep but you’ve always got state-of-the-art infrastructure to work against, and that’s just a very compelling argument.

    The other pieces, the administrative element goes away so there’s less people required to maintain it because it’s getting maintained for you. But the majority of our customers are moving to the cloud but for specific reasons and with specific applications, right? They’re not just wholesale-lifting their entire application portfolio to the cloud because it’s just not practical.

    So in the cases of customers that are still on premise, and that’s still the majority of large enterprises, I am not at all a cloud-denier. People are moving there and moving there aggressively, but when you look at large enterprises, I think your number was 50 percent are using and 50 percent are not.

    My on the ground sort of feeling is it’s less than 50 percent that are aggressively using the cloud for many different reasons, not the least of which are just security concern that still sort of haunt these large organizations. But the fact is anywhere your applications reside, right now DevOps is a good investment.

    Being able to increase the velocity at which you can build technology and deliver value through software to your end users is sort of a fundamental requirement nowadays in order to stay competitive in your own given space.

    So, we help with velocity, like I said earlier, on mainframes distributed technology, legacy systems, building a repeatable standardized release and deployment process with all the reporting that you’d expect to be able to identify where you’ve got areas of friction that can be remedied.

    So, we sort of approach with the same – our approach is the exact same whether it’s a legacy application or a nimble application that’s being written in containers to run in cloud infrastructure.
    The templates are the same, the mechanics of how you release and deploy those applications is the exact same.

    So, the beauty of our platform becomes anybody can use it, it’s understood, it’s centrally managed and it scales infinitely versus writing code which just is difficult and impossible to maintain over time. 

    Shimel: Sure. So, Derek, you brought an interesting point up though and it was one that I wanted to hit on. And that is, look, for those who are just moving to cloud, right, there’s a choice to be made. Do I take my inherited legacy, not so much infrastructure as much as my legacy stack and just port this existing stuff to the cloud?

    Or do I really just bite the bullet in Greenfield, right? Like, my stuff hasn’t been built on containers, maybe it wasn’t even built on hypervisors and virtualizations – who knows? But you know what, if I’m gonna move to the cloud, the heck with it, I might as well containerize and take advantage of micro-services and all of this.

    But my goodness, that’s such a major, you know, throwing out babies with bathwater potential. What’s your advice to companies faced with do I just port my existing architecture, or do I go for broke in more ways than one and adopt the new stuff?

    Langone: Yeah, I’ll tell you, in my experience, and I wouldn’t want to give advice ’cause every company sort of has to line up against their business objectives. But what I will tell you, what we see most often is people threading the needle, right? Basically taking these monolithic applications and starting to build components of those applications in containers on sort of more nimble infrastructure.

    You know, a good example, as I mentioned earlier, a money transfer app, right? That’s a legacy application that’s been running in a big bank for 25 years. The horsepower on the back end that does all the computations is still a couple of IBM mainframes strung together. But you’ve got referential databases that are living in distributed architecture maybe onsite, maybe offsite in the cloud somewhere.

    You’ve got containerized and mobile-centric front ends so you could do your mobile banking, web banking, things like that. So, that application lives in a lot of different places and you can, with some small investment in more nimble development platforms and infrastructure on the front end, really energize and give life to these legacy applications.

    So, there isn’t a need to move the entire thing to the cloud. You can move components of it to the cloud, but again, when you do that, you get the benefit of the faster architecture and the ability to deliver value through your software more frequently for your end users.

    But the consequences, getting those components to the cloud becomes really complex and that’s where our technology really lends a hand, where we understand those complexities, we’ve accounted for them already.

    We do this sort of every day for the biggest banks in the world so you can take advantage of not having to reinvent the wheel and still get the benefit of the velocity that you’re looking for and the flexibility you’re looking for in these applications that need to live on.

    Shimel: You know what, Derek, that was one of the best examples of hybrid cloud that I’ve heard. I think for too many people they think of hybrid cloud, they say, well, this application lives in the cloud, this application lives on my mainframe, this application lives in a data-center, my payroll system is here, my HR system is there, but that’s not really hybrid cloud.

    Hybrid cloud is we have one application that different elements and components of it live in this hybrid world, right?

    Langone: Yes, I think there’s a misunderstanding that you’re either in the cloud or you’re not, right? The fact is, I think, that in most cases, most of our clients, you’ve sort of got one leg in both places.

    Shimel: Yeah, at the same time.

    Langone: You’ve got I’m somewhat in the cloud, and they make decisions relative to where can I get the biggest bang for my buck? Some of this application needs to be in the cloud for a bunch of reasons so let’s do it, and then we’re just not gonna forklift up our mainframe apps and dump them on AWS. It’s a cost-ineffective strategy; we’d have to refactor them like crazy.

    So, yeah, and I don’t think that trend is gonna change, right? There’s certainly a bunch of Greenfield development that’s going on, containerized apps micro-services, just cloud-centric development. And that’s great but that represents generally less than ten percent of the application portfolio in a large organization.

    And that’s the fact is that 90 percent of the apps have been around for five years or longer, and those apps are critical to the business.
    And they, over time, will migrate to the cloud and be refactored and rewritten.

    But it’s just too big of an endeavor for any large company to take a 1000-application portfolio and say, hey, this year we’re going to rewrite all these for the cloud. I mean, I don’t know anybody that’s doing that.

    Shimel: I would hope not. Hey, Derek, I think I told you before we started, time goes really quick here. We’re at maybe 25 minutes now, we were supposed to be 15, so we could probably talk about this all day, but we’ll continue the conversation on our next visit with you.

    But, hey, this was great, Derek Langone, CEO, Xebia Labs. Thanks for being our guest on DevOps Chat today and we hope to have you back real soon here.

    Langone: Thanks, Alan, talk to you soon.

    Shimel: All right, this is Alan Shimel for devopsy.kinsta.cloud, we’ll see you soon on another DevOps Chat.

    — Alan Shimel

  • IBM Think 2018: DevOps Integrated Everywhere

    IBM Think 2018: DevOps Integrated Everywhere

    With the onset of conference season I have been running a bit ragged. But something I noticed at the recent IBM Think 2018 Conference really needs to be called to attention: DevOps was still a prominent theme at IBM Think. But instead of having a dedicated DevOps theater or DevOps section of the show floor, DevOps was integrated into everything—all the various flavors of cloud (hybrid, Cloud Private, public), development, apps, even cognitive and AI … all were integrated with DevOps. I, for one, think this is as it should be.

    It is a sign of DevOps maturity, I think, that instead of DevOps being called out as some special beast—a unicorn, even—it is more just the way things get done. I had a chance to talk to many different people on the show floor, attend several track sessions (which were also done on the show floor—much better than having to go into separate rooms) and, as usual, interviewed more than a few people for our DevOpsTV YouTube channel. While all of them were excited by various announcements and exhibits, it seemed as though DevOps was part of all of them.

    DevOps integrated everywhere

    Two great examples of this are my interview with DevOps Playbook author Sanjeev Sharma:

    and my interview with Mark Howell and James McLeod of Lloyds

    Another really interesting discussion was how DevOps plays into IBM’s Cloud Private offering. Cloud Private is a Kubernetes-based architecture. We spoke with Andy Gower, product marketing manager for Cloud Private. As you would expect with a Kubernetes-based offering, DevOps is right in the middle of things.

    This was the theme time and time again at IBM Think 2018. DevOps was not concentrated in any one area; it was everywhere. Even in the quantum computing area, which I will admit was cool as can be.

    Mainframes also were all about DevOps. This is not new for the IBM Enterprise Systems team. They have really led the way with DevOps and mainframes.

    This was the first year for IBM Think 2018. It represents the merging of several different IBM conferences into one large one. I enjoyed the format and look forward to future IBM Think events.

    Also a note on keynotes: The tone for IBM Think was set by IBM CEO Ginny Rometty. It was plain that IBM as a whole is focused on some key technologies and initiatives. Among these were cognitive and AI, cloud and disruptive technologies on the near horizon such as quantum computing.

    There was a lot going on at IBM Think 2018, check out the YouTube channel to get more of our coverage.

    — Alan Shimel

  • A Saner Way to Build a DevOps Cloud

    A Saner Way to Build a DevOps Cloud

    There’s a popular definition of insanity: doing the same thing repeatedly but expecting different results. Yet, too many enterprises implementing digital services and apps in the cloud fail to heed this warning as they turn to point-to-point integration of their cloud components. In the process, they’re introducing tremendous complexity that looks eerily similar to the point-to-point application integration headaches companies faced before the concept of centralized mediation emerged some 15 years ago.

    Consider the scope of the challenge. A cloud deployment can contain 30-plus product components that need to be integrated to run together smoothly. At any time, an update to one of these products can break processes that rely on the other components. DevOps compounds the complexity, since teams need to ensure consistency across development, test and production environments. It may be fine for a dedicated DevOps team in the group to handle these environments when there’s just one project. However, as the number of applications utilizing cloud technology grows, it is expensive to have DevOps teams build each environment as a wild west project.

    Standardizing on Stacks

    A saner approach is to implement a cloud architecture that standardizes on stack-level operations. Implemented effectively, a stack serves as the reference architecture for all the components and automation needed to create a replica of your production environment. This “full stack” is in essence much like the configuration management database (CMDB) once thought to be the holy grail of enterprises.

    With a meta-description of your full stack for a service or application in place, it becomes possible to deploy identical copies for development, test and production, as well as automate DevOps across your application. This ability to duplicate stacks removes the barriers to, for example, deploying multiple test environments or multiple copies of the stack for security compliance or disaster recovery.

    The stack is an important concept for understanding how you are building and running your software. If something goes wrong, it also provides visibility into what is running, how it was deployed and what the problem might be, facilitating the ability to systematically correct the problem and deploy the fix to all needed replicas. Developing a stack concept also lets you track applications—plus the associated tools, development practices, cloud practices and vulnerabilities—across your organization, providing a critical step in the maturity of your enterprise’s cloud development.

    Standardizing on stacks enables development teams to focus on building new applications and services rather than spending six to 18 months implementing the cloud architecture. At the same time, different groups may require different capabilities, making a one-stack-fits all-approach impractical. The middle ground is to provide a set of “sanctioned stacks” or a portal for configuring stacks, which limits options to products that have been pretested to confirm they work together.

    Structuring DevOps Cloud Stacks

    A DevOps cloud architecture will consist of at least two main stacks: the core infrastructure stack and the DevOps stack. Increasingly, these stacks run in containers, which provide two key advantages: a greater agility through the ability to spin up apps faster and more cost-effective use of resources through operating system-level virtualization.

    The core infrastructure stack supports a service or application with services that ensure security, reliability and scalability. It includes cloud infrastructure, such as networking and storage, which may be handled by a public cloud platform or a private cloud, along with container-specific functionality, such as a Docker runtime with orchestration provided by Docker Swarm or Kubernetes. The stack also has a layer for handling performance and management, including networking, load balancing, service directory, log management, monitoring, backup and recovery and vulnerability scanning, which are supported by a range of different products.

    At the top of the core infrastructure stack is an application layer or stack that includes development tools, such as Java Stack or Node.js Stack. More advanced application stacks will go beyond tools to provide the blueprints for migrating from monolithic apps to containers and microservices.

    The DevOps stack supports continuous integration/continuous deployment (CI/CD). It runs across multiple infrastructure stacks and codifies the tools, processes and procedures to test and deploy or rollback changes to the infrastructure stacks. It typically incorporates DevOps instructions using Chef or Terraform, Ansible, Puppet, Swarm, Helm and half a dozen other tools. Because automated testing is critical, DevOps stacks also should include tools that help with development, building, integration, automated testing. Popular options include WireMock and Selenium for testing web apps and services, Artillery for performance testing and Blackduck or Clare for security testing.

    Additionally, there are key functions within the DevOps cloud platform that extend across development, test and production stacks. These include security, a catalog of stack templates, a registry for certified containers and usage data collection to apply predictive analytics for performance and cost optimization.

    Introducing Stack Automation

    Enterprises implementing a DevOps-enabled cloud need to consider automating as many processes as possible, particularly for large installations. For example, a bank may have 150 to 200 groups developing applications. With each app requiring environments for development, test and production, that means anywhere from 450 to 600 deployed stacks to maintain.

    Significantly, updating stack components needs to be a coordinated process. It’s not enough to rely on automated upgrades and security patching provided by individual product vendors. That’s because if the upgrade or patch changes something that affects a component in the enterprise’s stack, the vendor probably doesn’t know that and this may break the stack.

    Automating stack functions in a coordinated way is best accomplished using an intelligent, centralized “command center” portal that incorporates a central orchestration hub. This eliminates much of the complexity associated with manually running multiple scripts by performing whole operations on a stack. Whether your organization builds it or you use a third-party solution, this hub for automating the execution of scripts should incorporate an orchestration engine, visual map, domain model, proactive monitoring and cost analysis.

    Importantly, a command center incorporating an automation hub lets you take advantage of improved visibility provided by stacks to track and report on cloud costs. Moreover, you can capitalize on “spot” instances—costing five to 10 times less than persistent instances—by using the hub to automatically handle periodic interruptions and redeploy the components taken away.

    Through automated stacks, your organization now has a sane way to cut the complexity of implementing a DevOps cloud while providing an agile platform to support your development team’s innovations.

    — John Mathon

  • Barracuda Networks Survey: DevSecOps Is Hard

    Barracuda Networks Survey: DevSecOps Is Hard

    Organizations that have adopted DevSecOps processes may be making progress when it comes to improving cybersecurity, but it’s far from easy. A survey of 618 IT decision-makers conducted by Dimensional Research on behalf of Barracuda Networks, a provider of IT security software and appliances, finds half have adopted either DevOps, DevSecOps or a continuous integration/continuous development (CI/CD) platform. A full 93 percent of those IT decision-makers said they faced challenges integrating security into those practices.

    Top challenges cited include: Existing security technologies don’t integrate with application development environments (63 percent), application developers are not comfortable with security (48 percent), and security processes have not evolved (48 percent).

    Much of the frustration can be tied to reliance on firewalls that don’t feature application programming interfaces (APIs) or are natively integrated with a public cloud, said Tim Jefferson, vice president for public cloud at Barracuda Networks. Each cloud service provider has a unique environment that requires providers of IT security software to write code that natively integrates with that platform. IT organizations can’t simply cut and paste security controls created for on-premises IT environments mainly because the cloud provider has already implemented its own controls at the infrastructure level. The IT organizations need to develop their own controls for the application layer, each of which then must be layered on top of the controls put in place by the cloud service provider.

    In the absence of those capabilities, developers get frustrated because a firewall running on a virtual machine on a public cloud presents them with a graphical user interface (GUI) rather than an API. Developers in the age of the cloud are not going to engage with any technology that they can’t programmatically invoke via an API, Jefferson said.

    Not surprisingly then, the survey finds the most requested firewall capabilities requested are cloud-native integration (74 percent), ease of deployment and configuration by cloud developers (59 percent), ability to regulate traffic flows between on-premises IT environments and public clouds (56 percent) and distributed policy enforcement (53 percent).

    Because many IT professionals don’t have these capabilities many of them conclude on-premises IT environment are more secure than public clouds. More than half the respondents (56 percent) say on-premises cybersecurity is still superior to a public cloud. Clearly, there a lot of technical and emotional factors that go into those assessments, but regardless of the truth, perception remains reality.

    Regardless of the approach taken, however, organizations that deploy firewalls in the cloud are expecting to pay for those services on a consumption basis, which doesn’t always align with taking a firewall running on virtual machine and then deploying it on a public cloud.

    Jefferson said that as cybersecurity in the age of the cloud continues to mature, expectations are rising regarding the capabilities a firewall should be able to provide—especially when it comes to controlling the flow of traffic coming into and out of a public cloud.

    Obviously, anything to do with DevSecOps these days is still evolving. But whatever the cybersecurity future holds the relationship between on-premises and cloud security is far more nuanced than many appreciate.

    — Mike Vizard