(c)iStock.com/barcin

By Jason Deck, vice president of strategic development, Logicworks

When your infrastructure is code, the art of developing great software applications and building great infrastructure systems start to look similar.

Many of the best practices of software development — continuous integration, versioning, integration testing — are now the best practices of systems engineers. In enterprises that have aggressively virtualised data centres or moved to the public cloud, servers, switches, and hypervisors are now strings and brackets in JSON.

The scripts that spin up a server (instance) or configure a network can be standardised, modified over time, and reused. These scripts are essentially software applications that build infrastructure and are maintained much like a piece of software. They are versioned in GitHub and engineers patch the scripts or containers, not the hardware, and test those scripts again and again on multiple projects until they are perfected.

Cloud MSPs build up a library of automation scripts over time, but it is not a plug and play system

Providers that build and manage cloud infrastructure for clients accumulate entire libraries of these scripts. These libraries are a cloud MSP’s core intellectual property, and what differentiates one MSP from another. And this software is a main reason why enterprises need MSPs in the first place.

Why automation software?

Engineers can easily be trained to perform the basics of cloud management manually. Anyone can launch an EC2 instance from the AWS console. But when you need to deploy an instance that has fully configured security groups, subnets, databases, etc. and is HIPAA compliant, it becomes harder to find and/or train this talent. Even fewer enterprises have the in-house staff capable of writing scripts that help developers or systems staff who can launch instances automatically.

It would take multiple, senior-level level automation engineers working for months to develop a script that spins up perfectly configured instances for a variety of applications from scratch. If cloud MSPs can run a script (created beforehand) to spin up a new environment in days, that is a huge value add for enterprises.

Why not just train engineers on the lower-level manual cloud configuration tasks? Because enterprises do not just want to turn manual data centre work into manual cloud console work. An infrastructure as code transition is also usually accompanied by a transition to a DevOps culture, part of which usually means helping developers to work faster. Business leaders do not want developers to wait for systems engineers to push new features. They want more experimentation and faster product lifecycles. Ideally, they want developers to have tools at their fingertips to deploy code without having to worry about the infrastructure at all.

Infrastructure automation makes a DevOps transition possible. Developers can get their code tested and in production in minutes. Automation empowers cost-effective experimentation. Tools like containerisation create a common language for both systems engineers and developers to communicate.

One caveat, however: cloud MSPs build up a library of automation scripts over time, but it is not a plug and play system. Various automation scripts have to be customised for the packages required to run those applications, and they need to be tweaked to meet the unique security demands of each client. That is just in the effort to get the infrastructure build-out process automated; a great cloud MSP will also orchestrate multiple automated systems across multiple environments, and these usually require a combination of custom jobs and cloud orchestration software.

Cloud orchestration

As we have discussed previously, infrastructure orchestration is a key missing element on many cloud projects. CTOs and CIOs struggle to coordinate projects across hundreds of data centres and multiple clouds, and compliance officers struggle to monitor and audit them. Lengthy governance processes are getting cut, but enterprises still have serious compliance and governance obligations that now must be met in even more complex systems.

Unfortunately, cloud orchestration software is not yet mature. MSPs are the only vendors that have developed true cloud orchestration software through a combination of custom programming and third party APIs.

Here is an example of one such application. When an engineer logs into their MSP-provided cloud software, they can:

• See a complete overview of what is running across multiple environments
• Monitor cloud costs (through a 3rd party application like CloudCheckr)
• Monitor security alerts
• Spin up new instances in a few clicks (perhaps using Docker)
• File repair/upgrade tickets
• See status of current tickets
• Read Wikis
• Pay bills
• Integrate with existing security monitoring software, antivirus, and logging systems, and even with monitoring of their on-premises virtualised environments.  

Developing such systems requires quite a bit of complex integration and software development. This is usually custom per-client. But this level of transparency across environments is exactly what enterprises need.

Next-generation cloud software

The services AWS and Google offer are constantly changing. AWS has released hundreds of major updates to its services in 2015. It is experimenting in mobile development software. It has created services that make complex cloud automation tasks easier.

We predict the next wave of software development will include the services that an MSP currently performs more or less manually, and that have limited or no software options on the market

Every six months, AWS releases services that have the potential to disrupt entire software industries. At the same time, AWS Marketplace has become the destination for cloud ISVs developing cloud-based software, including automation and other functions.

In other words, there is a fertile and rapidly shifting cloud ecosystem that appears to be swallowing up traditional software market channels. This has allowed newcomers to shape entire industries and forced old players to adapt.

We predict that the next wave of software development will include the services that an MSP currently performs more or less manually, and that have limited or no software options on the market including the following:

• Predictive, big data-crunching software that determines you are going to need more infrastructure before something like AWS CloudWatch knows
• Fully automated backups and disaster recovery
• Automated destructive testing that empirically proves the infrastructure is highly available, currently done manually with something like Netflix’s Simian Army
• More sophisticated multi-cloud integration software between AWS and other clouds
• More sophisticated hybrid cloud identity and access management, currently managed somewhat manually with AWS IAM and Active Directory
• More Docker-like packages of code with “built in” compliance, like HIPAA and PCI

Together, cloud automation and orchestration software have the potential to drastically reduce the effort in migrating to the cloud, reduce the risk of human error, guarantee that developers maintain compliance, and increase speed of development. Cloud MSPs will become software companies as well as curators of a dizzyingly complex software marketplace, and help enterprises put the latest cloud innovations to work.

The post Why Cloud MSPs Are Software Companies appeared first on Gathering Clouds.