Service Mesh - Cloud Control

So today I started toying around with a new tool I think would be awesome for the work I do with enterprise organizations and their cloud environments. The tool is called ServiceMesh.

With ServiceMesh I can create a new instance in any of a number of clouds, build the instance from a script, and deploy applications to it. OR I can design a blueprint for an environment (LAMP with separate instances for different work (disk, DB & compute let’s say)) and use that blueprint to easily create new editions to an environment when an app sees an infrastructure need change, or if I want to blueprint an app’s environment to rubber-stamp the next level up (say when building QA after building & testing DEV.)

ServiceMesh is a really exciting tool and not the only one of its kind, but certainly one of the most interesting from my perspective.

One of my current clients is building a workflow system whereby their internal customers who wish to see their app deployed go through a decision-making process “quiz” of sorts determining their infrastructure and environment needs. Along the path, certain key questions determine whether their environment should be built in AWS, Azure, or an OpenStack environment managed by RackSpace.

The answers essentially determine where ServiceMesh is going to send the build request for the app’s environment. That alone is pretty cool to see in operation. But that’s not all.

ServiceMesh also has scripting functionality built-in. This kind of functionality will mostly be used during the build process. However, it’s even handier when used to help automate deployments and push upgrades out for WebLogic, WebSphere App Server, JBoss, MQ, FUSE, or other 3rd party platform tools. The mere implication that these kinds of tools have the ability to build, deploy, update, and destroy environments is a massive promise of efficiency for today’s infrastructure engineers.