CloudCenter customers just got a big boost with Custom Service management capabilities in version 3.2.5. Now, you can address unique application requirements, package and leverage domain expertise, and help minimize application lockin to a specific cloud environment.
CloudCenter comes pre-populated with more than 30 Application Services. App developers or cloud admins can drag and drop cache, load balancer, web server, messaging, and database services from the Services Palette, and then combine those services with other application components and publish to the CliQr marketplace for broad consumption.
Now, CloudCenter admins can clone and modify existing out-of-box application services or create new custom services from scratch. In either case, they can add them to the Services Pallet, set a consumption price for each, and specify which users or user groups can use them build and publish applications.
The “Full Stack” Developer
First a bit about the problem CliQr solves. Without wading into the debate about whether a full stack developer is a unicorn, or trying prove or disprove the urban legend that Facebook only hires full stack developers, suffice it to say that the “Full stack” is a lot more complicated than it used to be. (Maybe Facebook only hired full stack developers when the stack was less complicated?)
Anyway, both application developers and senior engineers should focus on what they are good at. Most likely they have deep expertise at one layer of the stack. And an approach that modularizes and componentizes the stack helps optimize the efficiency and effectiveness of those with both general knowledge across the full stack and “Rock star” level skills in one area.
CliQr abstracts at three levels
CliQr has a unique cloud application management platform that works on-prem and across cloud environments. It abstracts the application from the various application middleware services that support the application, and also abstracts that full stack (application and middleware) from the specifics of each deployment environment.
1 – Application Service – Application services are the building blocks that are combined to form the foundation for multiple applications. Those with domain expertise (web server, database service, load balancer etc.) can recommend standard application services, or create Custom Services that deploy a fairly general service for use across multiple application stacks.
For example, the resident Jetty expert can choose to support the standard Jetty service that comes out of box, or create a custom Jetty Service and bake in corporate standards or best practices (version, initialization, configuration etc.) for everyone who uses that service. Both developers and operations can confidently use these building block services with only a summary level of expertise.
2 – Application – Those with application expertise (drug discovery environment, payroll) can combine Application Services and build and publish full application stacks in the CliQr Application Marketplace.
Application specific deployment steps or configuration actions that go beyond what is built into underlying application services are added to the application profile. With this abstraction, application services can be generic maximizing reusability. Applications can control more specific deployment of the generic application service.
The abstraction of the application from the underlying building block application services saves a lot of non-value add maintenance and configuration work as various layers of the stack are upgraded over time.
3 – Environment – The application stack is also abstracted from the deployment environment. CliQr CloudCenter deploys application services and applications across multiple cloud environments by having the CloudCenter Orchestrator handle environment specific API calls and service nuances. The application stack and underlying application services are not modified to specific cloud environments.
For all enterprise IT organizations that aren’t Facebook, this three tier approach breaks apart the “Full stack”, gives experts the opportunity to add value in their area of expertise, and allows everyone else to leverage their good work.
Some typical uses:
- Modify a standard application service, to use a Hardened OS version that is needed for certain types of applications. For example all applications that involve patient data, or are part of a point of sale application may require a specific hardened version of RHEL.
- Modify a standard application service, with different port configuration or different set of domain certificates.
- Create a custom service – that is a requirement for certain applications, but isn’t available in CliQr out of box services pallet.
This approach accelerates application deployment time. It also reduces ongoing management and maintenance costs as each tier of the stack may be upgraded on a different schedule.
How to create a Custom Service
Now admins will find a new “Custom Service” tab where they can add a new service. They can describe the service, select all the appropriate OS images, and if appropriate set a cost for service consumers.
Figure 1- Add a New Service
The other half of this new feature is lifecycle management as seen in Figure 2. Through the simple user interface, admins can easily model service lifecycle events, install, start, stop as well as actions during upgrade or graceful deprovisioning.
Figure 2 – Define Service Lifecycle Actions
This type of feature is what you’d expect with an application centric cloud management platform. A “define once, use anywhere” platform needs capability to componentize the full stack, create custom services where needed, give domain experts the ability to codify their expertise at each tier of the stack, and also not lock applications into a specific cloud.
New Custom Service capabilities in CloudCenter 3.2.5 makes this possible. Based on customer requests and initial demand, this will be a very popular feature with CliQr customers.