devopsy.kinsta.cloud

Author: Mike Vizard

  • Survey: Not Much Compliance Progress in DevOps World

    Survey: Not Much Compliance Progress in DevOps World

    A survey of 1,500 customers conducted by Chef illustrates the lacking state of DevSecOps in the enterprise today, finding that nearly three-quarters of IT organizations still manually assess whether applications comply with various regulations before being deployed to production. Worse yet, half the respondents also manually remediate any issue once it arrives, which takes days or sometimes weeks to accomplish.

    In fact, according to the survey, more than half the respondents (52 percent) have applied automation to fewer than 25 percent of the servers they manage.

    Manual processes conspire to make IT organizations less agile at a time when the pressure from the business to deploy applications and associated updates faster has never been higher.

    Julian Dunn, director of product marketing for Chef, said compliance—much like security—needs to move much further left into the DevOps process as a subset of DevSecOps. After all, most compliance regulations are trying to set a bare minimum standard for IT security.

    The first line of IT security defense is detecting vulnerabilities before they go into a production environment. Whenever a vulnerability gets exploited, most organizations incur the initial injury. But after the cybercriminals have come and gone the regulators show up, demanding explanations. Those explanations usually don’t do much to mitigate the fines and penalties that are assessed, especially in highly regulated industries.

    Chef has been making the case for applying the same constructs it developed to automate configurations to compliance for some time. Most compliance issues typically stem from one setting or another that wasn’t configured properly, noted Dunn.

    The issue is that most compliance officers inside organizations are unaware that many of these issues could be automatically resolved, and DevOps teams are too focused on daily operational issues to make anyone aware of what’s now possible. But now that DevSecOps is becoming more mainstream, many of the individuals involved are starting to realize they are dealing with the same issues time and again, said Dunn.

    Dunn added that, much like IT security professionals, compliance professionals who typically reside in a risk-management function need to be brought into the application development process earlier, but without slowing down the pace of application development. However, given the current level of manual remediation occurring, earlier participation mostly likely will reduce the level of manual work occurring right before the application is supposed to be going into production.

    When it comes to compliance, most IT organizations are their own worst enemy. Compliance requirements typically are spelled out in arcane language in documents that not many read, much less comprehend. Asking developers to make sense of those requirements is not the best use of their time. Besides, few of them would interpret the requirements correctly. An automated approach to compliance is not only going to create a better application, but it also should reduce a lot of unnecessary aggravation for all concerned.

    — Mike Vizard

  • Applitools Advances AI Testing of User Interfaces

    Applitools Advances AI Testing of User Interfaces

    Given the number of platforms applications now need to be able to run on, it’s little wonder that mistakes and errors that compromise the graphical experience of the end user appear all too regularly in production. Keeping up with all the various nuances of each platform is just too much to ask of the average developer. To even those odds, Applitools has developed Applitools Eyes, the latest release of which extends the reach and scope of user interface testing in addition to providing expanded third-party tool integrations, enhanced analytics and team collaboration tools.

    Version 10 of Applitools Eyes extends the company’s mission to employ artificial intelligence (AI) to enable organizations to consistently deliver a better application experience, said James Lamberti, chief marketing officer for Applitools.

    Testing of graphical user interfaces (GUIs) is becoming more complex because the front-end of each application is increasingly made multiple microservices. Any change to the application requires developers to test each individual microservice and associated content that gets rendered on any number of platform. Applitools Eyes automates that testing process in a way that enables organizations to deliver applications faster without compromising the user (UX) experience, said Lamberti.

    “AI makes it easier to identify where the UX is broken,” he said.

    Much of the AI focus on DevOps these days tends to be on automating back-end testing. But Lamberti said it’s already been proven AI has a significant role to play in automating UI testing as well. To spur awareness of that requirement, Applitools also announced an Application Visual Management initiative, an attempt to create a new category of tools for visually testing graphical user interfaces.

    Lamberti noted that functional tests today are automated, and the visual elements of an application are still conducted manually. That invariably leads to errors that conspire to impede application release cycles no matter how much time and effort may have been invested in continuous integration and continuous delivery (CI/CD) processes.

    Applitools claims to have already executed almost 100 million visual tests using its visual AI engine to analyze billions of individual UX elements. Version 10 of Applitools Eyes adds improvements to the Layout Algorithm for dynamic content use cases as well as dashboards to make it easier to discover the root cause of a UI issue. Development teams, for example, can review visual test execution status and baseline status updates, bugs squashed and coverage levels specific to individual tasks and test assignments.

    Bugs discovered by Applitool Eyes can now also be programmed to automatically generate a ticket with a bug tracking tool such as Jira.

    In addition, integration with collaboration tools from Micro Focus as well as Slack is planned for March.

    Developers are often especially challenged when it comes to application usability. Application Visual Management may provide a much-needed framework for capturing UI best practices that would enable developers to avoid the same issue over and over by, for example, enabling a testing tool to make specific recommendations about where to place specific functions on a screen. There may even come a day when AI builds the application. In the meantime, when it comes to building applications end users will actually embrace regularly, most developers need all the help they can get.

    — Mike Vizard

  • Oracle Unveils Autonomous Cloud Service

    Oracle Unveils Autonomous Cloud Service

    Oracle today unfurled at an Oracle CloudWorld event what it describes as a completely autonomous cloud service the company will manage primarily on behalf of application developers.

    The Oracle Autonomous Cloud Platform is a managed service that makes extensive use of machine and deep learning algorithms across instances of Oracle software that can invoked on a public cloud or deployed in an on-premises IT environment, said Amit Zavery, executive vice president of product development for Oracle Cloud Platform.

    “We’re taking away all the day-to-day management issues,” Zavery said.

    The Oracle Autonomous Cloud Platform builds on the Autonomous Database service launched last year. This latest service essentially puts all the responsibility for managing IT operations on Oracle, which is relying on a major investment in machine learning algorithms to automate DevOps processes.

    The implications of that capability are profound for IT organizations, many of which Zavery said now will be able to shift more resources over to developing and maintaining applications. At a time when more organizations are focusing on digital business transformation, those organizations need to be able to free up resources to focus in application development, he said.

    Amit Zavery, Oracle

    Examples of how Oracle envisions the transformation of both DevOps and DevSecOps include chatbots that can be interacted with using natural language processing to automate repetitive tasks to automatically identifying and remediating security issues in code within the context of a continuous integration/continuous development (CI/CD) deployment. There are also controls to prevent data leaks across structured and unstructured data repositories, along with built-in security monitoring tools.

    Other capabilities include an ability to create data flows with automated data lake and data prep pipeline creation for ingesting both stream and batch-oriented data, as well as automating the integration of various on-premises and software-as-a-service (SaaS) applications.

    Advanced analytics tools span everything from automated data discovery and preparation to visualization tools for displaying trends.

    Oracle may have come late to the cloud computing game, but clearly it intends to make up lost ground by infusing higher levels of automation into cloud services that rivals don’t yet provide. Most cloud service providers are headed in the same general direction as Oracle. But the scope of automation being provided by Oracle, spanning both a public cloud and on-premises IT environments, is unprecedented.

    In many ways that level of automation may represent an existential threat to a larger number of IT operations professionals. At the same time, it presents an opportunity. IT professionals should be able to spend more time adding true value to the business instead of having all their time and energy consumed by merely keeping the proverbial lights on in the data center.

    Of course, it may take a while for most organizations to make a transition to a single stack of integrated hardware and software provided by a single vendor. Most organizations have decades worth of IT infrastructure consisting of databases, middleware, virtual machines, servers and storage systems all from different vendors. Even if organizations decided the time had come to rationalize those investments in favor of a suite of managed cloud services, it would take several years to make that transition.

    In addition, many organizations would also still need to evaluate the total cost of acquiring and managing IT infrastructure over several years versus contracting for services over the same period of time.

    Regardless of the path a company chooses, IT operations is about to be transformer utterly by artificial intelligence (AI)-infused automaton.

    — Mike Vizard

  • HashiCorp Adds Terraform Workflow Tools for IT Ops

    HashiCorp Adds Terraform Workflow Tools for IT Ops

    HashiCorp this week moved to templatize automating IT operations by making it easier to share Terraform configuration files which make it simpler to programmatically invoke infrastructure that exposes application programming interfaces (APIs) without knowing how to code.

    Available in an on-premises edition or as a software-as-a-service (SaaS) application, HashiCorp Terraform Enterprise is intended for use by IT operations teams. A HashiCorp Terraform Enterprise Module Registry function has been added to enable IT operations teams to implement a publish-and-subscribe mechanism for Terraform configuration files.

    Company CTO Armon Dadgar said HashiCorp Terraform Enterprise is designed to enable IT operations teams to respond faster to requests from developers for infrastructure resources without requiring them to develop programming skills. It’s unlikely developers working for traditional enterprise IT organizations will be taking over control of IT infrastructure anytime soon, he said, and Hashicorp Terraform Enterprise allows IT organizations to inject a level of agility into their workflow processes without requiring IT operations teams to completely re-engineer existing processes.

    The HashiCorp Terraform Enterprise Module Registry extends that capability further by making it easier for IT operations professionals who have developed expertise employing declarative Terraform configuration files to share those files with other members of the team, Dadgar said.

    Related Content:

    HashiCorp Terraform Enterprise Empowers IT Administrators

    Operations Management Puts the ‘Ops’ in DevOps

    At the same time, IT operations teams that want to build workflow applications on HashiCorp Terraform Enterprise can use a set of application programming interfaces (APIs) that HashiCorp has exposed. In addition, the company has revamped the user interface for Terraform—workspaces now can be created by combining Terraform files into modular components that can be assigned to specific IT teams. Permissions to access are provided via support for the secure access markup language (SAML) as well as the Sentinel policy management software developed by HashiCorp.

    The HashiCorp approach to automating IT operations strikes at the core of the DevOps debate in the enterprise. While web-scale companies typically can afford to hire IT professionals with programming skills to manage IT infrastructure, the average enterprise IT organization still relies on administrators to manage servers, storage and networking. Not only are IT administrators in short supply, most of them would not be in IT operations if they knew how to program—they’d be writing and testing applications instead.

    Rival approaches to automating the management of IT infrastructure, despite being around for years, have yet to gain mainstream acceptance, mainly because they require programming skills. Declarative approaches allow IT infrastructure to be managed as code still, with less resistance from IT operations teams that tend to be more comfortable employing declarative tools. In fact, there’s long been a chicken-and-egg debate over the degree to which the transition to modern DevOps practices requires organizations to acquire new tools first or vice versa. The HashiCorp approach strikes a middle ground by providing tools that enable IT operations teams to first become more efficient, which ultimately should enable them to implement new processes that often is much less disruptive to the existing IT culture.

    — Mike Vizard

  • IBM Looks Toward Cloud Unification

    IBM Looks Toward Cloud Unification

    Now that IBM is achieving some critical mass in the cloud, the next major focus will be unifying the management of disparate cloud services.

    IBM recently reported revenue of $79.1 billion for its most recent fiscal year, a decline of 1 percent year over year. But within that revenue mix, Big Blue also reported that cloud revenue now accounts for $17 billion, an increase of 24 percent year over year. All told, cloud services now accounts for 21 percent of IBM’s revenues, and the company’s “as-a-service” annual exit run rate was $10.3 billion, up 24 percent year over year. Those revenues include $9.3 billion delivered as a service and $7.8 billion for hardware, software and services.

    IBM may not be in the same league as public cloud service providers such as Amazon Web Services (AWS). But the company is in a unique position to unify the management of public and private cloud computing services, said Rob Thomas, general manager for IBM Analytics.

    Most organizations are implementing a multicloud computing strategy. That decision creates significant data management issues that need to be addressed by a more holistic approach to DevOps, Thomas said, noting that IBM is betting that being able to consistently port applications and data between clouds will emerge as major theme in the enterprise in 2018 that it is in a unique position to address.

    Rob Thomas, IBM

    Today, most organizations are managing each cloud service they engage in isolation. But, rather than decreasing costs, each cloud service engaged brings with it additional overhead. In fact, each new cloud service conspires to increase the total cost of IT ownership for IT organizations as they move to master the tools required to support it. Despite that issue, the inherent business and IT agility cloud services provide are too compelling to ignore. Thomas said the result will be a continued proliferation of cloud services that enterprise IT organizations will want to unify under a common data strategy that also extends to their legacy IT environments. Otherwise, there ends up being too much duplication of data and effort, he said.

    Much of the effort to centralize the management of multiple cloud begins and ends with sound DevOps practices. The need to centralize the management of multiple clouds goes well beyond simply achieving cost synergies. Managing public and private clouds alongside legacy applications won’t be sustainable unless organizations modernize how they build, deploy, update and manage applications, Thomas said. Given the fact that each of those applications in turn increasingly will be made up of multiple microservices, modernizing the way the data that each of those services can access by extension also becomes critical, Thomas noted.

    Of all the major cloud services providers, IBM is the only one focused on providing the tools and services needed to help IT organizations make that transition at the level of scale required, Thomas said, noting that, in addition to a raft of DevOps and data management tools IBM provides, the company has extended the DevOps managed services it provides to enable organizations to accelerate that transition.

    It’s too early to say just yet how the rise of multicloud computing will transform enterprise IT. But it’s clear the days when the local data center was the primary focus of enterprise IT are long over.

    — Mike Vizard

  • Subtree Rises to Microservices Data Management Challenge

    Subtree Rises to Microservices Data Management Challenge

    Fresh off raising $10 million in funding, Subtree has emerged from stealth to launch a service based on the dotmesh open source utility for microservices to enable DevOps teams to capture the entire state of applications.

    Dotmesh captures application state as a series of units known as datadots, and captures and tracks all versions of all the databases, files and other data in any application based on a microservices architecture, said Subtree CEO Luke Marsden. That utility exposes a command line interface (CLI) through which data about the application captured by dotmesh can be collected, and a dotmesh server component stores all the datadots.

    Marsden said the dotmesh utility can be applied to any microservice regardless of what runtime or class of containers is being employed.

    Once captured, that information can be shared via a dothub repository managed as a service by Subtree. Marsden said there’s no requirement to use dothub as the repository because the dotmesh utility is available as open source code. But dothub is designed to be the most efficient way to share data about the state of microservices applications distributed across the enterprise, said Marsden.

    The goal, he said, is to provide the equivalent of the service for source code that Github makes available and designed specifically for sharing information about the state of microservices applications deployed in production environments.

    Related Content:

    Red Hat Survey Sees Broad Adoption of Microservices

    Flexera Extends Scope of Open Source Scanning Tools

    In effect, the combination of dotmesh and dothub creates a new type of service mesh for tracking and managing data, Marsden said.

    He noted that microservices create a significant data management challenge because best practices call for each one to have access to its own database. Managing applications made up of microservices that are tethered to larger numbers of databases makes it difficult to ascertain the state of an application built on top of multiple microservices, Marsden said. If one microservice should fail, for example, the DevOps team often has to stop the application because of all the dependencies between them. However, dotmesh utilities tethered to the dothub service via application programming interfaces (APIs) make it easier to determine the relationship between all those microservices and their data sources, he said.

    Subtree envisions DevOps teams employing both dotmesh and dothub together to create workflows that specifically address data management in a microservice environment. The degree to which IT organizations are currently challenged by data management varies according to the number of microservices they are attempting to manage. At some point, however, just about every IT organization that embraces microservices will need to address how the data attached to each microservice gets managed, especially within the context of a larger stateful application.

    The impact of a lack of data management that is designed for microservices is already being felt. Many organizations are unable to effectively test a microservices-based application because the tests don’t accurately reflect the true size and scope of the application.

    Pricing for the dothub service is $10 per month for 5GB of storage. There’s also a free tier of storage provided for up to 1GB of storage.

    It’s still not quite clear who inside IT organizations will manage the data being accessed by what inevitably will become thousands of microservices. But it is clear that currently, the tools for managing all that data are, for the most part, nonexistent.

    — Mike Vizard

  • GitLab Acquires Gemnasium to Advance DevSecOps

    GitLab Acquires Gemnasium to Advance DevSecOps

    GitlLab, as part of its effort to extend the reach of its DevOps platform into the realm of security, has acquired Gemnasium, a provider of tools to mitigate vulnerabilities in open source code.

    The goal is to incorporate the IT security tools Gemnasium has developed within a single software development lifecycle (SDLC) platform, said GitLab CEO Sid Sijbrandij.

    Because both companies relied on the Ruby on Rails programming language to write their respective applications, integration of the Gemnasium software into the core GitLab platform will be easier, he said.

    Sijbrandij noted a growing number of organizations are looking to extend the reach and scope of their DevOps processes to include security, also known as DevSecOps. The pitfall they face will be trying to integrate disparate DevOps and security management tools. GitLab is moving to integrate both classes of tools within a single SDLC environment that will make it easier for organizations to make the transition to DevSecOps.

    GitLab, Sijbrandij said, already had been moving down that path prior to the acquisition of Gemnasium. Previous releases of the company’s platform have included support for static application security testing (SAST), dynamic application security yesting (DAST) and container scanning. The separate software that Gemnasium developed will no longer be supported after May 15.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    CA Technologies Survey Uncovers DevSecOps Challenges

    Longer term, Sijbrandij said GitLab is moving toward being able to host its software on top of the open source Kubernetes container orchestration platform. That approach will make it easier to automate deployment of its software on multiple public clouds and on-premises IT environments using a zero-touch provisioning framework.

    Ultimately, embracing DevSecOps should result in more secure applications. But just as importantly, IT organizations need to be able to adroitly remediate software vulnerabilities whenever required. There’s a direct correlation between how long malware goes undiscovered and the amount of potential damage caused. It’s not uncommon these days for malware to go undetected for months; as such, eliminating as many of the vulnerabilities that cybercriminals routinely exploit must be a much higher priority for developers.

    Achieving that goal, however, is as much about process as it is tooling. Most developers are not security experts. Conversely, IT security experts typically know little about building applications. Developers are under more pressure than ever to roll out applications faster. But that pressure also often leads to them to short-shrift testing processes that otherwise would have uncovered a vulnerability. Organizations that embrace DevSecOps are trying to address security issues earlier in the process because fixing them once an application is in production is expensive. At the same time, however, no one wants to slow down the speed at which applications are being developed. That creates something of a chicken-and-egg dilemma for IT leaders trying to determine degree to which new tooling will foster changes to processes and culture, or whether they need to accomplish the latter before investing in new tooling.

    There’s always been a natural tension between developers and IT security teams. The hope is that by making them all part of the same DevSecOps team, that tension is either eliminated or sharply reduced. That outcome stands a better chance of being achieved when everyone involved is employing a common framework.

    — Mike Vizard

  • CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees Acquires Codeship to Extend CI/CD Reach

    CloudBees today signaled its DevOps ambitions to extend well beyond the Jenkins continuous integration/continuous deployment (CI/CD) platform by acquiring Codeship, a provider of a CI/CD platform that is delivered as a software-as-a-service (SaaS) application.

    The decision to acquire Codeship is being driven by the need to engage smaller DevOps teams that don’t have the time or expertise required to set up on-premises instances of Jenkins, said CloudBees CEO Sacha Labourey.

    Codeship today is being used by more than 100,000 developers spanning 2,400 customers. Many of those developers are working at smaller companies. But Labourey noted that small teams of developers inside larger companies also prefer to invoke a CI/CD platform as a service.

    “Different teams will decide to do different things in the same organization,” said Labourey.

    The Codeship platform is not based on Jenkins and there is no plan to rehost the Codeship service on Jenkins, says Laborey. Jenkins is designed to be highly customizable by the organization that employs it. The Codeship service is a highly opinionated instance of multitenant CI/CD platform that is designed to provide a turnkey experience capable of support lots of developers at once, explained Labourey.

    CloudBees will explore ways to bundle its core platform with the Codeship service for organizations that find themselves needing to deploy both a CI/CD platform on-premises in addition to a cloud service, he added.

    The acquisition of Codeship signals a wave of coming consolidation across the DevOps sector, Labourey said, predicting that over time, a much smaller number of companies will account for most of the DevOps software and services sold. Some will rise from the ranks of the pioneers of DevOps. Others will be the same companies that today dominate application lifecycle management (ALM) and software development lifecycle (SDLC) software in the enterprise. As DevOps continues to gain momentum in the enterprise, it’s now only a matter of time before legacy ALM and SDLC vendors are forced to modernize their portfolios by making acquisitions or partnering with companies such as CloudBees, he said.

    It’s too early to speculate how that consolidation might play out. But it’s clear the rise of microservices is about to force the DevOps issue in many enterprises. The rate at which DevOps processes have been adopted across enterprise has been uneven, but as organizations embrace microservices to build better applications faster, many will need to re-engineer their application development processes. There always will be monolithic enterprise applications that may be better-served by waterfall approaches to application development, but in time, the bulk of applications will be built employing microservices architectures that make it easier to update and manage applications employing modern DevOps best practices.

    How much those DevOps processes will be based on CI/CD platforms running in the cloud or on-premises is anybody’s guess. More than likely, most organizations will rely on a combination of both, depending on the size and scope of their efforts. Regardless of the approach, however, at a time when every company is becoming more aware of their dependency on software to compete, it will be those organizations that embrace DevOps processes best that will prosper at the expense of rivals.

    — Mike Vizard

  • IBM CTO Sees Bright Future for Java in 2018

    IBM CTO Sees Bright Future for Java in 2018

    Significant advances in microservices written in Java, as well as tighter coupling between Java applications and containers, are set to transform the way most organizations build and deploy Java applications by the end of the year.

    IBM Java CTO John Duimovich, as part of five Java predictions for 2018, noted that The Eclipse Foundation has taken over the development of MicroProfiles, a baseline platform definition that optimizes Enterprise Java for a microservices architectures, and the EE4J project, an effort to create standard application programming interfaces (API) for Java runtime. This, he said, will make it much easier to build next-generation Java applications using programming tools based on the Eclipse integrated development environment (IDE).

    In some instances, those applications will take the form of a microservice that gets deployed using a Java runtime. In other instances, those applications will be deployed using containers such as Docker. Duimovich said it’s not only a matter of time before containers and runtimes including Java will become more tightly coupled. That will result in more consistent memory management and easier wiring between Java constructs and containers. For example, Java applications will be able to determine automatically how much memory is available to any given container. That’s critical because the reason most containers fail is they exceed available memory limits, he said.

    Duimovich also predicted that Kotlin will be the next big variant of Java to be adopted in the enterprise. Concise coding syntax plus interoperability with other instances of Java have already made it popular for many developers. Now that Kotlin can be used to build applications for devices running Android, this year will see much broader usage of Kotlin to build greenfield applications, Duimovich said. However, he added, it won’t be too long before other variants of Java start employing similar concepts.

    Related Content:

    Hopes and Fails in DevOps 2017

    DevOps Chat: Microservices & Containers – Mastering the Replatforming of the IT Infrastructure

    Other major Java predictions for 2018, Duimovich noted, will be optimization of Java runtimes for serverless computing frameworks and a more regular six-month release cycle for incorporating new functions in Java. The rise of serverless computing frameworks will also result in more Java applications being deployed on public and private cloud services, he said.

    Duimovich noted that, from a practical perspective, a Java runtime is simply another type of container. The challenge facing DevOps teams will be determining when and where to use Docker containers instead of traditional Java runtime to deliver an application. Whatever the outcome, it’s unlikely any IT organization will standardize on one approach to the exclusion of all others.

    The increased rate of Java innovation can be attributed to an Oracle decision made last fall to place Java Enterprise Edition under the auspices of the Eclipse Foundation, said Duimovich. At the same time, IBM moved to open-source its implementation of a Java virtual machine. This has resulted in something of a Java Renaissance, as more developers and organizations are contributing expertise via the Eclipse Foundation.

    There’s no shortage of programming language options available these days. But in many cases, if Java is able to build modern applications, then it’s probable many developers will continue to use Java rather than take the time to learn something new.

    — Mike Vizard

  • Mirantis CEO Charts Hybrid Cloud Path Forward

    Mirantis CEO Charts Hybrid Cloud Path Forward

    Adrian Ionel is back at the helm of Mirantis as CEO at a time when the shift to hybrid cloud computing is tantalizingly close to being an everyday IT reality.

    Adrian Ionel, Mirantis CEO

    Ionel is one of the original co-founders of Mirantis, which provides a curated instance of OpenStack and Kubernetes cluster software alongside a suite of services to manage them on behalf of a customer. Ionel replaces Alex Freeland, who will remain on the board of directors of Mirantis.

    The decision to shift leaders is being driven by the need for Mirantis to grow more rapidly at a time when IT organizations soon will be moving toward unifying the management of multiple clouds, said Ionel.

    While Mirantis owes its existence to OpenStack, the company has been rapidly developing Kubernetes expertise that is at the heart of a recently unfurled managed hybrid cloud computing service. Ionel said the rise of Kubernetes provides a unique opportunity to manage private and public cloud services based on Kubernetes via a central control plane.

    The challenge Mirantis will face in achieving that goal is the reluctance IT organizations historically have shown when it comes relinquishing control over their IT environments to a third party. In addition, an already fierce number of rival managed service providers (MSPs) also are moving to embrace Kubernetes.

    Ionel said most IT organizations underestimate the complexity of managing multiple clouds. As more of them come to that realization, the number of organizations looking to rely more on external expertise to deploy modern microservices-based applications on Kubernetes should increase substantially. To facilitate that transition, Mirantis has crafted a hybrid Kubernetes service that can be invoked programmatically by developers. A crucial factor driving that decision will be increased awareness of the perils of being locked into a specific public cloud service provider. In fact, Ionel noted that many IT organizations today underestimate how easy it is to become entangled by proprietary application programming interfaces (APIs) on a public cloud service such as Amazon Web Services (AWS).

    For the immediate future Ionel said Mirantis expects to see most instances of Kubernetes to be deployed on top of virtual infrastructure. Use of Kubernetes on bare-metal systems is confined largely to application development, he said. But as Kubernetes continues to mature, Ionel noted it’s only a matter of time before IT organizations will be deploying more instances of Kubernetes running on both virtual machines and bare-metal servers. That, of course, will further add to the complexity that needs to be navigated.

    Ionel said rivals underestimate just how healthy the current Mirantis business is as use of OpenStack continues to increase. AT&T, for example, has now deployed more than 10,000 nodes employing instances of OpenStack provided by Mirantis, he said.

    New CEOs don’t usually magically transform a company by their mere presence. But in the case of Mirantis, the opportunity for Ionel to turn potential in real growth is higher, for no other reason than he doesn’t have to first learn how the company operates.

    — Mike Vizard