Netflix, Tinder, and IMDB are using cloud services as part of complex composite topologies, and so can you with CloudCenter’s ability to model any service using our newly expanded application service types.
AWS’ DynamoDB outage back in September of 2015 might not sound like a huge deal, but when Netflix, Tinder, IMDB and many others sites went dark, it quickly showed the number of companies using cloud-based services along side their own. CloudCenter is flexible enough to allow you to use these types of cloud-provided services along side more traditional VM-based application services. This means that applications are free to use a service that needs a VM deployed and managed, a consolidated service, or a cloud provided one.
As of CloudCenter 4.3, there are now three types of services:
Virtual Machine, with CliQr Agent (available previously): used when a service requires infrastructure provisioned to run. Adding the CliQr agent allows CloudCenter to gather information and run scripts on the service’s operating system. An example could be Oracle Fusion Middleware where you want it to be deployed and managed by CloudCenter.
Virtual Machine, without CliQr Agent: used when a service is delivered from a vendor as part of a locked-down, black box appliance. An example might be an F5 load balancer appliance that has been deployed outside of CloudCenter and therefore should not be managed by it.
External Service, no virtual machine launched: used in cases where an application needs to do something to make a service available, but it doesn’t require infrastructure to be deployed. Examples would be notifying a centralized load balancer that new machines are being activated or connecting to a cloud supplied service.
Configuring Services through Virtual Machines
The service types of Virtual machine with and without CliQr agent work fairly in much the same way.
- An Image abstraction is created in the CloudCenter UI
- The cloud image (AMI, vSphere template, etc) is then mapped to that image to represent what should be provisioned
- A new Service is created, selecting the image just created
- If this is a VM with no Cliqr agent, that’s it—the image will be deployed when the service is requested from an application
- If this is a VM with a CliQr agent, you have the option to configure further scripts from the service screen. The image will be deployed when the service is requested by an application and then the specified commands will be run
How Services through Virtual Machine Work
The application profile holds all the information about which services are required. When the application profile gets sent to a local-to-cloud CloudCenter Orchestrator, the Orchestrator makes API calls directly to the target cloud to provision the required infrastructure and then run any commands, if appropriate.
Configuring Services through External Services
The External service type works differently than the other types, in that only a command is run and no image/VM is provisioned. All that’s required is a link to the commands or scripts the service should run.
The Mighty External Service and how it works
It’s worth talking about how the External Service functionality works so you can truly appreciate it—it is, after all, the newest and most technically interesting of the three service types.
Once a service is created in CloudCenter and added to an application it can be deployed, just as any other service. When it’s deployed though, something interesting happens:
- On the CloudCenter Orchestrator (or in some cases a separate machine) a Docker container is created, matching the OS of the Orchestrator machine.
- Commands from within the CloudCenter service are run. These commands can call out to an API, a command line interface—whatever you need to get the service created
- Once the command is run successfully, the container is destroyed
- An inventory object is created for the newly deployed service in context of the application, meaning that when the application is destroyed, so is the service.
Two Things That Make CloudCenter’s External Services Stand Apart
- Security: Why go through all the trouble of running things within a Docker container? Security! Imagine allowing users to run command on a machine that is core to a business critical site where an unintended script can bring the site down. By using an ephemeral container, all commands are confined to the container and the state is refreshed after every use.
- Ease of use: Other products talk about “Anything as a Service” (XaaS) and while it’s technically true, you have to jump through a lot of hoops to get there. You might have to learn a separate orchestrator tool and then orchestrate the management of the service to make it do anything more than “fire and forget”. CloudCenter takes care of all that inventory management for you. All you have to do is tell it what to call.
Make sure to check back for my next post where I’ll be providing a walk through on how to create an External Service to make a DynamoDB instance in Amazon Web Services.