Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Mattermost today launched Mattermost Cloud, a software-as-a-service (SaaS) platform for managing DevOps workflows using pre-built playbooks that comes integrated with a wide variety of third-party developer tools.
Chandar Venkataraman, executive vice president and chief product officer for Mattermost, said Mattermost Cloud enables IT teams to take advantage of a single-tenant DevOps platform that they don’t have to maintain in a way that forces developers to give up their preferred tools.
In contrast, other DevOps platforms that are managed as a service require developers to make use of a narrow range of tools provided by the platform vendor, he said.
Built on top of an instance of Kubernetes, the single-tenant capability also ensures that any data or artifacts stored on the platform remain private. The Mattermost Cloud Professional edition, available today, provides a full set of collaboration and DevOps features, while the Mattermost Cloud Enterprise edition, currently in beta, adds dedicated single-tenant cloud infrastructure, enterprise-grade secure network topology and strict data residency options.
By building the platform on Kubernetes, he noted, it becomes much easier to scale the Mattermost Cloud platform up and down as required.
Mattermost Cloud is essentially a DevOps command center that provides single pane-of-glass pre-built workflows that address most common DevOps processes. IT teams can add their own custom workflows as their DevOps processes mature, Venkataraman said, noting plugins for Jira, Opsgenie, PagerDuty, GitLab, GitHub and Jenkins are already available.
The cloud platform also includes a pre-built best-practices incident management playbook to enable DevOps teams to address issues as they arise rather than trying to resolve them using a legacy ticket-based approach to IT service management (ITSM), he added.
Venkataraman noted Mattermost doesn’t expect DevOps processes to supplant existing ITSM platforms based on ITIL-frameworks. However, many DevOps teams are looking for ways to resolve incidents within their existing workflows using, for example, a messaging platform versus a workflow designed for IT support staff.
In general, Venkataraman said, many organizations that are relatively new to DevOps don’t want to manage the underlying platform. At the same time, he noted there are also many IT organizations that want to allocate more resources to writing code versus managing a DevOps platform.
Each IT organization will need to decide when it makes sense to stand up their own platform for managing DevOps workflows and playbooks instead of building and maintaining their own control plane. Many of those IT teams are already making use of artifact repositories and continuous integration/continuous delivery (CI/CD) platforms that are accessed via the cloud, so a DevOps command center is only one more logical extension.
Just as importantly, isolating the DevOps command center from the rest of the underlying DevOps platforms ultimately makes it easier for IT teams to switch out tools and platforms over time as they best see fit. The challenge now may be in finding a way to decouple workflows that are deeply intertwined with a specific platform.
